Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Progressive Decoding vs Lossy Encoding give different subjective quality #334

Closed
FallingSnow opened this issue Jan 6, 2017 · 13 comments
Closed

Comments

@FallingSnow
Copy link

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

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

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

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.

@FallingSnow FallingSnow changed the title Regression Decoding vs Lossy Encoding give different preservative quality Progressive Decoding vs Lossy Encoding give different preservative quality Jan 6, 2017
@bjorn3
Copy link

bjorn3 commented Jan 6, 2017

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
Copy link
Author

FallingSnow commented Jan 6, 2017

So that answer to

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

is yes? 😢

@jonsneyers
Copy link
Member

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
Copy link
Author

@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.

@FallingSnow FallingSnow changed the title Progressive Decoding vs Lossy Encoding give different preservative quality Progressive Decoding vs Lossy Encoding give different subjective quality Jan 7, 2017
@jonsneyers
Copy link
Member

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
Copy link
Author

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
Copy link
Member

jonsneyers commented Jan 8, 2017 via email

@FallingSnow
Copy link
Author

$ 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
Copy link
Member

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

@DarkZeros
Copy link

DarkZeros commented Jan 9, 2017

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
Copy link
Author

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

@jonsneyers
Copy link
Member

#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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants