Re: [Openexr-devel] scanline order

[Florian Kainz]

Charles Henrich wrote:
> 
> It appears that there is a significant penalty for reading an exr in the
> opposite line order that the file is encoded with.  I would've assumed some
> additional overhead, but I was under the impression the EXR libraries were
> compressing in small enough chunks and storing offset information in the
> header to minimize this.  Is this correct or am I way off base here?
> 
> -Crh
> 
>        Charles Henrich           Digital Domain          address@hidden
> 
>                          http://www.sigbus.com/~henrich
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel

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.

When an application calls readPixels(), and the corresponding
blocks are not in memory, then the IlmImf library must read 
the blocks from the file.  While reading, the library keeps 
track of the current position in the file.  When it is time 
to read another block, the library compares the current 
position with the location of the block.  If necessary, the 
library calls seekg() to move the current position to the
beginning of the block.

Seekg() calls can be rather slow; how slow depends on the
underlying filesystem.  Unless the filesystem is stored on
a RAM disk, reading the file's scan lines in order, and thus
avoiding seekg() calls, is going to be significantly faster
than reading the file back to front or in random order.

Compared to reading the file front to back, reading it back
to front triggers one additional seekg() per block (for PIZ
compression, you get one seekg() for every 32 scanlines).