Allow odd clap dimensions and offsets #2426
Conversation
The constraint in MIAF was replaced by an upsampling step before cropping.
|
@wantehchang Do you plan on submitting #1749 first? |
Done. The reason I had not submitted #1749 is that I am not sure whether only some of the members of the avifCleanApertureBox struct will be changed to int32_t in the next version of ISO BMFF. But it is fine to submit #1749 first because it describes how libavif interprets the members of the avifCleanApertureBox struct now. We can update the comment when the next version of ISO BMFF is released. |
| @@ -722,6 +699,16 @@ avifBool avifCropRectConvertCleanApertureBox(avifCropRect * cropRect, | |||
| // positive or negative. For cleanApertureWidth and cleanApertureHeight, | |||
| // N shall be positive and D shall be strictly positive. | |||
|
|
|||
| // ISO/IEC 23000-22:2024, Section 7.3.6.7: | |||
There was a problem hiding this comment.
It is best to wait until ISO/IEC 23000-22:2024 is formally published. Its status is still Final Draft Internal Standard (FDIS) right now: https://www.iso.org/standard/87576.html
| // - chroma is subsampled horizontally (i.e., 4:2:2 and 4:2:0) and cleanApertureWidth is odd | ||
| // - chroma is subsampled horizontally (i.e., 4:2:2 and 4:2:0) and left-most pixel is on an odd position | ||
| // - chroma is subsampled vertically (i.e., 4:2:0) and cleanApertureHeight is odd | ||
| // - chroma is subsampled vertically (i.e., 4:2:0) and topmost line is on an odd position |
There was a problem hiding this comment.
For AVIF, the first and third conditions are too strict. They are equivalent to disallowing odd widths for 4:2:2 and 4:2:0 and disallowing odd heights for 4:2:0, but AV1 supports those two cases. In libavif we can consider ignoring the first and third conditions.
| @@ -820,9 +827,10 @@ avifBool avifCleanApertureBoxConvertCropRect(avifCleanApertureBox * clap, | |||
| avifPixelFormat yuvFormat, | |||
| avifDiagnostics * diag) | |||
| { | |||
| (void)yuvFormat; | |||
There was a problem hiding this comment.
If we want to preserve the old behavior, we cannot ignore yuvFormat.
It would be useful to move lines 804-806 to a new function that takes const avifCropRect * cropRect and avifPixelFormat yuvFormat as input and returns the upsampleBeforeCropping boolean. Then we can call that new function here (to preserve the old behavior) and at line 804.
| avifPixelFormat yuvFormat, | ||
| avifDiagnostics * diag) | ||
| { | ||
| // Keep the same pre-deprecation behavior. |
There was a problem hiding this comment.
This does not keep the old behavior exactly. The difference is the first and third conditions at lines 706-710. So to be precise, the comment should say "most of the pre-deprecation behavior".
If we ignore the first and third conditions as I suggested in my comment at line 710, then we keep the old behavior exactly.
@wantehchang Did you find another approach? |
|
|
||
| *upsampleBeforeCropping = ((yuvFormat == AVIF_PIXEL_FORMAT_YUV420 || yuvFormat == AVIF_PIXEL_FORMAT_YUV422) && | ||
| (cropRect->width % 2 || cropRect->x % 2)) || | ||
| (yuvFormat == AVIF_PIXEL_FORMAT_YUV420 && (cropRect->height % 2 || cropRect->y % 2)); |
There was a problem hiding this comment.
An alternative design is to remove the yuvFormat input parameter and the upsampleBeforeCropping output parameter from this function (avifCropRectFromCleanApertureBox), and then add another function that takes const avifCropRect * cropRect and yuvFormat as input parameters, and returns upsampleBeforeCropping as the return value.
Note that yuvFormat and upsampleBeforeCropping are only used in this statement (lines 804-806), so this statement can be cleanly moved to a separate function.
Another alternative is for libavif to upsample to 4:4:4 and crop automatically when necessary so that libavif users don't need to worry about this. But I am not sure if this is a good idea.
There was a problem hiding this comment.
add another function that takes
const avifCropRect * cropRectandyuvFormatas input parameters, and returnsupsampleBeforeCroppingas the return value
The issue with this new function and with the current avifImage::clap are that users can easily ignore them. The point of the "mandatory" upsampleBeforeCropping argument was to force users to at least consider upsampling (because there is no other function available to get a rect). But they can just ignore clap anyway so it has little effect.
Another alternative is for libavif to upsample to 4:4:4 and crop automatically when necessary so that libavif users don't need to worry about this. But I am not sure if this is a good idea.
I would lean towards that as a default behavior, and why not add an "ignoreClap" setting in avifDecoder to keep the old behavior back.
However existing files with clap will no longer display the same, in places where clap is ignored by users of libavif.
The constraint in MIAF was replaced by an upsampling step before cropping.
Notes:
avifdecdoes not crop anything when decoding.clapfield inavifImage. It is the user's duty to upsample, hence the added output argument inavifCropRectFromCleanApertureBox().See AOMediaCodec/av1-avif#202 (comment).