: Larry Gritz l...@larrygritz.com
Date: Friday, February 27, 2015 1:10 PM
To: Chris Cox c...@adobe.com, openexr-devel@nongnu.org
openexr-devel@nongnu.org openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB
TIFF spec addenda may support fp16
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
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
on the unofficial Adobe draft and sample files.
Bob
Chris
From: Larry Gritz l...@larrygritz.com
Date: Friday, February 27, 2015 1:10 PM
To: Chris Cox c...@adobe.com, openexr-devel@nongnu.org openexr-devel@nongnu.org
openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] OpenEXR files
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
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
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
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),
@nongnu.orgmailto:openexr-devel@nongnu.org
openexr-devel@nongnu.orgmailto: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 02/23/2015 12:08 PM, Bob Friesenhahn wrote:
Most free/libre editing applications do not natively use floating
point to store internal raster data and they display their data using
interfaces which only support 8 integer bits per sample. OpenEXR is
useful to store floating point data. The
Am 23.02.15 um 18:46 schrieb Elle Stone:
On 02/23/2015 12:08 PM, Bob Friesenhahn wrote:
However, floating point TIFF and ICC do not normally go hand in hand.
I'm confused by this statement. LCMS reads and writes ICC profiles
embedded in floating point tiffs. GIMP 2.9 exports 32f tiffs with
On Feb 20, 2015, at 12:45 PM, Elle Stone wrote:
I'm involved with GIMP development as it pertains to ICC profile color
management. GIMP is primarily used for processing photographic images and for
creating digital art.
As Lars said, I've been writing EXR files with ICC profiles from After
On 02/21/2015 02:26 PM, Joseph Goldstone wrote:
The ACES committee (an unfortunate change of name from the Image
Interchange Framework committee) agreed with Florian on much of what was
published in this document, but let go of indirect output referred
imagery or output referred imagery in
On 22/02/15 11:32, Deke Kincaid wrote:
Hi Eli
There are ACES config files for ocio too
https://github.com/imageworks/OpenColorIO-Configs
Please note that these config files seem to not have been updated for
ACES1.0 yet.
___
Openexr-devel mailing
Ahh right, they are still in HP's fork here:
https://github.com/hpd/OpenColorIO-Configs
On Sunday, February 22, 2015, Gonzalo Garramuno ggarr...@gmail.com wrote:
On 22/02/15 11:32, Deke Kincaid wrote:
Hi Eli
There are ACES config files for ocio too
Hello Elle,
I put together the ACES 1.0 OCIO config for The Academy. Hopefully I can
help answer some of your questions.
Specifically, you asked
Does anyone use ACES in conjunction with ICC profile color management? If
so, do they use OpenEXR to store RGB data?
We have found that many people
.
Lars Borg
Adobe
Typos generously provided by the phone
Original message
From: Elle Stone
Date:02/22/2015 8:09 AM (GMT-10:00)
To: Deke Kincaid
Cc: openexr-devel@nongnu.org
Subject: Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB
On 02/22/2015 09:32 AM, Deke
After Effects uses icc profiles with exr.
Lars Borg
Adobe
Typos generously provided by the phone
Original message
From: Elle Stone
Date:02/22/2015 3:59 AM (GMT-10:00)
Does anyone use ACES in conjunction with ICC profile color management?
If so, do they use OpenEXR to store
On 22/02/15 15:35, Lars Borg wrote:
Original message
From: Elle Stone
Date:02/22/2015 3:59 AM (GMT-10:00)
Does anyone use ACES in conjunction with ICC profile color management?
If so, do they use OpenEXR to store RGB data?
My viewer, mrViewer supports ICC profiles as well as
The specific question was whether photographic image editors should allow
writing nonlinearly encoded RGB data to OpenEXR files, or whether instead
the RGB data should be converted to a linear gamma ICC profile before being
exported as OpenEXR.
In the usual photographic workflow, editing
On 21/02/15 21:09, Gonzalo Garramuno wrote:
On 21/02/15 07:28, Elle Stone wrote:
On 02/20/2015 09:03 PM, Piotr Stanczyk wrote:
So on the one hand, it seems arbitrary and pointless to insist that
data be converted from whatever ICC profile working space the user
has chosen, to a linear gamma
There’s this paragraph on page 1:
At this time the committee's work is not complete, and several aspects of what
is described below are not fully resolved. This document does not attempt to
define a standard. The goal of this document is to encourage interested parties
to experiment with CTL
On 02/20/2015 04:03 PM, Christopher Horvath wrote:
I would strenuously argue this is correct for the R, G, B channels,
specifically:
Others have maintained that statements in the OpenEXR documentation
such as By convention, OpenEXR stores scene-referred linear values
in the RGB
On 02/20/2015 09:03 PM, Piotr Stanczyk wrote:
Elle,
The intent is very much that of a scene linear encoded data for colour
data in an OpenEXR file.
Of course, you can put anything in there you like, but of the
applications I am aware of all will interpret the data as linear, scene
referred.
On 02/21/2015 12:19 PM, Piotr Stanczyk wrote:
Thanks Elle,
When you have a moment, could you post a link to this group to the gimp
conversation, if possible?
Piotr
Part of the conversation is in a bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=316646
Part of the conversation was on
I would strenuously argue this is correct for the R, G, B channels,
specifically:
Others have maintained that statements in the OpenEXR documentation such
as By convention, OpenEXR stores scene-referred linear values in the RGB
floating-point numbers (Technical Introduction to OpenEXR)
Elle,
The intent is very much that of a scene linear encoded data for colour data
in an OpenEXR file.
Of course, you can put anything in there you like, but of the applications
I am aware of all will interpret the data as linear, scene referred.
Out of interest, what is your motivation for
27 matches
Mail list logo
