This looks reasonable to me. Almost every question I had was answered by the document,
One part that was unclear was 1.2, which talks about deep pixels and ad hoc encodings in the same paragraph. I feel like I could read 1.2 as deep pixels are, or are not, supported. I think they would be, but would suggest breaking the discussion of deep and ad hoc apart. I deduce also that you are proposing ASCII encoding, although I think UTF8 should be supported either as the designated encoding or as an option. The reason for this is that in my own work I like to designate ids with URI's and anticipate wanting to encode Japanese strings. Of course I could introduce my own secondary mapping of exr id to URI at the expense of extra work at my end, but I thought it's worth a bit of discussion. Similarly, it's not clear to me that a separating character like semicolon is necessary to be called out. If the intention is that there will be a set of standard tools that can parse the assignments, I can see the utility, but the counter examples like "tunic with leather" suggests general parsing is perhaps not anticipated. If semicolon is to be somehow special then I suggest that the manner of escaping semicolon also be described. Could be as simple as ;; or \; means a literal semicolon, not a separator. Happy to see new thoughts around EXR, - Nick p ________________________________ From: Openexr-devel <[email protected]> on behalf of Peter Hillman <[email protected]> Sent: Monday, August 14, 2017 8:23:51 PM Cc: [email protected] Subject: [Openexr-devel] Proposal for storing ID manifests in OpenEXR headers Hi all, As Deke mentioned earlier, At Siggraph I presented a proposal for an OpenEXR attribute to store ID manifests (i.e. a table that maps between text string names of entities and the numerical values encoded in the EXR image) Attached is an updated draft giving more details of this proposal. There are a few modifications from the earlier draft following suggestions from those attending Siggraph: many thanks to all those who commented. This is not a proposed complete single standard for storing IDs within OpenEXRs. There are reasons to choose one storage scheme over another depending on circumstances, suggesting that it is worthwhile to support different encoding schemes. The requirement for an ID manifest is a common requirement amongst those schemes. This document merely defines a standard attribute for encoding the manifest and for allowing it to be compressed. This should allow for a standard set of tools for reading, writing and examining the attribute. The intention is that I will implement this attribute in the next few months - certainly before the end of the year. Feel free to comment on the standard before then! Peter
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
