add more ways to compare

[gtoderici]

The current way of choosing which target bitrates to use is perhaps fine for casual users, but for researchers it's a bit harder than it needs to be.

I would like to propose to add a radio button group in the UI with the following options:

Subjective Size - this would trigger the current behavior, where users get to select "Small", "Big", etc.

Bitrate - this would have a specific set of bitrates, say 0.15, 0.3, 0.5, 1.0, 1.5, 2.0, 3.0, 4.0bpp, and for those images that can't be coerced to get to the target bitrate for all codecs, simply drop those that don't apply.

JPEG Equivalent Bitrate where the target bitrates would be matching those of compressing the image with JPEG at various Q-levels (say Q0, Q25, Q50, Q75, Q90, Q100)

This change is of course requiring some work on the backend/preprocessing as well (i.e., the part which generates the compressed images, and exposes the bitrates).

[jyrkialakuijala]

+1 for George's proposal.

The current methodology is to use a video codec (BPG/x265 quality 24) for deciding the base bitrate. Using a video codec to decide the bitrates in my view puts the other codecs with video heritage (WebP, WebP2, AOM) in advantage over photography codecs (Mozjpeg, JXL). A photographic codec will need to distribute bits differently -- the bit distribution is not attention driven as no delta frames will fix the subtle textures later.

In addition to fixed bitrates, I'd be interested to see what codecs do if they are asked to match 1.0 bpp (etc.) for the whole corpus, i.e., codecs would be allowed to decide how to distribute the bits between the images. This would very likely immediately fix the issues that image codecs have on some of those sub 0.1 BPP images and would match more the normal use of image encoding -- where all production images are compressed with some chosen quality setting rather than to a specific BPP.

[eclipseo]

Bitrate - this would have a specific set of bitrates, say 0.15, 0.3, 0.5, 1.0, 1.5, 2.0, 3.0, 4.0bpp, and for those images that can't be coerced to get to the target bitrate for all codecs, simply drop those that don't apply.

That could be interesting but I am limited by one factor, the amount of data available for hosting on Github. I am currently at the upper limit of what is acceptable (5GB) so I can't add new quality levels.

+1 for George's proposal.

The current methodology is to use a video codec (BPG/x265 quality 24) for deciding the base bitrate. Using a video codec to decide the bitrates in my view puts the other codecs with video heritage (WebP, WebP2, AOM) in advantage over photography codecs (Mozjpeg, JXL). A photographic codec will need to distribute bits differently -- the bit distribution is not attention driven as no delta frames will fix the subtle textures later.

I have dropped BPG and use MozJPEG Q85 as a reference point.