Hey Julien, On Wed, May 18, 2011 at 12:38 PM, Julien Enche <julien.en...@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 <and...@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 <and...@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.en...@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 <and...@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 <and...@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.en...@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@blender.org >> >>> >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >>> >> _______________________________________________ >> >>> >> Bf-committers mailing list >> >>> >> Bf-committers@blender.org >> >>> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >>> >> >> >>> > >> >>> _______________________________________________ >> >>> Bf-committers mailing list >> >>> Bf-committers@blender.org >> >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >>> >> >> _______________________________________________ >> >> Bf-committers mailing list >> >> Bf-committers@blender.org >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> > >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers