I can already tell you -- since you are starting with 8 bit data, you'll be 
better off with TIFF because it natively supports 8 bit channels.  OpenEXR does 
not -- it will have to up-convert to 'half' (16 bit floating point), and 
furthermore, the ImageCache/TextureSystem internally converts half to float for 
storage in the in-memory cache.  


On Oct 12, 2012, at 9:37 AM, Michel Lerenard wrote:

> Thanks for these examples. That's exactly what I need.
> 
> I'll run the same test and will compare EXR and Tiff to see if one format is 
> better than the other.
> 
> On 10/11/2012 06:32 AM, Larry Gritz wrote:
>> 
>> Even when using automip and autotile, you're going to get horrible 
>> performance if your texture cache size is not at least big enough to hold 
>> the image.
>> 
>> For JPEG images, we're just calling the underlying libjpeg, we ask for 
>> scanlines in batches, but I can't swear to the efficiency of libjpeg, for 
>> all I know it tries to read the whole thing at once and buffer it.  I can 
>> vouch more strongly for libtiff and OpenEXR.  
>> 
>> For film anyway, JPEG is considered a poor texture format because it doesn't 
>> support alpha channels, is only 8 bits, is lossy, and doesn't have any 
>> notion of MIP-mapping.  So we figured it was so ill-suited to the task that 
>> the requirement was simply to make it work, not to make it very efficient 
>> for huge files.  For that, we turn to TIFF and OpenEXR, which tend to 
>> satisfy the whole range of requirements of a good texture format.
>> 
>> If you must use this JPEG file in its original form, assuming you have 
>> memory to burn, I would advise using a 2 GB cache.  256 or 512 MB is just 
>> too small, that will force it to constantly need to re-read sections of the 
>> image.
>> 
>> You can convert it to a tiled format with
>> 
>>  iconvert world.topo.bathy.200411.3x21600x21600.C1.jpg --tile 64 64 tiled.tif
>> 
>> Took me 48 seconds (including I/O), and the file is 415 MB (versus 43 MB for 
>> the original JPEG -- but that's because it's a lossy format)
>> 
>> That will get it tiled, which should make a big difference.  Additionally 
>> making into a full MIP-mapped, tiled texture, via
>> 
>>  maketx world.topo.bathy.200411.3x21600x21600.C1.jpg -o mipped.tx
>> 
>> That took 3 minutes and needed several GB of RAM (it's a huge file!), and 
>> results in a 550 MB tiled MIP-mapped TIFF file, which should be extremely 
>> efficient to texture map.
>> 
>> 
>> 
>> On Oct 10, 2012, at 7:33 AM, Lerenard Michel wrote:
>> 
>>> Hi,
>>> 
>>> Brecht: thanks for your answers, it does clear things a bit.
>>> I've enabled automap and autotile options. It does solve the memory issue, 
>>> but i get horrible peformance instead: on small files it works with 
>>> overhead, on the huge one below it was so slow i had to stop the rendering 
>>> process.(using the default 256 cache value)
>>> 
>>> Larry: the file i use to test is a huge JPEG, => 
>>> http://eoimages.gsfc.nasa.gov/images/imagerecords/73000/73884/world.topo.bathy.200411.3x21600x21600.C1.jpg
>>> that can be found on this page: 
>>> http://visibleearth.nasa.gov/view.php?id=73884
>>> 
>>> 
>>> After thoses tests, i think i'm going to work with temp images in EXR, 
>>> converted from formats that does not support tiles: 
>>> the cache does work correctly in this case. (i checked with a 250Mo tiled 
>>> exr file)
>>> I have not yet tested maketx, i don't know if it's a fast process, but it 
>>> seems to be a good candidate to do the work.
>>> 
>>> 
>>> --------------
>>> Michel
>>> [email protected]
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> 
>> --
>> Larry Gritz
>> [email protected]
>> 
>> 
>> 
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected]


_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to