Re: [ocs-dev] Got Luts?
Bruno Nicoletti <bruno.j....@...>
Hi Jeremy,
toggle quoted messageShow quoted text
these are the ones we support in Nuke... .vf Nuke native vector field vfz gzip compressed .vf files .cub(e) Truelight 1D or 3D LUT .cube Iridas LUT .csp Cinespace LUT .3dl Autodesk/Scratch LUT .blut Houdini mplay blut I can get you example files b
On 21 May 2010 22:35, Jeremy Selan <jeremy...@...> wrote:
Hello! --
Bruno Nicoletti
|
|
Re: [ocs-dev] Got Luts?
Bruno Nicoletti <bruno.j....@...>
80 Megs or so of data seems to have confused Google.
toggle quoted messageShow quoted text
Anyother way? b
On 24 May 2010 10:59, Bruno Nicoletti <bruno.j....@...> wrote:
Hi Jeremy, --
Bruno Nicoletti
|
|
[ocs-dev] Re: Got Luts?
Jeremy Selan <jeremy...@...>
Ah, there is a 10MB per-file limit to uploads on google groups. Let
me whip up an alternative... On May 24, 9:15 am, Bruno Nicoletti <bruno.j....@...> wrote: 80 Megs or so of data seems to have confused Google.
|
|
[ocs-dev] Re: Got Luts?
Mark Alexander <malex...@...>
I can send the specs for the Houdini .lut (ASCII) and .blut (bin)
formats, if you need that. They're also in the HDK documentation, if you have access to that.
|
|
Re: Got Luts?
Jeremy Selan <jeremy...@...>
Thanks!
toggle quoted messageShow quoted text
I do have the houdini docs, but if you could send me known good examples luts that would be helpful as well. If the files are small (under 10 MB) just post them to this as files to this group. I am setting up an ftp site today, which will have a first code drop as well as allow folks to post larger luts / images as needed. -- Jeremy
On May 25, 7:55 am, Mark Alexander <malex...@...> wrote:
I can send the specs for the Houdini .lut (ASCII) and .blut (bin)
|
|
Lut format chart
Jeremy Selan <jeremy...@...>
Blake was kind enough to a google doc spreadsheet of lut formats:
http://spreadsheets.google.com/ccc?key=0Avn2cZhY9jaYdF9qTHYteU1MUDYtdnFkSDJQdHpaU1E&hl=en I'll try to edit it to keep it up to date. (what formats we support, are planning to support, have examples of, etc). And eventually it'll probably turn into part of the ocs website.
|
|
Re: [ocs-dev] Lut format chart
Larry Gritz <l...@...>
Neat. So just to clarify, the big idea is that any app that uses your color library properly will, by extension, understand ALL of these luts (whichever happens to be available/used at the facility using the app)?
Just how automated can this be? I'm a little unclear on how much extra homework a display program needs to do. Will your library... um... just find the lut specs in whatever standard places they are stored and know how to correct images for proper display on that device? Are there standard places for the luts to be stored? Will an app need various user options/dialogs to set this up? Is this too much of a newbie question? On May 25, 2010, at 2:51 PM, Jeremy Selan wrote: Blake was kind enough to a google doc spreadsheet of lut formats:-- Larry Gritz l...@...
|
|
Re: Lut format chart
Jeremy Selan <jeremy...@...>
Exactly. Clients apps will automatically have support for all lut
toggle quoted messageShow quoted text
formats. (It's about time!) To an end user, this should feel pretty automated. Apps shouldn't need ebd user options / dialogs, all of the lut-location mojo is internal to the ColorConfiguration file. Specifying which configuration to use is controlled via a single environment variable (which points at an ocs file). (Explicit initialization is also allowed, but this will probably be less common). The internals of the .ocs file are still in flux, but the rough idea is that there will be two flavors. One flavor will be a human- readable xml file, of which one element lut dir. The alternative will be a binary ocs 'package', where the lut dir is self contained in the file. (Think tgz of a config / lut dir). In the super common newbie-case, downloading a single .ocs binary file, and pointing to it with OCS_CONFIG will be all that's needed. -- Jeremy
On May 25, 3:09 pm, Larry Gritz <l....@...> wrote:
Neat. So just to clarify, the big idea is that any app that uses your color library properly will, by extension, understand ALL of these luts (whichever happens to be available/used at the facility using the app)?
|
|
ftp site ready
Jeremy Selan <jeremy...@...>
We've now got an ftp site setup at spi for large file posting. If you
want to post files > 10MB email me and I'll send you the login info.
|
|
Re: Lut format chart
Jeremy Selan <jeremy...@...>
An additional clarification...
toggle quoted messageShow quoted text
There does need need to be some end-user ui for image display. (I didnt want to imply no UI was necessary). You just dont need lut- directory / browser / setup interface). For a display application, the most common ui would be to have two popdowns. One would be the ColorSpace corresponding to image state. (Such as identifying the file as genesis log, film log, scene linear, etc). The other popdown would be to specify the output display profile (such as rec709, p3 dlp, srgb, etc). -- Jeremy
On May 25, 3:42 pm, Jeremy Selan <jeremy...@...> wrote:
Exactly. Clients apps will automatically have support for all lut
|
|
.3DL format support
Jeremy Selan <jeremy...@...>
I'm fleshing out support for additional lut formats, and have a
question on 3d. There's a 1D shaper lut at the top of the file, and the 3D component further on, all of which use integer types. Simple enough. However, the range of the integers appears not to be explicitly specified. In the examples I've found thus far, all values appear to be either 10, 12, or 16 bit int. (and in a few cases the shaper lut and the 3d component do not appear to have the same bit depth). This means we'll need to be clever (bad clever, not good clever) in determining bit depth. GetBitDepth(maxValue): if maxValue > 32768: return 16 if maxValue > 2048: return 12 if maxValue > 512: return 10 This would mean for a max value [513,2047] -> 10 bits, [2048,32768] -> 12 bits, etc. (I'm allowing for a bit of overshoot in the luts, presuming 11 / 13 bit luts aren't allowed). The obvious downside (other than ugliness) is that depending on the thresholds, you wouldnt be able to make a really dark lut which didnt use the full range of output values. (Consider a 12 bit lut where you really did want to darken the image below 512). This is unlikely to happen in practice, but a bit unsettling. How do other people handle this issue? Should we only handle 10,12,16 bit luts, or all even bit depths >=8?
|
|
3DL cube format.
bsloan <bsl...@...>
Regarding 3dl --
The lore I've been fed is that Mitch Bogdonowicz formerly of Kodak wrote (invented? burped?) the 3dl "specification" when he was at Kodak as a quick and dirty solution of 3D LUT ASCII serialization. Various interpretations have since been adopted (supported?) by Arri, Autodesk, Assimilate and others. Yes, the initial 1D monochrome shaper array is in some cases in a different bit depth from the 3D rgb array. What's more, various applications choke if the header comment fields (those preceded with a"#") are not 'just so' (eg. truelight's tl-utils). I guess the point is that there isn't just one spec for it. Maybe the way to deal with 3dl is to treat different interpretations as different formats: *arri.3dl *autodesk.3dl *scratch.3dl ugly -r- us. :) -blake
|
|
Re: [ocs-dev] 3DL cube format.
Jeremy Selan <jeremy...@...>
Cool, thanks for the info. So it sounds like when we want to write a .3dl exporter, we'll need to specify which flavor of .3dl to write. However, on the import side it still sounds like we'll be able to get away with a generalized import, presuming we're a bit clever with the bit-depth interpretation. Would you agree?
toggle quoted messageShow quoted text
-- Jeremy
On Wed, May 26, 2010 at 7:08 PM, bsloan <bsl...@...> wrote: Regarding 3dl --
|
|
Re: 3DL cube format.
bsloan <bsl...@...>
Yes. Agreed. The importer can use the fuzzy greater-than-1/2-max
toggle quoted messageShow quoted text
heuristic for guessing the bit-depths of A and B. ...and be correct most of the time. -blake
On May 26, 7:14 pm, Jeremy Selan <jeremy...@...> wrote:
Cool, thanks for the info. So it sounds like when we want to write a .3dl
|
|
First Code Drop: OCS v0.5.4
Jeremy Selan <jeremy...@...>
Folks,
We've made a lot of progress on Open Color Space, and decided to post our first cut. This is first code drop of many; we will try to post the trunk either every week or every 2 weeks. (And soon enough we'll be on github for those interested in tracking 'live'.) This code is pre-alpha. Major components of the codebase are commented out, and/or only spec'd in pseudo-code. However, for those interested in the API or library implementation details, it gives a really good idea for where we're looking to go. The current build is a demonstration of the end-to-end processing chain. We include the OCS Nuke Plugin, and use it to convert images between different colorspaces. Cheers, Jeremy 0.5.4: * Initial code drop * CMake linux support * XML OCS format parsing / saving * Example colorspace configuration with a few 'trivial' colorspaces * Mutable colorspace configuration API * Support for 1D lut processing * Support for SPI 1D fileformats. * Nuke plugin Up next: * Additional processing ops: 3D lut, matrix, analytical log * 3rd party lut support * Python API ... and after that: * GPU support * Output Display Device transforms git grep -i todo Color.0.5.4 | wc -l93
|
|
OCS v0.5.5 posted
Jeremy Selan <jeremy...@...>
This one will actually build on other people's machines...
please see INSTALL file for instructions on how to build the Nuke example (posted here as well): Make a build directory, cd into it: mkdir -p buildConfigure cmake, pointing at your nuke include dir: cmake -D NUKE:FILEPATH=/usr/local/nuke6.0.3/include/ -D CMAKE_BUILD_TYPE=Release ../Build all targets: makeYou will now see the built .so files: lsSet the environment variable pointing at which configuration to use: (Point this to your install) setenv OCS /net/homedirs/jeremys/git/Color/configs/spivfx/config.ocsLaunch nuke (the same version you used for the include files), then load the plugin (this can also go in your init.py) nuke.load('/net/homedirs/jeremys/git/Color//build/libNukeColorSpaceConversion.so')Connect an image to the OCSColorSpaceConversion node. Our 'spivfx' config has only a few example colorspaces, this one demonstrates a conversion between scene linear and a film-log colorspace.
|
|
Re: [ocs-dev] OCS v0.5.5 posted
Bruno Nicoletti <bruno.j....@...>
Hi Jeremy,
toggle quoted messageShow quoted text
looking much nicer. However, I have The Fear as you are using C++ TR1 for smart pointer magic. We are on Visual Studio 2005 for Windows and there is no TR1 for VS5 (we won't be changing in the near future, long story). A #ifndef around SharedPtr and DynamicPtrCast would help, as we could redirect this to boost. Another minor quibble, should not the OCS::ImageDesc have ctors rather than the initRGBA/initSingleBuffer/initMultiBuffer methods? Similarly for other classes? b
On 4 June 2010 00:44, Jeremy Selan <jeremy...@...> wrote:
This one will actually build on other people's machines... --
Bruno Nicoletti
|
|
Re: [ocs-dev] OCS v0.5.5 posted
Jeremy Selan <jeremy...@...>
The use of tr1 shared_ptr is only a stub. When we get multi-platform
stuff sorted out that section will definitely be replaced with platform / compiler specific #ifdefs. Any shared_ptr that provides a dynamic_cast will suffice. (tr1 does work on osx already though :) ) First a justification of shared_ptrs in general... We've spend a long time thinking about object ownership and object lifetimes, and the choice to expose a smart pointer was not arrived at lightly. I do not see a graceful alternative. If people are interested we should probably discuss this further to bring everyone on board. (Or to prove me wrong!) The quick summary is that in the context of multi-threaded apps, where there exists a 'global' config people can get/set, you need to have some form of reference counting to assure that configs aren't destroyed while still in use. I would have ended up just re inventing a shared_ptr / intrusive_ptr, so it seemed expedient to just use a real one. It will also allow for a more simper python use model, as objects can now be created on either side of the fence (C++ or python) and passed back and forth without concern for object lifetime. (Keeping a reference to the python object will keep the C++ object alive, which is very desirable). This will particularly be useful in python UIs that make use of the mutable API. (To create and edit configs 'live') One related thing of note - all exposed objects which use shared-ptrs have private constructors; the only way to create them is with static factory functions. Example: ColorSpaceRcPtr ColorSpace::Create() . This is done so that the shared pointer is always created with a custom object deallocator. Our hope is this will work solve the windows dll memory management issue. (And we hope to verify this soon). OCS::ImageDesc The init functions could definitely be constructors. My concerns is that it would then rely on type signatures to maintain uniqueness, and this has hosed me in the past. (Particularly where default values / int / bools are involved). You can accidentally create a change which is binary compatible, but not source compatible. I really like having super explicit names such as initRGBA, initSingleBuffer, initMultiBuffer. This will also let us add new convenience constructors should they be desired without worrying about compatibility. (Consider 'initRGB', which would have the same type signature as initRGBA. But I agree the current init functions aren't ideal. Does anyone have ideas? Soon enough we will have a live share of the GIT repo, and which point everyone can start contributing... ;) -- Jeremy On Fri, Jun 4, 2010 at 4:09 AM, Bruno Nicoletti <bruno.j....@...> wrote: Hi Jeremy,
|
|
Re: OCS v0.5.5 posted
Jeremy Selan <jeremy...@...>
Oh, and to clarify,
toggle quoted messageShow quoted text
Is your fear related to the specific include of the TR1 shared_ptr, or to shared_ptrs in public headers in general? -- Jeremy
looking much nicer. However, I have The Fear as you are using C++ TR1
|
|
Re: [ocs-dev] OCS v0.5.5 posted
Bruno Nicoletti <bruno.j....@...>
Hi Jeremy,
toggle quoted messageShow quoted text
thanks for the reply. I'm a firm believer in smart pointers, choosing what to expose can be problematic in an API like this when there is no firm standard. #ifndefs is the way around it. As for the ctors, derive thin classes from the base one, which have nothing but ctors in them. class PackedImageDesc : public ImageDesc { public : PackedImageDesc(....); }; class PlanarImageDesc : public ImageDesc { public : PlanarImageDesc(....); }; All you functions should take const references to ImageDesc, and it will all work happily. That should do it.
On 4 June 2010 16:41, Jeremy Selan <jeremy...@...> wrote:
The use of tr1 shared_ptr is only a stub. When we get multi-platform --
Bruno Nicoletti
|
|