![]() Registered Member ![]()
|
Hi everyone,
I've done a bit of searching regarding this issue, and haven't seen any activity since a brief thread in 2012, so apologies if I'm asking in the wrong place. I work at a visual effects studio that's linux based. OpenColor and OpenImage support in Krita are amazing and absolutely perfect for us, however all of the color pickers in Krita seem to clamp at 0 and 1. When working in a log colorspace (like dpx for film & tv plates) it's extremely common to have values slightly in the negative and very high (50s or higher) in positive RGB channels. When working in linear, (we do 99% of everything in exr format internally), the sky's the limit as channels can go from -65536 to +65536 in 16 bit to +/- 17.7m in 32 bit space. Practically, HDR images (such as a properly exposed/unclamped sun value) can come in in the tens of thousands, and it's very common for cg renders to have extremely large values in data passes such as zdepth, but generally expose in approximately the same range as your average HDR or dpx film plate. Given the foundations (ocio/oiio), I wouldn't imagine that getting 16 & 32-bit ranges implemented in the pickers & brushes would be a huge deal, but I did want to check in and bump the community on this to see if any progress had been made on this front or if I was looking in the wrong place. Thanks! |
![]() Registered Member ![]()
|
I think there aren't many users with the same use case in this forum that can reply to to your question. So unless a dev pass by...
You are better off asking Krita's mailing list about the current state of color pickers ranges. If it's not implemented they'll ask you to file a bug report with the feature request and place it under the wish list. EDIT: I forgot, Krita has official commercial support too. The development of OpenColorIO support for Krita was sponsored by commercial support. Among other things they offer custom development of plugins, bridges and special features. If 16 & 32-bit ranges pickers and brushes are critical for your work and studio, ask KO GmbH for development cost figures and then decide if it's worth the production boost. |
![]() KDE Developer ![]()
|
Yes, this is the bug: https://bugs.kde.org/show_bug.cgi?id=288716
|
![]() KDE Developer ![]()
|
I completely missed the original message -- I try to keep up with the forum, but sometimes that's pretty hard! Yes, we need to fix our color selectors. Actually, it's on the todo for Krita 2.9, but if you would like to expedite that, either sponsorship through the Krita Foundation or getting KO GmbH involved would help a lot!
|
![]() Registered Member ![]()
|
Thanks for the update!
Will check in with the powers that be about sponsorship as well. A viable float & ocio friendly image editor for Linux is super high on the wishlist of organizations like ours. Also worth mentioning, now that I look at the bug report, folks who work in float and/or with LUTs generally prefer to see linear pre-transform/lut/exposure colors in pickers, sometimes with an option to see the post transform. When in doubt, have a look at the way Nuke handles the exposure/gain/lut situation (there's a learning edition). For many of us in this field, Nuke's the only thing we truly trust with color. Thanks again, --T |
Registered users: Bing [Bot], Evergrowing, Google [Bot]