Hi Nick,
Thanks for your comments.
Yes, my section 1.2 is a little ambiguous: what I meant to say is that
this proposal for an attribute is 'storage agnostic': the manifest
should be compatible with most schemes for storing IDs in EXRs. It works
both for schemes that use regular images and those that use deep.
I pondered writing about UTF8 vs ASCII and decided not to for brevity.
As it stands, you can use UTF8 to encode strings: reserving the ASCII
'/' character (i.e. the byte code 0x2F) for hierarchy separation works
with pure ASCII as well as UTF8. My understanding is that in UTF8 the
byte range 0x00 to 0x7F always means ASCII characters; those bytes don't
appear in multibyte character representations, as those all have their
top bit set. There is something to be said for an attribute which
defines the character encoding used for all 'human readable' attributes
in an EXR, but that seems like a wider discussion.
The semicolon is 'semi-special' under this scheme. Using it in strings
shouldn't cause any errors. I wouldn't propose parsing strings
concatenated like that in any software. It might be handy to display a
concatenated name like "tunic;leather" and if there's a character which
is rarely used elsewhere (escaped or otherwise) things will be clearer
to read. If you are looking for a character to use for some special
meaning with object names, try picking something other than semicolon.
However, if you have a semicolon in your URI then don't bother changing
it or escaping it. That said, the / character being a hierarchy
separator will mean your URIs are likely to be treated as a hierarchy.
That may well be desirable; if not you will need to encode it differently.
Peter
On 16/08/17 05:59, Nick Porcino wrote:
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
