|
Re: Apply color transformation on images containing a single channel
Jeremy Selan <jeremy...@...>
If your image is packed separately per channel (ex: RRRRRRR... GGGGG... BBBB.... ), the Planar ImageDesc is probably what you're looking for. Give that a try?
On Wed, Apr 10, 2013 at 8:36 PM, Mark Boorer <mark...@...> wrote:
|
|
|
|
Apply color transformation on images containing a single channel
Mark Boorer <mark...@...>
Hi, In my application, images are split into their separate channels, and operations are performed per channel. I have individual float arrays for each channel (obtained via openimageio), and I would like to perform a colorspace transformation to each, preferably without joining them together.OCIO::PackedImageDesc img(data, w, h, 1, "R"); Mark |
|
|
|
Re: OCIOLookTransform missing in Nuke 7.0v4?
Hugh Macdonald <hugh.ma...@...>
Your other option is to select Other -> All Plugins -> Update, and then finding it in the Other -> All Plugins -> O menu. On 8 April 2013 18:47, Jeremy Selan <jeremy...@...> wrote:
D I S C L A I M E R : This email and any files transmitted with it are intended solely for the intended addressee,
and may contain confidential information or material protected by law,
copyright or other legislation. If you have received this message in
error, please return it to the sender or notify the sender by calling
+44 (0)20 3167 3860, and immediately and permanently delete it. You
should not copy it or use it for any purpose, nor disclose its contents
to any other person. Only the intended recipient may place any reliance
upon it. Nvizible Limited accepts no responsibility or liability for
emails sent by its employees or personnel which are not sent in the
course of its business or that of its clients. Nvizible
Limited, 3 Richfield Avenue, Richfield Place, Reading, Berkshire, RG1
8EQ . Registered in England & Wales with Company Number: 6900121 |
|
|
|
Re: OCIOLookTransform missing in Nuke 7.0v4?
Jeremy Selan <jeremy...@...>
It looks like Nuke 7.0v6 ships with the OCIOLookTransform node, though it's not exposed in the menus by default. Quoting the release notes...
BUG ID 24785 - OCIOLookTransform was missing from the Other > All plugins menu. You can also access OCIOLookTransform by pressing X on the Node Graph, making sure TCL is selected in the dialog that opens, typing OCIOLookTransform, and clicking OK
On Sun, Apr 7, 2013 at 6:33 PM, Alex - <ale...@...> wrote:
|
|
|
|
OCIOLookTransform missing in Nuke 7.0v4?
Alex - <ale...@...>
It seems like the OCIOLookTransform node mentioned on this page: Is missing from the OCIO bundled with Nuke 7.0v4. Has the LookTransform node been deprecated or am I missing something? Regards Alex |
|
|
|
Re: converting The Right Way™ from linear -> custom log -> monitor
Jeremy Selan <jeremy...@...>
Hi!
toggle quoted message
Show quoted text
So you shouldnt have to muck around with any of the specific underlying Transforms (you mention the log transform, and the file transform). The typical use case with OCIO is that these are all abstracted away inside the OCIO configuration, and that clients of the library treat the color transformation stack as a 'black box'. (The reason we expose these *.Transforms at all in python is that so it's possible to script the creation of Configs using the python API.)
I.e., if you wanted to convert pixels from colorspace "A" to colorspace "B"... config.getProcessor("A","B") would suffice. (either the names, or roles)
The client would *not* need to know whether the definitions of A and B involved 1-D LUTs, 3-D LUTs, log converts, etc. So can you confirm your facility already has a show-level OCIO config with the colorspace definitions already setup? (If you're using Katana or Nuke or Mari with OCIO functionality, it's likely you already have one setup). Also note that I see you're calling OCIO.GetCurrentConfig(). That reads from $OCIO, so if you're not seeing a warning in the shell then you're probably good to go.
The one exception where you DO need to use a Transform in a client app is the DisplayTransform, which is the simplest way to create a "canonical viewing transform".
So say you wanted to convert colors, from log space, to something suitable for image display. As this is for image display, the DisplayTransform is most appropriate:
config = OCIO.GetCurrentConfig() t = OCIO.DisplayTransform() t.setInputColorSpaceName( "NAME OF YOUR LOG COLORSPACE OR ROLE_COMPOSITING_LOG ") t.setDisplay( config.getDefaultDisplay() )
t.setView( config.getDefaultView( config.getDefaultDisplay() ) ) And then you get the processor, processor = config.getProcessor(t) And then you use the processor to process pixels.
For extra credit... Note that if you're drawing a gradient and having the user pick colors, a log space gradient - while much better than scene-linear - may not be ideal. I.e., you may find that the distribution of colors along the gradient is not to your liking. One of the OCIO pre-defined roles is ROLE_COLOR_PICKER. The intent is that this would be the alias to the color space most suitable for use in a color-picker. (The Katana color picker makes use of this role, for example). And the default OCIO configs we publish have this defined in a manner suitable for color picking.
Let me know if you have any further questions along these lines. This color picker stuff is both complicated, and fun. :) -- Jeremy On Mon, Mar 18, 2013 at 8:12 AM, <sor...@...> wrote: I'm writing a fairly simple Python based color-managed color picker. OCIO seems like a good tool for the job, and it's an opportunity for me to learn a new API. Beyond hacking something together that "just works" I'd like to understand The Correct Way To Do Things According To The OCIO Python API. At the moment I'm not sure how my problem fits into the OCIO abstraction of roles, Displays, ColorSpaces, Transforms, Processors, Looks, Views, and Configs. |
|
|
|
Re: Bugs in Windows build process
Jeremy Selan <jeremy...@...>
Hi!
toggle quoted message
Show quoted text
We're definitely interested in posting a pre-compiled windows binary. (It's a very common request). If you can point me where to download it (off-list), I will add it to the downloads section. Thanks! -- Jeremy On Fri, Mar 8, 2013 at 6:53 AM, Marie Fétiveau <m...@...> wrote:
Hello ! |
|
|
|
Re: Bugs in Windows build process
Marie Fétiveau <m...@...>
Hello ! Does Windows pre-compiled ociobakelut still interest you ? I've just built static and dynamic libs, ociocheck and ociobakelut for win7 64 (msvc 2010 express).
Here. I also have win32 binaries but they are pretty old (1.RC). Not very interesting... ++
Marie On Wed, Dec 12, 2012 at 1:44 AM, Jeremy Selan <jeremy...@...> wrote:
|
|
|
|
Pull Request: better disk caching behavior for concurrent lookups
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/309
Previously, if one loaded a file (LUT) that wasnt in cache, this would block concurrent access of the file caches, even for different files. With this update, lookups for different files are non-blocking. However, lookups on the same file are blocking; a lut should never be loaded twice from disk even when concurrently used. This change was added so image viewers which need real time performance can efficienly use a 'prefetch' thread to see the file caches ahead of time. This is particularly useful when used when playing clips with per-shot 3-D LUTs. |
|
|
|
Re: Linear workflow in Silhouette? And example LUT files?
Paul Miller <ste...@...>
I wonder if the 1.0 clamping issue happens with LUTs only, or if it willSilhouette isn't doing any clamping of its own, so this must be happening in the FileTransform. Also, I bring up DPXs because if I use DPX in Silhouette, I can set itsWe put the Gain transform before the FileTransform because that is what Mari does/did. I can see the reasoning of that, if the file LUT is meant to model a specific special display. Sounds like a custom Config is the way to go. |
|
|
|
Re: Linear workflow in Silhouette? And example LUT files?
Paul Miller <pa...@...>
On 2/13/2013 12:38 AM, Derek Melmoth wrote:
I'm attempting to get a linear workflow working in Silhouette (4.5.3),Silhouette lets you use a straight-up OCIO config, or you can select a single LUT file. Sounds like you may need a custom config to do this, or find a LUT that combines both conversions. Silhouette makes it very easy to apply a LUT file... so all I shouldSilhouette reads all the LUT formats supported by OCIO. Can you convert your .CSP file to another format that is supported? Second question:If you're working with EXRs you're already using a linear workflow, so that statement is a bit confusing. Switching to DPXs would require an additional conversion (handled by OCIO), so there is no need to do that. Silhouette v5 was just released and we're working on a point release that adds/fixes a few things. I could look at getting the CSP bug fix in there.
|
|
|
|
Linear workflow in Silhouette? And example LUT files?
Derek Melmoth <derek....@...>
Hi!
I'm attempting to get a linear workflow working in Silhouette (4.5.3), which uses OpenColorIO. I'd like to load in scene-linear EXRs, apply a 1D linear-to-CineonLog transform, and then apply a 3D LUT. Silhouette makes it very easy to apply a LUT file... so all I should need is a LUT file that contains both a 1D lin-to-log shaper LUT and a 3D LUT. I'm able to create such LUT files for some applications (e.g. I can create .CSP luts that work in RV and Nuke), but I'm having trouble finding a file format that works correctly in Silhouette. First question: Are there example LUT files available anywhere? I want to try all the different LUT formats (or at least the ones with 1D shaper luts), but can't find example LUT files anywhere, so I've been digging up the specs for each type and creating my own test LUTs in Python. If I had an example LUT file of each type it would be the most helpful thing in the world for me, and maybe for other developers just getting into OpenColorIO :D Second question: A single LUT file may be the simplest way for me to get a linear workflow in Silhouette, but perhaps it's not the best way or the recommended way? What's the recommended approach to linear workflow in Silhouette? Or should we switch to DPXs instead of EXRs? Is there a way to apply 2 LUT files instead of 1? Should I look into creating a new OCIO configuration? Thanks! -Derek Anyone interested in what I've tried so far may read ahead: ============================== So far here are the issues I've been having with the different LUT formats: 3dl (Autodesk Apps: Lustre, Flame, etc. Supports shaper LUT + 3D) Problem: I don't think it can accept input values above 1.0, can it? csp (Cinespace (Rising Sun Research) LUT. Spline-based shaper LUT, with either 1D or 3D LUT.) CSP is perfect and allows a 1D shaper LUT with arbitrary inputs and outputs, and we've been using these in RV for a while. Problem: In Silhouette CSP cannot be used right now because of a known CSP-reader bug in OCIO: https://github.com/imageworks/OpenColorIO/pull/304 (It expects to read the string "CSPLUTV100", but instead reads "CSPLUTV100\n" with the newline character at the end, and fails to read the file.) hdl (Houdini. 1D Lut, 3D lut, 1D shaper Lut) The 1D portion doesn't allow arbitrary input coordinates like CSP does, but luckily the inaccuracy in the darkest colours is only slightly noticeable. Problem: Unfortunately there's a bug that clips input values that are above 1.0, and this is a deal-breaker. So, scene-linear values from 0 to 1 work as expected, but anything above 1 fails to go above 0.6696 in log space. Is there a place to file a bug report for this? Also the lut file's extension had to be renamed to .lut in order for Silhouette to read it :) From the LUT list in the OCIO FAQ, it looks like the only other format that supports shaper LUTs is .cub (Truelight format). I will try this format next! Are there any other LUT formats in OCIO that support 1D shaper LUTs? Or should I instead just use the 3D LUT that accepts CineonLog input? Thanks for reading! And I must say I'm pretty thankful for OpenColorIO and the VES Cinematic Color white paper! :D Cheers, -Derek |
|
|
|
Review: docs for Blender and Sony Vegas Pro OCIO support
dbr/Ben <dbr....@...>
Documenting support for OCIO in latest stable release of Blender, and Sony Vegas Pro 12 |
|
|
|
Re: yaml-cpp 0.5.0
Richard Shaw <hobbe...@...>
On Tue, Jan 8, 2013 at 9:54 PM, Jeremy Selan <jeremy...@...> wrote:
I think the plan is to stick with the existing API, until there is aNot that I know of. And as long as nothing else in Fedora wants yaml-cpp it doesn't really matter. The problem would be if another package wanted/needed 0.5.0 then we would have to decide if it was practical for all packages to use the same version of yaml-cpp or if we would have to come up with a parallel installable package (no namespace or file conflicts) which depending on upstream can be easy or hard. Richard |
|
|
|
Re: yaml-cpp 0.5.0
Jeremy Selan <jeremy...@...>
I think the plan is to stick with the existing API, until there is a
toggle quoted message
Show quoted text
compelling reason to upgrade. Is there any advantage to bumping up? -- Jeremy On Tue, Jan 8, 2013 at 6:05 AM, Richard Shaw <hobbe...@...> wrote:
I noticed that yaml-cpp 0.5.0 was released with the new API. Is there |
|
|
|
yaml-cpp 0.5.0
Richard Shaw <hobbe...@...>
I noticed that yaml-cpp 0.5.0 was released with the new API. Is there
a plan to move to the new API or stick with the 0.3.0 API? Thanks, Richard |
|
|
|
Re: photoshop config.ocio
Joe <joseph...@...>
Nishith,
toggle quoted message
Show quoted text
sicne you are testing the screen output you can sample the color from the display. on kde looking linux you can use kcolorpicker on the mac you can use DigitalColor Meter (in application utilities) Color sync on the mac is very, or was very difficult to null out. You may wind up with differences in Photoshop and After Effects based on your display profile -Joseph On Tuesday, December 25, 2012 1:13:38 AM UTC-8, Nishith Singhai wrote: Hi, |
|
|
|
Re: photoshop config.ocio
dbr/Ben <dbr....@...>
On 25/12/2012, at 7:43 PM, Nishith Singhai wrote:
2) what is the way to measure that output from nuke after applying lut is looking same as that of after effects. is there a measuring tool or is it based on the observation only.I found the most effective way is to run both applications on the same machine. Load the same image, and compare the two by toggling between each application (alt+tab or cmd+tab) It's easy to align the images (with a bit of panning and zooming), so you can get a good A/B comparison between the applications. If you can't run the two applications on the same host, connecting the two machines to the same monitor is the next best thing (but switching can take a few seconds, which makes a comparison hard). Failing that, you could try screenshoting both applications, or something like the "DigitalColor Meter" app on OS X, but these both introduce more steps that can go wrong As Brendan said, the most likely culprit is the applications interpreting the source footage differently.. A 16-bit TIFF version of a test image (e.g Marcie!) is usually a good place to start, as most applications tend to load them without any unexpected conversions Start of by checking the "raw" image is displayed the same in both applications, disabling any custom viewer-LUT's. When that matches, compare the LUT's. |
|
|
|
Re: photoshop config.ocio
Brendan Bolles <bre...@...>
On Dec 25, 2012, at 1:13 AM, Nishith Singhai wrote:
1) By thumb rule a lg10 to srgb8 in nuke and lg10 to srgb8 in after effects should give the same result. true or false. Nuke and After Effects have different color space defaults, so it's very easy to import the same file into each and get different results with OpenColorIO. In fact, to get the programs to match up you need a good understanding of how each works. I wish it were simpler. A good thing to do is get an image with an area you can easily sample with your mouse (like the Marci image) and check to make sure the values match in each program. Both programs will show a readout of the pixel value you hover over (in After Effects it's in the Info palette). Nuke defaults to linear color space and automatically converts most file formats to linear unless you check the "Raw Data" checkbox in the Read node. If you're using OCIO to do color conversions, you'll probably want to check that box in every case. Cineon/DPX files will default to log, EXR to linear, and most others to sRGB. After Effects, on the other hand, defaults to no color space, which basically means your monitor's color space, or sRGB. The one exception is EXR files, which will get converted from linear to sRGB with the default setup unless you check "Preserve RGB". There's more information about this in the PDF manual included with the After Effects plug-in. If you're still having trouble, let me ask: which kind of file are you importing? Brendan |
|
|
|
Re: photoshop config.ocio
Andrew Britton <andrew.d...@...>
One thing to check is that both the Nuke flow and photoshop color settings are using the same gamma curve and color gamut (i.e. make sure they're both in the same color space first). If you're working 'scene linear' in Nuke but not in Photoshop then I can easy imagine troubles will ensue. Good luck! On Dec 25, 2012, at 2:13 AM, Nishith Singhai <singha...@...> wrote:
|
|
|