• 0 Posts
  • 7 Comments
Joined 5 months ago
cake
Cake day: January 23rd, 2024

help-circle


  • mke@lemmy.worldtomemes@lemmy.worldgoddamnit
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    4 days ago

    I think I know what you’re talking about, and I think you might have misunderstood a few things. I’ll explain my point and I’d appreciate it if you could confirm later whether it helped, or if I’m the one who misunderstood you.

    “Saving as…” is, usually, just for setting the name of the file. The full filename, extension included. The extension is just another part of the name. It doesn’t define what rules the file’s contents actually follow. They’re for other purposes, such as helping your operating system know which software to use when opening each file. For example:

    User double clicks a .pdf System: Oh, I should try opening this in Adobe Acrobat.

    But that doesn’t mean the file is actually a PDF. You can change the extension of any file, and it won’t automatically be converted to that extension (unless a specific feature has been added to make that implicit conversion). You could give an executable a .pdf extension and your system might then try opening it in Acrobat. Of course, it won’t work—there’s no way the system could have automatically made that conversion for you.

    So you might wonder, why does your (fake) PNG—which is really just a webp with an incorrect extension—still work just fine? You can open it, view it, send it. What’s the trick?

    Thing is, the software that actually deals with those files doesn’t even need to care about the extension, it’s a lot smarter than that. These programs will use things like magic bytes to figure out what the file they’re handling really is and deal with it appropriately.

    So in this scenario, the user could save a webp file as PNG.

    funny cat.png (still a webp!)

    Then they might double click to open it.

    System: How do I open a .png again?

    • .webp -> try the image viewer
    • .jpeg -> try the image viewer
    • .png -> try the image viewer (there it is)

    And finally, the image viewer would correctly identify it as a webp image and display it normally.

    Image viewer: reading magic bytes… Image viewer: yeah, that’s a webp alright

    The user might then assume that, since everything works as expected, they properly converted their webp to a PNG. In reality, it’s all thanks to these programs, built upon decades of helping users just make things work. Same with Discord, Paint.NET, etc. Any decent software will handle files it’s meant to handle, even if they aren’t properly labeled.

    If you were to check the file contents though, using a tool like file, czkawka to find incorrect extensions, or even just checking image properties, it should still be identified as a webp.

    I didn’t try it myself as you said because, to my understanding of files and software, doing so made no sense. But again, do tell if I got something wrong or misinterpreted your comment.


  • mke@lemmy.worldtomemes@lemmy.worldgoddamnit
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    5 days ago

    Hey, thanks for the input. I’d like to read more about this, but I can’t seem to find anything related online. Anything else you could share?

    Just checking, you sure you’re not confusing fallback-to-another-format when the browser doesn’t support webp? Because that’s a bit of separate issue, and not a terribly relevant one since all major browsers have supported webp for a while now.


  • mke@lemmy.worldtomemes@lemmy.worldgoddamnit
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    2
    ·
    edit-2
    6 days ago

    Sorry, is this comment meant in jest? If not, could you explain what exactly you mean by “no need for a converter?”

    I’m pretty sure that’s not how it works. No actual file data conversion is happening when you do that unless you’re using additional tools e.g. browser extensions.


  • mke@lemmy.worldtomemes@lemmy.worldgoddamnit
    link
    fedilink
    English
    arrow-up
    102
    arrow-down
    6
    ·
    edit-2
    4 days ago

    Semi-related, I’m still salty about Google’s rejection of JPEG XL. I can’t help but remember this when webp discussion crops up, since Google were the ones who created it.

    Why care about JPEG XL?

    Because it seems very promising. source with details.

    Rejection?

    Google started working on JPEG XL support for chrome, then dropped it despite significant industry support. Apple is also in, by the way.

    Why do that?

    Don’t know, many possible reasons. In fairness, even Mozilla hasn’t decided to fully invest in it, and libjxl hasn’t defined a stable public API yet.

    That said, I don’t believe that’s the kind of issue that’d stop Google if they wanted to push something forward. They’d find a way, funding, helping development, something.

    And unfortunately for all of us, Google Chrome sort of… Immensely influences what the web is and will be. They can’t excuse themselves saying “they’ll work on it, if it gains traction” when them supporting anything is fundamental to it gaining traction in the first place.

    You’d have to believe Google is acting in good faith for the sake of the internet and its users. I don’t think I need to explain why that’s far from guaranteed and in many issues incredibly unlikely.

    Useless mini-rant

    I really need a single page with all this information I can link every time image standards in the web are mentioned. There’s stuff I’m leaving out because writing these comments takes some work, especially on a phone, and I’m kinda tired of doing it.

    I still hold hope for JPEG XL and that Google will cave at some point.