4 ms·

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 d

by 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.
      - a1369209993 4y ago
        > A jpeg straight from a camera is 'more lossless' than a downscaled 8-bit png that was created from it. Well there's your problem right there: PNGs don't come from cameras. PNGs come from image generation software that produces specific, discrete pixel values. Changing #555555 to #565656 in lossless image data is no more acceptable than changing "UUU" to "VVV" in lossless text data. Unfortunately, gzip et al don't perform well on image data, so different but still lossless compression algorithms are required.

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.
    - a1369209993 4y ago
      > A jpeg straight from a camera is 'more lossless' than a downscaled 8-bit png that was created from it. Well there's your problem right there: PNGs don't come from cameras. PNGs come from image generation software that produces specific, discrete pixel values. Changing #555555 to #565656 in lossless image data is no more acceptable than changing "UUU" to "VVV" in lossless text data. Unfortunately, gzip et al don't perform well on image data, so different but still lossless compression algorithms are required.