Requirements on sato item and its input images

[maryla-uc]

The current draft specification says:

The input image items and the Sample Transform Derived Image Item shall:

• each be associated with a PixelInformationProperty and an 'ispe' property;
• have the same number of channels and the same chroma subsampling (or lack thereof) as defined by the PixelInformationProperty and AV1ItemConfigurationProperty;
• have the same dimensions as defined by the 'ispe' property;
• have the same color information as defined by the ColourInformationBox properties (or lack thereof).

Does this mean that the sato item and its input image items must all have a colr property with the same content, OR must have no colr property associated with any of them? This is how I would naturally interpret "have the same color information as defined by the ColourInformationBox properties (or lack thereof)" but this is not what libavif is currently outputting. In the images created in avif16bitttest.cc, neither the sato box nor the extra input items have any colr property (this may be a bug with libavif).

The same question applies to pixi/av1C. Especially if version 0 of pixi is used, then I believe the only way to signal chroma subsampling is through the av1C box. But then this makes it sound like the sato item should have an av1C box too.

[maryla-uc]

Here is an example image generated by libavif by the way.

weld_sato_8plus8bit_alpha.avif.zip

[leo-barnes]

@maryla-uc @y-guyon
Should we try to address this before publishing v1.2?

[y-guyon]

Does this mean that the sato item and its input image items must all have a colr property with the same content, OR must have no colr property associated with any of them? This is how I would naturally interpret "have the same color information as defined by the ColourInformationBox properties (or lack thereof)"

Me too.

this is not what libavif is currently outputting. In the images created in avif16bitttest.cc, neither the sato box nor the extra input items have any colr property (this may be a bug with libavif).

I do not understand. This is what libavif is outputting then: "must have no colr property associated with any of them".

The same question applies to pixi/av1C. Especially if version 0 of pixi is used, then I believe the only way to signal chroma subsampling is through the av1C box. But then this makes it sound like the sato item should have an av1C box too.

Good catch. To me the spec says "same subsampling everywhere or no subsampling anywhere". As av1C is mandatory, it means input images (assuming they are coded) have subsampling defined. It follows sato shall have subsampling defined too. But av1C can (should?) only be associated with coded image items. It results sato shall be associated with a pixi with px_flags=1 (when officially published).
The alternative would be to use non-coded input image items (iden).

Should we try to address this before publishing v1.2?

It feels rushed but I guess a note such as the following would be fine:
In order to satisfy the requirement that either all input and sato items have the same signaled subsampling or none of them have associated subsampling information, because of the subsampling information signaled by av1C which may not be associated with non-coded image items, iden derived image items can be inserted between coded image items and sato, or sato can be associated with a pixi with px_flags=1 described the same subsampling as the av1C associated with its coded input image items.

[maryla-uc]

this is not what libavif is currently outputting. In the images created in avif16bitttest.cc, neither the sato box nor the extra input items have any colr property (this may be a bug with libavif).

I do not understand. This is what libavif is outputting then: "must have no colr property associated with any of them".

The first input item of the sato item does have a colr box. So there is a mismatch with the second input item and with the sato item. This can be fixed in libavif if this was indeed the intended meaning of the spec.

Note that libavif does not currently support iden (can also be fixed, although we probably want to concentrate our efforts on the rust port CrabbyAvif).

[y-guyon]

The first input item of the sato item does have a colr box. So there is a mismatch with the second input item and with the sato item. This can be fixed in libavif if this was indeed the intended meaning of the spec.

I missed the "extra" in "extra input items".

Note that libavif does not currently support iden (can also be fixed, although we probably want to concentrate our efforts on the rust port CrabbyAvif).

And libavif has AVIF_ENABLE_EXPERIMENTAL_EXTENDED_PIXI.

[maryla-uc]

Sounds like a decent solution then.