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

CICP color property takes precedence over any color information in the image bitstream. #875

Open
ledyba-z opened this issue Mar 12, 2022 · 1 comment

Comments

@ledyba-z
Copy link
Contributor

ledyba-z commented Mar 12, 2022

Hi!

I'm currently working on making cavif to conform to the latest standards.

I found these statements in ISO - ISO/IEC 23000-22:2019/Amd 2:2021:

All image items, both coded and derived, should be associated with at least one colour information
property.
The handling of colour information by the system (i.e. colour management) is outside the scope of this
document; a renderer takes this information into account when rendering the image(s).
If a coded image has no associated CICP colour property, the default property is defined as having
colour_type equal to 'nclx' with properties as follows:
— colour_primaries equal to 1,
— transfer_characteristics equal to 13,
— matrix_coefficients equal to 5 or 6 (which are functionally identical), and
— full_range_flag equal to 1.

NOTE 1
Any colour information in the bitstream is ignored by the MIAF reader and MIAF renderer processing
models. The colour information property whether explicit or default, takes precedence over any colour
information in the image bitstream.

If I understand correctly, it says "Do not use color information in OBU Sequence Header any more. Use default values if nclx absent" in AVIF context.

However, it looks libavif tends to use color information from OBU sequence header:

libavif/src/read.c

Lines 3633 to 3665 in 7a6d13b

if (!data->cicpSet && (data->tiles.count > 0)) {
avifTile * firstTile = &data->tiles.tile[0];
if (firstTile->input->samples.count > 0) {
avifDecodeSample * sample = &firstTile->input->samples.sample[0];
// Harvest CICP from the AV1's sequence header, which should be very close to the front
// of the first sample. Read in successively larger chunks until we successfully parse the sequence.
static const size_t searchSampleChunkIncrement = 64;
static const size_t searchSampleSizeMax = 4096;
size_t searchSampleSize = 0;
do {
searchSampleSize += searchSampleChunkIncrement;
if (searchSampleSize > sample->size) {
searchSampleSize = sample->size;
}
avifResult prepareResult = avifDecoderPrepareSample(decoder, sample, searchSampleSize);
if (prepareResult != AVIF_RESULT_OK) {
return prepareResult;
}
avifSequenceHeader sequenceHeader;
if (avifSequenceHeaderParse(&sequenceHeader, &sample->data)) {
data->cicpSet = AVIF_TRUE;
decoder->image->colorPrimaries = sequenceHeader.colorPrimaries;
decoder->image->transferCharacteristics = sequenceHeader.transferCharacteristics;
decoder->image->matrixCoefficients = sequenceHeader.matrixCoefficients;
decoder->image->yuvRange = sequenceHeader.range;
break;
}
} while (searchSampleSize != sample->size && searchSampleSize < searchSampleSizeMax);
}
}

Is it correct?

@novomesk
Copy link
Contributor

novomesk commented Oct 5, 2022

This question is related to the discussion in AOMediaCodec/av1-avif#195

It think implementation in libavif give good backward compatibility with existing images, when it was not allowed to have both ICC and NCLX at the same time.

If the authors of the standard really wanted to always ignore info in bitstream, I'd appreciate they confirm/deny that so we remove discrepancy between implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants