Re: Reversed transform for a OCIO::DisplayTransform


Dmitry Kazakov <dimu...@...>
 

Hi, All!

Thank you for your replies! Now I understood that not every display transform is revertible :) So I will have to refactor our color selectors code to make it work with color proof'ed colors :(


On Sat, Apr 12, 2014 at 6:06 AM, bsloan <bsl...@...> wrote:
For most workflows that use a 3D LUT to render extended dynamic range images, it is not necessary to reverse the operation on the picked color. Your application should just look up the un-transformed pixel value from the image (not the displayed frame buffer), based on the selection position.

It would be *very* handy if your application would render the various color pickers and swatches through the OCIO display transform as well. Photoshop does not do this. 




On Friday, April 11, 2014 10:24:38 AM UTC-7, Dmitry Kazakov wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.



--
Dmitry Kazakov

Join {ocio-dev@lists.aswf.io to automatically receive all group messages.