Loading half data directly about tinyexr HOT 7 CLOSED

Hello Andrew.

Yes, currently tinyexr doesn't output half image directly(tinyexr widen half pixel to float type).
Its rather easy to output half image as is, for example by adding preferred pixel type flag in LoadMultiChannelEXR.

from tinyexr.

In cdf93e6, I have added internal_pixel_types and internal_images field, which stores pixelType in .EXR and original fp16 value for half pixel image channel, respectively.

For other pixel type(i.e. FLOAT and UINT), internal_images[c] is set to NULL.

@andrewfb @richardeakin could you please try to use these field for fp16 texture?

from tinyexr.

I think this would address our immediate use case, but I wonder if there might be a more general solution. It seems to me TinyEXR has as a first priority making the standard RGBA case easy, with f32 being the most general type. However most of the makings for a generalized EXR read-write solution are already here; specifically reading f16 and uint types, as well as arbitrary channels. I think this could be achieved pretty easily, though it may require a 2-function API. As a suggestion:

EXRImage image;
ParseEXRFromMemory( &image, rawExrData ); // inits 'image'
LoadEXR( &image );
FreeExrImage( &image );

This of course is not an improvement in its own right; it would simply return float data by default. But it would allow something like this:

EXRImage image;
ParseEXRFromMemory( &image, rawExrData );
for( size_t c = 0; c < image.num_channels; ++c )
    image.requested_pixel_types[c] = TINYEXR_PIXELTYPE_HALF;
LoadEXR( &image );
half *channel0Data = (half*)image.images[0];
FreeExrImage( &image );

In this case, we've requested half data regardless of what's stored internally. The flow I would propose is that ParseEXRFrom(Memory|File) reads all of the data, but does no decompression, byte-swapping or conversion on it. That way the file handle can be closed immediately. Then LoadEXR() does all of the decompression / conversion necessary based on the data types in requested_pixel_types. This would also allow a user to ignore a channel by setting its requested type to TINYEXR_PIXELTYPE_NONE.

To my mind, something like this is the most generalized solution, and wouldn't require massive changes. We'd be up for collaborating on an experimental implementation to this effect if it's in line with your goals for TinyEXR. Thanks again for your work on it.

from tinyexr.

The other nice thing about a 2 step process is that it facilitates async loading, where you can retrieve header info, size etc synchronously up front, then issue the actual data load async, separately.

from tinyexr.

I have added ParseEXR*** and requested_pixel_types feature in loading/saving EXR.

f62d0e8

Please take a look of this change. Usage is written in test.cc or README.md

from tinyexr.

Thanks - this looks good from Cinder's perspective in terms of loading. I will experiment with saving in the next couple of days...

from tinyexr.

BTW do you need EXR saving feature for Cinder? Note that saving is not yet perfect(e.g. lineOrder is missing). PR is also welcome!

from tinyexr.