y-guyon
commented
5 days ago Thank you for the feedback.
If we'd called it bits_per_channel_minus_one we could have got there, but a bit late to change the semantics.
Too late because we are at AMD WD stage or because it would be too confusing compared to 'pixi' version 0?
If doable I think it is a reasonable change.
I also couldn't find the right part in ISO/IEC 23091-2 for the definition for GenericSubsamplingType
Same. Should we keep only Rec. ITU-T H.273 as reference or are we confident enough that ISO/IEC 23091-2 will be updated before this amendment draft is published?
In the semantics for channel_idc: "Values 3-8 are reserved for future use." That should say "Values 3-7 are reserved...", since there are only three bits.
Good catch.
It seems like there is a lot of finessing to make it still be 'meta'
I agree.
Possibly there could actually be two compact versions - a really simple one that doesn't allow much (maybe just image + alpha), and is well suited to simple web page images, and a second one with the full tools.
"The second one with the full tools" would be regular HEIF, right?
Otherwise, introducing an alternative representation of HEIF is already a big change. Introducing two would be confusing in my opinion.
In P.2, the statement that 23008-12 is a Publically Available Standard on the ITTF page is (sadly) no longer true
Right.
farindk
bradh
Comments on working draft at https://www.mpeg.org/wp-content/uploads/mpeg_meetings/146_Rennes/w23988.zip
For the version 1 of PixelInformationProperty (pixi):
it might be slightly cleaner if channel_data_type used the same enumeration values as 23001-17 Table 2 (plus AMD 2, which adds 3 for signed integer). Interestingly pixi bits_per_channel doesn't have enough range for the extreme case in 23001-17. If we'd called it bits_per_channel_minus_one we could have got there, but a bit late to change the semantics.
I also couldn't find the right part in ISO/IEC 23091-2 for the definition for GenericSubsamplingType and GenericSubamplingSampleLocType, and assume they might be in a CD somewhere. Possibly needs an additional reference.
In the semantics for channel_idc: "Values 3-8 are reserved for future use." That should say "Values 3-7 are reserved...", since there are only three bits.
For the compressed meta box:
It seems like there is a lot of finessing to make it still be 'meta', including needing removing restrictions in ISOBMFF that an implementer could potentially have relied on. I don't think that effort is worth it, and it would be cleaner to just call it "met2" or "cmet" or something else. It is so different in terms of syntax, it'll probably be cleaner just to parse it separately anyway. A consumer can still synthesise an in-memory MetaBox if the implementation needs that, and there is no reason why it can't use other boxes (i.e. whatever is allowed for MetaBox), although I'd like to see a limitation that prevents inconsistency.
Possibly there could actually be two compact versions - a really simple one that doesn't allow much (maybe just image + alpha), and is well suited to simple web page images, and a second one with the full tools.
In P.2, the statement that 23008-12 is a Publically Available Standard on the ITTF page is (sadly) no longer true. While that might still be in work, perhaps we should just reference "ISO/IEC 23008-12" and be silent on the location. Updating the other MIME type registrations can be left for a future contribution.