On Fri, Apr 15, 2011 at 5:27 AM, Florian Kainz <ka...@ilm.com> 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: g...@hobbelt.com mobile: +31-6-11 120 978 --------------------------------------------------
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/openexr-devel
