Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB
We published TIFF Technote 3 documenting all of that, but our developer relations group seems to keep losing it on the website. (LOOONG story behind that) Chris On 2/28/15 4:47 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Fri, 27 Feb 2015, Chris Cox wrote: Well, that's a bug that only Nuke can fix. I wonder if it would help if Adobe would release an official specification for float in TIFF as well as official sample files? ;-) There are a number of independent interoperable implementations based 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 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 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? ___ 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
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
Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB
On Fri, 27 Feb 2015, Chris Cox wrote: Well, that's a bug that only Nuke can fix. I wonder if it would help if Adobe would release an official specification for float in TIFF as well as official sample files? ;-) There are a number of independent interoperable implementations based 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 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 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? Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel -- Larry Gritz l...@larrygritz.com -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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
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
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? ___ 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
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 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
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 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? ___ 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
Well, that's a bug that only Nuke can fix. Chris From: Larry Gritz l...@larrygritz.commailto:l...@larrygritz.com Date: Friday, February 27, 2015 1:10 PM To: Chris Cox c...@adobe.commailto:c...@adobe.com, openexr-devel@nongnu.orgmailto:openexr-devel@nongnu.org openexr-devel@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 February 27, 2015 12:24:44 PM PST, Chris Cox c...@adobe.commailto: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.commailto: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.orgmailto:Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel -- Larry Gritz l...@larrygritz.commailto: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
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 whole path may not be loss free unless it is round-tripped in the same format. At one point, and with the notable exceptions of Cinepaint and some of the command-line-only programs, free/libre image editors mostly worked with 8-bit data. Things have changed. RawTherapee and darktable do all internal processing at 32f. Darktable allows saving to disk 32f OpenEXR and tiff. RawTherapee hasn't yet added support for outputting 32f images, but it's being worked on. GIMP 2.8 only works with 8-bit images internally. But GIMP 2.9 from git has worked with 32-bit images for several years now, does all processing at 32f, and provides input-output options for several high bit depth file formats. Krita, of course, has supported 32f images for a long time. 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 embedded ICC profiles and darktable recognizes the embedded ICC profiles, and vice versa. And so on. And so forth. Elle ___ 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
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 embedded ICC profiles and darktable recognizes the embedded ICC profiles, and vice versa. And so on. And so forth. 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. IMO, it would make much more sense to set colour space ranges per image and not hard coded. So, yes the Tiff spec is mostly silent about floating point data. Thus the implementation is at the discretion of each developer. Only one pice of information comes to mind. Greg Ward introduced at one point the nits tag. How are value ranges handled inside OpenEXR supporting applications? Are there conventions. Composing a candle light scene and a sun illuminated scene into one image appears not straight forward - maybe. ___ 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
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 Effects and Photoshop for some time. Code for the custom attribute is here: https://github.com/fnordware/openexrAE/blob/master/src/OpenEXR_iccProfileAttribute.h My rationale is simple: I can't prevent users from putting non-linear pixels into an EXR file. The color information I get from these programs is an ICC profile, so that's the metadata I store. (I also do my best to convert the ICC info to EXR standard attributes like chroaticity.) Brendan ___ 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
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 OpenEXR, IDCES and ODCES as explicitly named things, and a lot of other stuff. For example, the ACES 1.0 release carries a lot of the metadata as clip-level XML that the paper you reference proposes be carried as OpenEXR attributes The ACES 1.0 source and doc bundle can be reached from this page: http://www.oscars.org/science-technology/sci-tech-projects/aces And if you are going to be looking at how to make OpenEXR files for an ACES workflow, look at SMPTE ST 2065-4:2013, “ACES Image Container File Layout”. On 02/21/2015 07:10 PM, Gonzalo Garramuno wrote: This is handled by the ACESclip metadata and CTL. It allows you to have different Look Mod Transforms and save them along your image. Or a gradeRef to convert from and to a different space (like log) and apply ASC CDL transforms (SOPNode and SatNode). mrViewer supports the first variety and is in progress to support the second variety, too. Thanks! for the links and the clarification on how ACES is used with OpenEXR files. I've been peeping over my shoulder at the ACES workflow and how people in the world of cinema handle color management for a while now. The context of my question about the OpenEXR document on ACES wasn't about ACES per se but rather about how to use OpenEXR in a strictly photographic workflow, as a way to transport high bit depth RGB data between various photographic image editors that use ICC profile color management (the ACES-OpenEXR propsal mentions encoding nonlinear RGB data). 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 operations are performed directly on the RGB data to intentionally modify the scene-linear nature of the raw data that was captured by the camera. From the photographer's point of view, whether data should be exported as linear or nonlinear RGB depends on why the photographer wants to export the data. For example, if the goal is to rescale the image in another image editor, the data should be converted to a linear gamma ICC profile. But if the goal is adding or removing noise, usually the photographer will prefer results of operating on perceptually uniform data. The question of writing nonlinearly encoded RGB values as OpenEXR came up because the GIMP devs are currently working on GIMP's OpenEXR read/write code. We (I contribute to GIMP development, mostly in the area of ICC profile color management) want to accomodate the needs of photographers while making sure we follow OpenEXR specifications and best practices. On 02/21/2015 02:26 PM, Joseph Goldstone wrote: The Academy doc set is in the unfortunate position of trying to provide color-managed substrate around which digital motion picture workflows could be built, while trying to stay agnostic with regards to workflow and not provide a ‘best practice’ there. I’m not any sort of official spokesperson for the Academy (just an 11-years-on-the-committee worker bee) but I think they will stay agnostic, and see what kinds of workflows are developed by productions and by interested individuals. My guess is that over the next year the ACES discussion group at https://groups.google.com/forum/?hl=en#!forum/academyaces https://groups.google.com/forum/?hl=en#%21forum/academyaces will move a bit from developer conversations to user conversations. And I hope that, supplanting that discussion group which is pretty linear and textual, we’ll see ACES usage discussions on websites like your own (which I wish had been there in the early 2000s when I was trying to use littlecms for movie production). Does anyone use ACES in conjunction with ICC profile color management? If so, do they use OpenEXR to store RGB data? I wish OpenEXR supported ICC profile color management by means of embedded ICC profiles. If the data is converted to a linear gamma ICC profile before export as OpenEXR, then the chromaticities and white point can be used to construct an ICC profile. But many applications that do read ICC profiles, don't read or write OpenEXR chromaticities plus white point and don't have code that constructs ICC profiles from chromaticities plus white point. Elle ___ 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
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 list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB
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 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 list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ 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
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 that use ACES and ICC profiles convert their images to a 16 bit integer encoding before working with the data. The transfer function used for the encoding is usually one of the many flavors of log, like Cineon, ACEScc, LogC, a bespoke log-base2 transform and so-on. ICC profiles are then authored to expect data in that encoding. Example ICC profiles are included in the ACES 1.0 OCIO config's 'baked' directory. A growing number of people are painting directly on linear/HDR/scene-referred data as Photoshop has increased it's support for LUT formats that handle linear/HDR/scene-referred data more naturally than ICC. The Cinespace (.csp) LUT format seems to be gaining wider use in facilities that want to do this, as the format is now relatively well supported in Photoshop and a number of major applications used in VFX, like Nuke and Maya. Example .csp LUTs for the ACES and ACEScg space are also included in the ACES 1.0 OCIO config's 'baked' directory. I know your original question wasn't about ACES specifically, but hopefully that helps. If you have further questions about the ACES transforms, the OCIO config or the general ACES approach, feel free to ask directly, through the ACES Google Group or through the a...@oscars.org alias. We'd love to get feedback from the Gimp development team and user community. Regards, HP Duiker Consultant for The Academy On Sunday, February 22, 2015, Deke Kincaid dekekinc...@gmail.com wrote: 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 javascript:_e(%7B%7D,'cvml','ggarr...@gmail.com'); wrote: 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 list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ 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
Afaik, ocio supports color transforms, not color management, complementing icc. Ct~ changing the look within a given color space, or along a path of preconfigured color spaces. Cm~ preserving the look automatically between arbitrary color spaces having known arbitrary color characteristics. 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 Kincaid wrote: Hi Eli I would look at a project called OpenColorIO (OCIO). It is a common way many DCC applications handle color these days via luts, cdl and a variety of other color transforms. Through OCIO you could transform to scene linear, apply a viewer transform and have the appearance of working in some type of display referred space. It also includes a tool to bake icc files which is how the ACES profile for Photoshop was created. http://opencolorio.org/ http://opencolorio.org/userguide/baking_luts.html?highlight=icc https://github.com/imageworks/OpenColorIO There are ACES config files for ocio too https://github.com/imageworks/OpenColorIO-Configs Hi Deke, Right now GIMP only uses ICC profile color management and only works with display-referred print-oriented (electronic or paper) images. At some point in the future I'm pretty sure the plan is to accomodate HDR scene-referred editing, at which point implementing OCIO would be a really good thing to do. Even when that happy day arrives, many GIMP users will still want to use ICC profile color management. And other ICC profile color managed editing applications with which GIMP users might want to exchange high bit depth OpenEXR images, might not support OCIO. In the meantime, if you don't mind some (possibly really dumb) questions from someone who doesn't know anything at all about OCIO: 1. Can you configure OCIO to use information that in an ICC profile workflow is contained in the monitor's ICC profile? So that what is seen on the screen in an OCIO workflow looks like what you'd see in an ICC profile color-managed workflow? For example, my LCD monitor is not (and can't be) calibrated to exactly match sRGB. Rather it's profiled in its native state for maximum color gamut and smoothest tonal transitions. 2. Is there information on the web that explains OCIO color management to people like myself who've only ever used ICC profile color management? 3. In a strictly output-referred workflow - digital paintings or photographic editing of images that will be displayed as a paper print or on a display device - what advantage would there be in adapting OCIO/ACES rather than using an ICC profile color managed workflow? To put some context around this third question, many algorithms have been written to make photographic images instantly pretty and surely these algorithms can be encoded via luts, cdl and a variety of other color transforms. However, some photographers don't use automated tools to achieve instant pretty. Rather they analyze the image and process it part by part, as per the wet darkroom, where a flat print is made and then examined to determine where to apply dodging and burning to make the final print match the photographer's envisioned rendering. This latter approach involves using masks and layers to confine various processing steps to specific parts of the image. I'm not very clear on how/where this hands-on masks and layers approach to photographic image editing can be accomodated in an OCIO/ACES workflow. Elle ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ 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
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 RGB data? I wish OpenEXR supported ICC profile color management by means of embedded ICC profiles. If the data is converted to a linear gamma ICC profile before export as OpenEXR, then the chromaticities and white point can be used to construct an ICC profile. But many applications that do read ICC profiles, don't read or write OpenEXR chromaticities ___ 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
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 CTL transforms and they can be intermixed. However, is up to the user to remember what color space they are operating in. With ACES1.0, this becomes more difficult. As such, I suspect nobody uses that feature, sticking to using ICC profiles or CTL scripts only. My plan was to remove support for ICC, as CTL makes it obsolete. ___ 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
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 operations are performed directly on the RGB data to intentionally modify the scene-linear nature of the raw data that was captured by the camera. From the photographer's point of view, whether data should be exported as linear or nonlinear RGB depends on why the photographer wants to export the data. I'd say that irrespective of your image state, or the processing you want to perform, you should be writing linear rgb into openexr files. Otherwise, there are likely all sorts of interop landmines that will be stepped upon. There are some places, like lossy compressors, where data is assumed to be linear and transformed i to a perceptual space. Storing nonlinear data, and not marking the channels as 'pLinear', will yield less than ideal results. That said, this flag is really meant for things like color differences, and should not be interpreted as encouraging the storage of nonlinear rgb. ___ 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
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 ICC profile, before being saved to disk and then reopened in another editing application, whereupon a second ICC profile conversion would be required to transform the data back into the user's desired ICC profile RGB working space. This is handled by the ACESclip metadata and CTL. It allows you to have different Look Mod Transforms and save them along your image. Or a gradeRef to convert from and to a different space (like log) and apply ASC CDL transforms (SOPNode and SatNode). mrViewer supports the first variety and is in progress to support the second variety, too. ___ 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
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 and its use in actual production workflows, and to provide feedback to the author. However, the text below should not be regarded as a draft of what the Image Interchange Framework committee may recommend in the future. The committee's final recommendations may differ significantly from what is described here. 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 OpenEXR, IDCES and ODCES as explicitly named things, and a lot of other stuff. For example, the ACES 1.0 release carries a lot of the metadata as clip-level XML that the paper you reference proposes be carried as OpenEXR attributes. The ACES 1.0 source and doc bundle can be reached from this page: http://www.oscars.org/science-technology/sci-tech-projects/aces And if you are going to be looking at how to make OpenEXR files for an ACES workflow, look at SMPTE ST 2065-4:2013, “ACES Image Container File Layout”. The Academy doc set is in the unfortunate position of trying to provide color-managed substrate around which digital motion picture workflows could be built, while trying to stay agnostic with regards to workflow and not provide a ‘best practice’ there. I’m not any sort of official spokesperson for the Academy (just an 11-years-on-the-committee worker bee) but I think they will stay agnostic, and see what kinds of workflows are developed by productions and by interested individuals. My guess is that over the next year the ACES discussion group at https://groups.google.com/forum/?hl=en#!forum/academyaces will move a bit from developer conversations to user conversations. And I hope that, supplanting that discussion group which is pretty linear and textual, we’ll see ACES usage discussions on websites like your own (which I wish had been there in the early 2000s when I was trying to use littlecms for movie production). —joseph On Feb 21, 2015, at 5:00 AM, Elle Stone ellest...@ninedegreesbelow.commailto:ellest...@ninedegreesbelow.com wrote: 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 floating-point numbers (Technical Introduction to OpenEXR) should be interpreted to mean that OpenEXR RGB data should always be encoded as linear gamma data, and that reading and writing of non-linearly encoded RGB data shouldn't be supported. Though I'm sure there are wildly differing uses. There's no reason you couldn't create Rnonlinear, Gnonlinear, Bnonlinear channels or something similar, if you intend to break with convention. C The proposed ACES workflow using OpenEXR (UsingOpenEXRandCTL.pdf) discusses storing output data that's not scene-linear as part of an overall ACES workflow. For example page 11, ImageState, has three values: SCENE_LINEAR, INDIREDT_OUTPUT_REFERRED, and OUTPUT_REFERRED. When OUTPUT_REFERRED RGB data is stored, is it stored in something like Rnonlinear, Gnonlinear, Bnonlinear? Or does it just use bog-standard RGB, relying on the special metadata field to indicate the state of the data? In interest of full disclosure, I'm the only GIMP dev that's lobbying for letting the user decide how to encode data stored as OpenEXR, as dictated by the user's own purposes. I do agree that the concern to not violate officially sanctioned ways of using OpenEXR is an important concern. I think the devs would be much happier about allowing nonlinearly encoded RGB data if there were an officially sanctioned metadata field that would indicate nonlinear or better yet hold an ICC profile. But having kept tabs over the years on discussions about OpenEXR that start with can we have ICC profile support, I don't think that's very likely to happen any time soon. Elle ___ Openexr-devel mailing list Openexr-devel@nongnu.orgmailto:Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Openexr-devel mailing list Openexr-devel@nongnu.org
Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB
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 floating-point numbers (Technical Introduction to OpenEXR) should be interpreted to mean that OpenEXR RGB data should always be encoded as linear gamma data, and that reading and writing of non-linearly encoded RGB data shouldn't be supported. Though I'm sure there are wildly differing uses. There's no reason you couldn't create Rnonlinear, Gnonlinear, Bnonlinear channels or something similar, if you intend to break with convention. C The proposed ACES workflow using OpenEXR (UsingOpenEXRandCTL.pdf) discusses storing output data that's not scene-linear as part of an overall ACES workflow. For example page 11, ImageState, has three values: SCENE_LINEAR, INDIREDT_OUTPUT_REFERRED, and OUTPUT_REFERRED. When OUTPUT_REFERRED RGB data is stored, is it stored in something like Rnonlinear, Gnonlinear, Bnonlinear? Or does it just use bog-standard RGB, relying on the special metadata field to indicate the state of the data? In interest of full disclosure, I'm the only GIMP dev that's lobbying for letting the user decide how to encode data stored as OpenEXR, as dictated by the user's own purposes. I do agree that the concern to not violate officially sanctioned ways of using OpenEXR is an important concern. I think the devs would be much happier about allowing nonlinearly encoded RGB data if there were an officially sanctioned metadata field that would indicate nonlinear or better yet hold an ICC profile. But having kept tabs over the years on discussions about OpenEXR that start with can we have ICC profile support, I don't think that's very likely to happen any time soon. Elle ___ 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
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. Out of interest, what is your motivation for wanting to encode exr files with a non-trivial gamma? Piotr Hi Piotr, I'm not sure what you mean by non-trivial gamma. In an ICC profile color managed workflow using matrix profiles, the profile's tone reproduction curve (TRC) is commonly either the sRGB TRC or the lstar TRC or a simple gamma curve such as gamma=1.0, 1.8, or 2.2. The motivation for writing nonlinearly encoded RGB data is to use OpenEXR to transport high bit depth RGB data between various ICC profile color managed editing applications that can work at 32-bit floating point precision, for example Krita (painting), GIMP development branch (photographic editing), and darktable (raw processor). The RGB data that's being transported from one image editor to the next might be scene-linear. But more likely it's already been processed to be very far from scene-linear. So in this context OpenEXR is being used as a data container to transport data between applications that aren't expecting scene-linear data (though of course the data might be scene-linear, depending on the user's editing goal). 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 ICC profile, before being saved to disk and then reopened in another editing application, whereupon a second ICC profile conversion would be required to transform the data back into the user's desired ICC profile RGB working space. And on the other hand, there is a desire to read and write OpenEXR files in accordance with the online OpenEXR PDF documentation, which seems open to diverging interpretations. Elle ___ 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
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 IRC, for which I don't think there are logs. But it's a friendly channel if you want to ask a question or make a comment: irc://irc.gimp.org/#gimp Elle ___ 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
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) should be interpreted to mean that OpenEXR RGB data should always be encoded as linear gamma data, and that reading and writing of non-linearly encoded RGB data shouldn't be supported. Though I'm sure there are wildly differing uses. There's no reason you couldn't create Rnonlinear, Gnonlinear, Bnonlinear channels or something similar, if you intend to break with convention. C On Fri, Feb 20, 2015 at 12:45 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Hi all, 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. We are having a discussion about whether it's OK to read and write OpenEXR RGB files that aren't encoded using linear gamma RGB data. Some of us have argued that: * OpenEXR is a data container. * Nothing in the OpenEXR specifications forbids reading or writing non-linearly encoded RGB data. * After opening the file in an ICC profile color managed editing application, it should be up to the user to assign the correct ICC profile to interpret the data. 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) should be interpreted to mean that OpenEXR RGB data should always be encoded as linear gamma data, and that reading and writing of non-linearly encoded RGB data shouldn't be supported. We were hoping you all could shed some light on this question. Thanks in advance for advice as to whether there really is a requirement that OpenEXR RGB data always be encoded linearly. Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ 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, 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 wanting to encode exr files with a non-trivial gamma? Piotr On 20 February 2015 at 12:45, Elle Stone ellest...@ninedegreesbelow.com wrote: Hi all, 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. We are having a discussion about whether it's OK to read and write OpenEXR RGB files that aren't encoded using linear gamma RGB data. Some of us have argued that: * OpenEXR is a data container. * Nothing in the OpenEXR specifications forbids reading or writing non-linearly encoded RGB data. * After opening the file in an ICC profile color managed editing application, it should be up to the user to assign the correct ICC profile to interpret the data. 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) should be interpreted to mean that OpenEXR RGB data should always be encoded as linear gamma data, and that reading and writing of non-linearly encoded RGB data shouldn't be supported. We were hoping you all could shed some light on this question. Thanks in advance for advice as to whether there really is a requirement that OpenEXR RGB data always be encoded linearly. Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
