Date   

Re: Status of CSP prelut?

"dbr/Ben" <b...@...>
 

Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.
Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.
https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready? I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).
SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.
Do you have example CSP files that use the prelut? I'd love to look at them.
-- Jeremy
On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..
From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?
- Ben


Re: Review: ociocheck

"dbr/Ben" <b...@...>
 

Only seems to use BOOST_FOREACH - should be easy enough to replace with an old-fashioned for()

On 05/02/2011, at 9:46 AM, Malcolm Humphreys wrote:

I was looking at oiio argparse but that too seems dependant on boost for something I remember.

.malcolm

On 05/02/2011, at 7:00 AM, Jeremy Selan wrote:

Agreed about the --inputconfig / $OCIO option. I've added that.

I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.

-- Jeremy

On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote:
Looks good!

Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:

$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...

Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)

Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?

On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555

ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.

-- Jeremy


Re: Review: ociocheck

Malcolm Humphreys <malcolmh...@...>
 

I was looking at oiio argparse but that too seems dependant on boost for something I remember.

.malcolm

On 05/02/2011, at 7:00 AM, Jeremy Selan wrote:

Agreed about the --inputconfig / $OCIO option. I've added that.

I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.

-- Jeremy

On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote:
Looks good!

Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:

$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...

Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)

Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?

On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555

ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.

-- Jeremy


Re: Review: ociocheck

Jeremy Selan <jeremy...@...>
 

Agreed about the --inputconfig / $OCIO option. I've added that.

I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.

-- Jeremy

On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote:
Looks good!

Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:

$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...

Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)

Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?

On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555

ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not.  This will catch
potential errors related to missing luts, etc.

-- Jeremy


Re: Review: upgrade to pyglue

Jeremy Selan <jeremy...@...>
 

Ope, that's an embarrassing copy/paste error... fixed!

I totally agree that python docstrings are critical. I'll add the
task to the git issues list, and try to get to it soon.

-- Jeremy

On Fri, Feb 4, 2011 at 2:26 AM, dbr/Ben <b...@...> wrote:
Looks much more Python'y \o/

Would be good to have more helpful method signatures for __init__ - would make this feature more discoverable - currently it just says:

help(OCIO.FileTransform)
...
 |  __init__(...)
 |      x.__init__(...) initializes x; see x.__class__.__doc__ for signature

Also,
OCIO.FileTransform(cccid = "a")
..causes a segfault - probably due to line 213:

if(cccid) transform->setCCCId(src);

On 04/02/2011, at 5:42 AM, Jeremy Selan wrote:

Commits:
http://github.com/jeremyselan/OpenColorIO/commit/a764a5f7fb151d13be93107697262a670ba34392


This add kwarg support to most of the transform constructors in
python. Makes it way more convenient to construct profiles in python.

Old:
t = OCIO.FileTransform()
t.setSrc('taco')

New:
t = OCIO.FileTransform(src='taco')

group = OCIO.GroupTransform(transforms)

-- Jeremy


Re: Review: ociocheck

"dbr/Ben" <b...@...>
 

Looks good!

Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:

$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...

Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)

Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?

On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555

ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.

-- Jeremy


Re: Review: upgrade to pyglue

"dbr/Ben" <b...@...>
 

Looks much more Python'y \o/

Would be good to have more helpful method signatures for __init__ - would make this feature more discoverable - currently it just says:

help(OCIO.FileTransform)
...
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature

Also,
OCIO.FileTransform(cccid = "a")
..causes a segfault - probably due to line 213:

if(cccid) transform->setCCCId(src);

On 04/02/2011, at 5:42 AM, Jeremy Selan wrote:

Commits:
http://github.com/jeremyselan/OpenColorIO/commit/a764a5f7fb151d13be93107697262a670ba34392


This add kwarg support to most of the transform constructors in
python. Makes it way more convenient to construct profiles in python.

Old:
t = OCIO.FileTransform()
t.setSrc('taco')

New:
t = OCIO.FileTransform(src='taco')

group = OCIO.GroupTransform(transforms)

-- Jeremy


Re: Stable Version, Ahoy!

Malcolm Humphreys <malcolmh...@...>
 

Hi,

My top few right now

- Bit depth support in the API
- !<Look> concept fleshed out a little
- Transform / Op Plugin API
- Static Link working
- Update to the latest yaml-cpp from trunk, it has some new features so we can have tags like (!ColorSpace) rather than (!<ColorSpace>), mostly visual but really makes it not look like xml.

.malcolm

On 04 Feb, 2011,at 01:05 PM, Jeremy Selan <jere...@...> wrote:

Team Coco,

OpenColorIO is rapidly approaching stability, so the time is ripe to
lock off on our next stable API version. If you have any short-term
additions or requests that will break API binary compatibility (or
modify the .ocio format in a non-backwards compatible manner), now is
the time to shout.

The plan is by March 1 to lock off on a stable 0.8 branch.

Of course, there's a whole slew of features + optimizations scheduled
to be addressed after March 1st, but all of these will addressed in an
ABI friendly manner.

The long-term plan is for 0.8 to be rock solid for 6 or so months, and
then to address all (hopefully minor) comments in a 1.0 release around
summer.

Thanks for keeping up with us thus far!

-- Jeremy


Stable Version, Ahoy!

Jeremy Selan <jeremy...@...>
 

Team Coco,

OpenColorIO is rapidly approaching stability, so the time is ripe to
lock off on our next stable API version. If you have any short-term
additions or requests that will break API binary compatibility (or
modify the .ocio format in a non-backwards compatible manner), now is
the time to shout.

The plan is by March 1 to lock off on a stable 0.8 branch.

Of course, there's a whole slew of features + optimizations scheduled
to be addressed after March 1st, but all of these will addressed in an
ABI friendly manner.

The long-term plan is for 0.8 to be rock solid for 6 or so months, and
then to address all (hopefully minor) comments in a 1.0 release around
summer.

Thanks for keeping up with us thus far!

-- Jeremy


Re: Status of CSP prelut?

Jeremy Selan <jeremy...@...>
 

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.
Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.
https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready?  I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).
SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.
Do you have example CSP files that use the prelut? I'd love to look at them.
-- Jeremy
On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..
From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?
- Ben


Review: update config file loading

Jeremy Selan <jeremy...@...>
 

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/05354bc1aad4325eca4cdbef64b4edaade8f16dc

$OCIO, ociocheck, and other programs that end up calling
Config::CreateFromFile(...), can now specify relative path locations.

-- Jeremy


Review: ociocheck

Jeremy Selan <jeremy...@...>
 

Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555

ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.

-- Jeremy


Review: upgrade to pyglue

Jeremy Selan <jeremy...@...>
 

Commits:
http://github.com/jeremyselan/OpenColorIO/commit/a764a5f7fb151d13be93107697262a670ba34392


This add kwarg support to most of the transform constructors in
python. Makes it way more convenient to construct profiles in python.

Old:
t = OCIO.FileTransform()
t.setSrc('taco')

New:
t = OCIO.FileTransform(src='taco')

group = OCIO.GroupTransform(transforms)

-- Jeremy


Re: Status of CSP prelut?

Malcolm Humphreys <malcolmh...@...>
 

I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.

Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.
https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/trunk/src/Interpolators.c

Ben - Do you already have suitable spline code ready? I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).
SplineOp should sampled into the 1D lut on load (+1)

If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.

Do you have example CSP files that use the prelut? I'd love to look at them.

-- Jeremy


On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben


Re: Review: added ociobuildicc app

Malcolm Humphreys <malcolmh...@...>
 

Using the Probev2_ICCv4 Profile (http://www.color.org/probeprofile.xalter) Photoshop CS5 doesn't seem to support the MPE tags.

boo

.malcolm

On 01/02/2011, at 4:08 PM, Malcolm Humphreys wrote:

Hi Joesph,

It has been approved but not added to a new spec yet.

http://www.color.org/icc_specs2.xalter
--snip--
Approved revisions since ICC.1:2004-10
25 Feb 2010 Dictionary Type and Metadata TAG Definition
7 Nov 2007 Deletion of mediaBlackPointTag
11 Apr 2007 Colorimetric Intent Image State tag
11 Apr 2007 Profile Sequence Identifier tag
2 Nov 2006 Floating Point Device Encoding Range
13 Jun 2006 Motion Picture technology tags
22 Feb 2005 Perceptual Intent Reference Medium Color Gamut
--snip--

It's also referenced in the book 'Color Management: Understanding and Using ICC Profiles'. Both http://sourceforge.net/projects/sampleicc/ and littleCMS support MPE tags, and the book also suggests that their is a version of Adobe CMM that also supports MPE.

I have only recently been aware of the new MPE tags and haven't gotten it to work in photoshop, would be nice if it did work. I'm sure their is some secrete sauce lying around somewhere that will make it work.

.malcolm

On 01/02/2011, at 12:49 PM, Joseph Slomka wrote:

Malcolm,

This is slightly off topic.

Is there a new ICC standard support for the MPE tags? The newest document I found on this was http://ntust-ciic.no-ip.info/ciic/Phil_Green-Taiwan-Presentations/ITRI-ICC-6-10-09.pdf That document is not even a proposal.

It still looks like the D2Bx tags are not officially supported. In your expecience do most CMM's and applications implement D2Bx support?

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Thursday, January 27, 2011 10:47 PM
To: OpenColorIO Developers
Subject: [ocio-dev] Review: added ociobuildicc app

Added ociobuildicc app which will build a soft-proofing icc profile for a given working space.
(added LCMS2 into ext)

Commits:
https://github.com/malcolmhumphreys/OpenColorIO/commit/1b0d39fb10db10f4edbf1fb0fed124b548b836d9

Attached is an example of two profiles in action.

From the left
* sRGB reference image (ocio cpu)
* matte paint allocation space
* log space image.

The visual difference in the log image is most likely caused by 16bit quantization errors in the CLUT of the AToB0Tag. These errors are less with the matte paint allocation as the distance to travel is less.

I did play around with supporting the new MPE D2Bx and B2Dx tags which should make this problem go away (http://www.color.org/ICCSpecRevision_02_11_06_Float.pdf) but couldn't get it too work reliably so I pulled it out till I can.

.malcolm


Re: Status of CSP prelut?

Jeremy Selan <jeremy...@...>
 

Yes, we're waiting on spline interpolation code.

Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.

Ben - Do you already have suitable spline code ready? I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).

If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.

Do you have example CSP files that use the prelut? I'd love to look at them.

-- Jeremy

On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben


0.7.6 Released

Jeremy Selan <jeremy...@...>
 

Hello!

OpenColorIO 0.7.6 has been released:

**Version 0.7.6 (Feb 1 2011):**
* Updated Config Display API (.ocio config format updated)
* Added ocio2icc app (ICC Profile Generation)
* Revamp of ASC CDL, added .cc and .ccc support
* Documentation Improvements
* Makefile enhancements (Boost_INCLUDE_DIR, etc)


We have also posted updated profiles that use the new .config file format.
http://sites.google.com/site/opencolorio/downloads

-- Jeremy


Re: Review: DisplayTransform interface update

Jeremy Selan <jeremy...@...>
 

Committed.

-- Jeremy

On Tue, Feb 1, 2011 at 2:37 PM, dbr/Ben <dbr....@...> wrote:
Looks good. I think the display/view terminology is much clearer/more descriptive


Status of CSP prelut?

dbr/Ben <dbr....@...>
 

I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben


Re: Review: DisplayTransform interface update

dbr/Ben <dbr....@...>
 

Looks good. I think the display/view terminology is much clearer/more descriptive

On 02/02/2011, at 8:18, Jeremy Selan <jeremy...@...> wrote:

Here's an update that addresses all previous comments.
http://github.com/jeremyselan/OpenColorIO/commit/2b926355196bcd1690f9dd5a924c3d04ff24cd53

This commit updates the APIs to use our newer terminology + functionality:
- Display - a virtual or physical display device
- View - a meaningful view of the reference space on a Display

It also changes the .ocio config format:

displays:
DCIP3:
- !<View> {name: Raw, colorspace: nc10}
- !<View> {name: Log, colorspace: lg10}
- !<View> {name: Film, colorspace: p3dci8}
sRGB:
- !<View> {name: Raw, colorspace: nc10}
- !<View> {name: Log, colorspace: lg10}
- !<View> {name: Film, colorspace: srgb8}
Cheese:
- !<View> {name: Raw, colorspace: nc10}
- !<View> {name: Log, colorspace: lg10}
active_displays: [sRGB, DCIP3, Cheese]
active_views: [Film, Log, Raw]

(The old format is still allowed for backwards compatibility purposes.)

New environment variables are exposed:
$OCIO_ACTIVE_DISPLAYS
$OCIO_ACTIVE_VIEWS
which allow these lists to be pruned / prioritized at runtime.

Upon this commit being approved, I will put out updated configurations
that match this spec.

-- Jeremy

1781 - 1800 of 2226