Date
1 - 4 of 4
Adding multiple bit depths to one <!ColorSpace>
|
Joseph Slomka <jsl...@...>
Malcolm,
toggle quoted message
Show quoted text
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 |
|
|
|
Malcolm Humphreys <malcolmh...@...>
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.
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 <malcolmh...@...>
Hi did you guys have any more thoughts on this? Jeremy do you see this fitting in somehow with contexts? .malcolm On 14 Dec, 2010,at 01:35 PM, Malcolm Humphreys <malcol...@...> wrote:
|
|
|
|
Jeremy Selan <jeremy...@...>
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 On Thu, Dec 16, 2010 at 3:05 PM, Malcolm Humphreys <malcolmh...@...> wrote: Hi did you guys have any more thoughts on this? Jeremy do you see this |
|
|