Re: [Openexr-devel] is tile order important?

[Florian Kainz]

Axel Waggershauser wrote:
> Hi, 
>
> I wondered if the order in which the tiles are written to disk is
> important/influential to the result on disk, i.e. for best read
> performance should I write/read the tiles in a specific order? What
> about mipmap levels, should I start with the lowest or the highest
> level?

For optimum performance, you should read the tiles in the
order in which they were stored in the file.  Doing this
avoids potentially slow seek operations.

The order in which the tiles are stored is controlled by the
lineOrder attribute in the file's header.  If you set lineOrder
to RANDOM_Y, each tile is stored soon as you call writeTile().
With INCREASING_Y or DECREASING_Y lineOrder, the library
sorts the tiles into a fixed order.  For details, see the
"File Structure" section in http://www.openexr.com/details.html.

> I have tried to write partial mipmap files, meaning, I omitted the
> levels with smaller data window size than the tile size, since I am not
> interested in them anyway. I could read the images but the open
> operation took ages, compared to a complete file. Is it meant to be that
> way?

You should write all levels of a mipmap file.  The file
contains a "tile offset table" that allows quick random
access to the tiles.  The table is stored in the file only
after all tiles have been written.  If you omit any tiles,
the table in the file will be empty.

When you open an incomplete file for reading, the library
notices that the tile offset table is not valid, and scans
the entire file in order to reconstruct the table.  This
happens in the constructor for your input file object, so yes,
opening the file will take a lot longer.  Once the file is open,
you should see no speed difference compared to a file without
missing tiles.  If you try to read one of the missing tiles,
the library throws an exception.

When Wojciech Jarosz implemented tiled files, we considered
supporting mipmap files with missing tiles or levels, but we
decided against it.  The most common case would be omitting
the lowest-resolution mipmap levels, but those levels take
up only a small amount of file space anyway.  (Tiles that
extend beyond the data window are cropped before they are
stored in the file; the lowest-resolution level really
contains only one pixel).
However, omitting tiles or levels makes reading a mipmap file
more complicated:  The library could provide a method to test
if a given tile is present in the file, but this would force
applications to call this method before every tile read.
Alternatively, the library could return a tile filled with
default values when the application tries to read a missing
tile, but this could cause texture-mapping artifacts.
The appearance of textured objects could change dramatically
if their orientation or their distance from the camera
changes.