[Suggestion] Add before size at the output info

[Draghmar]

Hi I just discovered your tool and I started to test all the options and how they impact quality and size. One small thing I really like about your tool is that it gives direct and simple info on how efficient encoding was by showing output size. What would be even more convenient is to add info about input size. Something like this: some_file.jpg: 100KB -> 50KB (other stuff ;)) The reasoning here is that I often first check how specific combination of parameters impact size and then how it looks. And it's simply easier to check it when I don't have to jump between windows. Especially when I do a batch encoding. :P

[kornelski]

I thought about it, but decided not to add it. This is a lossy compressor, so the before and after sizes are not comparable. Seeing file size halve here doesn't mean the codec is twice as good. It could even be making compression worse and you wouldn't know it just by looking at two out of four relevant variables (the other two are visual quality before and after, and they can't be computed without access to uncompressed source, so I can't add them).

[Draghmar]

Even though I get your reasoning when comparing codecs, I don't agree if we talk about scenario I was selling here. We're using encoder to get the best quality with the smallest size possible for the content and the place it will be displayed in. So it's quite natural to compare different outputs with different quality settings for the same file. Does bringing quality from 65 to 60 brings any significant size gain? And how it impact the visual quality? And is avif even better for that particular file or maybe jpg is enough? Those are the three main questions asked when dealing with compression. And the suggestion I've made was to make it easier for the first two to be answered without having to jump to the window/list and check the files themselves. So it's simply to replace the thing anyone is already doing (checking how much compression you'll get) and put it in a more convenient place.

Anyway, it's your choice.

[kornelski]

Right, this confirms it's for a suboptimal workflow I would like to discourage. You should never use JPEG q=60 to make an AVIF file. You should use PNG or JPEG q=100 as the input.

If you take a JPEG q=65 and make an AVIF file from it that is 20% smaller, it's not a 20% gain. You don't know if just resaving the same file with JPEG at lower quality wouldn't be smaller than AVIF.

This is possible, because the distortions that made JPEG file smaller are preserved in AVIF, and also make AVIF files larger. So AVIF pays quality degradation cost of JPEG with none of the benefits, and then pays extra cost of AVIF encoding to preserve the useless distortions, and then needs to add its own degradation too. So you lose twice and pay twice.

The big compression advantage that AVIF has over JPEG in quality/filesize ratio applies to undistorted uncompressed files. In lossy to lossy conversion AVIF is not guaranteed to be that good (it might still be a net benefit if you lower quality significantly, but it's not going to be as good as compressing from full-quality source).

Lossy codecs are all about quality/filesize ratio, not just absolute file size. You can take a JPEG and re-save it as JPEG to make it 20% smaller and look almost the same. That "it's much smaller, but looks almost the same" trick is what all lossy formats do.

[Draghmar]

Well...I have never stated that my source files are compressed...Actually at most cases I have lossless or high quality as a source. Then I apply compression. Before avif adoption it was only into jpg or png and webp. But I always need to check if there's really reason to use webp (and avif now) because that depends on the image. For example gaining 1kB is not worth the effort of maintaining more versions of the same file. And unfortunately both webp and avif heavily depends of specific image file, which means sometimes results are awesome vs jpg/png and sometimes...not. The same applies to checking if lowering quality within the same codec gives anything interesting in terms of quality/file size ration. I did many tests for different codecs on different files that I normally work with to get the general idea of what I can get with codecs and their settings.

Anyway, like I said - it's your app and I respect your decision. :)