Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Chris Cox]

Well, that's a bug that only Nuke can fix.

Chris


From: Larry Gritz mailto:l...@larrygritz.com>>
Date: Friday, February 27, 2015 1:10 PM
To: Chris Cox mailto:c...@adobe.com>>, 
"openexr-devel@nongnu.org 
openexr-devel@nongnu.org" 
mailto:openexr-devel@nongnu.org>>
Subject: Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

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 
mailto: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" 
mailto: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?




Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Larry Gritz]

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  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" 
>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?
>
>
>___
>Openexr-devel mailing list
>Openexr-devel@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/openexr-devel

-- 
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Elle Stone]

On 02/27/2015 03:24 PM, Chris Cox 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, thanks! I've been wondering about that for a while, whether 
32-bit floating point OpenEXR somehow was able to accomodate more stops 
of information than 32-bit floating point tiff. So what matters is the 
bit depth, and not whether it's OpenEXR or tiff.


Elle



On 2/27/15 6:44 AM, "Elle Stone"  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?


___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Chris Cox]

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"  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?


___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Kai-Uwe Behrmann]

Am 27.02.2015 um 15:44 schrieb Elle Stone:
> On 02/23/2015 02:42 PM, Kai-Uwe Behrmann wrote:
>> LCMS is just one CMM, with its prefered set of min and maximal values
>> for certain colour spaces. I could never find it convincing to have
>> CIE*L expressed in % in LCMS, the same goes for Cmyk - a printing space.
>> But LCMS uses these fixed value ranges from inbuild defaults.
>
> I'm not sure what you mean by "fixed value ranges from inbuild defaults".
>
> Since LCMS version 2 there is no clipping during conversions from RGB
> to LAB, XYZ, or another RGB color space. There's also no clipping upon
> export as long as the file format can hold 32-bit floating point RGB
> values outside the range 0-1 floating point.

Oh, I wrote from remembering lcms1, which is not much used these days.
You are right that the default value range changed with lcms2 to 0-1 for
floating point, which appears good to me.

> Of course there are precision limitations on how high those 32-bit
> floating point tiff values can go before there's too little precision
> for useful image editing, though I don't know where the line should be
> drawn.

Wikipedias Logluv_TIFF article links to the following:
http://www.anyhere.com/gward/hdrenc/hdr_encodings.html

> 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?


___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Elle Stone]

On 02/23/2015 02:42 PM, Kai-Uwe Behrmann wrote:

LCMS is just one CMM, with its prefered set of min and maximal values
for certain colour spaces. I could never find it convincing to have
CIE*L expressed in % in LCMS, the same goes for Cmyk - a printing space.
But LCMS uses these fixed value ranges from inbuild defaults.


I'm not sure what you mean by "fixed value ranges from inbuild defaults".

Since LCMS version 2 there is no clipping during conversions from RGB to 
LAB, XYZ, or another RGB color space. There's also no clipping upon 
export as long as the file format can hold 32-bit floating point RGB 
values outside the range 0-1 floating point.


The only limitation on these "unbounded" LCMS2 ICC profile conversions 
is the profile tone reproduction curve. It has to allow unambiguous 
extrapolation below zero and above 1.


GIMP 2.9 can import, create, and export 32-bit floating point tiffs with 
RGB values much greater than 1.0, and also less than zero if such values 
have been created during ICC profile conversions or editing.


Of course there are precision limitations on how high those 32-bit 
floating point tiff values can go before there's too little precision 
for useful image editing, though I don't know where the line should be 
drawn.


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?


Elle





___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel