[Bf-committers] ASC-CDL test suite compliance

[Andrew Hunter]

Hey Julien,

On Wed, May 18, 2011 at 12:38 PM, Julien Enche <julien.enche at gmail.com> wrote:
> Hi Andrew,
>
> iv and Nuke show you the data unconverted (so you see Log value without any
> Log -> RGB conversion) and without gamma correction.
> The problem here is that if I change the code to correctly load this
> picture, it will fail for every other pictures I've used so far.

hmmm.... I'm not sure what to do here.

> I don't know if OIIO and Nuke are fully DPX compliant, I've always compared
> the behavior of my code with GraphicsMagick which still seems to be the most
> advanced free software on the DPX/Cineon side (more than ImageMagick). And
> the question was also raised about ASC CDL handling [1].
>
> So I don't see any easy way to correct this, perhaps it could be useful to
> have a compositor node that allow to apply different LUTs on a picture to
> correct it ?

Troy and I have been working on getting a node written in C++ to work.
I feel it would be great to have an OpenColorIO node(s) in blender for
exactly this sort of thing.

Perhaps you could assist us there?

Cheers,

Andrew

> [1] : http://osdir.com/ml/video.graphicsmagick.help/2007-03/msg00006.html
>
>
> 2011/5/17 Andrew Hunter <andrew at aehunter.net>
>
>> Hey Julien,
>>
>> I can confirm that OpenImagIO's and Nuke's handling match [1]. Please
>> note that Nuke PLE watermarks the image.
>>
>> Cheers,
>>
>> Andrew
>>
>> [1] http://imgur.com/oI7WK
>>
>> On Tue, May 17, 2011 at 1:11 PM, Andrew Hunter <andrew at aehunter.net>
>> wrote:
>> > Hey Julien,
>> >
>> > Thanks for your work, but I think I've uncovered further issues with
>> > respect to the dpx handeling.
>> >
>> > Blender is now internally consistent [1] but the reference image
>> > (sop_ref_image.102.dpx) is now very different from what I believe it
>> > should be [2].
>> >
>> > For reference, here is a screenshot of how iv (and OpenImageIO) loads
>> > the file [3].
>> >
>> > I will compare how the file loads in Nuke PLE to try and get some
>> > consensus on how this should look.
>> >
>> > I suspect that the inconsistencies we continue to experience
>> > (particularly noticeable on the ASC-CDL transform!) have to do with
>> > the conversion from log->lin. Perhaps with pynodes to speed along a
>> > proof of concept, we can determine if ImBuf and the color management
>> > code is to blame.
>> >
>> > Cheers,
>> >
>> > Andrew
>> >
>> > [1] http://imgur.com/CdNZq
>> > [2] http://imgur.com/FnnVz
>> > [3] http://imgur.com/fGKfV
>> >
>> > On Mon, May 16, 2011 at 4:13 PM, Julien Enche <julien.enche at gmail.com>
>> wrote:
>> >> Andrew,
>> >>
>> >> You were right, that didn't work. I've released a new patch which should
>> >> work fine.
>> >> Thanks for reporting !
>> >>
>> >> Julien
>> >>
>> >> 2011/5/16 Andrew Hunter <andrew at aehunter.net>
>> >>
>> >>> Hey Julien,
>> >>>
>> >>> I've compiled a build with your patch attached and I'm still noticing
>> >>> that saved files  don't match what is displayed in the viewer.
>> >>>
>> >>> I've uploaded a .blend to my server [1] and posted an annotated
>> screenshot
>> >>> [2].
>> >>>
>> >>> Lets get this figured out :)
>> >>>
>> >>> [1]
>> >>>
>> http://files.aehunter.net/Blender/image-load%20difference-with-dpx-patch.blend
>> >>> [2] http://i.imgur.com/6Sl8T.png
>> >>>
>> >>> On Mon, May 16, 2011 at 10:22 AM, Andrew Hunter <andrew at aehunter.net>
>> >>> wrote:
>> >>> > Hey Julien,
>> >>> >
>> >>> > That log -> rgb conversion is a whole other architechtural issue, but
>> >>> > I'll leave that aside.
>> >>> >
>> >>> > Could you please test each of the three blend files from my ASC-CDL
>> >>> > package and compare the output?
>> >>> >
>> >>> > Cheers,
>> >>> >
>> >>> > Andrew
>> >>> >
>> >>> > On Sat, May 14, 2011 at 11:44 AM, Julien Enche <
>> julien.enche at gmail.com>
>> >>> wrote:
>> >>> >> If you're talking about the image sop_ref_input_image.1920.dpx, I
>> get a
>> >>> >> very bright picture (see here :
>> >>> >> http://imageshack.us/photo/my-images/830/captureblender1.png).
>> >>> >> This image is in Log colorspace, my code convert it automatically to
>> RGB
>> >>> >> so this is an expected result. GraphicsMagick and ImageMagick give
>> the
>> >>> >> same output (try display -colorspace RGB
>> sop_ref_input_image.1920.dpx).
>> >>> >>
>> >>> >>
>> >>> >> Le 14/05/2011 17:31, Troy Sobotka a écrit :
>> >>> >>> Just curious Julien, does your new code work with the ASC reference
>> >>> image
>> >>> >>> tests Andrew posted above?
>> >>> >>>
>> >>> >>> With respect,
>> >>> >>> TJS
>> >>> >>> _______________________________________________
>> >>> >>> Bf-committers mailing list
>> >>> >>> Bf-committers at blender.org
>> >>> >>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >> _______________________________________________
>> >>> >> Bf-committers mailing list
>> >>> >> Bf-committers at blender.org
>> >>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>> >>
>> >>> >
>> >>> _______________________________________________
>> >>> Bf-committers mailing list
>> >>> Bf-committers at blender.org
>> >>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> >
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>