6 ms·

Good riddance to bad rubbish. PNG 'optimizers' that change the image data rather than the compression and framing settings were bad enough; the last thing we ne

by a1369209993 4y ago

Good riddance to bad rubbish. PNG 'optimizers' that change the image data rather than the compression and framing settings were bad enough; the last thing we need is to displace JPG/PNG entirely with a format that doesn't distinguish[0] between lossy and lossless compression in the first place. 0: No, embedded metadata doesn't count; the same format is being used for two incompatible kinds of compression.

lifthrasiir 4y ago
Unfortunately, if the format supports at least lossless compression (i.e. able to represent all uniform range in the pixel domain with a reasonable compression rate, amortized) then there is no practical way to distinguish lossy compression from lossless compression. PNG -> JPEG -> PNG is a lossy compression but the resulting output is seemingly lossless while it isn't.
- a1369209993 4y ago
  Sufficiently badly behaved software can definitely still screw you over, but with separate formats you at least have a chance to notice that there's a problem during the PNG -> JPEG part of the process. Decoders like libpng will outright refuse to handle JPGs, image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". With JPEG XL, images can get switched to lossy mode silently, without breaking anything, and then back, also silently, also without breaking anything. JPEGXL -> JPEGXL -> JPEGXL is a lossy compression that doesn't give you any intermediate state where touching the images will loudly scream "something is wrong here"; you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image.
  - lifthrasiir 4y ago
    > image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". As you have noticed, the latter behavior is slowly becoming a norm even for user-facing applications (paint.net for example can handle them) because users have no idea how .png and .jpg can differ. And good JPEG encoders have made a visual inspection a lot harder. It's kinda futile. > you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image. I should note that, while this is hardly an ideal situation, generation loss in modern image formats is much harder to spot in the intended bits-per-pixel range. And JPEG XL is one of the best performing image formats in terms of generation loss, so repeated lossy compression is not a big issue for it.
    - a1369209993 4y ago
      > generation loss in modern image formats is much harder to spot As noted, things that make lossy compression more silent make the situation worse, not better. > As you have noticed, the latter behavior is slowly becoming a norm even for user-facing applications Yes, and that's a problem that should be fixed. JPEG XL instead makes things even worse than they already are. Hence good riddance to bad rubbish.
      - lifthrasiir 4y ago
        I believe the problem is fundamentally not solvable and maintaining a false dichotomy is bad for users. I can argue the same for, say, audio formats. Users have been trained to think that mp3/ogg are lossy and flac is lossless. Now flac streaming is a thing, but streaming services often give you flac files transcoded from an mp3 original, because that's all they've got. If you have spent a premium for using flac (oh, many do) you are screwed, but in reality users can't tell any difference anyway. So maybe the premium was pointless all the way and we should be less tolerant about technical lossy vs. lossless distinction. If you can here a compression artifact then it doesn't matter if it was apparently lossy or lossless.
        jonsneyers 4y ago
        Ultimately, 'real lossless' does not exist since all raster image data (or audio data) consists of quantized samples with a limited spatial (or temporal) resolution (and in case it was captured, as opposed to synthesized, there will be errors caused by the capturing process too). But as long as the precision is high enough to be indistinguishable by humans in the viewing conditions (or editing conditions) that matter to them, everything is fine. Whether that is achieved through lossless codecs (possibly used in near-lossless ways) or through lossy codecs is probably less important in practice. What matters is getting the workflow right to minimize generation loss and precision loss during authoring. If your workflow critically depends on assumptions like "png is lossless, jpeg is lossy", you should probably re-think your workflow. A jpeg straight from a camera is 'more lossless' than a downscaled 8-bit png that was created from it. Just going by file type to determine where in the workflow you are, is not a good strategy.

lifthrasiir 4y ago

Unfortunately, if the format supports at least lossless compression (i.e. able to represent all uniform range in the pixel domain with a reasonable compression rate, amortized) then there is no practical way to distinguish lossy compression from lossless compression. PNG -> JPEG -> PNG is a lossy compression but the resulting output is seemingly lossless while it isn't.

a1369209993 4y ago
Sufficiently badly behaved software can definitely still screw you over, but with separate formats you at least have a chance to notice that there's a problem during the PNG -> JPEG part of the process. Decoders like libpng will outright refuse to handle JPGs, image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". With JPEG XL, images can get switched to lossy mode silently, without breaking anything, and then back, also silently, also without breaking anything. JPEGXL -> JPEGXL -> JPEGXL is a lossy compression that doesn't give you any intermediate state where touching the images will loudly scream "something is wrong here"; you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image.
- lifthrasiir 4y ago
  > image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". As you have noticed, the latter behavior is slowly becoming a norm even for user-facing applications (paint.net for example can handle them) because users have no idea how .png and .jpg can differ. And good JPEG encoders have made a visual inspection a lot harder. It's kinda futile. > you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image. I should note that, while this is hardly an ideal situation, generation loss in modern image formats is much harder to spot in the intended bits-per-pixel range. And JPEG XL is one of the best performing image formats in terms of generation loss, so repeated lossy compression is not a big issue for it.
  - a1369209993 4y ago
    > generation loss in modern image formats is much harder to spot As noted, things that make lossy compression more silent make the situation worse, not better. > As you have noticed, the latter behavior is slowly becoming a norm even for user-facing applications Yes, and that's a problem that should be fixed. JPEG XL instead makes things even worse than they already are. Hence good riddance to bad rubbish.
    - lifthrasiir 4y ago
      I believe the problem is fundamentally not solvable and maintaining a false dichotomy is bad for users. I can argue the same for, say, audio formats. Users have been trained to think that mp3/ogg are lossy and flac is lossless. Now flac streaming is a thing, but streaming services often give you flac files transcoded from an mp3 original, because that's all they've got. If you have spent a premium for using flac (oh, many do) you are screwed, but in reality users can't tell any difference anyway. So maybe the premium was pointless all the way and we should be less tolerant about technical lossy vs. lossless distinction. If you can here a compression artifact then it doesn't matter if it was apparently lossy or lossless.
      - jonsneyers 4y ago
        Ultimately, 'real lossless' does not exist since all raster image data (or audio data) consists of quantized samples with a limited spatial (or temporal) resolution (and in case it was captured, as opposed to synthesized, there will be errors caused by the capturing process too). But as long as the precision is high enough to be indistinguishable by humans in the viewing conditions (or editing conditions) that matter to them, everything is fine. Whether that is achieved through lossless codecs (possibly used in near-lossless ways) or through lossy codecs is probably less important in practice. What matters is getting the workflow right to minimize generation loss and precision loss during authoring. If your workflow critically depends on assumptions like "png is lossless, jpeg is lossy", you should probably re-think your workflow. A jpeg straight from a camera is 'more lossless' than a downscaled 8-bit png that was created from it. Just going by file type to determine where in the workflow you are, is not a good strategy.