Date   

Re: Review: updated readme and usage example

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

LGTM

On 15 Dec, 2010,at 06:42 AM, Jeremy Selan <jere...@...> wrote:

Commits:

1c2d95e82e

Not much to this one...

-- Jeremy


Re: Review: Bugfix for GLSL GPU

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

LGTM

On 15 Dec, 2010,at 05:40 AM, Jeremy Selan <jere...@...> wrote:

Commits:
54b464d255

Fixed the bug where the application of MatrixOps on the GPU (for GLSL
only) had the wrong multiplication order.

-- Jeremy


Review: Added example image viewer

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

I've added a working GLSL image viewer example.

It relies on OpenImageIO to load an arbitrary image, and then will
display it using OpenColorIO. It's pretty awesome to see how little
code in practice is needed to implement a full-fledged monitor
interface!
(Including fstop exposure controls, channel swizzling, etc).

For those interested in adding OCIO natively to existing viewers, this
is a great place to start.

Commits:
18ac496924e06
899b272d710ea

Caveot : this doesn't yet work with the CMake makefile, I hope to get
that added soon.

-- Jeremy


Review: updated readme and usage example

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

Commits:

1c2d95e82e

Not much to this one...

-- Jeremy


Review: Bugfix for GLSL GPU

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

Commits:
54b464d255

Fixed the bug where the application of MatrixOps on the GPU (for GLSL
only) had the wrong multiplication order.

-- Jeremy


Re: Adding multiple bit depths to one <!ColorSpace>

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


I like it. However I'd like to keep the option for a family designation. For simple colorspaces I see this as great way to simplify things. The family designation is still useful for instances like in IIF:ACES where the 10 and 16 bit ADX transformations are significantly different.
 
Yeah I can see 'family' would be really useful for grouping colorspaces based on purpose which could be as abstract as the profile builder would like. In the examples I couldn't see a case where family wasn't being used for bit-depth, but I agree it should stay. I agree if a bitdepth change significantly changes the transform required, this would suggest a different !<ColorSpace>.

For differences in bitdepth, I guess the usual case will be buffer A at a certain depth and buffer B at a certain depth, give me the transform from color space A -> B.

I was thinking something along the lines of:
ConstProcessorRcPtr processor = config->getProcessor(
    OCIO::ROLE_COMPOSITING_LOG,
    OCIO::ROLE_SCENE_LINEAR,
    OCIO::BIT_DEPTH_UINT10,
    OCIO::BIT_DEPTH_F16);

This would give you back the correct 10ui log -> f16 linear, without needing to mess around with colorspace names. This would likely end up looking a bit different with the 'context' ideas Jeremy and I chatted about.

Under the hood the colorspace could define the family implicitly from the name.

The SPI examples use the family designation in a very simple way. I could see a reason to place all video space transforms under a single family, for example. This could results in a family with 2 colorspaces that are named differently with the same bit depth.
 
Could you see a colorspace existing in two families? maybe we could have ',' separated tags which would allow for some powerful grouping of colorspace, I'm guessing families are mostly used for UI purposes, ie give me list of all 'video' color spaces. These would be similar to 'tag clouds' www people use to have items in multiple categories / groups.

eg.
- !<ColorSpace>
   name: vdhd
   family: video, hd
   ...

- !<ColorSpace>
   name: vdntsc
   family: video, ntsc
   ...

Maybe that's just a little bit two much over-engineering, for simple grouping.

.malcolm


Re: Adding multiple bit depths to one <!ColorSpace>

Joseph Slomka <jsl...@...>
 

Malcolm,

I like it. However I'd like to keep the option for a family designation. For simple colorspaces I see this as great way to simplify things. The family designation is still useful for instances like in IIF:ACES where the 10 and 16 bit ADX transformations are significantly different.

Under the hood the colorspace could define the family implicitly from the name.

The SPI examples use the family designation in a very simple way. I could see a reason to place all video space transforms under a single family, for example. This could results in a family with 2 colorspaces that are named differently with the same bit depth.

-Joseph

-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Malcolm Humphreys
Sent: Monday, December 13, 2010 4:27 AM
To: ocio...@...
Subject: [ocio-dev] Adding multiple bit depths to one <!ColorSpace>

After playing around with ocio profiles a bit more, I think it would be and idea to have multiple bitdepths defined in one <!ColorSpace> definition.

Below is the vd and nc family colorspaces from the spi-vfx profile. This kind of replaces the family concept, as it seems in all the spi examples that families and names are the way to group color spaces of similar purpose but of different bit-depths.

I'm thinking it feels a bit nicer for a host app to request a named colorspace at a default depth, or request it at a specific depth. I can see that we could get a list of color spaces and do this in a host app but this seems like it should be done by ocio.

ie. the displays would look more like this:

displays:
- !<Display> {device: sRGB, name: Film, colorspace: srgb, bitdepth: 8ui}
- !<Display> {device: sRGB, name: Log, colorspace: lg, bitdepth: 10ui}
- !<Display> {device: DCIP3, name: Film, colorspace: p3dci, bitdepth:
16ui}

Is there a case for two colorspaces in the same family to have the same bitdepth? I would think that would be confusing.

eg. this would make the spi-vfx profile have 11 colorspaces rather than 26, this also helped me spot some possible typos.
--snip--
- !<ColorSpace>
name: ln
isdata: false
gpuallocation: lg2
gpumin: -15
gpumax: 6
bitdepth: 32f
bitdepths:
32f: !<ColorSpaceDetail>
16f: !<ColorSpaceDetail>
16ui: !<ColorSpaceDetail>
gpumax: 0 # typo in the vfx profile?

- !<ColorSpace>
name: lg
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 10ui
bitdepths:
16ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: lg16.spi1d, interpolation:
nearest}
10ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: lg10.spi1d, interpolation:
nearest}
8ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: lg10.spi1d, interpolation:
nearest}
32f: !<ColorSpaceDetail>
gpumin: -0.25
gpumax: 1.5
to_reference: !<FileTransform> {src: lgf.spi1d, interpolation:
linear}

- !<ColorSpace>
name: gn
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 16ui
bitdepths:
16ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: gn16.spi1d, interpolation:
nearest}
10ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: gn16.spi1d, interpolation:
nearest}
8ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: gn16.spi1d, interpolation:
nearest}
32f: !<ColorSpaceDetail>
gpumin: -0.25
gpumax: 1.5
to_reference: !<FileTransform> {src: gnf.spi1d, interpolation:
linear}

- !<ColorSpace>
name: vd
isdata: false # can override these in each bitdepth if needed
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 8ui
bitdepths:
16ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: version_8_whitebalanced.spimtx,
interpolation: unknown, direction: inverse}
- !<FileTransform> {src: vd16.spi1d, interpolation: nearest}
8ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: version_8_whitebalanced.spimtx,
interpolation: unknown, direction: inverse}
- !<FileTransform> {src: vd16.spi1d, interpolation: nearest}
10ui:
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: version_8_whitebalanced.spimtx,
interpolation: unknown, direction: inverse}
- !<FileTransform> {src: vd16.spi1d, interpolation: nearest}
32f:
to_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: vd, src-depth: 16, dst: ln,
dst-depth: 32f}

- !<ColorSpace>
name: hd
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 10ui
bitdepths:
10ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: hdOffset.spimtx, interpolation:
nearest, direction: inverse}
- !<ColorSpaceTransform> {src: vd, src-depth: 32f, dst: ln,
dst-depth: 32f}

- !<ColorSpace>
name: dt
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 8ui
bitdepths:
8ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: diffuseTextureMultiplier.spimtx,
interpolation: nearest}
- !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln,
dst-depth: 32f}
16ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: diffuseTextureMultiplier.spimtx,
interpolation: nearest}
- !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln,
dst-depth: 32f}

- !<ColorSpace>
name: cp
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 32f
bitdepths:
32f: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: cpf.spi1d, interpolation: linear}

- !<ColorSpace>
name: nc
isdata: true
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepths:
8ui: <!ColorSpaceDetail>
10ui: <!ColorSpaceDetail>
16ui: <!ColorSpaceDetail>
isdata: false # vfx profile typo?
32f: <!ColorSpaceDetail>

- !<ColorSpace>
name: srgb
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 8ui
bitdepths:
8ui: !<ColorSpaceDetail>
from_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg,
dst-depth: 32f}
- !<FileTransform> {src: spi_ocio_srgb_test.spi3d,
interpolation: linear}

- !<ColorSpace>
name: p3dci
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 16ui
bitdepths:
16ui: !<ColorSpaceDetail>
from_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg,
dst-depth: 10ui}
- !<FileTransform> {src: colorworks_filmlg_to_p3.3dl,
interpolation: linear}

- !<ColorSpace>
name: xyz
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 16ui
bitdepths:
16ui: !<ColorSpaceDetail>
from_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: lnf, dst: p3dci8}
- !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1]}
- !<FileTransform> {src: p3_to_xyz16.spimtx, interpolation:
unknown}
- !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1], direction:
inverse}
--snip--

.malcolm


Re: Review: added TestForDDImageVersion.cxx to support multiple versions of nuke

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

Looks good to me, thanks!
-- Jeremy

On Mon, Dec 13, 2010 at 1:21 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
On 13/12/10 20:05, Malcolm Humphreys wrote:

(excuse the typos in the actual commit msg)
now fixed with (git commit --amend)

https://github.com/malcolmhumphreys/OpenColorIO/commit/c95536a609a6b72a612a505a9702abb4d4ac5b3f


Added TestForDDImageVersion.cxx to FindNuke.cmake so that we can workout
which version of nuke we are building against. This now gets appended to the
'$CMAKE_INSTALL_PREFIX/lib/nuke${Nuke_DDImageVersion}'. This makes it easier
to build and run against multiple versions of nuke.

Added init.py and menu.py so that the ocio nuke plugins can be setup with
the NUKE_PATH searchpath, to make it easier to test and integrate into our
toolchains.

Updated the INSTALL file to reflect these changes.


https://github.com/malcolmhumphreys/OpenColorIO/commit/8d45b1dd71b845cc3b685263f365f25358ad8c68

.malcolm


Re: Review: Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt

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

Looks good to me.

On Sun, Dec 12, 2010 at 5:43 PM, Malcolm Humphreys
<malcolmh...@...> wrote:
Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt, this is temp till we
remove '#include <boost/shared_ptr.hpp>' from OpenColorTypes.h

https://github.com/malcolmhumphreys/OpenColorIO/commit/0077676cd4e44b03df3e0931d594f350fba3fef9

We don't have the boost headers on our linux image so this was failing to
build the nuke plugins.

.malcolm


Adding multiple bit depths to one <!ColorSpace>

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

After playing around with ocio profiles a bit more, I think it would be and idea to have multiple bitdepths defined in one <!ColorSpace> definition.

Below is the vd and nc family colorspaces from the spi-vfx profile. This kind of replaces the family concept, as it seems in all the spi examples that families and names are the way to group color spaces of similar purpose but of different bit-depths.

I'm thinking it feels a bit nicer for a host app to request a named colorspace at a default depth, or request it at a specific depth. I can see that we could get a list of color spaces and do this in a host app but this seems like it should be done by ocio.

ie. the displays would look more like this:

displays:
- !<Display> {device: sRGB, name: Film, colorspace: srgb, bitdepth: 8ui}
- !<Display> {device: sRGB, name: Log, colorspace: lg, bitdepth: 10ui}
- !<Display> {device: DCIP3, name: Film, colorspace: p3dci, bitdepth: 16ui}

Is there a case for two colorspaces in the same family to have the same bitdepth? I would think that would be confusing.

eg. this would make the spi-vfx profile have 11 colorspaces rather than 26, this also helped me spot some possible typos.
--snip--
- !<ColorSpace>
name: ln
isdata: false
gpuallocation: lg2
gpumin: -15
gpumax: 6
bitdepth: 32f
bitdepths:
32f: !<ColorSpaceDetail>
16f: !<ColorSpaceDetail>
16ui: !<ColorSpaceDetail>
gpumax: 0 # typo in the vfx profile?

- !<ColorSpace>
name: lg
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 10ui
bitdepths:
16ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: lg16.spi1d, interpolation: nearest}
10ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: lg10.spi1d, interpolation: nearest}
8ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: lg10.spi1d, interpolation: nearest}
32f: !<ColorSpaceDetail>
gpumin: -0.25
gpumax: 1.5
to_reference: !<FileTransform> {src: lgf.spi1d, interpolation: linear}

- !<ColorSpace>
name: gn
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 16ui
bitdepths:
16ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest}
10ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest}
8ui: !<ColorSpaceDetail>
to_reference: !<FileTransform> {src: gn16.spi1d, interpolation: nearest}
32f: !<ColorSpaceDetail>
gpumin: -0.25
gpumax: 1.5
to_reference: !<FileTransform> {src: gnf.spi1d, interpolation: linear}

- !<ColorSpace>
name: vd
isdata: false # can override these in each bitdepth if needed
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 8ui
bitdepths:
16ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse}
- !<FileTransform> {src: vd16.spi1d, interpolation: nearest}
8ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse}
- !<FileTransform> {src: vd16.spi1d, interpolation: nearest}
10ui:
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: version_8_whitebalanced.spimtx, interpolation: unknown, direction: inverse}
- !<FileTransform> {src: vd16.spi1d, interpolation: nearest}
32f:
to_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: vd, src-depth: 16, dst: ln, dst-depth: 32f}

- !<ColorSpace>
name: hd
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 10ui
bitdepths:
10ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: hdOffset.spimtx, interpolation: nearest, direction: inverse}
- !<ColorSpaceTransform> {src: vd, src-depth: 32f, dst: ln, dst-depth: 32f}

- !<ColorSpace>
name: dt
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 8ui
bitdepths:
8ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: diffuseTextureMultiplier.spimtx, interpolation: nearest}
- !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln, dst-depth: 32f}
16ui: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: diffuseTextureMultiplier.spimtx, interpolation: nearest}
- !<ColorSpaceTransform> {src: vdf, src-depth: 32f, dst: ln, dst-depth: 32f}

- !<ColorSpace>
name: cp
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 32f
bitdepths:
32f: !<ColorSpaceDetail>
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: cpf.spi1d, interpolation: linear}

- !<ColorSpace>
name: nc
isdata: true
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepths:
8ui: <!ColorSpaceDetail>
10ui: <!ColorSpaceDetail>
16ui: <!ColorSpaceDetail>
isdata: false # vfx profile typo?
32f: <!ColorSpaceDetail>

- !<ColorSpace>
name: srgb
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 8ui
bitdepths:
8ui: !<ColorSpaceDetail>
from_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg, dst-depth: 32f}
- !<FileTransform> {src: spi_ocio_srgb_test.spi3d, interpolation: linear}

- !<ColorSpace>
name: p3dci
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 16ui
bitdepths:
16ui: !<ColorSpaceDetail>
from_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: ln, src-depth: 32f, dst: lg, dst-depth: 10ui}
- !<FileTransform> {src: colorworks_filmlg_to_p3.3dl, interpolation: linear}

- !<ColorSpace>
name: xyz
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
bitdepth: 16ui
bitdepths:
16ui: !<ColorSpaceDetail>
from_reference: !<GroupTransform>
children:
- !<ColorSpaceTransform> {src: lnf, dst: p3dci8}
- !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1]}
- !<FileTransform> {src: p3_to_xyz16.spimtx, interpolation: unknown}
- !<ExponentTransform> {value: [2.6, 2.6, 2.6, 1], direction: inverse}
--snip--

.malcolm


Re: Review: added TestForDDImageVersion.cxx to support multiple versions of nuke

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

On 13/12/10 20:05, Malcolm Humphreys wrote:
(excuse the typos in the actual commit msg)
now fixed with (git commit --amend)

https://github.com/malcolmhumphreys/OpenColorIO/commit/c95536a609a6b72a612a505a9702abb4d4ac5b3f


Added TestForDDImageVersion.cxx to FindNuke.cmake so that we can workout which version of nuke we are building against. This now gets appended to the '$CMAKE_INSTALL_PREFIX/lib/nuke${Nuke_DDImageVersion}'. This makes it easier to build and run against multiple versions of nuke.

Added init.py and menu.py so that the ocio nuke plugins can be setup with the NUKE_PATH searchpath, to make it easier to test and integrate into our toolchains.

Updated the INSTALL file to reflect these changes.

https://github.com/malcolmhumphreys/OpenColorIO/commit/8d45b1dd71b845cc3b685263f365f25358ad8c68

.malcolm


Review: added TestForDDImageVersion.cxx to support multiple versions of nuke

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

(excuse the typos in the actual commit msg)

Added TestForDDImageVersion.cxx to FindNuke.cmake so that we can workout which version of nuke we are building against. This now gets appended to the '$CMAKE_INSTALL_PREFIX/lib/nuke${Nuke_DDImageVersion}'. This makes it easier to build and run against multiple versions of nuke.

Added init.py and menu.py so that the ocio nuke plugins can be setup with the NUKE_PATH searchpath, to make it easier to test and integrate into our toolchains.

Updated the INSTALL file to reflect these changes.

https://github.com/malcolmhumphreys/OpenColorIO/commit/8d45b1dd71b845cc3b685263f365f25358ad8c68

.malcolm


Review: Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt

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

Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt, this is temp till we remove '#include <boost/shared_ptr.hpp>' from OpenColorTypes.h
https://github.com/malcolmhumphreys/OpenColorIO/commit/0077676cd4e44b03df3e0931d594f350fba3fef9

We don't have the boost headers on our linux image so this was failing to build the nuke plugins.

.malcolm


OCIO 0.7.2 released

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

Version 0.7.2 (Dec 9 2010):
    * GPUAllocation refactor (API tweak)
    * Added AllocationTransform
    * Added LogTransform
    * Removed CineonLogToLinTransform
    * A few bug fixes

Available for download,

Updated configurations and example images will also be posted shortly.


Re: Review: Added 'pure' LogTransform

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

Looks good to myself!
:)


Re: Review: AllocationTransform

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

No objections? Rolling it in...


Re: Review: Bugfix for Nuke LogConvert

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

No one objected, so I've merged this in.


Re: Review: Inital pass at searchpath impl

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

How about we shoot for tomorrow, I'm still getting backup to speed with things.

.malcolm

On 07 Dec, 2010,at 09:08 AM, Jeremy Selan <jere...@...> wrote:

What's your schedule like this week? Up for a conference call? I'd
like to primarily discuss the env-vars / 'globals' / per-shot cc look
options.

-- Jeremy


Review: Added 'pure' LogTransform

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

As a pseudo-replacement for the CineonLogTransform, added
LogTransform. This is the pure mathematical Log operator, with a user
configurable base.

Commits:
7f7ad979

-- Jeremy


Re: Review: Inital pass at searchpath impl

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

* I like supporting only strings for now. In the future, I can also
see numbers being supported (such as allowing for CDL blocks that rely
on envvars), but this can be added as needed.
It would also be super nice if the CDLTransform supported the full Color Correction Collection (CCC) in the CDL spec, where you could have something along the lines of '!<CDLTransform> { src: '/path/to/basegrades.ccc', id: '${SEQ}_${SHOT}_balance' }'.
* The FileTransform will probably have to get a bit smarter. Say
you're using a pershot lut, and for some shots you dont want any such
table. This could be solved by either not installing a lut in the
expected location, or by installing an identity lut. Which is
preferable? In the current implementation, if a lut is not found
this is always an error condition. Maybe we should introduce on the
FilmTransform a 'silent error mode', where this would just skip the
application of that specific LUT?
Keep the system simple let it error, it should be up to the user to setup the searchpath so that an identity lut is found if other paths fail to resolve to a lut.

It might be an idea to make this case not an exception, but a error which gets sent through some kind or error handler.

* The "globals" pre-declaration could also define an optional default
(used if the envvar is not set). If the envvar is not set, and no
default is specified, any references to the global variable would
probably be an error.
+1

.malcolm

1901 - 1920 of 2201