correctness bug in ctl render about aces-dev HOT 6 CLOSED

input frame
http://code.google.com/p/opencolorio/downloads/detail?name=cmstestpattern_logallocation_input.exr

output demonstrating bug
http://code.google.com/p/opencolorio/downloads/detail?name=badoutput_ncf.exr

from aces-dev.

Can you try this using rrt_ut2.ctl instead? I think the garbage to which you are referring may be a consequence of algorithmic problems within rrt_ut11.ctl and not ctlrender itself. I get dramatically different (and better) results when using RRT_UT2.

from aces-dev.

I'm happy to test the new RRT, but would you please look again at the example images I provided?

There are adjacent pixels in the input image, which have the same initial ACES values, mapping to completely different output values! Ugh. See the skinny lines at the bottom area of the image? They shouldnt be there.

As CTL is not supposed to be spatially varying, this error is definitely a bug (either in ctl render or ctl itself). Whether or not a new RRT exposes it or not, this is probably worth investigating further.

from aces-dev.

Ah, I missed that "garbage" when I compared the outputs. This appears to be similar to horizontal streaking that we've seen occasionally in other frames with other CTL transforms. I've been unable to reproduce this reliably but is definitely something we need to look into.

from aces-dev.

Cool. I believe this test case does reproduce it reliably (at least on my end). Can you confirm?

from aces-dev.

Yes, I can confirm that I can duplicate the same effect.

from aces-dev.