(one ‘which’ which might be ‘that’?)
m36363 Draft white paper on the High Efficiency Image File Format (ISO/IEC 23008-12)
(as above)
m36469 Demonstration of the High Efficiency Image File Format (ISO/IEC 23008-12)
Thank you for the demonstration and evidence of implementability. This is a javascript implementation of the file format and HEVC.
(We note also a demonstration from Telecom ParisTech, thank you.)
m36470 Support of multi-layer HEVC extensions in ISO/IEC 23008-12
To WD at this meeting.
Conclusion on Still Image File Format
We have an 8-week editing period, with the editors releasing documents periodically in that interval as meeting input, and accepting comments and handling them.
Choices:
-
as now
-
extend the item info entry with property boxes (no sharing)
-
have a property bag box, extend the item info entry with property references (sharing)
-
have a completely new item property association box, that associates items by item_ID with a set of property boxes (like 1, but separate) (no sharing)
-
have a property bag somewhere, and the new item properties box associates items by item_ID with properties in the bag by index. (sharing)
-
have an item properties box, that associates by having a property box and then lists the items by ID that use that property; (sharing)
-
include the properties in the item info entry, and then share properties by having an item reference type that picks up all the properties of another or other item(s)
Critique:
-
Minuses: many items, item references; use of iloc to find basic information; Plus: sharing is easy (two ways, init refs and extent sharing); nothing new.
-
Minuses: we fiddle with an existing structure (infe); no sharing; the infe now has fields and trailing boxes. Plus: no new boxes, no new item props, no bag.
-
Minuses: has both introduced a new box and fiddled with the infe; Plus: the infe is cleanly just fields; sharing.
-
Minuses: existing systems may discard; is a new structural concept in meta; no sharing. Pluses: leaves existing boxes alone.
-
Minuses: existing systems may discard; is a new structural concept in meta; Pluses: leaves existing boxes alone; sharing.
-
as 5.
-
as 2 but with sharing. minus: you have to do a closure over item refs before you have item props for a given item.
We want sharing: 1, 3, 5, 6, 7.
We don’t want many items: 3, 5, 6, 7.
Minimal disruption: 5, 6, 7.
Uncomfortable with making item info entries ‘long’, closure is bad: 5, 6.
Close to usual practice: 5.
ItemPropsBox {
ItemPropsContainer {
prop;
prop;
}
ItemPropReferences {
Item_count;
loop {
Item_ID;
property_count;
{bit (1) ignorable; property_index} [property_count];
} [item_count]
}
}
irot and clap are defined items with only a property and no body. all descriptive info (w+h, decoderconfig etc.) is a property. Properties are applied in order.
Possible definitions?
Derived image: an image item that is built by performing an operation on another image item
Transformed image: an image that has mutation operations in its properties.
Mime parameter is a list starting with the item type and including the essential properties.
Dostları ilə paylaş: |
