Outstanding, thanks! I was going to send you guys a separate email, but just
hadn't quite gotten to it yet.
OIIO already reads these fp16 TIFF files just fine, but the code to enable
writing them is currently '#if 0'ed out (instead, it automatically promotes
half pixels to float when outputting TIFF). As soon as it's safe, I will
re-enable it. Unfortunately, "safe" means not only fixed in Nuke (and other
apps where it's broken), but also letting enough time go by for those fixed
versions to proliferate to minimize the number of people who will get bitten by
the problem any time they do a sequence of image operations that starts with a
half exr and ends with TIFF (all other things being equal, it will try to write
with the same data type as the input, and then kapow).
-- lg
On Feb 28, 2015, at 1:26 PM, Deke Kincaid <dekekinc...@gmail.com> wrote:
> I bugged this internally at The Foundry when I saw your pull request on oiio
> a week or so back.
>
> If anyone really wants it email our support and refer to this id: Bug 47739
> - Add half float support to Tiff
>
>
> On Friday, February 27, 2015, Larry Gritz <l...@larrygritz.com> wrote:
> TIFF spec addenda may support fp16, but Nuke (among many other apps) doesn't
> read it correctly, which makes it nearly useless on a VFX pipeline.
>
>
>
> On February 27, 2015 12:24:44 PM PST, Chris Cox <c...@adobe.com> wrote:
> No, 32 bit float is 32 bit float.
> And TIFF supports 16 (half, same as EXR), 24, and 96 bit float formats as
> well.
>
>
> Chris
>
>
>
>
>
> On 2/27/15 6:44 AM, "Elle Stone" <ellest...@ninedegreesbelow.com> wrote:
>
> Are there differences in the number of stops that can be held in 32-bit
> floating point tiffs vs 32-bit floating point OpenEXR images?
>
>
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
