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

Support alpha plane with different bit-depth, size or range #86

Open
ledyba-z opened this issue Mar 4, 2020 · 3 comments
Open

Support alpha plane with different bit-depth, size or range #86

ledyba-z opened this issue Mar 4, 2020 · 3 comments
Labels
backlog Not being actively considered for work, undecided

Comments

@ledyba-z
Copy link
Contributor

ledyba-z commented Mar 4, 2020

Bit-depth, size and range of Alpha plane can be different to the RGB plane (Please see discussion in AOMediaCodec/av1-avif#68). However, there is no way to know bit-depth, size and range of alpha planes.

I think we need fields like alphaDepth, alphaWidth, alphaHeight and alphaRange in avifImage struct to handle alpha planes correctly.

@ledyba-z
Copy link
Contributor Author

ledyba-z commented Mar 4, 2020

I know that limited-ranged alpha is corrected to full-ranged internally (in here), but it may cause performance issue....

@ledyba-z ledyba-z changed the title Support alpha plane with different bit-depth or size Support alpha plane with different bit-depth, size or range Mar 4, 2020
@joedrago
Copy link
Collaborator

joedrago commented Mar 4, 2020

My personal opinion (not the opinion of the AVIF standard or AOM):

I think this creates a lot of pain points, corner cases, and complexity for very little gain, if I'm being honest. If you're actually planning to do anything meaningful with that alpha channel, you very likely want it to be the same dimensions as the color channel, and I think you'd at least want them to be the same AV1 profile (if not the same depth for color shifting reasons). HEIF/AVIF is quite a massive spec of features, and some of these cases where a file is "legal" might not be worth the headaches associated.

My stance on issues like this:

Given that such a file is a legal AVIF, I'm sure I'll eventually add decode support for it, just like it is legal for the alpha plane to be encoded in limited range, despite that being somewhat nonsensical once you go to use the channel itself. I'd eventually like to be able to decode any reasonable AVIF and do something useful with the payload. As for encoding such a combination, I'm not in a big rush to make avifEncoder encode every possible combination of boxes that HEIF/AVIF can offer. My current encoding goal is to easily pack a single 8/10/12bpc image with optional alpha at various quality rates, metadata, and color profiles, with as many AV1 codec implementations as possible. A lot of these weirder combinations are lower priority for me, for now.

@ledyba-z
Copy link
Contributor Author

ledyba-z commented Mar 4, 2020

@joedrago Thank you to reply!

To tell you the truth, I really agree with you.
I think 8-bit RGB with 10-bit alpha is meaning-less.
(In contrast, I think depth image with different dit-depth and different size might be helpful)

How about adding additional constraints about alpha images for AVIF standard?
(I think it is confusing if there are differences between reference implementation and standards)

Do you know where the standard is discussed?

If you know, please tell me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Not being actively considered for work, undecided
Projects
None yet
Development

No branches or pull requests

2 participants