Provide a way to avoid conversion from a studio-ranged alpha channel to a full-ranged about libavif

[joedrago]

There are two topics in your issue to discuss.

#1. Limited Range: more personal opinion time from me:

As a general statement, I think limited range is an antiquated notion from the analog era that has turned into an almost-enforced bad habit for video encoding, and now that images are starting to be encoded as one frame videos, is bleeding into the image encoding space. It is silly to me that we go out of our way to support higher bit depths (10bpc, 12bpc) and then out of this bad analog habit, throw away ~14% of the codepoint space. For HDR, we encode with the PQ curve, which is designed around each codepoint having a barely-human-perceptible difference, and limited range throws a monkey wrench into that.

I don't think limited range has a place in image files, ever. I begrudgingly support it because of this fear that these bad limited range habits will find its way into silicon, and we'll have hardware decoders that can't handle full range someday, and everyone will be stuck making AV1 payloads in limited range for eternity. It is doubly foolish with the alpha plane, where precision is paramount if you want clean masks, and no bleed / sparkly artifacts when panning masked images across other images.

The code you're citing is me trying to make sense of a fairly ridiculous encoded alpha plane. To your point, however, I do allow this to exist in the color plane, so I suppose I could plumb through an alphaRange in avifImage and leave it up to the enduser to decide what to do with it. That will hurt API ergonomics a bit though, as people will either just get into the habit of always calling some extra function they might not fully understand, or (worse) never call it and wonder why their decoded images look odd sometimes.

This is a tricky one, but perhaps #2 might help pick a direction for this issue.

#2. Images using depth >8bpc are stored in U16, but aren't proper unorm.

This is a real issue, simply because graphics hardware doesn't really have a pixel format for "unorm 10bpc inside of 16bpc", so you're either stuck with a rescale-to-65535 as a decode fixup step as you cited, or custom fragment shaders and flagging decoded image with this kind of metadata.

This is something that might make sense as a libavif helper function... something that'd take RGB(A) data in a similar fashion to how YUV->RGB is done and would ensure that we've scaled limited->full in-place and upscaled >8bpc content to full unorm, so it always makes sense for graphics hardware.

If such a helper function existed, having limited range for alpha would still be silly, but most of the pain associated with it would be put in an optional function call, and people that chose to take limited range YUV and limited range Alpha could choose to do so (and avoid this step). I'll talk this over with my team today and possibly make a breaking change for 0.6.0.

[joedrago]

It currently is impossible to receive a limited range alpha channel because of the block of code ledyba-z cites in the original post, but I'm planning to allow it (but keep the default for encoding at full range). The new RGB plumbing will allow people to create an interleaved RGBA pixel buffer that ends up being full range, normalized RGB+A, but if you're directly pulling the alpha channel in Chromium (which I believe you are), you'll have to check for this, unfortunately. I can add a helper function specifically for that use case if/when we need it.

[joedrago]

(to whom it may concern)

These are links to the README and avif.h in my feature branch for my RGB refactor. Give them a look over, as this is very likely to be the new way to convert YUV(A) <-> RGB(A) in libavif starting in v0.6.0. It might cost you a few extra lines of code to setup, but it allows for conversion directly into and out of your own RGBA buffers, including range conversion and depth rescaling. The goal here is for people that just want to fill their 8bpc or 16bpc buffer with "correct" (full range, unorm) data and don't care what how the image was encoded, this does all of the work for you.

@dalecurtis Would you like me to make a separate helper function which converts the avifImage alpha plane into full range, as I know you're not using the RGB conversion path, or are you planning to do that using some pre-existing Chromium routine? (The alpha channels in an avifRGBImage buffer are always full range.)

https://github.com/AOMediaCodec/libavif/blob/rgb/README.md
https://github.com/AOMediaCodec/libavif/blob/rgb/include/avif/avif.h#L325

[joedrago]

I've discussed this here at work, and I'm very likely to refactor RGB-related code and how alpha range is used this week in libavif, which will certainly be a breaking change in 0.6.0. I just wanted to warn you in advance that things are going to change in that regard.

@dalecurtis I don't imagine it will impact Chromium much as it isn't using the RGB pipeline, but there might be a tweak necessary for handling (hopefully rare) limited range alpha.

@cryptomilk @wantehchang @novomesk I wanted to warn you three in advance as well, as I know you've been using the library a lot lately. I think it'll be worth it.

[cryptomilk]

I don't use the alpha channel. But let me know when the code is in and I will check.

[dalecurtis]

Huh, had no idea the alpha plane would be limited range. So long as that's knowable from some public structure that sgtm. Thanks!

[novomesk]

I use alpha in my GIMP plug-in and also in plug-in for Qt Image Formats. I am preparing to work with image sequences in the near future too.

[ledyba-z]

Thank you for refactoring.

1: Limited Range

As a general statement, I think limited range is an antiquated notion from the analog era that has turned into an almost-enforced bad habit for video encoding,

As an indivisual programmer who likes image compressing formats, I strongly agree with you.

However, we are using limited-ranged images, because the encoded image binary becomes smaller.
Of course, color reproducibility gets worse, but we accepted it.
Because we are distributing images to mobile users, who care about traffic usages rather than colors.

I also agree that alpha planes strongly should be full-ranged by default. It is much more artificial data than primary image.
Also, I think it is more better AVIF spec banned limited-range alpha, or at least deprecate it.

2: Images using depth >8bpc are stored in U16, but aren't proper unorm.

Thank you for breaking changes.
I convert YUV/Alpha planes to RGBA using Apple's framework(vImage) in smart phones, so I really would like to avoid conversion in C and convert them myself.

[dalecurtis]

We'll convert on our own. We just need a signal that it's a limited range alpha plane.

[joedrago]

This is all in. Once I get clap, imir, and irot metadata plumbed through, I'll bump all of this to v0.6.0 and chaos can ensue. Thanks for the continued help, all.