Date   

OCS 0.5.7 posted

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

0.5.7 features:
* Python API is much more fleshed out (object ownership is clarified),
object mutability is explicit
* Improved public C++ header (functions if-def'd out have been removed
(temporarily))

Coming up soon:
* Addl image processing ops
* DisplayTransform / GPU


Re: [ocs-dev] Re: Got Luts?

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

Good feedback. How about this:

Let's support all trivial image formats, as long as it doesn't
introduce a library dependency or support headache. So PPM is in. If
there's a simple raw/ascii float format someone can recommend, let's
add that too.

Exr, dpx, tiff, jpg, etc are out.

As OIIO supports ppm we just need to validate the conversion path, and
then we can recommend it's use as a pre-process. (And OIIO will be
gaining DPX support this summer so then all bases are covered).

I'd like to avoid larry suggested 'raw lut access' approach in the
short-term, at least until the bundled .ocs file support is worked
out.

-- Jeremy

On Tue, Jun 8, 2010 at 1:58 PM, bsloan <bsl...@gmail.com> wrote:
I've used 10bit DPX for this purpose in the past (when I thought I'd
invented 2D 3D LUTs).

8 or 16 bit PPM may be a good compromise. It won't please everyone but
implementation requires so little code -- and the advantage of *not*
having to depend on openimageio may outweigh the disadvantage of
whining developers :).

There's some precedent for this -- NVidia's early Cg SDK provided the
source for a lightweight PPM IO library.

Who knows? This may be one case where OCS can influence the standard.

-blake


On Jun 8, 11:28 am, Larry Gritz <l....@imageworks.com> wrote:
I wouldn't burden OCS with the image-reading functionality.  You'll never make everybody happy without supporting a bzillion formats.  Why not just allow the lut to be specified as a big array and call it a day, and let apps that use OCS be responsible for reading the image files (or having its own dependency on an image-reading library) in order to pass the array?

On Jun 8, 2010, at 11:10 AM, Naty Hoffman wrote:



There are some subtleties with layout and mappings, so let me know
when it's time to implement the import/export logic and I'll write up
a spec.
As for file formats, people use different ones - TIFF and TGA are
common.  There are enough tools to support converting between 2D
formats that I don't know if it's worth adding complex library
dependencies to Open Color Space just for this. Does OCS have any 2D
image file formats supported at the moment? PPM (the RGB version of
PBM) could perhaps work - how widely is it supported by common image
viewing utilities, OS thumbnails, etc.?
Naty
Sent from my iPhone
On Jun 8, 2010, at 10:05 AM, Jeremy Selan <jeremy...@gmail.com>
wrote:
Yah, the "lut as image" approach should be really easy to support,
I'll add that to the short list.  My only concern would be which
fileformats to support.  I'd still like to keep our dependencies as
low as possible though.  Naty, when folks use this approach in
production, which file formats are actually used to store the pixel
data?
If it were a trivial ascii format (such as pbm,pnm, etc) that would be
ideal... ;)
-- Jeremy
On Jun 7, 7:04 pm, "Nathaniel Hoffman" <n....@io.com> wrote:
Jeremy,
The 2D LUT format I describe below is starting to become a bit more
standardized in the game industry - it is being used by two major
middleware companies (Crytek and Epic - see here:http://
udn.epicgames.com/Three/ColorGrading.html). So it might make sense
to support it after all...
Thanks,
Naty
Jeremy,
There are two LUT formats I know of that are used in game
development.
One is a 2D image format (any lossless image format will do -
we've used
BMP, TGA and PNG) with a 2D representation of the LUT where the
planes
along the 3rd axis have been placed next to each other. So a
32x32x32 LUT
would turn into a 1024x32 2D image. A common usage is for an
identity LUT
in this format to be placed next to an ungraded screenshot, both
manipulated in Photoshop or some other color manipulation package,
and
then the colorized LUT is extracted.
The other format is a DDS (Microsoft DirectDraw Surface) file with
a 3D
texture in it, typically uncompressed. This is usually loaded
directly
into the game engine.
These are both a bit ad-hoc and not really standardized, so I
don't know
if they are relevant for OCS. If they are, let me know and I can
try to
work up something more like an actual spec for each of these.
Thanks,
Naty
Hello!
I'm at the stage where I would like to get a survey of lut file
formats (1d, 3d, matrix, etc) that folks actually use in the wild.
If you commonly use a lut format at your facility, or define one in
your software package, I would hugely appreciate it if you could
upload example files and/or spec documents so I can begin work on
the
importers.
Even if it's a proprietary format, I'd love to take a peek so I can
get a sense of the scope of formats out in the wild.  (I need to
make
sure the internal API is rich enough to encompass current use
cases).
Many formats have been mentioned previously, including:
   - Truelight ASCII .cub 3D lut
   - Assimilate Scratch  (Arri /Kodak .3dl)
   - Iridas Framecycler  (Iridas .cube)
   - Autodesk            (MESH3D, .lut, etc.)
For the majority of these, I do not have either example files or
specifications. Please help! :)
Also, does anyone know if the majority of lut formats
identifiable by
their extension?  Are there common extension conflicts?  Ideally,
I'd
like to try and have format reader registered based on file
extension,
and only if that fails give each lut loader a chance to read it.
(Similar to how reader plugins work in nuke).
(Note that I'm not assuming 1 file == 1 lut.  (We will support
readers
where 1 file can generate multiple transforms, such as a 1d
shaper lut
-> 3d lut -> 1d shaper lut.))
--
Larry Gritz
l....@imageworks.com


Re: Got Luts?

bsloan <bsl...@...>
 

I've used 10bit DPX for this purpose in the past (when I thought I'd
invented 2D 3D LUTs).

8 or 16 bit PPM may be a good compromise. It won't please everyone but
implementation requires so little code -- and the advantage of *not*
having to depend on openimageio may outweigh the disadvantage of
whining developers :).

There's some precedent for this -- NVidia's early Cg SDK provided the
source for a lightweight PPM IO library.

Who knows? This may be one case where OCS can influence the standard.

-blake

On Jun 8, 11:28 am, Larry Gritz <l....@imageworks.com> wrote:
I wouldn't burden OCS with the image-reading functionality.  You'll never make everybody happy without supporting a bzillion formats.  Why not just allow the lut to be specified as a big array and call it a day, and let apps that use OCS be responsible for reading the image files (or having its own dependency on an image-reading library) in order to pass the array?

On Jun 8, 2010, at 11:10 AM, Naty Hoffman wrote:



There are some subtleties with layout and mappings, so let me know  
when it's time to implement the import/export logic and I'll write up  
a spec.
As for file formats, people use different ones - TIFF and TGA are  
common.  There are enough tools to support converting between 2D  
formats that I don't know if it's worth adding complex library  
dependencies to Open Color Space just for this. Does OCS have any 2D  
image file formats supported at the moment? PPM (the RGB version of  
PBM) could perhaps work - how widely is it supported by common image  
viewing utilities, OS thumbnails, etc.?
Naty
Sent from my iPhone
On Jun 8, 2010, at 10:05 AM, Jeremy Selan <jeremy...@gmail.com>  
wrote:
Yah, the "lut as image" approach should be really easy to support,
I'll add that to the short list.  My only concern would be which
fileformats to support.  I'd still like to keep our dependencies as
low as possible though.  Naty, when folks use this approach in
production, which file formats are actually used to store the pixel
data?
If it were a trivial ascii format (such as pbm,pnm, etc) that would be
ideal... ;)
-- Jeremy
On Jun 7, 7:04 pm, "Nathaniel Hoffman" <n....@io.com> wrote:
Jeremy,
The 2D LUT format I describe below is starting to become a bit more
standardized in the game industry - it is being used by two major
middleware companies (Crytek and Epic - see here:http://
udn.epicgames.com/Three/ColorGrading.html). So it might make sense
to support it after all...
Thanks,
Naty
Jeremy,
There are two LUT formats I know of that are used in game  
development.
One is a 2D image format (any lossless image format will do -  
we've used
BMP, TGA and PNG) with a 2D representation of the LUT where the  
planes
along the 3rd axis have been placed next to each other. So a  
32x32x32 LUT
would turn into a 1024x32 2D image. A common usage is for an  
identity LUT
in this format to be placed next to an ungraded screenshot, both
manipulated in Photoshop or some other color manipulation package,  
and
then the colorized LUT is extracted.
The other format is a DDS (Microsoft DirectDraw Surface) file with  
a 3D
texture in it, typically uncompressed. This is usually loaded  
directly
into the game engine.
These are both a bit ad-hoc and not really standardized, so I  
don't know
if they are relevant for OCS. If they are, let me know and I can  
try to
work up something more like an actual spec for each of these.
Thanks,
Naty
Hello!
I'm at the stage where I would like to get a survey of lut file
formats (1d, 3d, matrix, etc) that folks actually use in the wild.
If you commonly use a lut format at your facility, or define one in
your software package, I would hugely appreciate it if you could
upload example files and/or spec documents so I can begin work on  
the
importers.
Even if it's a proprietary format, I'd love to take a peek so I can
get a sense of the scope of formats out in the wild.  (I need to  
make
sure the internal API is rich enough to encompass current use  
cases).
Many formats have been mentioned previously, including:
   - Truelight ASCII .cub 3D lut
   - Assimilate Scratch  (Arri /Kodak .3dl)
   - Iridas Framecycler  (Iridas .cube)
   - Autodesk            (MESH3D, .lut, etc.)
For the majority of these, I do not have either example files or
specifications. Please help! :)
Also, does anyone know if the majority of lut formats  
identifiable by
their extension?  Are there common extension conflicts?  Ideally,  
I'd
like to try and have format reader registered based on file  
extension,
and only if that fails give each lut loader a chance to read it.
(Similar to how reader plugins work in nuke).
(Note that I'm not assuming 1 file == 1 lut.  (We will support  
readers
where 1 file can generate multiple transforms, such as a 1d  
shaper lut
-> 3d lut -> 1d shaper lut.))
--
Larry Gritz
l....@imageworks.com


Re: [ocs-dev] Re: Got Luts?

Larry Gritz <l...@...>
 

I wouldn't burden OCS with the image-reading functionality. You'll never make everybody happy without supporting a bzillion formats. Why not just allow the lut to be specified as a big array and call it a day, and let apps that use OCS be responsible for reading the image files (or having its own dependency on an image-reading library) in order to pass the array?


On Jun 8, 2010, at 11:10 AM, Naty Hoffman wrote:

There are some subtleties with layout and mappings, so let me know
when it's time to implement the import/export logic and I'll write up
a spec.

As for file formats, people use different ones - TIFF and TGA are
common. There are enough tools to support converting between 2D
formats that I don't know if it's worth adding complex library
dependencies to Open Color Space just for this. Does OCS have any 2D
image file formats supported at the moment? PPM (the RGB version of
PBM) could perhaps work - how widely is it supported by common image
viewing utilities, OS thumbnails, etc.?

Naty

Sent from my iPhone

On Jun 8, 2010, at 10:05 AM, Jeremy Selan <jeremy...@gmail.com>
wrote:

Yah, the "lut as image" approach should be really easy to support,
I'll add that to the short list. My only concern would be which
fileformats to support. I'd still like to keep our dependencies as
low as possible though. Naty, when folks use this approach in
production, which file formats are actually used to store the pixel
data?
If it were a trivial ascii format (such as pbm,pnm, etc) that would be
ideal... ;)

-- Jeremy

On Jun 7, 7:04 pm, "Nathaniel Hoffman" <n....@io.com> wrote:
Jeremy,

The 2D LUT format I describe below is starting to become a bit more
standardized in the game industry - it is being used by two major
middleware companies (Crytek and Epic - see here:http://
udn.epicgames.com/Three/ColorGrading.html). So it might make sense
to support it after all...

Thanks,

Naty



Jeremy,
There are two LUT formats I know of that are used in game
development.
One is a 2D image format (any lossless image format will do -
we've used
BMP, TGA and PNG) with a 2D representation of the LUT where the
planes
along the 3rd axis have been placed next to each other. So a
32x32x32 LUT
would turn into a 1024x32 2D image. A common usage is for an
identity LUT
in this format to be placed next to an ungraded screenshot, both
manipulated in Photoshop or some other color manipulation package,
and
then the colorized LUT is extracted.
The other format is a DDS (Microsoft DirectDraw Surface) file with
a 3D
texture in it, typically uncompressed. This is usually loaded
directly
into the game engine.
These are both a bit ad-hoc and not really standardized, so I
don't know
if they are relevant for OCS. If they are, let me know and I can
try to
work up something more like an actual spec for each of these.
Thanks,
Naty
Hello!
I'm at the stage where I would like to get a survey of lut file
formats (1d, 3d, matrix, etc) that folks actually use in the wild.
If you commonly use a lut format at your facility, or define one in
your software package, I would hugely appreciate it if you could
upload example files and/or spec documents so I can begin work on
the
importers.
Even if it's a proprietary format, I'd love to take a peek so I can
get a sense of the scope of formats out in the wild. (I need to
make
sure the internal API is rich enough to encompass current use
cases).
Many formats have been mentioned previously, including:
- Truelight ASCII .cub 3D lut
- Assimilate Scratch (Arri /Kodak .3dl)
- Iridas Framecycler (Iridas .cube)
- Autodesk (MESH3D, .lut, etc.)
For the majority of these, I do not have either example files or
specifications. Please help! :)
Also, does anyone know if the majority of lut formats
identifiable by
their extension? Are there common extension conflicts? Ideally,
I'd
like to try and have format reader registered based on file
extension,
and only if that fails give each lut loader a chance to read it.
(Similar to how reader plugins work in nuke).
(Note that I'm not assuming 1 file == 1 lut. (We will support
readers
where 1 file can generate multiple transforms, such as a 1d
shaper lut
-> 3d lut -> 1d shaper lut.))
--
Larry Gritz
l...@imageworks.com


Re: [ocs-dev] Re: Got Luts?

Naty Hoffman <na...@...>
 

There are some subtleties with layout and mappings, so let me know when it's time to implement the import/export logic and I'll write up a spec.

As for file formats, people use different ones - TIFF and TGA are common. There are enough tools to support converting between 2D formats that I don't know if it's worth adding complex library dependencies to Open Color Space just for this. Does OCS have any 2D image file formats supported at the moment? PPM (the RGB version of PBM) could perhaps work - how widely is it supported by common image viewing utilities, OS thumbnails, etc.?

Naty

On Jun 8, 2010, at 10:05 AM, Jeremy Selan <jeremy...@gmail.com> wrote:

Yah, the "lut as image" approach should be really easy to support,
I'll add that to the short list. My only concern would be which
fileformats to support. I'd still like to keep our dependencies as
low as possible though. Naty, when folks use this approach in
production, which file formats are actually used to store the pixel
data?
If it were a trivial ascii format (such as pbm,pnm, etc) that would be
ideal... ;)

-- Jeremy

On Jun 7, 7:04 pm, "Nathaniel Hoffman" <n....@io.com> wrote:
Jeremy,

The 2D LUT format I describe below is starting to become a bit more
standardized in the game industry - it is being used by two major
middleware companies (Crytek and Epic - see here:http:// udn.epicgames.com/Three/ColorGrading.html). So it might make sense
to support it after all...

Thanks,

Naty



Jeremy,
There are two LUT formats I know of that are used in game development.
One is a 2D image format (any lossless image format will do - we've used
BMP, TGA and PNG) with a 2D representation of the LUT where the planes
along the 3rd axis have been placed next to each other. So a 32x32x32 LUT
would turn into a 1024x32 2D image. A common usage is for an identity LUT
in this format to be placed next to an ungraded screenshot, both
manipulated in Photoshop or some other color manipulation package, and
then the colorized LUT is extracted.
The other format is a DDS (Microsoft DirectDraw Surface) file with a 3D
texture in it, typically uncompressed. This is usually loaded directly
into the game engine.
These are both a bit ad-hoc and not really standardized, so I don't know
if they are relevant for OCS. If they are, let me know and I can try to
work up something more like an actual spec for each of these.
Thanks,
Naty
Hello!
I'm at the stage where I would like to get a survey of lut file
formats (1d, 3d, matrix, etc) that folks actually use in the wild.
If you commonly use a lut format at your facility, or define one in
your software package, I would hugely appreciate it if you could
upload example files and/or spec documents so I can begin work on the
importers.
Even if it's a proprietary format, I'd love to take a peek so I can
get a sense of the scope of formats out in the wild. (I need to make
sure the internal API is rich enough to encompass current use cases).
Many formats have been mentioned previously, including:
- Truelight ASCII .cub 3D lut
- Assimilate Scratch (Arri /Kodak .3dl)
- Iridas Framecycler (Iridas .cube)
- Autodesk (MESH3D, .lut, etc.)
For the majority of these, I do not have either example files or
specifications. Please help! :)
Also, does anyone know if the majority of lut formats identifiable by
their extension? Are there common extension conflicts? Ideally, I'd
like to try and have format reader registered based on file extension,
and only if that fails give each lut loader a chance to read it.
(Similar to how reader plugins work in nuke).
(Note that I'm not assuming 1 file == 1 lut. (We will support readers
where 1 file can generate multiple transforms, such as a 1d shaper lut
-> 3d lut -> 1d shaper lut.))


Re: OCS v0.5.6 posted

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

Oh, and for those who geek out on python binding implementations, I'd
invite you to check out:
src/pyglue/
PyConfig.h
PyConfig.cpp

I'm curious to see how people feel about this approach. Rather than
automatically generating bindings (or using tools like boost::python),
I'm hand-crafting them to allow for explicit object / interface
design. The biggest issue is that we're making explicit use of const-
ness on the C side, and python does not have a way to carry this
information over. Our custom binding approach lets us handle this in
a way that's uber-explicit to the end user, with calls such as:

config.isEditable()
config.createEditableCopy()

The hope is that this leads to minimal confusion on the python API
side.

If anyone knows of an approach which automates binding generation, but
also tackles this issue please let me know.

Thanks!

-- Jeremy

On Jun 8, 10:14 am, Jeremy Selan <jeremy...@gmail.com> wrote:
Version 0.5.6 (June 8 2010):
    * PyConfig stub implementation
    * Dropped ImageDesc.init; added PlanarImageDesc / PackedImageDesc
    * Dropped tr1::shared_ptr; added boost::shared_ptr


OCS v0.5.6 posted

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

Version 0.5.6 (June 8 2010):
* PyConfig stub implementation
* Dropped ImageDesc.init; added PlanarImageDesc / PackedImageDesc
* Dropped tr1::shared_ptr; added boost::shared_ptr


Re: Got Luts?

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

Yah, the "lut as image" approach should be really easy to support,
I'll add that to the short list. My only concern would be which
fileformats to support. I'd still like to keep our dependencies as
low as possible though. Naty, when folks use this approach in
production, which file formats are actually used to store the pixel
data?
If it were a trivial ascii format (such as pbm,pnm, etc) that would be
ideal... ;)

-- Jeremy

On Jun 7, 7:04 pm, "Nathaniel Hoffman" <n....@io.com> wrote:
Jeremy,

The 2D LUT format I describe below is starting to become a bit more
standardized in the game industry - it is being used by two major
middleware companies (Crytek and Epic - see here:http://udn.epicgames.com/Three/ColorGrading.html). So it might make sense
to support it after all...

Thanks,

Naty



Jeremy,
There are two LUT formats I know of that are used in game development.
One is a 2D image format (any lossless image format will do - we've used
BMP, TGA and PNG) with a 2D representation of the LUT where the planes
along the 3rd axis have been placed next to each other. So a 32x32x32 LUT
would turn into a 1024x32 2D image. A common usage is for an identity LUT
in this format to be placed next to an ungraded screenshot, both
manipulated in Photoshop or some other color manipulation package, and
then the colorized LUT is extracted.
The other format is a DDS (Microsoft DirectDraw Surface) file with a 3D
texture in it, typically uncompressed. This is usually loaded directly
into the game engine.
These are both a bit ad-hoc and not really standardized, so I don't know
if they are relevant for OCS. If they are, let me know and I can try to
work up something more like an actual spec for each of these.
Thanks,
Naty
Hello!
I'm at the stage where I would like to get a survey of lut file
formats (1d, 3d, matrix, etc) that folks actually use in the wild.
If you commonly use a lut format at your facility, or define one in
your software package, I would hugely appreciate it if you could
upload example files and/or spec documents so I can begin work on the
importers.
Even if it's a proprietary format, I'd love to take a peek so I can
get a sense of the scope of formats out in the wild.  (I need to make
sure the internal API is rich enough to encompass current use cases).
Many formats have been mentioned previously, including:
    - Truelight ASCII .cub 3D lut
    - Assimilate Scratch  (Arri /Kodak .3dl)
    - Iridas Framecycler  (Iridas .cube)
    - Autodesk            (MESH3D, .lut, etc.)
For the majority of these, I do not have either example files or
specifications. Please help! :)
Also, does anyone know if the majority of lut formats identifiable by
their extension?  Are there common extension conflicts?  Ideally, I'd
like to try and have format reader registered based on file extension,
and only if that fails give each lut loader a chance to read it.
(Similar to how reader plugins work in nuke).
(Note that I'm not assuming 1 file == 1 lut.  (We will support readers
where 1 file can generate multiple transforms, such as a 1d shaper lut
-> 3d lut -> 1d shaper lut.))


Re: [ocs-dev] Got Luts?

"Nathaniel Hoffman" <na...@...>
 

Jeremy,

The 2D LUT format I describe below is starting to become a bit more
standardized in the game industry - it is being used by two major
middleware companies (Crytek and Epic - see here:
http://udn.epicgames.com/Three/ColorGrading.html). So it might make sense
to support it after all...

Thanks,

Naty

Jeremy,

There are two LUT formats I know of that are used in game development.

One is a 2D image format (any lossless image format will do - we've used
BMP, TGA and PNG) with a 2D representation of the LUT where the planes
along the 3rd axis have been placed next to each other. So a 32x32x32 LUT
would turn into a 1024x32 2D image. A common usage is for an identity LUT
in this format to be placed next to an ungraded screenshot, both
manipulated in Photoshop or some other color manipulation package, and
then the colorized LUT is extracted.

The other format is a DDS (Microsoft DirectDraw Surface) file with a 3D
texture in it, typically uncompressed. This is usually loaded directly
into the game engine.

These are both a bit ad-hoc and not really standardized, so I don't know
if they are relevant for OCS. If they are, let me know and I can try to
work up something more like an actual spec for each of these.

Thanks,

Naty

Hello!

I'm at the stage where I would like to get a survey of lut file
formats (1d, 3d, matrix, etc) that folks actually use in the wild.

If you commonly use a lut format at your facility, or define one in
your software package, I would hugely appreciate it if you could
upload example files and/or spec documents so I can begin work on the
importers.

Even if it's a proprietary format, I'd love to take a peek so I can
get a sense of the scope of formats out in the wild. (I need to make
sure the internal API is rich enough to encompass current use cases).

Many formats have been mentioned previously, including:
- Truelight ASCII .cub 3D lut
- Assimilate Scratch (Arri /Kodak .3dl)
- Iridas Framecycler (Iridas .cube)
- Autodesk (MESH3D, .lut, etc.)

For the majority of these, I do not have either example files or
specifications. Please help! :)

Also, does anyone know if the majority of lut formats identifiable by
their extension? Are there common extension conflicts? Ideally, I'd
like to try and have format reader registered based on file extension,
and only if that fails give each lut loader a chance to read it.
(Similar to how reader plugins work in nuke).

(Note that I'm not assuming 1 file == 1 lut. (We will support readers
where 1 file can generate multiple transforms, such as a 1d shaper lut
-> 3d lut -> 1d shaper lut.))


Re: [ocs-dev] Re: OCS v0.5.5 posted

Bruno Nicoletti <bruno.j....@...>
 

My fear is that TR1 is somewhat variably implemented at the moment,
though smart pointers should be pretty much stable. The biggie is that
we can't support it on Windows yet.

b

On 4 June 2010 16:49, Jeremy Selan <jeremy...@gmail.com> wrote:
Oh, and to clarify,

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
for smart pointer magic.
--
Bruno Nicoletti


Re: [ocs-dev] OCS v0.5.5 posted

Bruno Nicoletti <bruno.j....@...>
 

Hi Jeremy,

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...@gmail.com> wrote:
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....@googlemail.com> wrote:
Hi Jeremy,

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...@gmail.com> wrote:
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 build
cd build
Configure 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:
make
You will now see the built .so files:
ls
Set the environment variable pointing at which configuration to use:
(Point this to your install)
setenv OCS /net/homedirs/jeremys/git/Color/configs/spivfx/config.ocs
Launch 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')
nuke.menu('Nodes').addMenu('Color').addCommand('OCSColorSpaceConversion', 'nuke.createNode("OCSColorSpaceConversion")')
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.


--
Bruno Nicoletti
--
Bruno Nicoletti


Re: OCS v0.5.5 posted

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

Oh, and to clarify,

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
for smart pointer magic.


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....@googlemail.com> wrote:
Hi Jeremy,

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...@gmail.com> wrote:
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 build
cd build
Configure 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:
make
You will now see the built .so files:
ls
Set the environment variable pointing at which configuration to use:
(Point this to your install)
setenv OCS /net/homedirs/jeremys/git/Color/configs/spivfx/config.ocs
Launch 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')
nuke.menu('Nodes').addMenu('Color').addCommand('OCSColorSpaceConversion', 'nuke.createNode("OCSColorSpaceConversion")')
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.


--
Bruno Nicoletti


Re: [ocs-dev] OCS v0.5.5 posted

Bruno Nicoletti <bruno.j....@...>
 

Hi Jeremy,

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...@gmail.com> wrote:
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 build
cd build
Configure 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:
make
You will now see the built .so files:
ls
Set the environment variable pointing at which configuration to use:
(Point this to your install)
setenv OCS /net/homedirs/jeremys/git/Color/configs/spivfx/config.ocs
Launch 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')
nuke.menu('Nodes').addMenu('Color').addCommand('OCSColorSpaceConversion', 'nuke.createNode("OCSColorSpaceConversion")')
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.
--
Bruno Nicoletti


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 build
cd build
Configure 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:
make
You will now see the built .so files:
ls
Set the environment variable pointing at which configuration to use:
(Point this to your install)
setenv OCS /net/homedirs/jeremys/git/Color/configs/spivfx/config.ocs
Launch 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')
nuke.menu('Nodes').addMenu('Color').addCommand('OCSColorSpaceConversion', 'nuke.createNode("OCSColorSpaceConversion")')
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.


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 -l
93


Re: 3DL cube format.

bsloan <bsl...@...>
 

Yes. Agreed. The importer can use the fuzzy greater-than-1/2-max
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...@gmail.com> wrote:
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?

-- Jeremy

On Wed, May 26, 2010 at 7:08 PM, bsloan <bsl...@gmail.com> wrote:
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?

-- Jeremy

On Wed, May 26, 2010 at 7:08 PM, bsloan <bsl...@...> wrote:
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


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


.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?

2141 - 2160 of 2190