@walter.arrighetti I don’t think this is true. You can currently have 0-10 <archivedAcesPipeline> elements. The intention here was to simply change an <acesPipeline> to <archivedAcesPipeline>. No need to imbed it in another nested tag. The group talked at length about the role of the <archivedAcesPipeline> and felt it was probably best practice to have an AMF per output device and/or essence. The group felt one monolithic AMF would become too big, too complex, and too confusing. Obviously this is a matter of perspective and opinion.
Currently we are using amf as the namespace. There isn’t any real reason we need to stick with that but your point is a good one and I’ll update the examples to explicitly use the namespace. I see your point about using aces as the namespace and shortening the element names. It’s interesting but I’d love to hear other’s opinions. Just a bunch of work to modify the documentation and we are already late in getting this to the TAC for review.
Frankly I’m not sure I understand the proposal for the per-manufacturer table. The goal of AMF isn’t to transport all camera metadata. It’s to communicate an ACES viewing pipeline. I understand there may be value in providing a standardize container to transport other camera metadata but much like the conversation around framing it just seems out of scope right now. Am I misunderstanding out this is critical to the communication of an ACES viewing pipeline? We’d also discussed trying to minimize the use of attributes which obviously your metadata element proposal utilizes heavily. That’s just an detail but the key is scope and adoption.