External Dependencies
Jeremy Selan <jeremy...@...>
Folks,
I've been trying to get OCIO compiled for the iPad (think siggraph tech demo), and I've been having a very hard time getting the XCode cmake exporter to generate a working project. I've followed all the online instructions, upgraded to the latest cmake, and even investigated not using xcode and just cross-compiling to create a static arm library - but no success thus far. Has anyone else given this a shot? I've pinged a few people in the cmake / ios community, and their universal recommendation is, if possible, to not rely on cmake to generate the xcode project but it instead just add the library to your native project as source files. For the core OCIO library this would be rather simple, with the exception of two libraries cmake pulls at build time from ext: tinyxml, yaml-cpp. What would people's thoughts be on pulling these libs back into src/core (as they used to be)? All the other libraries (lcms,sphinx,...) would remain in ext. This would allow people to easily build the core library, even in circumstances where cmake is not available / appropriate. (Basically all you'd have to do is provide the constants in the OpenColorABI.h and the rest would be simple.) I really like the cleanliness of the current cmake build system, but I imagine in the context of high performance mobile devices this will come up more and more, and my gut feel is that any native cmake -> xcode (or equivalent) process will be fragile in the long term. -- Jeremy
|
|
Review: Refactored baker code to allow for more advanced lut output
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/116
This addresses oliver's bug where an HDR lin -> Dreamcolor ociobakelut command was clipping the highlights. After this fix, you can get a proper output .csp both with and without the --shaper specified. (if the shaper is not specified, it will fall back on the allocation for the input space, and for oliver's linear example (lg2, -7.5, 4) will match the 'log' shaper space almost exactly. There is one known regression in this code - I have temporarily disabled the .hdl lut baking as I have not ported that code. But I wanted to get this checkin in before then, as it's such a large change (in terms of number of lines of code). Other changes: * Added .3dl baking * Added Processor.hasChannelCrosstalk() * Exposed both FormatName + FormatExtension * FileFormats can register multiple names. (ex: lustre 3dl / flame 3dl) * Baker defaults are format specific * ociobakeluts has cleaned up syntax, fewer args needed in most cases The bakelut logic has been moved from the Baker.cpp, into each output format. This can eventually be re-refactored, but in the meantime until we have more examples I think we can get higher quality (format specific) color output by doing the logic in each outputter. Remaining tasks: * update houdini lut baker to work again. (currently disabled) * let the .csp output dynamically pick between a 1d and 3d output (now that hasChannelCrosstalk is exposed, this will be trivial) -- Jeremy
|
|
Review: misc python updates
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/114
* PyColorSapce supports kwarg initialization * Exposed ClearAllCaches to python -- Jeremy
|
|
Review: Added OCIO_VERSION_HEX to public header for easy version comparison
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/112
This exposes a single 4-byte hex number, e.g. 0x01050200 == 1.5.2 Use this for numeric comparisons, e.g. #if OCIO_VERSION_HEX >= ... Note: in the case where SOVERSION is overridden at compile-time, this will reflect the original API version number. Code concept is stolen from cpython source. Addresses issue https://github.com/imageworks/OpenColorIO/issues/65 -- Jeremy
|
|
OCIO 0.8.1 Released
Jeremy Selan <jeremy...@...>
Version 0.8.1 (May 9 2011):
* New roles: TEXTURE_PAINT + MATTE_PAINT * Mari API Example (src/mari) * FileFormat registry updated to allow Windows + Debug support * boost_ptr build compatibility option -- Jeremy
|
|
Review: FileFormat registry refactor
Jeremy Selan <jeremy...@...>
https://github.com/imageworks/OpenColorIO/pull/111
FileFormat registry refactor The registration mechanism is now less fragile, using the 'construct on first use' approach rather than relying on static initialization to register each format. This is a more portable implementation (should work on windows), and also avoid some issues we've been seeing when using gcc debug versions of the library. -- Jeremy
|
|
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
|
|