|
Malcolm Humphreys <malcolmh...@...>
Oliver Farkas <oliver...@...> wrote: Hey guys,
thanks for the feedback from both of you. Jeremy's workaround does the
trick
brilliantly, that's exactly what I was looking for. Thanks very much
Jeremy.
Malcolm, I know about the Vectorfield node problem in Nuke, because
I've
checked with your csp lut as well and saw it was blown out. By now I've
tried an endless number of combinations of inputspace, shaperspace,
outputspace, but the tops were always clamped. I'm happy that this
workaround does the trick.
There's just one thing I don't understand, Malcolm: how were you able
to
bake out the Kodak2383_sRGB.csp if this bug was in the code before? Its good that Jeremy could get a fix for you. I built all the luts before I left with ociobakelut to make sure we were not using any pre ocio data. This was checked with all the host apps and the ocio nuke nodes so its a bit strange that it doesn't work now or in this case. The baker was a pretty quick first pass so its not a complete surprise that it has issues but this sounds like its broke. On Tue, May 3, 2011 at 9:53 AM, Jeremy Selan <jeremy...@...>
wrote:
Oliver,
I've checked this out and am able to recreate exactly what you
describe. I see the clamping when playing back the 'no shaper' baked
lut using OCIO. And also see the brightness increase when using the
shaper lut. For both tests I am just comparing the unbaked lut
application to that using OCIOFileTransform (in nuke).
The issue is related to some assumptions the Baker class is making
internally. I will try to refactor the Baker code to address this
issue this week (though it may push to next week). I will also touch
up a bunch of 'todos' in that part of the code (allowing for looser
input restrictions). Afterwards, the syntax you describe (both with,
and without, the shaperlut) will support HDR allocations. (For those
who dont specify shaperluts, the gpu allocation will be used to
achieve a similar effect).
In the meantime I am providing a simple workaround script which can be
used to generate HDR friendly csp luts. Note that for this csp lut
I'm taking advantage of non-uniformly sampled input domains. I am not
sure if all apps support this feature of .csp files. If your client
apps do not support this, let me know and we can work around this with
a one or two line change.
http://github.com/jeremyselan/OpenColorIO/tree/shapertest/testdata/csp/oliverbug
-- Jeremy
-- Sent from my phone.
|
|
|
Oliver Farkas <oliver...@...>
Hey guys,
thanks for the feedback from both of you. Jeremy's workaround does the trick brilliantly, that's exactly what I was looking for. Thanks very much Jeremy.
Malcolm, I know about the Vectorfield node problem in Nuke, because I've checked with your csp lut as well and saw it was blown out. By now I've tried an endless number of combinations of inputspace, shaperspace, outputspace, but the tops were always clamped. I'm happy that this workaround does the trick.
There's just one thing I don't understand, Malcolm: how were you able to bake out the Kodak2383_sRGB.csp if this bug was in the code before? Or you used something else than ociobakelut?
Thanks again guys, I appreciate it. Oliver
On Tue, May 3, 2011 at 9:53 AM, Jeremy Selan <jeremy...@...> wrote:
Oliver,
I've checked this out and am able to recreate exactly what you
describe. I see the clamping when playing back the 'no shaper' baked
lut using OCIO. And also see the brightness increase when using the
shaper lut. For both tests I am just comparing the unbaked lut
application to that using OCIOFileTransform (in nuke).
The issue is related to some assumptions the Baker class is making
internally. I will try to refactor the Baker code to address this
issue this week (though it may push to next week). I will also touch
up a bunch of 'todos' in that part of the code (allowing for looser
input restrictions). Afterwards, the syntax you describe (both with,
and without, the shaperlut) will support HDR allocations. (For those
who dont specify shaperluts, the gpu allocation will be used to
achieve a similar effect).
In the meantime I am providing a simple workaround script which can be
used to generate HDR friendly csp luts. Note that for this csp lut
I'm taking advantage of non-uniformly sampled input domains. I am not
sure if all apps support this feature of .csp files. If your client
apps do not support this, let me know and we can work around this with
a one or two line change.
http://github.com/jeremyselan/OpenColorIO/tree/shapertest/testdata/csp/oliverbug
-- Jeremy
|
|
|
Jeremy Selan <jeremy...@...>
Oliver, I've checked this out and am able to recreate exactly what you describe. I see the clamping when playing back the 'no shaper' baked lut using OCIO. And also see the brightness increase when using the shaper lut. For both tests I am just comparing the unbaked lut application to that using OCIOFileTransform (in nuke). The issue is related to some assumptions the Baker class is making internally. I will try to refactor the Baker code to address this issue this week (though it may push to next week). I will also touch up a bunch of 'todos' in that part of the code (allowing for looser input restrictions). Afterwards, the syntax you describe (both with, and without, the shaperlut) will support HDR allocations. (For those who dont specify shaperluts, the gpu allocation will be used to achieve a similar effect). In the meantime I am providing a simple workaround script which can be used to generate HDR friendly csp luts. Note that for this csp lut I'm taking advantage of non-uniformly sampled input domains. I am not sure if all apps support this feature of .csp files. If your client apps do not support this, let me know and we can work around this with a one or two line change. http://github.com/jeremyselan/OpenColorIO/tree/shapertest/testdata/csp/oliverbug-- Jeremy
|
|
|
Malcolm Humphreys <malcolmh...@...>
Hi Oliver,
Ok I wrote all of this and then released are you trying to check these csp luts in the nuke vectorfield node? nuke vectorfield node currently doesn't support the prelut section in the csp format you will just get a blown out image. Check the luts in RV and if it still doesn't work feel free to read on..
I played around a bit with the settings. The scene_grey18 entry in the config file contains no transform whatsoever, so I assumed the next would do nothing at all. ociobakelut --inputspace scene_grey18 --outputspace scene_grey18 But the highlights get clamped. This means that it's not the jplinlog or the print lut that's causing the clamping.
All 1D or 3D luts are bound limited in nature, even for half floats you would need a very large lut to cover all values. So I would expect a scene_grey18 -> scene_grey18 to reflect an identity lut which would clamp input values outside the 0.0 - 1.0 range.
I would hope this would be identical to the luts created for HP LCD but using a different cube for the Dreamcolors.
You should have a color space defined for each of your display devices, in your case the sRGB and Dreamcolor LCDs. ie.
- !<ColorSpace> name: # device space ... from_reference: !<GroupTransform> children: - !<CDLTransform> # cool grade in linear (drd custom) - !<FileTransform> # jp lin to log 1D - !<FileTransform> # log to device cube
I would first check that each of these behave as expect in nuke using the OCIO node, if this does work (which I'm guessing does I would be surprised if it doesn't) this points to something going a bit wrong when baking. If it doesn't work something has gone a bit wrong with the truelight cube export.
Just check that you have the following at the top of your config.
- !<ColorSpace> name: scene_grey18 family: lin bitdepth: 32f isdata: false gpuallocation: lg2 gpumin: -15 gpumax: 6
- !<ColorSpace> name: scene_grey18_log family: log bitdepth: 10ui isdata: false gpuallocation: uniform gpumin: 0 gpumax: 1 from_reference: !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
I would expect the baking command line in this case would be something the lines of.
ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --shaperspace scene_grey18_log --outputspace <device space> --format cinespace
When the serialisation/baking of the device space happens the grade will also be taken into account. You shouldn't need to create a separate linearGraded colorspace as ben suggested. I haven't checked the code but I have a feeling this might not work as expected.
It should be noted that the shaperspace should only be used to allocate/shape the data and not contain colorimetry type transforms ie color grades.
If you can test exporting both a houdini and cinespace lut and see if you get the same results in RV and Mplay and let us know.
.malcolm The exr files do have rgb values that go over 1.0, so maybe this problem's got to do something with that... but I'm not too sure what's happening. I'll try to dig into the code to see if I can find where this is coming from.
Thanks, Oliver
On Fri, Apr 29, 2011 at 9:58 AM, dbr/Ben <dbr....@...> wrote:
You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.
If I understood the code right, it does..
CSP prelut: input to shaperspace as 1D LUT
3D LUT: shaperspace to output space
If omit the shaperspace arg, then it's all done in the cube (and the prelut is a no-op)
...so I think your display colourspace needs to have a 0-1 log input (just the kodak LUT). Then you would do:
--inputspace graded_linear --shaperspace jplog --outputspace kodak2383_dreamcolour
Not ideal, although you could possibly do the grade in the dreamcolor space by doing a log2lin, CDL then lin2log, and replace the graded_linear space with your scene_grey18
Ideally the Baker would inspect the transform op-tree and put as much of the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in the cube.. Not sure how difficult this would be to achieve (think there's todos in the code about this)
- Ben
On 29/04/2011, at 2:56, Jeremy Selan < jeremy...@...> wrote:
> Hmmm,
>
> Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
> to re-create this on my end. Dont worry about the Kodak cube lut, I
> can use one of my own there instead.
>
> One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
> probably set it to 'Dreamcolor' on the absence of other information.
> (The family is often used to short-circuit conversions of the same
> type, but at differing bit depths). I should probably update the API
> so people can leave it blank if they dont know it, and to assume the
> color-space name in that case).
>
> -- Jeremy
>
> On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas < oliver...@...> wrote:
>> Hey guys,
>>
>> I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest
>> opencolorio (0.8.0), but getting weird results. It clamps the tops, details
>> in the bright areas are completely gone. I'm wondering if I'm missing
>> something.
>>
>>
>> The command I'm using is this:
>>
>> ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace
>> Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp
>>
>> The corresponding parts in the config.ocio look like this:
>>
>>
>> - !<ColorSpace>
>> name: scene_grey18
>> family: lin
>> bitdepth: 32f
>> isdata: false
>> gpuallocation: lg2
>> gpumin: -15
>> gpumax: 6
>>
>>
>> - !<ColorSpace>
>> name: Dreamcolor
>> family: lin
>> bitdepth: 32f
>> isdata: false
>> gpuallocation: uniform
>> gpumin: 0
>> gpumax: 1
>> from_reference: !<GroupTransform>
>> children:
>> - !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814,
>> 0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
>> - !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
>> - !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation:
>> linear}
>>
>>
>>
>> Cheers,
>> Oliver
>>
|
|
|
Jeremy Selan <jeremy...@...>
Oliver,
Sorry I haven't had a chance to look into this yet. I will do my best
to get to it first thing tomorrow. (Mon AM). My expectation is that
this shouldn't be too hard, OCIO is designed to work with HDR float32
-- and we use it internally in exactly the way you describe - so it's
likely just a minor bug you've run into first.
-- Jeremy
toggle quoted message
Show quoted text
On Sun, May 1, 2011 at 10:48 PM, Oliver Farkas <oliver...@...> wrote: Hey guys,
Ben, I've tried what you suggested. The input is graded scene linear, the
shaper is lin to log and the output is a log to Kodak2383 on a DCI screen. I
assumed this would work, but when I applied the generated lut on top of a
scene linear exr, then the result I got was a blown out image: everything
was fully bright, I could only see few parts of the image, all the rest was
white.
I played around a bit with the settings. The scene_grey18 entry in the
config file contains no transform whatsoever, so I assumed the next would do
nothing at all.
ociobakelut --inputspace scene_grey18 --outputspace scene_grey18
But the highlights get clamped. This means that it's not the jplinlog or the
print lut that's causing the clamping.
The exr files do have rgb values that go over 1.0, so maybe this problem's
got to do something with that... but I'm not too sure what's happening. I'll
try to dig into the code to see if I can find where this is coming from.
Thanks,
Oliver
On Fri, Apr 29, 2011 at 9:58 AM, dbr/Ben <dbr....@...> wrote:
You'll need to use the --shaperspace to make a LUT that goes from a non
0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.
If I understood the code right, it does..
CSP prelut: input to shaperspace as 1D LUT
3D LUT: shaperspace to output space
If omit the shaperspace arg, then it's all done in the cube (and the
prelut is a no-op)
...so I think your display colourspace needs to have a 0-1 log input (just
the kodak LUT). Then you would do:
--inputspace graded_linear --shaperspace jplog --outputspace
kodak2383_dreamcolour
Not ideal, although you could possibly do the grade in the dreamcolor
space by doing a log2lin, CDL then lin2log, and replace the graded_linear
space with your scene_grey18
Ideally the Baker would inspect the transform op-tree and put as much of
the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in
the cube.. Not sure how difficult this would be to achieve (think there's
todos in the code about this)
- Ben
On 29/04/2011, at 2:56, Jeremy Selan <jeremy...@...> wrote:
Hmmm,
Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
to re-create this on my end. Dont worry about the Kodak cube lut, I
can use one of my own there instead.
One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
probably set it to 'Dreamcolor' on the absence of other information.
(The family is often used to short-circuit conversions of the same
type, but at differing bit depths). I should probably update the API
so people can leave it blank if they dont know it, and to assume the
color-space name in that case).
-- Jeremy
On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...>
wrote:
Hey guys,
I'm trying to use ociobakelut to bake out a .csp lut. I'm using the
latest
opencolorio (0.8.0), but getting weird results. It clamps the tops,
details
in the bright areas are completely gone. I'm wondering if I'm missing
something.
The command I'm using is this:
ociobakelut --iconfig ./config.ocio --inputspace scene_grey18
--outputspace
Dreamcolor --format cinespace >
./Kodak2383CoolGrade_ocio_Dreamcolor.csp
The corresponding parts in the config.ocio look like this:
- !<ColorSpace>
name: scene_grey18
family: lin
bitdepth: 32f
isdata: false
gpuallocation: lg2
gpumin: -15
gpumax: 6
- !<ColorSpace>
name: Dreamcolor
family: lin
bitdepth: 32f
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
from_reference: !<GroupTransform>
children:
- !<CDLTransform> {slope: [0.80369623146242275,
0.9566818354009814,
0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation:
1}
- !<FileTransform> {src: jp_lin2log.lut, interpolation:
linear}
- !<FileTransform> {src: Kodak2383_Dreamcolor.cub,
interpolation:
linear}
Cheers,
Oliver
|
|
|
Oliver Farkas <oliver...@...>
Hey guys,
Ben, I've tried what you suggested. The input is graded scene linear, the shaper is lin to log and the output is a log to Kodak2383 on a DCI screen. I assumed this would work, but when I applied the generated lut on top of a scene linear exr, then the result I got was a blown out image: everything was fully bright, I could only see few parts of the image, all the rest was white.
I played around a bit with the settings. The scene_grey18 entry in the config file contains no transform whatsoever, so I assumed the next would do nothing at all.
ociobakelut --inputspace scene_grey18 --outputspace scene_grey18
But the highlights get clamped. This means that it's not the jplinlog or the print lut that's causing the clamping.
The exr files do have rgb values that go over 1.0, so maybe this problem's got to do something with that... but I'm not too sure what's happening. I'll try to dig into the code to see if I can find where this is coming from.
Thanks, Oliver
On Fri, Apr 29, 2011 at 9:58 AM, dbr/Ben <dbr....@...> wrote:
You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.
If I understood the code right, it does..
CSP prelut: input to shaperspace as 1D LUT
3D LUT: shaperspace to output space
If omit the shaperspace arg, then it's all done in the cube (and the prelut is a no-op)
...so I think your display colourspace needs to have a 0-1 log input (just the kodak LUT). Then you would do:
--inputspace graded_linear --shaperspace jplog --outputspace kodak2383_dreamcolour
Not ideal, although you could possibly do the grade in the dreamcolor space by doing a log2lin, CDL then lin2log, and replace the graded_linear space with your scene_grey18
Ideally the Baker would inspect the transform op-tree and put as much of the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in the cube.. Not sure how difficult this would be to achieve (think there's todos in the code about this)
- Ben
On 29/04/2011, at 2:56, Jeremy Selan < jeremy...@...> wrote:
> Hmmm,
>
> Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
> to re-create this on my end. Dont worry about the Kodak cube lut, I
> can use one of my own there instead.
>
> One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
> probably set it to 'Dreamcolor' on the absence of other information.
> (The family is often used to short-circuit conversions of the same
> type, but at differing bit depths). I should probably update the API
> so people can leave it blank if they dont know it, and to assume the
> color-space name in that case).
>
> -- Jeremy
>
> On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas < oliver...@...> wrote:
>> Hey guys,
>>
>> I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest
>> opencolorio (0.8.0), but getting weird results. It clamps the tops, details
>> in the bright areas are completely gone. I'm wondering if I'm missing
>> something.
>>
>>
>> The command I'm using is this:
>>
>> ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace
>> Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp
>>
>> The corresponding parts in the config.ocio look like this:
>>
>>
>> - !<ColorSpace>
>> name: scene_grey18
>> family: lin
>> bitdepth: 32f
>> isdata: false
>> gpuallocation: lg2
>> gpumin: -15
>> gpumax: 6
>>
>>
>> - !<ColorSpace>
>> name: Dreamcolor
>> family: lin
>> bitdepth: 32f
>> isdata: false
>> gpuallocation: uniform
>> gpumin: 0
>> gpumax: 1
>> from_reference: !<GroupTransform>
>> children:
>> - !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814,
>> 0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
>> - !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
>> - !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation:
>> linear}
>>
>>
>>
>> Cheers,
>> Oliver
>>
|
|
|
You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.
If I understood the code right, it does..
CSP prelut: input to shaperspace as 1D LUT
3D LUT: shaperspace to output space
If omit the shaperspace arg, then it's all done in the cube (and the prelut is a no-op)
...so I think your display colourspace needs to have a 0-1 log input (just the kodak LUT). Then you would do:
--inputspace graded_linear --shaperspace jplog --outputspace kodak2383_dreamcolour
Not ideal, although you could possibly do the grade in the dreamcolor space by doing a log2lin, CDL then lin2log, and replace the graded_linear space with your scene_grey18
Ideally the Baker would inspect the transform op-tree and put as much of the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in the cube.. Not sure how difficult this would be to achieve (think there's todos in the code about this)
- Ben
toggle quoted message
Show quoted text
On 29/04/2011, at 2:56, Jeremy Selan <jeremy...@...> wrote: Hmmm,
Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
to re-create this on my end. Dont worry about the Kodak cube lut, I
can use one of my own there instead.
One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
probably set it to 'Dreamcolor' on the absence of other information.
(The family is often used to short-circuit conversions of the same
type, but at differing bit depths). I should probably update the API
so people can leave it blank if they dont know it, and to assume the
color-space name in that case).
-- Jeremy
On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...> wrote:
Hey guys,
I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest
opencolorio (0.8.0), but getting weird results. It clamps the tops, details
in the bright areas are completely gone. I'm wondering if I'm missing
something.
The command I'm using is this:
ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace
Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp
The corresponding parts in the config.ocio look like this:
- !<ColorSpace>
name: scene_grey18
family: lin
bitdepth: 32f
isdata: false
gpuallocation: lg2
gpumin: -15
gpumax: 6
- !<ColorSpace>
name: Dreamcolor
family: lin
bitdepth: 32f
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
from_reference: !<GroupTransform>
children:
- !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814,
0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
- !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
- !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation:
linear}
Cheers,
Oliver
|
|
|
Jeremy Selan <jeremy...@...>
Hmmm,
Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
to re-create this on my end. Dont worry about the Kodak cube lut, I
can use one of my own there instead.
One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
probably set it to 'Dreamcolor' on the absence of other information.
(The family is often used to short-circuit conversions of the same
type, but at differing bit depths). I should probably update the API
so people can leave it blank if they dont know it, and to assume the
color-space name in that case).
-- Jeremy
toggle quoted message
Show quoted text
On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...> wrote: Hey guys,
I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest
opencolorio (0.8.0), but getting weird results. It clamps the tops, details
in the bright areas are completely gone. I'm wondering if I'm missing
something.
The command I'm using is this:
ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace
Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp
The corresponding parts in the config.ocio look like this:
- !<ColorSpace>
name: scene_grey18
family: lin
bitdepth: 32f
isdata: false
gpuallocation: lg2
gpumin: -15
gpumax: 6
- !<ColorSpace>
name: Dreamcolor
family: lin
bitdepth: 32f
isdata: false
gpuallocation: uniform
gpumin: 0
gpumax: 1
from_reference: !<GroupTransform>
children:
- !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814,
0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
- !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
- !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation:
linear}
Cheers,
Oliver
|
|
|
