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.

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

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

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

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....@...> 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.))

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

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

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

I wasn't originally in love with the name Open Color Space, but I have
to admit it's grown on me.

What are other people's feeling on "OCS"?

Previously, David (Gordon) has suggested that the use of "Open" is
very 90s/cliche, and recommended dropping it. It's hard to disagree,
plain "ColorSpace" is not really googleable.

Malcolm has also suggested that a name such as "Open Color Space" is
perhaps misleading...

Malcolm: "I was telling one of the digital sups about it at DrD today.
His first response was asking which monitor probes it will support,
which I then had to go through and explain what OCS is trying to
achieve and what that would mean for productions at DrD (ie for DrD
this doesn't replace truelight or cinespace, just compliments them)."

Malcolm's suggested a few additions (with my added notes)

- OpenColorWorkSpace   (Sony's DI facility is called ColorWorks, not
sure if this is good or bad)
- OpenColorIO
- OpenColorFlow  (same name as kodak product)
- OpenColorWorkFlow
- OpenColorTransfer
- OpenColorBase (makes me think it's related to baselight)

None of these particularly jump out at me, but I'm open to all ideas.

What are peoples thoughts?

There's time yet to rethink OCS's name, but the window is closing...

I agree that the system is more about conversion between spaces.  OCC?

RGB

PS - nice try sneaking the "u" into color, Bruno...

On Fri, Jun 18, 2010 at 6:59 AM, Bruno Nicoletti

<bruno.j....@...> wrote:

How about "Open Colour Management"? Seeing as it is more about
coordinating the whole mess of colour spaces and displays and so on,
rather than being a colour space per se.

b

On 18 June 2010 08:52, Jeremy Selan <jeremy...@...> wrote:

I wasn't originally in love with the name Open Color Space, but I have
to admit it's grown on me.

What are other people's feeling on "OCS"?

Previously, David (Gordon) has suggested that the use of "Open" is
very 90s/cliche, and recommended dropping it. It's hard to disagree,
plain "ColorSpace" is not really googleable.

Malcolm has also suggested that a name such as "Open Color Space" is
perhaps misleading...

Malcolm: "I was telling one of the digital sups about it at DrD today.
His first response was asking which monitor probes it will support,
which I then had to go through and explain what OCS is trying to
achieve and what that would mean for productions at DrD (ie for DrD
this doesn't replace truelight or cinespace, just compliments them)."

Malcolm's suggested a few additions (with my added notes)

- OpenColorWorkSpace   (Sony's DI facility is called ColorWorks, not
sure if this is good or bad)
- OpenColorIO
- OpenColorFlow  (same name as kodak product)
- OpenColorWorkFlow
- OpenColorTransfer
- OpenColorBase (makes me think it's related to baselight)

None of these particularly jump out at me, but I'm open to all ideas.

What are peoples thoughts?

There's time yet to rethink OCS's name, but the window is closing...

--
Bruno Nicoletti

Ope,

Turns out I may have opened a can of worms on our end.  I didnt
realize this yesterday, but we'd already gotten legal signoff on the
"OCS" name, and changing it now is not gonna be simple.

So keep thinking of ideas, but don't anyone get their hopes up about
"Open Color Management" yet. :(

-- Jeremy