Unit Tests
Malcolm Humphreys <malcolmh...@...>
Hi,
I would like to write tests for the work that I do. What unit test framework are you planning on using, as I guess it adds another dependancy. I have gotten used to using the boost framework but I'm sure you have something else planned. .malcolm
|
|
Re: [ocs-dev] Unit Tests
Bruno Nicoletti <bruno.j....@...>
We use boost's unit test suite here as well, a few quibbles but it
toggle quoted messageShow quoted text
works fairly well. b
On 21 July 2010 15:23, Malcolm Humphreys <malcolmh...@...> wrote:
Hi, --
Bruno Nicoletti
|
|
Re: [ocs-dev] Supporting 1D luts which are different per channel
Jeremy Selan <jeremy...@...>
Malcolm,
I believe the 1D lut op does allow for a different number of entries per channel. If we look at src/core/Lut1DOp.h, you'll see the entry for each color channel lut is stored in an individual vector: fv_t luts[3]. So in your loading code (if we hardcoded the sizes used in your example), lut1d->luts[0].resize(11); lut1d->luts[1].resize(6); lut1d->luts[2].resize(6); Does the rest of the Format loading code make sense to you? All your work should be in a single file, a la FileFormat3DL. A few additional questions for you: * Currently, OCIO only support linear and nearest interpolation for 1D luts. If the examples you've given are typical (where the 1d lut is size 6) I couldnt imagine linear interpolation would suffice, and I'd also imagine that the interpolation type chosen would highly influence the resulting image. Does CSP dictate the interpolation type? What type would you prefer? I have no problem adding higher types (cubic, etc) I just hadnt had the need to yet. (Note that the .3dl shaper 1D lut also has this issue (it's often size 17), I just hadnt tackled it yet.) * Do you care about 4 channel luts? (I.e., changing alpha) We've never needed this at SPI, which is why the OCIO currently assumes 3 channels, but if other people think its important for completeness sake Im open to it. -- Jeremy On Wed, Jul 21, 2010 at 6:11 AM, Malcolm Humphreys <malcolmh...@...> wrote: Hi,
|
|
Re: [ocs-dev] Unit Tests
Jeremy Selan <jeremy...@...>
Boost sounds great; let's start with that.
-- Jeremy On Wed, Jul 21, 2010 at 7:31 AM, Bruno Nicoletti <bruno.j....@...> wrote: We use boost's unit test suite here as well, a few quibbles but it
|
|
Re: [ocs-dev] Unit Tests
Larry Gritz <l...@...>
I've been using that lately on OIIO and OSL, and for our simple needs it works just fine. Also nice because if you're already using Boost for anything else, you can use its unit tests without adding any new dependencies.
-- lg On Jul 21, 2010, at 8:57 AM, Jeremy Selan wrote: Boost sounds great; let's start with that.-- Larry Gritz l...@...
|
|
Re: Supporting 1D luts which are different per channel
Malcolm Humphreys <malcolmh...@...>
Hi Jeremy,
toggle quoted messageShow quoted text
oops never mind looks like it will support it. Yep it all looks ok to me, just really feel like spliting out the non-core stuff into a plugin or similar dir. For now I think nearest iterp is fine as we normally have enough points for 10bits in all channels, we have used Catmull-Rom in the past. As we will be only using this for viewing scene linear it should be ok in the short term. I don't need 4 channel luts, but other people might. .malcolm
On Jul 22, 1:53 am, Jeremy Selan <jeremy...@...> wrote:
Malcolm,
|
|
Birds of Feather Tomorrow (wed)
Jeremy Selan <jeremy...@...>
It was great seeing some of you at today's Siggraph class!
If anyone is interested in more detailed info (or just wants to say hello in person) we'll be having a BOF tomorrow. Hope to see some of you there! Birds of a Feather : OpenColorIO WEDNESDAY, 28 JULY | 2:30 PM - 3:30 PM | ROOM 506 Cheers, Jeremy
|
|
Luma attr error checking
Alan Jones <sky...@...>
Hi all,
The example config doesn't appear to have the required luma attributes. Could someone let me know what and where they should be? Also is there any documentation around or should I just run doxygen over the source? Cheers, Alan
|
|
Re: Luma attr error checking
Jeremy Selan <jeremy...@...>
Alan,
toggle quoted messageShow quoted text
Good catch. I've updated the git repo and the downloads site ( http://code.google.com/p/opencolorio/downloads/list ) so all the configs will work with the latest trunk release. Unfortunately, I'm also a bit behind in the publishing the docs. (I have a version internally, but they're a but out of date). I'll do my best to repost them all within a day or two. Of course, in the next few months I'd like the library to be entirely self documenting (doxygen), and if anyone would like to help get the ball rolling, i'd be very appreciative. (i'm happy to write them all, I just dont have doxygen formatting / makefile experience). I'd also like to have the color profiles be self documenting. (I picture a command-line tool that will load a config, and generate an html page outlining its use, options, etc). -- Jeremy
On Aug 5, 12:25 pm, Alan Jones <sky...@...> wrote:
Hi all,
|
|
Re: [ocs-dev] Re: Luma attr error checking
Alan Jones <sky...@...>
Hi Jeremy,
On Thu, Aug 5, 2010 at 4:16 PM, Jeremy Selan <jeremy...@...> wrote: Good catch. I've updated the git repo and the downloads site (Thanks - it's running happily now. Unfortunately, I'm also a bit behind in the publishing the docs. (II'm currently working on writing a quicktime generator using OpenImageIO, OpenColorIO, libquicktime and Qt. I'd like to check that I'm correctly understanding OpenColorIO's intention. Is it intended that it will handle the color transforms and that those transforms will be stored in it's own XML based format? If so, would it be within the scope of the project to build importers and exporters that for various formats? I'm thinking of cases where I want to bring in a LUT to apply to footage or when I want to supply a LUT from OpenImageIO to another application. Of course, in the next few months I'd like the library to be entirelyI can probably throw in with the doxygen style comments - they're pretty easy so if you're cool with me passing some dumb questions (like the ones above) I'd be happy to help out ther. I'd also like to have the color profiles be self documenting. (IThat sounds like a fantastic idea - LUT formats don't seem to have info needed to really know how to use them. Like what stage they're intended for, the direction of the transform, whether the user will want to offset/multiply/whatever afterward. Cheers, Alan.
|
|
Re: Luma attr error checking
Jeremy Selan <jeremy...@...>
I'm currently working on writing a quicktime generator using OpenImageIO,Cool! That sounds like a really good use case. On our medium term list is to build a bridge between OIIO and OCIO, so you can use OIIO's command-line utilities to do color conversions. But I wouldnt want to promise a date for that, and hooking em up yourself shouldnt be too hard. I'd like to check that I'm correctly understanding OpenColorIO's intention.Yes, exactly. The XML configuration file (.ocio) is super light-weight. All the heavy data (1D LUTs, 3D LUTs) are references to other existing files (which remain in their native formats). Also, you don't have to hand- craft the XML. You can use the OCIO API to build configurations, see src/testbed/main.py for an example. There's also talk of making an ocio "bundle" for easy distribution (which would be the .ocio xml file + the luts directory), but I havent tackled this yet. If so, would it be within the scope of the project to build importersVery much so! What LUT formats do you need support for? Let's get em in there. At some point soon I'll add an ocio command-line utility that will do LUT transcoding - which along with support for more luit formats - should be a really popular option. -- Jeremy
|
|
OCIO 0.5.11 posted
Jeremy Selan <jeremy...@...>
This is a relatively minor update.
Version 0.5.11 (Aug 11 2010): * DisplayTransform API * ASC CDL Support Available on github, and as a .tgz on google code. http://code.google.com/p/opencolorio/downloads/detail?name=ocio.0.5.11.tgz#makecha Most important is that I've recently been stuck with writer's block (coder's block?) on how to generalize the DisplayTransform code, and this gets us over the hump. Full GPU support should now be just around the corner. (Feel free to place bets on the check-in date.) ... and I haven't forgotten about the FAQ and documentation either! -- Jeremy
|
|
The S-Log formula
Alan Jones <sky...@...>
Hi All,
I'm currently writing a LUT to go from S-Log to Rec709. I've got the transfer functions for both and generally the curves I've plotted look like what I expect, but one part of the formula is bothering me. The t in the S-Log whitepaper from Sony (camera Sony - not imageworks) says t ranges from 0 to 109%. So I've been trying to ascertain whether this means in 10bit (for example) that 1023 should be 1.09 or whether it should be 1. A section of the whitepaper shows examples of converting between 10bit S-Log and 14bit linear. It just has some magic numbers in there and I've been trying to nail down exactly how they're calculated in order to answer the 1 vs 1.09 question. Though while I can step kinda close to it I've not just hit exact. So I'm hoping someone here can shed some light on this. Cheers, Alan.
|
|
LUT Plugin API
Alan Jones <sky...@...>
Hi All,
I was thinking it'd be neat if OCIO provided an API for plugin LUTs (i.e. libraries that perform a LUT - they could use formula or whatever internally without any restrictions on syntax, outside of C++ of course). Making the API SIMD compatible could also be worth considering. I thought this may have some benefits over a straight formula syntax support. Particularly not requiring a syntax, the ability to use any library out there, also would make it simple for someone to offload to GPU and use built-in LUT support on those. I'm thinking it'd still be referenced by an xml config the same as all the others - just the source instead of myspace.lut would be myspace.so Cheers, Alan.
|
|
Re: The S-Log formula
Jeremy Selan <jeremy...@...>
Ah, when you read Sony Camera documents you often have to put on your
toggle quoted messageShow quoted text
"video engineer" goggles. :) Which camera are you using? We've done a few Sony camera characterizations, and may have real data for the camera you're interested in. F35, perhaps? In my experience, if you have the luxury of actually running exposure sweeps on a camera you tend to get much more plausible linearizations than by obeying manufacturer claims. Sometimes it's a communication issue, but more often the documentation fails to discriminate between the transform to get to a scene referred linear (input space) vs an output referred linear (display space). Are you referring to this document for the formulas? (SRW_ITG_S- Log_001_IO_EN.pdf) (google search: sony slog) Assuming we trust the document for the moment, I think the rule of thumb is understanding that whenever these guys talk about numbers that include percentages (such as 0%, or 109%), these are video folks talking in IRE land. (Ugh!) In the world of broadcast HD television (rec709 with headroom), a "broadcast safe" black level is at 64/1023, and safe white is 940/1023. Thus for folks in a broadcast-land mindset, if you use the full 10-bit code range you're 'over white' by (1023 / 940) = 1.09. So when the document says "t has a range of 0 to 1.09", I take this to mean that you're expected to have input 10-bit codevalues from 64 - 1023. code 64 = t 0.0 code 1023 = t 1.09 In the later example "S-Log Formula" this is already taken into account for you. Y = 379.044 * log10(((x-128)/1752 + 0.037584) + 630 (This assumes 10-bit input, which in practice will only contain values from 3-1019 due to HD link peculiarities, which you can safely ignore in this case). -- Jeremy
On Aug 12, 9:07 am, Alan Jones <sky...@...> wrote:
Hi All,
|
|
Re: [ocs-dev] Re: The S-Log formula
Alan Jones <sky...@...>
Hi Jeremy,
On Thu, Aug 12, 2010 at 12:01 PM, Jeremy Selan <jeremy...@...> wrote: Ah, when you read Sony Camera documents you often have to put on yourIndeed - I'm still pretty fresh to dealing with this stuff so directly. Time to re-read Poynton's Digital Video. Which camera are you using? We've done a few Sony cameraYes - the F35 :) In my experience, if you have theAnywhere you could point me to for reading up on doing this and using it to generate LUTs? Sometimes it's a communication issue, but more often theYeah - I've taken the formula as being input space and then applying linear to rec709 to the result in order to generate the slog to rec709 LUT. Are you referring to this document for the formulas? (SRW_ITG_S-Yes. Assuming we trust the document for the moment, I think the rule ofAhhhh - thanks :) So when the document says "t has a range of 0 to 1.09", I take this toPerfect :) In the later example "S-Log Formula" this is already taken intoI'm still trying to figure out where some of these values come from. The 1752 is Reference white minus Black level and the 128 is black level. Though the 379.044 and 630 are still mysteries to me. I've tried dividing them by the equivalent part of the formula (though I've been using anti s-log to work on this rather than s-log, but same numbers anyway) and the resulting numbers don't have any easily identifiable correlation with either the input or output spaces. I'd love to know how those are calculated as at the moment I can get my results close when trying to find a generic way to deal with the formula (so I can make it for an arbitrary bit depth), but not exact. Cheers, Alan.
|
|
Re: LUT Plugin API
Jeremy Selan <jeremy...@...>
Sorry for the delay in answering this...
toggle quoted messageShow quoted text
Adding OCIO plugins is a really promising idea, which I'd like to explore in the medium term. I particularly like that it would allow for a clean partitioning of dependencies, and thus could be our window to CTL support! However, in the near team (before Jan) I'm a bit concerned about mission creep, and would like to keep the project focused on getting the simplest, cleanest, and fastest 1.0 implementation out the door. And having a bit of experience with plugin APIs, if they're worth doing at all they're usually worth doing right, so I'd like to make sure we have the time to really focus on doing a thorough job. -- Jeremy
On Aug 12, 9:11 am, Alan Jones <sky...@...> wrote:
Hi All,
|
|
Re: The S-Log formula
Jeremy Selan <jeremy...@...>
Alan,
As a heads up, we're in touch with the Sony camera guys and may be able to offer a 'blessed' f35 linearization as part of OCIO soon... -- Jeremy
|
|
OCIO 0.5.12 posted
Jeremy Selan <jeremy...@...>
A new version is out!
Version 0.5.12 (Aug 18 2010): * Additional DisplayTransform improvements * Additional GPU Improvements * Added op hashing (processor->getGPULut3DCacheID) The big picture overview is that progress is going really well now, and we're definitely on track to have the API locked down in September. (Which will be the 'API stable' 0.6 version). At that point we'll start focusing on documentation, optimization, unit testing, and a bunch more 3rd party plugins (including RV, houdini, etc). ... which are all part of a push for a January 1.0 release! -- Jeremy
|
|
Re: The S-Log formula
Alan Jones <sky...@...>
Hi Jeremy,
On Wed, Aug 18, 2010 at 12:06 PM, Jeremy Selan <jeremy...@...> wrote: As a heads up, we're in touch with the Sony camera guys and may beAwesome - good to know, thanks. I've implemented using that formula with the black point at 64 in 10bit. It looks pretty good and it'd be great to know if it's correct - if anything it feels like it might be crunching the lower end a little too much. Cheers, Alan.
|
|