Progressive Decoding vs Lossy Encoding give different subjective quality

[FallingSnow]

Description

Regression downscaling decoding does not give results anywhere near downscaling lossy encoding.

Use Case

I would like to only serve the full resolution, lossless flif files so that people only need to do a partial request of ~7.3kB or so for 300x171 image. However, using regression decoding of, for example, ~7.3kB does not yield the same results as delivering a predownscaled ~7.3kB flif.

Test Case

Below I have included a test case I have made.

Original File

highRes.png 5146x2935 19MB

Setup

flif -e highRes.png highRes.flif

highRes.flif 5146x2935 12.4MB

Regression Downscaling + Decoding

Lossy decoding straight from a highres flif returns very poor results.

flif -d -q10 --fit=300x171 highRes.flif decoded.png

decoded.png 300x171 84.2kB

Downscaling + Lossy Encoding

However, if you downscale the original, then encode, and finally decode the encoded flif you get good quality.

gm convert -scale 300 highRes.png downscaled.png

downscaled.png 300x171 92.8kB

flif -e -Q10 downscaled.png encoded.flif

encoded.flif 300x171 7.3kB

flif -d encoded.flif downscaled-encoded-decoded.png

downscaled-encoded-decoded.png 300x171 92.1kB

Followup

As you can see the quality between decoded.png and downscaled-encoded-decoded.png are very different. Is this a limitation of engine? (If I want to achieve the quality of predownscaled flif, will I will need a separate flif?)

Let me know if you have any questions.

[bjorn3]

Lossy encoding does some transforms to make the image encode to a smaller file. See https://github.com/FLIF-hub/FLIF/blob/master/src/flif-enc.cpp#L375 .

[FallingSnow]

So that answer to

If I want to achieve the quality of predownscaled flif, will I will need a separate flif?

is yes? 😢

[jonsneyers]

You can always get the best quality/size ratio by doing something lossy (as opposed to using a progressive preview of a lossless file).

However, you might get slightly better results if you avoid --fit and use --scale or --resize instead (followed by a browser-side downscale to get it to the exact dimension you want), since --fit uses dumb downsampling. Also, you usually shouldn't specify a -q if you're already specifying a lower decode dimension (you might want to use some -vvv's to see what exactly is going on).

[FallingSnow]

@bjorn3 @jonsneyers Thank you for taking the time to answer!

Also, you usually shouldn't specify a -q if you're already specifying a lower decode dimension (you might want to use some -vvv's to see what exactly is going on).

I see that now, thank you.

So it tried flif -e -Q10 -s16 ../highRes.flif encoded.flif and that gives me a resolution of 322x184 @ 11.6kB, which is close to my target width of 300. However the quality is still much worse than first downscaling with gm and running flif -e -Q10 ../downscaled.png encoded.flif.

This leads me to believe that 2 factors may contribute to the fact that predownscaling results in better quality than using flif alone.

1. Flif's internal scaling may actually degrade the the encoder's efficiency
2. Gm does scaling that actually produces an image that will result in higher encoder efficiency

On a side note is there a possibility of using pipes or stdin as an input for flif? That way I can pipe gm into it.

[jonsneyers]

Progressive previews of a FLIF file are downsampled versions of the original, not downscaled (though luma will have higher resolution than chroma). So you get aliasing artifacts. These become especially noticeable if there's a big difference between the full resolution and the decode resolution.

You can use stdin/stdout by using the special filename -, e.g. flif -e - - encodes stdin to stdout.

[FallingSnow]

Thanks for that explanation, that make sense.

I tried to pipe using stdin and stdout but am receiving an error. Am I using it correctly?

$ cat highRes.flif | flif -e - - | tee out.flif
Input file does not exist: -

I also tried

$ cat highRes.flif | flif -d - out.png
Input file does not exist: -

Appending -vvv did not provide any additional info.

[jonsneyers]

Are you using the most recent version of FLIF? This was only added recently iirc.

…

On Sat, Jan 7, 2017 at 10:54 PM, Ayrton Sparling ***@***.***> wrote: Thanks for that explanation, that make sense. I tried to pipe using stdin and stdout but am receiving an error. Am I using it correctly? $ cat highRes.flif | flif -e - - | tee out.flif Input file does not exist: - I also tried $ cat highRes.flif | flif -d - out.png Input file does not exist: - Appending -vvv did not provide any additional info. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#334 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOUJFPUn51BVGvhrpUF-V6xi66B_h2sbks5rQAmzgaJpZM4LcSvJ> .

[FallingSnow]

$ flif --version
  ____ _(_)____
 (___ | | | ___)   FLIF (Free Lossless Image Format) 0.2.2 [8 Nov 2016]
  (__ | |_| __)    Copyright (C) 2016 Jon Sneyers and Pieter Wuille
    (_|___|_)      License LGPLv3+: GNU LGPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[jonsneyers]

You'll need version 0.3 from git for stdin/stdout.

[DarkZeros]

Internally FLIF uses final pixel values, it is a downsample, not a downscale (as jonsneyers said).
Changing it to a downscale version, might severely degrade compression (or not), but I think it is an interesting thing to test out or have as a feature (different downsample/prediction patterns).

[FallingSnow]

If it is possible I would love to see a feature that would allow progressive decoding with results similar to predownscaled encoding.

[jonsneyers]

#209 is related to that. It would not be for the current FLIF bitstream (FLIF16), but in a next-gen FLIF format (I'm calling it FLIF18 for now, because it is unlikely to be ready in 2017), we should have a feature like that. It would have many advantages, it's just a bit hard to do in a lossless way without hurting compression.

[FallingSnow]

@jonsneyers @DarkZeros
Thanks for the intel, I'll be looking forward to FLIF18.