Re: Per-pixel Object Identifiers?

--===============6580301672399813169==
Content-Type: multipart/alternative; boundary=90e6ba1f0078d1f16e04a0f6eaba

--90e6ba1f0078d1f16e04a0f6eaba
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 15, 2011 at 5:27 AM, Florian Kainz <[email protected]> wrote:

> In the file, the objectID attribute will store the mapping from pixel
> values
> to lists of strings in a compact form, without any indexing structure.  The
> data will be expanded into a form that can be queried quickly during
> reading,
> and packed tightly during writing.  The in-memory form of the attribute
> will
> probably consist of two STL maps (which are usually implemented as RB trees
> or AVL trees).
>

I can see why you'ld want to do it that way (and it's far more in line with
how openEXR 'does' EXR files right now than my 'direct access' thought) but
that approach is much less useful for me as it's no big improvement over
what I have currently (one channel at int per pixel plus external
direct-access (mapped) store). Alas.

If you're going to store the strings in compacted form, I guess applying
zlib to them is the easiest way to get a nice size reduction. (I've played
with suffix trees and such for 'optimal' storage of strings before (kinda
delta compression on string data), but it's a lot of hassle and little gain
over feeding zlib an ordered stream of string+meta data (index number or
other) to compress, particularly when you're doing a transform (to STL maps)
on write and read anyway. And since we already have a zlib dependency...
Thanks for giving me the idea to store more than just a few bytes in
attributes in an EXR though, i.e. treating an attribute as a BLOB store,
where the blob might even be larger than the image data itself. That hadn't
crossed my mind before. Sometimes the simplest things... :-)

-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

--90e6ba1f0078d1f16e04a0f6eaba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Apr 15, 2011 at 5:27 AM, Florian Kainz <=
span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex;">
In the file, the objectID attribute will store the mapping from pixel value=
s<br>
to lists of strings in a compact form, without any indexing structure. =A0T=
he<br>
data will be expanded into a form that can be queried quickly during readin=
g,<br>
and packed tightly during writing. =A0The in-memory form of the attribute w=
ill<br>
probably consist of two STL maps (which are usually implemented as RB trees=
<br>
or AVL trees).<br></blockquote><div><br></div><div>I can see why you&#39;ld=
 want to do it that way (and it&#39;s far more in line with how openEXR &#3=
9;does&#39; EXR files right now than my &#39;direct access&#39; thought) bu=
t that approach is much less useful for me as it&#39;s no big improvement o=
ver what I have currently (one channel at int per pixel plus external direc=
t-access (mapped) store). Alas.</div>
<div><br></div><div>If you&#39;re going to store the strings in compacted f=
orm, I guess applying zlib to them is the easiest way to get a nice size re=
duction. (I&#39;ve played with suffix trees and such for &#39;optimal&#39; =
storage of strings before (kinda delta compression on string data), but it&=
#39;s a lot of hassle and little gain over feeding zlib an ordered stream o=
f string+meta data (index number or other) to compress, particularly when y=
ou&#39;re doing a transform (to STL maps) on write and read anyway. And sin=
ce we already have a zlib dependency...</div>
<div>Thanks for giving me the idea to store more than just a few bytes in a=
ttributes in an EXR though,=A0i.e. treating an attribute as a BLOB store, w=
here the blob might even be larger than the image data itself. That hadn&#3=
9;t crossed my mind before. Sometimes the simplest things... :-)</div>
<div><br></div><div>--=A0</div></div>Met vriendelijke groeten / Best regard=
s,<br><br>Ger Hobbelt<br><br>----------------------------------------------=
----<br>web:=A0 =A0 <a href=3D"http://www.hobbelt.com/">http://www.hobbelt.=
com/</a><br>
=A0 =A0 =A0 =A0 <a href=3D"http://www.hebbut.net/">http://www.hebbut.net/</=
a><br>mail:=A0=A0 <a href=3D"mailto:[email protected]">[email protected]</a><br=
>mobile: +31-6-11 120 978<br>----------------------------------------------=
----<br><br>


--90e6ba1f0078d1f16e04a0f6eaba--


--===============6580301672399813169==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Openexr-user mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/openexr-user

--===============6580301672399813169==--