Color space transform bidirectionality
Alan Jones <sky...@...>
Hi All,
I'm just reading through the Nuke plugin to get an idea of the API and how things are supposed to work together. I notice that it adds all color spaces to both the input and output. This assumes that all color transforms can be reversed. I was under the impression that some transforms would not be. Is there any facility within OCIO's current design for this? Cheers, Alan.
|
|
Re: Color space transform bidirectionality
Jeremy Selan <jeremy...@...>
Alan,
toggle quoted messageShow quoted text
OCIO is being a bit clever under the hood, though in my opinion not in a dangerous way. OCIO's currently approach is that to make colorspace definitions "convenient", we assumes inverse color transforms are allowed when the round-trip can automatically be made 100% accurately. I.e, if your colorspace definition is only built from cleanly invertible ops (simple cc math, matrix ops, log, 1D lookup tables), and is round-trip safe, the inverse transform is allowed. If your colorspace definition relies on 3D LUTs, any attempt to run the inverse transform will fail during the getProcessor call. (If you try to add a 3d lut to nuke and try to perform the inverse you'll see this). I'd love to figure out a way to make this more explicit in the API. Suggestions? The reason we defer the inverse 3d lut check to this late part in the API is to allow for the following interesting possibility. Say you have 2 display emulation colorspaces defined as follows. srgb: (A normal filmlook) lin_to_log.lut1d log_to_srgb.lut3d srgb_warm: (A warmer filmlook varient). lin_to_log.lut1d log_to_srgb.lut3d warm.mtx Say you have pixels in a baked srgb representation, and you wanted to view them with the warm look. Internally, our processing chain would look like: INPUT -> inverse log_to_srgb.lut3d -> inverse lin_to_log.lut1d -> lin_to_log.lut1d -> log_to_srgb.lut3d -> warm.mtx -> OUTPUT But, OCIO ( will soon) optimize this to a simplified conversion: INPUT -> warm.mtx -> OUTPUT This particular color space transformation, although conceptually requiring an inverse 3d lut, doesnt actually end up using it! Which is pretty cool, and really convenient in practice. This is why in Nuke we just blindly added all color spaces to both the input and output side, to allow for these circumstances. I can see this is subtle though, and potentially misleading from a new user perspective. Thoughts? -- Jeremy
On Mon, Aug 23, 2010 at 1:53 PM, Alan Jones <sky...@...> wrote:
Hi All,
|
|
Re: Color space transform bidirectionality
Alan Jones <sky...@...>
Hi Jeremy,
On Mon, Aug 23, 2010 at 4:30 PM, Jeremy Selan <jeremy...@...> wrote: OCIO's currently approach is that to make colorspace definitionsFor practical purposes those are all probably invertible, but even a 1D lut can lose information (such as everything below black point getting pushed to 0 - though seeing that information isn't required it doesn't really matter). I'm not a fan of putting too much effort into protecting users from their own stupidity ;) An uninvertible matrix could also happen, but again, probably not in practice. I'd love to figure outThat depends - you make a good usage case that somewhat goes out the window. The only real solution (which unfortunately cuts down your options for processing shortcuts and also limits what LUTs you can bring in) I can think of is something like follows. A color space is defined and it is always defined relative to scene referred linear. This way for each space it knows how to convert to or from scene referred and nothing else. Then when it registers it can say which directions it can handle. You kind of also need to define types of LUTs at this point though. I'm thinking of three. Storage LUTs (which pull data two and from representations used for storage, such as S-Log etc), Grading LUTs (which are designed to apply a particular look whether that's a color grade or a film transfer representation), and Display LUTs (which modify values to ensure that it displays correctly on a given device - i.e. sRGB, Rec709 etc). With this storage LUTs would go from whatever their storage form across to scene referred linear usually (though you'd use the reverse for saving perhaps) then the grading LUTs would make any changes to the color (if you had some magical linear display then this data would look correct on that display, but the grading LUTs wouldn't be used until the end as not to screw the radiometric linearity of your data). The finally with that data you apply the display LUT for your output device. So it'd be 1 Storage LUT 0+ Grading LUTs 1 Display LUT as the common workflow. I've got no idea how well this aligns with the design goals of OCIO as I'm just getting familiar with it, but that's how I'd look at structuring things to help define the process so it's more accessible to less technical users. It's pretty much what I'm planning on putting in place in the pipeline I'm building here, but on a pipeline wide scale where at ingest everything is shifted to radiometrically linear space and stored in float (well probably half-float for most cases) on disk. Then people working in lighting/comp would have grading+display LUTs applied on the fly so they're looking at as close to final as possible. I'd be interested to hear your thoughts. Cheers, Alan.
|
|
OCIO 0.5.13 posted
Jeremy Selan <jeremy...@...>
Version 0.5.13 (Aug 18 2010):
* GPU Processing now supports High Dynamic Range color spaces * Added log processing operator, and updates to many other ops * Numerous bug fixes + updates to python glue * Exposed PyOpenColorIO header, for use in apps that require custom python glue * Matrix op is optimized for diagonal-only subcases * Numerous updates to Nuke Plugins (now with an addition node, OCIODisplay) All code available from github and google code (as usual). We're in the process of porting Katana (our internal lighting and compositing tool) to OCIO, and work is progressing well. (Our target completion date is mid Sept). Katana happens to be a nice testbed for OCIO development - utilizing both the GPU + CPU code paths, and also having a prior (similar) color management implementation as a reference sanity check).
|
|
Re: Color space transform bidirectionality
Jeremy Selan <jeremy...@...>
Alan,
toggle quoted messageShow quoted text
Sorry for the delay in responding. (Had to attend to non-OCIO responsibilities this week). The approach you describe is exactly in line with what I've been thinking. Excellent. A few additions: You refer to the different LUT types as "storage, grading, and display". In the currently library we dont draw hard lines between the different transform uses. All three of these would be color spaces, and are treated equally in the code. Adapting your terminology to OCIO, "storage" color spaces would always provide transforms both to and from scene linear, display color spaces typically would only define a transform from scene linear, and grading spaces would be defined dynamically at runtime. But there's no code-level distinction between the types. Is there any benefit to doing so? I've been thinking about adding metadata (tags) that will let the user tag color spaces as belonging to different categories. (such as 'display', 'IO', etc). This would probably help in the UI (you could filter by tag), but I cant think of any other uses so it's a bit low on the priority list. * You refer to these things all as LUTs. I'd prefer to just call them "transforms" to leave open the possibility of other correction math. (For example, the grading lut could just as easily be a 1D lut, a 3D lut, or a ASC-CDL). Your processing pipeline is already expressed in the DisplayTransform. You specify the storage LUT (inputColorSpace), the displayLut (outputColorSpace), and also optional color correction(s). (Which can occur in any color space, including scene linear or a log-like DI space). The Nuke OCIODisplay node provides an example of using this API. -- Jeremy
On Mon, Aug 23, 2010 at 2:59 PM, Alan Jones <sky...@...> wrote:
Hi Jeremy,
|
|
Re: Color space transform bidirectionality
Alan Jones <sky...@...>
Hi Jeremy,
On Fri, Aug 27, 2010 at 4:18 PM, Jeremy Selan <jeremy...@...> wrote: Sorry for the delay in responding. (Had to attend to non-OCIONo worries :) The approach you describe is exactly in line with what I've beenThis is great news :) But there's no code-level distinctionI agree, the only benefit is from a UI perspective to assist the user in not doing something stupid. Downside to this is sometimes there is a good reason to do something stupid. So perhaps it would be best to go for some middle road (listing the logical ones first and including the type of all transforms for instance). I'd prefer to just call them "transforms" to leave open the possibility of other correctionSounds like a logical choice of terminology to me. Your processing pipeline is already expressed in the DisplayTransform.Great stuff :) thanks for sharing. Slowly getting my head around how OCIO works. Cheers, Alan
|
|
OCIO 0.5.14 posted
Jeremy Selan <jeremy...@...>
Version 0.5.14 (Sept 1 2010):
* Python binding enhancements * Simplified class implementations (reduced internal header count) Most changes this week were internal, all API changes were binary compatible additions. (Which is a good sign, considering a stable 0.6 is fast approaching!) -- Jeremy
|
|
Re: [ocs-dev] Re: Supporting 1D luts which are different per channel
Malcolm Humphreys <malcolmh...@...>
Hi,
toggle quoted messageShow quoted text
Just looking at this again, one thing we didn't cover was a prelut which has non-uniform spaced points (scattered). Would you see this as support we would need to add to the Lut1DOp or would this end up being a different op type. This is a simple example from the csp spec. --snip-- Map extended input (max. 4.0) into top 10% of LUT 11 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 4.0 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 11 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 4.0 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 11 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 4.0 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 --snip-- A more complex example could be --snip-- 11 0.0 0.1 0.2 0.3 0.4 0.45 0.5 0.8 0.85 1.0 4.0 0.0 0.1 0.2 0.3 0.4 0.5 0.55 0.6 0.7 0.9 1.0 --snip-- .malcolm
On 22/07/2010, at 12:39 PM, Malcolm Humphreys wrote:
Hi Jeremy,
|
|
Re: [ocs-dev] Re: Supporting 1D luts which are different per channel
Jeremy Selan <jeremy...@...>
Definitely a new Op. How about Spline1DOp?
-- Jeremy On Fri, Sep 3, 2010 at 6:27 AM, Malcolm Humphreys <malcolmh...@...> wrote: Hi,
|
|
OCIO 0.5.15 posted
Jeremy Selan <jeremy...@...>
Version 0.5.15 (Sept 8 2010):
* Library is well behaved when $OCIO is unset, allowing for use in an un-colormanaged environment * Color Transforms can be applied in Python (config->getProcessor) * Simplification of API (getColorSpace allows cs name, role names, and cs objects) * Makefile enhancements (courtesy Malcolm Humphreys) * A bunch of bug fixes
|
|
Development Priorities?
Jeremy Selan <jeremy...@...>
Folks,
If you're considering using OpenColorIO in the near term, we would greatly appreciate it if you would respond and let us know which of the topics below you personally consider to be most important. Perhaps reply with the top 5 items you care about? (Note: We plan on addressing all of these issues, but would love to get a sense of what's holding people up in the short term). If there's an important task that isn't represented on this list, please add it! Thanks! -- Jeremy -------------------------------------------------------------------------------- Fall 2010 OpenColorIO Development Topics: Documentation - Quickstart Guide - End User (Artist) Docs - Developer API Docs - Color Config Authoring Docs Facility Integration - Support for additional lut formats (import) - Support for lut export - 3rd party app plugins RV OFX OpenImageIO Houdini <Your App Here!> "Real" Color Configurations - Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use - Add a example ACES ocio config - Add a config that emulates the default nuke color configuration - Add example color config authoring scripts - Document 'best practice' for each config, and provide workflow examples with imagery Core Library: - Unit testing / correctness validation - Overall performance optimization Issues deferred until after 1.0 (tentatively Jan '11): - Dynamic Color API (OCIO Plugin API) - Live CDL Support
|
|
Re: Development Priorities?
"Nathaniel Hoffman" <na...@...>
1) Document 'best practice' for each config, provide examples with imagery
toggle quoted messageShow quoted text
2) Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use 3) Add example color config authoring scripts 4) End User (Artist) Docs 5) Color Config Authoring Docs Naty
Folks,
|
|
Re: Development Priorities?
Alan Jones <sky...@...>
Hi Jeremy,
On Tue, Sep 14, 2010 at 6:59 PM, Jeremy Selan <jeremy...@...> wrote: Perhaps reply with the top 5 items you care about?The top five for me would be as follows. 1) API Documentation (the classes and how the pieces are supposed to work together - I guess that may count as config documentation) 2) LUT export 3) Unit testing (this kinda should be number one, but I'm trying to be somewhat pragmatic) 4) Color config authoring docs 5) Additional LUT formats I'd say for now the biggest thing holding me back on OIIO is there is no big picture documentation. I don't really know how OCIO is intended to work and what all the pieces are. I can try piece it together from the code, but a document covering intended structure would make both using it and identifying areas to provide meaningful contribution much easier. The reason I say big picture rather than purely API is I'm thinking not just of the API for how to access it, but how it's intended to work within a pipeline. Cheers, Alan.
|
|
Re: Development Priorities?
Est <rame...@...>
Hi Jeremy,
toggle quoted messageShow quoted text
I'm currently adding OpenColorIO support to my compositor. My list would be: - End User (Artist) Docs - Developer API Docs - Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use - Color Config Authoring Docs - Add example color config authoring scripts I can port the existing Colorspace and Display Nuke plugins to OFX if there is interest. Just let me know. Est.
On Sep 15, 4:49 pm, Alan Jones <sky...@...> wrote:
Hi Jeremy,
|
|
Re: Development Priorities?
Marie Fétiveau <m...@...>
Hello Jeremy and all !
toggle quoted messageShow quoted text
I don't have much time to focus on OCIO now but soon or late I will...;) And when that day will come, I'll be happy to find : - Developer API Docs
- Color Config Authoring Docs
- Add a example ACES ocio config - End User (Artist) Docs
- Live CDL Support
Thanks !
Marie
On Thu, Sep 16, 2010 at 1:39 AM, Est <rame...@...> wrote: Hi Jeremy,
|
|
OCIO 0.5.16 posted
Jeremy Selan <jeremy...@...>
Version 0.5.16 (Sept 16 2010):
* PyTransforms now use native python class inheritance * OpenColorIO C++ namespace can now be configured at build time (for safe distribution in commercial apps) * Updated make install behavior * DisplayTransform accepts generic cc operators (instead of CDL only) * A few bug fixes / compile warning fixes And coming next week, 0.6.0 !
|
|
Re: Development Priorities?
srluka <srl...@...>
Hello Jeremy,
toggle quoted messageShow quoted text
I would like to see OCIO grow into a library that can handle all our color transformations. I can see it being used in the current xml'ized form within our production environment to keep the color options well- defined, but still want the eventual capability for dynamic color transformations. Performance for realtime playback is also important to us. With that in mind, here are my top five: - Developer API Docs - Color Config Authoring Docs - Overall performance optimization - Dynamic Color API - OpenImageIO Stefan
On Sep 16, 8:36 am, Marie Fétiveau <m....@...> wrote:
Hello Jeremy and all !
|
|
Compilation fail on FC13
Alan Jones <sky...@...>
Hi All,
For some reason the compilation of the latest trunk is failing on FC13. It's complaining about main not being defined, but from what I've read on the boost unit testing defining BOOST_TEST_MODULE should take care of that. Any ideas? Error output is below. Cheers, Alan. Linking CXX executable ocio_core_tests /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[2]: *** [src/core/ocio_core_tests] Error 1 make[1]: *** [src/core/CMakeFiles/ocio_core_tests.dir/all] Error 2
|
|
Re: Compilation fail on FC13
Alan Jones <sky...@...>
Best way to solve a problem? Post on a mailing list asking for help, then
you'll find the solution within minutes. Cheers, Alan.
|
|
Re: Compilation fail on FC13
Jeremy Selan <jeremy...@...>
Hmmm, that patch doesnt quite work for us locally at Imageworks. (I
toggle quoted messageShow quoted text
think it's probably because we use a namespaced version of boost, and the macro isn't quite right in our context). Let me see if I can find a solution that works for both of us. I've also been rethinking the use of boost within OCIO. Currently there are only two things we use it for: shared_ptr and the unit test framework. Given the issues that can occur when linking against other apps the rely on different boost versions, boost may be a can of worms worth avoiding, particularly considering that at this time it may be a pretty simple dependency to remove. Does anyone have any strong feelings (or experience) on this? -- Jeremy
On Mon, Sep 20, 2010 at 1:05 PM, Alan Jones <sky...@...> wrote:
Best way to solve a problem? Post on a mailing list asking for help, then
|
|