Re: Proposal for storing ID manifests in OpenEXR headers
Nick Porcino <[email protected]> Tue, 15 Aug 2017 17:59:37 +0000
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <DM5PR1601MB13564E83D120816F37E68F58A48D0@DM5PR1601MB1356.namprd16.prod.outlook.com> |
--===============7291449841265203798== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DM5PR1601MB13564E83D120816F37E68F58A48D0DM5PR1601MB1356_" --_000_DM5PR1601MB13564E83D120816F37E68F58A48D0DM5PR1601MB1356_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This looks reasonable to me. Almost every question I had was answered by th= e 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 pixe= ls are, or are not, supported. I think they would be, but would suggest bre= aking 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 a= nd anticipate wanting to encode Japanese strings. Of course I could introdu= ce my own secondary mapping of exr id to URI at the expense of extra work a= t 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, b= ut 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 esc= aping semicolon also be described. Could be as simple as ;; or \; means a l= iteral 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 heade= rs Hi all, As Deke mentioned earlier, At Siggraph I presented a proposal for an OpenEX= R attribute to store ID manifests (i.e. a table that maps between text stri= ng names of entities and the numerical values encoded in the EXR image) Att= ached 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 Open= EXRs. There are reasons to choose one storage scheme over another depending= on circumstances, suggesting that it is worthwhile to support different en= coding schemes. The requirement for an ID manifest is a common requirement = amongst those schemes. This document merely defines a standard attribute fo= r encoding the manifest and for allowing it to be compressed. This should a= llow for a standard set of tools for reading, writing and examining the att= ribute. The intention is that I will implement this attribute in the next few month= s - certainly before the end of the year. Feel free to comment on the stan= dard before then! Peter --_000_DM5PR1601MB13564E83D120816F37E68F58A48D0DM5PR1601MB1356_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> This looks reasonable to me. Almost every question I had was answered by th= e document, <br> <br> 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 pixe= ls are, or are not, supported. I think they would be, but would suggest bre= aking the discussion of deep and ad hoc apart.<br> <br> 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 a= nd 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 wo= rth a bit of discussion.<br> <br> 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, b= ut the counter examples like "tunic with leather" suggests general parsing is perhaps not anticipated.<br= > <br> If semicolon is to be somehow special then I suggest that the manner of esc= aping semicolon also be described. Could be as simple as ;; or \; means a l= iteral semicolon, not a separator.<br> <br> Happy to see new thoughts around EXR,<br> <br> - Nick p<br> <br> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Openexr-devel <ope= nexr-devel-bounces+[email protected]> on behalf of Pe= ter Hillman <[email protected]><br> <b>Sent:</b> Monday, August 14, 2017 8:23:51 PM<br> <b>Cc:</b> [email protected]<br> <b>Subject:</b> [Openexr-devel] Proposal for storing ID manifests in OpenEX= R headers</font> <div> </div> </div> <div>Hi all,<br> <br> As Deke mentioned earlier, At Siggraph I presented a proposal for an OpenEX= R attribute to store ID manifests (i.e. a table that maps between text stri= ng names of entities and the numerical values encoded in the EXR image) Att= ached is an updated draft giving more details of this proposal. There are a few modifications from the earl= ier draft following suggestions from those attending Siggraph: many thanks = to all those who commented.<br> <br> This is <i>not</i> a proposed complete single standard for storing IDs with= in OpenEXRs. There are reasons to choose one storage scheme over another de= pending on circumstances, suggesting that it is worthwhile to support diffe= rent encoding schemes. The requirement for an ID manifest is a common requirement amongst those schemes. This doc= ument merely defines a standard attribute for encoding the manifest and for= allowing it to be compressed. This should allow for a standard set of tool= s for reading, writing and examining the attribute. <br> <br> The intention is that I will implement this attribute in the next few month= s - certainly before the end of the year. Feel free to comment on the= standard before then!<br> <br> Peter<br> <br> <br> </div> </body> </html> --_000_DM5PR1601MB13564E83D120816F37E68F58A48D0DM5PR1601MB1356_-- --===============7291449841265203798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel --===============7291449841265203798==--