A couple of things to bear in mind: You should handle -ve values with care with pow. You might clip, or mirror or do something else entirely. You may or may not have needs and control of your pipe so that you could do a round trip ...
The round trip, half to float is lossless, but as you point to, the other way is not, we are loosing bits afterall. There is care in the design so that the deltas are contained in frequent parts of the image. Off the top of my head I can't remember if we published the docs on the number representations ... but there is a reference to the IEEE standard in the Technical Introduction that will shed light on the behaviour. Piotr On 30 April 2014 13:03, Gonzalo Garramuno <[email protected]> wrote: > On 30/04/14 16:30, Paul Miller wrote: > >> >> pow() doesn't like negative values, and I've seen different results on >> different machines. You should clip negatives before calling it. >> >> Thanks. That was part of the problem. However, I still don't get a > clean transition from float to half uint16. There are differences in the > result between calling exr_halflt2uint( uint16_t ) and doing > exr_half2float(uint16_t) + exr_flt2uint(uint32_t). > My guess is that it is because conversion from float to half is lossy. > > > > _______________________________________________ > Openexr-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel >
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
