Re: [Openexr-devel] scanline order

[Brian Willoughby]

[  > With ZIP and PIZ compression, pixels are stored in blocks of 16 or 32
[  > scanlines, respectively.  With RLE and ZIPS compression, pixels are stored
[  > in single-scanline blocks.
[
[  Anyway to alter this value in the writer to write in smaller chunks trading
[  off compression for accessability?  32 scanlines seems like a rather huge
[  chunk, especially for any "normal" size image?

Why not write an intermediate object (or subclass) which caches entire blocks?  
 The new object could query the block size and uncompress an entire block  
before returning an individual scan line.  Assuming that your access is  
sequential and not random, this should greatly speed up reverse line order at  
the expense of greater memory usage.  Of course, random access would generally  
show no improvement since the cache would rarely get used before being  
overwritten.

I'm assuming that there is a way to query the block size used by the  
underlying compression scheme.  Given this information, the new object would  
need to make some calculations to determine the start of the block for the  
requested scan line (in your example, the initial scan line requested would be  
the last scan line).  Further calculations would be needed to find the  
requested scan line within the decoded chunk, and to determine whether  
subsequent scan lines requested still can be found in the cache, or whether a  
new chunk should be uncompressed into the cache.

Your existing code would still see the same interface (witness the power of  
object-oriented programming :-) and yet would perform better in your use case.  
 
If your new class works well, it could be opened up to the project as helper  
code.

Brian Willoughby
Sound Consulting