Adding multiple bit depths to one <!ColorSpace>

[Malcolm Humphreys]

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

[Joseph Slomka]

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

[Malcolm Humphreys]

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

[Malcolm Humphreys]

Hi did you guys have any more thoughts on this? Jeremy do you see this fitting in somehow with contexts?

.malcolm

[Jeremy Selan]

Malcolm - interesting idea!

I do agree that right now families feel a bit like a second-class
concept, and I would like them to be easier to deal with. I also
agree that it's appealing to present the user as short a list of colorspaces,
as much as possible, and not to burden them with bitdepth options if we
can avoid it.

(I'm not sure this relates to contexts.)

One side note: currently family names *are* used as an
optimization within the library, and it's assumed that all transformed
to/from colorspaces of the same family can be considered a no-op.
I.e., if you define an image as being in the 'lg10' space, and ask to
transform it to 'lgf', it will determine that both spaces are in the
same family and no work will be done. This is actually a nice
optimization for a lot of reasons related to internal performance.

So, Joseph, in the case of of the IIF's adx10 vs adx16, these would
currently need to be separate families anyways. (In the Academy Density
Encoding spec (ADX), the 10 and the 16 bit representation differ in
more than just precision, the 16-bit spec also encodes a greater
density range).

I'd like to consider this further, but the next big API extension I'm
looking at is the per-shot look / "Context" stuff. Let's bring it up
again when that is complete.. (i.e., in a few weeks)

-- Jeremy