avif can't keep icc profile and other metadata

[Lee-lithium]

Hello, kornelski
cavif-rs is work very well, file size and quality is amazing :),
but compressed avif can't keep icc profile and other metadata,
probably can add a flag to handle icc profile and other metadata?

[kornelski]

I'm planning to apply color profiles in order to convert pixel data to one of color spaces already supported by AVIF.

OTOH embedding ICC in AVIF would be an anachronism and a waste of space. To me profiles are only a workaround for crappy old 8-bit formats that can't represent wider gamut otherwise. AV1 supports Rec. 2020, HDR, and high bit depths natively, so ICC profiles are just a waste of space, processing and needless loss of precision.

[Lee-lithium]

Thank you for your reply kornelski :)
Actually i want use avif like this method(png, jpg => avif =>png),
so i need icc profile to make sure my decode png can keep same color space,

And a little curious, av1 rav1e encoder probably can use ycocg(--nclx 1/13/0)?
use ycocg on png file, can let avif file color space more accurate.

[kornelski]

I haven't finished implementing ycocg, and once I've realized it needs 9 bits to be lossless I'm not in a rush. 10 or 12 bits in another color space could be precise enough? It's still a lossy compression anyway.

As for conversion to png, an AVIF decoder should generate a new ICC profile if necessary, based on what color space AVIF used. If AVIF can store 10 or 12 bit Rec 2020, that should be more than enough for any profile. Then you can decode to 16bit png with Rec 2020 ICC or something smaller if you have a smart converter. For 8 bit png I would not bother with anything larger than sRGB, regardless of ICC support.

[WebMechanic]

OTOH embedding ICC in AVIF would be an anachronism and a waste of space. To me profiles are only a workaround for crappy old 8-bit formats that can't represent wider gamut otherwise.

Well, as long as 8-bit raster formats and devices are the dominant species on the web and in consumer's hands using and presuming sRGB only is the worst possible solution to the problem - no matter what you think about it and the world won't change just because of your personal opinion.
It's not ideal, granted, but it's reality and reality needs workarounds until your Image Utopia is here.

Most people don't have time (or knowledge) to fiddle with images: they want their "good looking 8-bit consumer JPEGs" to become good looking AVIFs - just with less data, because they were told it's nice to use less data for virtually the same image quality. They understand that.
If their images look flat, they klick the "Auto Correct" button, crank up the contrast, destroy the image data in the process and "Save to Web": Image looks good to me. Upload. End of story.

If the image you tool creates looks like shit to many people, they won't use or recommend your tool and promoting AVIF will become harder, because for Jane and Joe Average "AVIF images always look like shit".
Well done, sir! 👏🏻

You might be blessed with a perfectly calibrated HDR wide gamut screen, but mere mortals unfortunately have crappy 8-bit screens on their desks and in their hands and those that produce content for these people need a working and practical solution.
Properly tagged images are a solution for those that do bother to give their audience the best possible image for their consumer devices -- and not necessarily the perfect.

Even high-end RAW footage is "flawed" and editing such footage always requires the colour profile of the camera that took the footage (image or video) to allow any target device to display as much of the image data as possible (colours and dynamic range). Same issue.
Software the does the processing needs these profiles to deliver the best possible image for these different crappy targets, because there's no perfect image source to begin with let alone the perfect target device to watch it.
There's no such thing as the "correct" colour for any pixel, which is why colour profiles are required to translate between image data and image display: you should know that, so please don't be ignorant about it and call it an "archaic concept".
Reality is what it is.

There's also no need to "waste data" by embedding the whole profile anyway. If it's a well known and common profile available for virtually all devices and any image and video processing software, the maximum about of bytes wasted are those for the ICC tag.

Thanks for the software, anyway.
And please add effing ICC support FFS.

Have a good time. 👋🏻

[kornelski]

Your rant is not appropriate here, both for its tone, and for beating a technically-inaccurate strawman.

• The problem of reading images with ICC correctly is separate from embedding ICC in AVIF. Please consider the difference between these two cases, as I've said I'm planning to support former, but not the latter.

• AVIF is not limited to 8 bits, and supports very wide gamuts "natively" without ICC, so AFAIK it can achieve everything ICC is used for, without actual ICC embedding. In other words there are two pathways for specifying bigger-than-sRGB color in AVIF, and one of them is old and redundant, so I don't care about supporting it.

• Budget consumer displays and 8-bit image pipelines are de-facto sRGB(-ish). For them any color space other than sRGB only loses precision, because instead of 1:1 mapping of input range to output range you have an intermediate processing step that has to lose data due to pigeonhole principle. So the absolutely best thing you can do to support low-end displays is to always use sRGB for everything, and not use ICC profiles with any other color space.

• Please don't lecture me about utopias and class divide. I'm actually taking care to maximize color consistency on 8-bit image pipelines and sRGB screens. Support for HDR, wide gamuts, ICC, etc. requires extra code paths, which I haven't gotten around to implementing yet. I do not consider copying embedded ICC as an opaque byte blob from input file to output file as a good solution (it adds bloat, may cause unnecessary reduction in color precision). Applying it properly with full understanding of ICC's color transformations is non-trivial, and requires pulling in extra dependencies, which I'll be on hook supporting when people struggle to compile them. It's a chore for me. I'm making a free tool in my free time, and in return I get randos on the Internet ranting to me about a problem they've imagined. Fuck that.

[zachlewis]

Hey @kornelski --

• This project is awesome, and I appreciate your work.
• I think not embedding custom ICC profiles is wise; CICP tuples are the de facto mastering targets for AVIF content. Keep it simple for everybody.
• If you were to support custom ICC profiles, it might make more sense to "bake" (i.e., naively apply) the ICC profile into the data before encoding, instead of embedding an ICC profile to be applied after the encoding. In other words, you'd be supporting custom ICC profiles only as a user-provided means for adapting pixel values to CICP mastering targets.
• I do have one very specific use case for a simple technical embedded ICC profile, for your consideration: for cases when the middle CICP value is set to "2" (i.e., trc is "undefined"). I would love to be able to provide a custom exponent value for a simple channel-independent power function, encoded as an embedded ICC profile.
• What I'm after, specifically, is a way to encode for Rec.1886-Rec.709 HDTV broadcast display targets; but there is no way to specify a gamma 2.4 nonlinearity. For mov containers, we can get away with appending ffmpeg options like -color_primaries 1 -color_trc 2 -colorspace 1 -movflags write_colr+write_gama -mov_gamma 2.4; and I'm wondering + hoping a simple embedded ICC profile might be able to handle this very specific use case.
• Either way... cheers.

[kornelski]

@zachlewis As far as I know, Rec. 709 has the same primaries and white point as sRGB, only the gamma differs. But when encoding to 10-bit depth there should be enough precision left to convert from ~2.2 to 2.4. To support this I'd just need to accept higher-depth inputs.

There also is a constant for Rec. 709 gamma in AV1 metadata, so even that doesn't need ICC.