Re: ociobakelut clamps tops?
Malcolm Humphreys <malcolmh...@...>
Oliver Farkas <oliver...@...> wrote:
Hey guys,Its good that Jeremy could get a fix for you. I built all the luts before I left with ociobakelut to make sure we were not using any pre ocio data. This was checked with all the host apps and the ocio nuke nodes so its a bit strange that it doesn't work now or in this case. The baker was a pretty quick first pass so its not a complete surprise that it has issues but this sounds like its broke. On Tue, May 3, 2011 at 9:53 AM, Jeremy Selan <jeremy...@...>-- Sent from my phone.
|
|
Re: ociobakelut clamps tops?
Oliver Farkas <oliver...@...>
Hey guys,
toggle quoted messageShow quoted text
thanks for the feedback from both of you. Jeremy's workaround does the trick brilliantly, that's exactly what I was looking for. Thanks very much Jeremy. Malcolm, I know about the Vectorfield node problem in Nuke, because I've checked with your csp lut as well and saw it was blown out. By now I've tried an endless number of combinations of inputspace, shaperspace, outputspace, but the tops were always clamped. I'm happy that this workaround does the trick.
There's just one thing I don't understand, Malcolm: how were you able to bake out the Kodak2383_sRGB.csp if this bug was in the code before? Or you used something else than ociobakelut?
Thanks again guys, I appreciate it. Oliver
On Tue, May 3, 2011 at 9:53 AM, Jeremy Selan <jeremy...@...> wrote: Oliver,
|
|
Re: ociobakelut clamps tops?
Jeremy Selan <jeremy...@...>
Oliver,
I've checked this out and am able to recreate exactly what you describe. I see the clamping when playing back the 'no shaper' baked lut using OCIO. And also see the brightness increase when using the shaper lut. For both tests I am just comparing the unbaked lut application to that using OCIOFileTransform (in nuke). The issue is related to some assumptions the Baker class is making internally. I will try to refactor the Baker code to address this issue this week (though it may push to next week). I will also touch up a bunch of 'todos' in that part of the code (allowing for looser input restrictions). Afterwards, the syntax you describe (both with, and without, the shaperlut) will support HDR allocations. (For those who dont specify shaperluts, the gpu allocation will be used to achieve a similar effect). In the meantime I am providing a simple workaround script which can be used to generate HDR friendly csp luts. Note that for this csp lut I'm taking advantage of non-uniformly sampled input domains. I am not sure if all apps support this feature of .csp files. If your client apps do not support this, let me know and we can work around this with a one or two line change. http://github.com/jeremyselan/OpenColorIO/tree/shapertest/testdata/csp/oliverbug -- Jeremy
|
|
Re: ociobakelut clamps tops?
Malcolm Humphreys <malcolmh...@...>
Hi Oliver, Ok I wrote all of this and then released are you trying to check these csp luts in the nuke vectorfield node? nuke vectorfield node currently doesn't support the prelut section in the csp format you will just get a blown out image. Check the luts in RV and if it still doesn't work feel free to read on..
All 1D or 3D luts are bound limited in nature, even for half floats you would need a very large lut to cover all values. So I would expect a scene_grey18 -> scene_grey18 to reflect an identity lut which would clamp input values outside the 0.0 - 1.0 range. I would hope this would be identical to the luts created for HP LCD but using a different cube for the Dreamcolors. You should have a color space defined for each of your display devices, in your case the sRGB and Dreamcolor LCDs. ie. - !<ColorSpace> name: # device space ... from_reference: !<GroupTransform> children: - !<CDLTransform> # cool grade in linear (drd custom) - !<FileTransform> # jp lin to log 1D - !<FileTransform> # log to device cube I would first check that each of these behave as expect in nuke using the OCIO node, if this does work (which I'm guessing does I would be surprised if it doesn't) this points to something going a bit wrong when baking. If it doesn't work something has gone a bit wrong with the truelight cube export. Just check that you have the following at the top of your config. - !<ColorSpace> name: scene_grey18 family: lin bitdepth: 32f isdata: false gpuallocation: lg2 gpumin: -15 gpumax: 6 - !<ColorSpace> name: scene_grey18_log family: log bitdepth: 10ui isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 from_reference: !<FileTransform> {src: jp_lin2log.lut, interpolation: linear} I would expect the baking command line in this case would be something the lines of. ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --shaperspace scene_grey18_log --outputspace <device space> --format cinespace When the serialisation/baking of the device space happens the grade will also be taken into account. You shouldn't need to create a separate linearGraded colorspace as ben suggested. I haven't checked the code but I have a feeling this might not work as expected. It should be noted that the shaperspace should only be used to allocate/shape the data and not contain colorimetry type transforms ie color grades. If you can test exporting both a houdini and cinespace lut and see if you get the same results in RV and Mplay and let us know. .malcolm
|
|
Re: ociobakelut clamps tops?
Jeremy Selan <jeremy...@...>
Oliver,
toggle quoted messageShow quoted text
Sorry I haven't had a chance to look into this yet. I will do my best to get to it first thing tomorrow. (Mon AM). My expectation is that this shouldn't be too hard, OCIO is designed to work with HDR float32 -- and we use it internally in exactly the way you describe - so it's likely just a minor bug you've run into first. -- Jeremy
On Sun, May 1, 2011 at 10:48 PM, Oliver Farkas <oliver...@...> wrote:
Hey guys,
|
|
Re: ociobakelut clamps tops?
Oliver Farkas <oliver...@...>
Hey guys,
toggle quoted messageShow quoted text
Ben, I've tried what you suggested. The input is graded scene linear, the shaper is lin to log and the output is a log to Kodak2383 on a DCI screen. I assumed this would work, but when I applied the generated lut on top of a scene linear exr, then the result I got was a blown out image: everything was fully bright, I could only see few parts of the image, all the rest was white.
I played around a bit with the settings. The scene_grey18 entry in the config file contains no transform whatsoever, so I assumed the next would do nothing at all. ociobakelut --inputspace scene_grey18 --outputspace scene_grey18
But the highlights get clamped. This means that it's not the jplinlog or the print lut that's causing the clamping. The exr files do have rgb values that go over 1.0, so maybe this problem's got to do something with that... but I'm not too sure what's happening. I'll try to dig into the code to see if I can find where this is coming from.
Thanks, Oliver
On Fri, Apr 29, 2011 at 9:58 AM, dbr/Ben <dbr....@...> wrote: You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.
|
|
Re: ociobakelut clamps tops?
dbr/Ben <dbr....@...>
You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.
toggle quoted messageShow quoted text
If I understood the code right, it does.. CSP prelut: input to shaperspace as 1D LUT 3D LUT: shaperspace to output space If omit the shaperspace arg, then it's all done in the cube (and the prelut is a no-op) ...so I think your display colourspace needs to have a 0-1 log input (just the kodak LUT). Then you would do: --inputspace graded_linear --shaperspace jplog --outputspace kodak2383_dreamcolour Not ideal, although you could possibly do the grade in the dreamcolor space by doing a log2lin, CDL then lin2log, and replace the graded_linear space with your scene_grey18 Ideally the Baker would inspect the transform op-tree and put as much of the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in the cube.. Not sure how difficult this would be to achieve (think there's todos in the code about this) - Ben
On 29/04/2011, at 2:56, Jeremy Selan <jeremy...@...> wrote:
Hmmm,
|
|
Re: ociobakelut clamps tops?
Jeremy Selan <jeremy...@...>
Hmmm,
toggle quoted messageShow quoted text
Oliver - could you email be your jp_lin2log.lut (directly)? I'd like to re-create this on my end. Dont worry about the Kodak cube lut, I can use one of my own there instead. One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd probably set it to 'Dreamcolor' on the absence of other information. (The family is often used to short-circuit conversions of the same type, but at differing bit depths). I should probably update the API so people can leave it blank if they dont know it, and to assume the color-space name in that case). -- Jeremy
On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...> wrote:
Hey guys,
|
|
ociobakelut clamps tops?
Oliver Farkas <oliver...@...>
Hey guys,
I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest opencolorio (0.8.0), but getting weird results. It clamps the tops, details in the bright areas are completely gone. I'm wondering if I'm missing something. The command I'm using is this: ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp The corresponding parts in the config.ocio look like this: - !<ColorSpace> name: scene_grey18 family: lin bitdepth: 32f isdata: false gpuallocation: lg2 gpumin: -15 gpumax: 6 - !<ColorSpace> name: Dreamcolor family: lin bitdepth: 32f isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 from_reference: !<GroupTransform> children: - !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814, 0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1} - !<FileTransform> {src: jp_lin2log.lut, interpolation: linear} - !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation: linear} Cheers, Oliver
|
|
Review: Mari / OCIO Examples
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/106
This adds two examples demonstration an integration between OpenColorIO and Mari (Foundry's texture painting app). This is very much a work in progress, but still serves as a nice API integration starting point. It is not expected that these will become part of the OCIO install, but rather will be eventually shipped along inside of Mari by default. Note that you cannot test this code without Mari 1.3v2+, so it will be hard for others to actually test this code. But it's still nice to email this to ocio-dev to keep everyone in the development loop. -- Jeremy
|
|
Review: boost_ptr convenience fix
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/105
When using the boost_ptr compatibility mode, previously clients would need to know which option was used and to compile with the same #define setting (which is error prone). Now, this value is baked into the header for convenience. This has been verified to not impact the ABI, and is appropriate for 0.8. -- Jeremy
|
|
OCIO 0.7.9 / 0.8.0 Released
Jeremy Selan <jeremy...@...>
The time is ripe to lock off on a stable 0.8 release.
(We've actually been avoiding ABI breaks for awhile now, this should be anti-climactic). New features / bug fixes will continue to be welcome in 0.8, presuming they are low risk and the code is vetted. -- Jeremy **Version 0.8.0 (Apr 19 2011):** * ABI Lockoff for stable 0.8 branch New features can be added, but the ABI will only be extended in a binary compatible manner * Otherwise identical to 0.7.9 **Version 0.7.9 (Apr 18 2011):** * Added support for .vf luts * Misc. Nuke enhancements * Adds optional boost ptr support (backwards compatibility) * Makefile enhancements (Nuke / CMAKE_INSTALL_EXEC_PREFIX) * cdlTransform.setXML crash fix
|
|
Added support for .vf luts
Jeremy Selan <jeremy...@...>
|
|
Review: Nuke OCIOColorSpace
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/102
OCIOColorSpace node now supports context overrides. Also, a few additional code cleanups. -- Jeremy
|
|
Review(s): OCIOCDLTransform reverse option and others
dbr/Ben <b...@...>
First is some minor doc changes: Second is a reverse checkbox for the OCIOCDLTransform node, and a "select cccid" button for the OCIOFileTransform (along with a question about determining the file format of a FileTransform) https://github.com/imageworks/OpenColorIO/pull/101
|
|
NAB, Anyone?
Jeremy Selan <jeremy...@...>
If any OCIO users (or lurkers) are going to be at NAB next week, and
are interesting in meeting up, please send me an email. I'd love to say hi in person. (I will be there to talk about Katana (with native OCIO support) at the Foundry booth.) http://www.thefoundry.co.uk/articles/2011/04/05/230/come-and-visit-the-foundry-at-nab-2011-sl5625/ -- Jeremy
|
|
Review: Context Bugfix
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/98
This fixes two major bugs in OCIO::Context. First, Context.getStringVar didnt work due to an incomplete definition of the Compare funtion. (The consequence being that keys would be sorted by string length, but for strings of equal length the wrong value would be returned.). Also, setStringVar (used in the Nuke context overrides) had no effect due to a bug in the use of multimaps. These have been verified to work now. -- Jeremy
|
|
Review: Fixes a few compiler warnings
Jeremy Selan <jeremy...@...>
|
|
Review: Adds build option to use boost ptr instead of tr1
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/96
This adds a compile-time option to use boost ptr instead of tr1. The tr1 ptr is defaut, but for folks who had already locked off on OCIO 0.7s ABI before the removal of boost (such a Imageworks), this lets us compile without breaking binary compatibility. This code path will also be necessary for windows support, which apparently does not have tr1 support yet. -- Jeremy
|
|
Re: Review: Build Nuke stuff into lib/nuke6.2
Malcolm Humphreys <malcolmh...@...>
LGTM long live the bubbles system ;)
On 04 Apr, 2011,at 11:25 PM, dbr/Ben <...@...> wrote:
|
|