Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Allow odd clap dimensions and offsets #2426
Allow odd clap dimensions and offsets #2426
Changes from all commits
67025a1
62b1d99
607096e
0191fd5
ce97e08
8010388
dfecdc4
baf2525
dead45b
2be929f
0323aba
ee24cbb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future: I think we should add an
avifImageUpsample()
oravifImageUpsampleTo444()
function for completeness.I also found that I did not read your reply to my suggestion of adding
avifCropRectRequiresUpsampling()
. Sorry about that. I sometimes review a new version of the pull request directly, without reading the comments.You are right that libavif users may neglect to call
avifCropRectRequiresUpsampling()
. To help prevent that mistake, we should either return the "requires upsampling" boolean as an output parameter (as you did before), or upsample the image for the users. If we do the latter, we might as well crop the image for the users.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We went away from that approach already, and it does not cover the orientation.
I began writing a PR for that and quickly gave up. It requires a lot of changes, especially because the whole implementation revolves around
avifDecoder::image
. Since it is part of the public API, it must stay there, and it must be the buffer that is cropped/orientated/upsampled. However it is also used by the underlying codec, so it cannot be cropped/oriented/upsampled (at least till the last frame is decoded or the codec is destroyed).So some internal
avifDecoderData::image
must be introduced, andavifDecoder->image
is either a copy or a view of it, depending on the transform.Upsampling can be done in multiple ways (nearest etc.) and has to take into account chroma citing metadata.
avifDecoderDecodedRowCount()
must also be adapted to cropping/orientation.A cheaper alternative could be a helper function that returns a new image object with all the necessary transforms applied, and users must call that. But it will not go well with incremental support and may introduce unnecessary buffer copies.
Yet another path is to add a public API
avifDecoder::imageWithTransformsApplied
. This is roughly the same amount of work as the internalavifDecoderData::image
but with fewer risks of breaking something in the existing API.Overall it felt like a lot of work compared to just writing in avif.h that users must take care of that themselves, which I agree is not great, but also already the current situation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the analysis.
Do you think we should provide an
avifImageUpsample()
function? Or should we just document that one can also convert YUV to RGB and then crop the RGB image?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Chrome, samples can be rendered directly without being converted to RGB first, right? If so, it would be useful at least for this kind of use case.
Is orientation and cropping both applied in Chrome?
That sounds useful to mention, even if libavif offers an alternative in the future. Done.
Also added another comment about applying transform next to
avifDecoder::image
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chrome's blink::AVIFImageDecoder can provide either YUV samples or RGB samples to its callers. Cropping is done by blink::AVIFImageDecoder. (It requires that the top left corner of the clean aperture be located at (0, 0).) Orientation is applied by the callers of blink::AVIFImageDecoder.