Re: [Openexr-devel] EXR texture memory overhead

[Larry Gritz]

> On Sep 16, 2016, at 11:21 AM, Alexandre <address@hidden> wrote:
> Overall I wonder why I see users in the nature with so many untiled EXR files 
> (and what application is producing them) where tiled files seem to be much 
> more efficient for any application that is not scan-line based.

I think this is for historical and simplicity reasons: It's just easier to 
write a program that loops over scanlines (for y = ... for x = ...), than it is 
to process things in tiled order (let alone to have both the tiled and scanline 
cases supported). When you combine this with many file formats that don't 
support tiles at all, you get a lot of apps that just don't bother considering 
tiles. So even for formats like TIFF and OpenEXR that do support tiles, many 
readers and apps (<cough>Nuke<cough>) just don't bother reading tiles, so then 
other apps are careful not to write tiles for fear that they won't  be read 
properly, and the cycle continues.

But yeah, in general, things would be a lot better if tiled images were the 
norm.

In VFX, Nuke is a MAJOR culprit. Our renderer naturally produces tiles 
(theading divides the image up into tile-shaped buckets), but then we are 
forced to perform an extra full-image read and write of every output and AOV 
after the render is complete in order to convert the tiled outputs into 
scanline for subsequent compositing. It's super wasteful.

--
Larry Gritz
address@hidden