I have extreemly slow exr read speed in fu6.1
just put one loader with exr seq. play - and everage speed is 1.1 fps.
open this loader in Fu5.3 - speed is 2.2 fps.
somebody have this issues?
-------------EDIT
After reinstall - all became fine.
fuuf. strange.
Very Slow Exr Read Speed.
Started by
robocop
, Jul 01 2010 08:00 AM
6 replies to this topic
#1
Posted 01 July 2010 - 08:00 AM
#2
Posted 02 July 2010 - 08:05 AM
Hey Robo,
can you perhaps post some fps when working with large EXR files and seqs?
For me, maybe it sounds strange but, working with large EXRs / seqs is reeeeally a slow pain
in the ass.
cheers
naik
can you perhaps post some fps when working with large EXR files and seqs?
For me, maybe it sounds strange but, working with large EXRs / seqs is reeeeally a slow pain
in the ass.
cheers
naik
robocop, on 01 July 2010 - 08:00 AM, said:
I have extreemly slow exr read speed in fu6.1
just put one loader with exr seq. play - and everage speed is 1.1 fps.
open this loader in Fu5.3 - speed is 2.2 fps.
somebody have this issues?
-------------EDIT
After reinstall - all became fine.
fuuf. strange.
just put one loader with exr seq. play - and everage speed is 1.1 fps.
open this loader in Fu5.3 - speed is 2.2 fps.
somebody have this issues?
-------------EDIT
After reinstall - all became fine.
fuuf. strange.
#3
Posted 03 July 2010 - 03:50 AM
I can confirm this.
FU 6.1 or 6.0 = 3.5 Frames/sec
FU 5.3 = 4.5 Frames/sec
Full HD EXR
FU 6.1 or 6.0 = 3.5 Frames/sec
FU 5.3 = 4.5 Frames/sec
Full HD EXR
#4
Posted 07 July 2010 - 09:42 AM
Is there any difference in speed between 16 bit floating point and 32 bit floating point?
I understand the 16 bit float is compatible with the half data type for NVIDIA and is supported natively for their recent cards.
If there's a significant speed difference, it might be possible to develop the comp using 16 bit, and point the loader to 32 bit for the final render?
I understand the 16 bit float is compatible with the half data type for NVIDIA and is supported natively for their recent cards.
If there's a significant speed difference, it might be possible to develop the comp using 16 bit, and point the loader to 32 bit for the final render?
#5
Posted 08 July 2010 - 07:19 PM
I seem to recall that there are different methods for saving .exr files in your creation programs (3D or whatever). Something about "tiled" vs "scanline" flavors of saved files. I believe that Max 2011 now has an option for this, and that saving in "scanline" is much faster for other programs to load or open those files. I might not be 100% correct here, but I rememebr reading something about this recently...
Anyone know about this?
-David
Anyone know about this?
-David
#6
Posted 09 July 2010 - 03:57 AM
yes, the exr specification allows different types of exrs. tiled and scanline based methods, beside this there are different compression methods availible
in case of nuke its better to have the exrs in scanline mode with a 1zip compression. so the application can just read the scanline that is needed to process.
dont know how fusion handles this stuff, but i imagine its also better to have scanline exrs with 1zip compression
and 3dsmax has since the 2010 connection extension pack a new exr writer, in which you can specify to write out scanline exrs with 1zip compression and also DOD. this has a little downside on the rendering: max has to keep the whole image in memory until a scanline is complete before it can write it to disk and free the memory (in tile based mode it writes every rendered bucket to disk can free the memory)
in case of nuke its better to have the exrs in scanline mode with a 1zip compression. so the application can just read the scanline that is needed to process.
dont know how fusion handles this stuff, but i imagine its also better to have scanline exrs with 1zip compression
and 3dsmax has since the 2010 connection extension pack a new exr writer, in which you can specify to write out scanline exrs with 1zip compression and also DOD. this has a little downside on the rendering: max has to keep the whole image in memory until a scanline is complete before it can write it to disk and free the memory (in tile based mode it writes every rendered bucket to disk can free the memory)
#7
Posted 27 July 2010 - 06:35 PM
One thing that might speed up exr reading:
If your software has the ability to:
"shrink the data window of the layer to only encompass pixels that actually contain values within the layer.
OpenEXR images use the data window to define a rectangle that actually contains pixel values.
This may be smaller than the actual size of the image.
This is basically like a only saving a limited region of the final image,
---
exrTrader can do this when used with Lightwave.
If your software has the ability to:
"shrink the data window of the layer to only encompass pixels that actually contain values within the layer.
OpenEXR images use the data window to define a rectangle that actually contains pixel values.
This may be smaller than the actual size of the image.
This is basically like a only saving a limited region of the final image,
---
exrTrader can do this when used with Lightwave.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users













