Not rounding errors in the interpolation, but a scaling error with the
range of the LUT. Can't remember exactly, but it's something along the
lines of: with a 10 bit LUT, it would be dividing by 1024 instead of
1023 (so the max floating point value would be 1/1024th below 1)
I have not tested the VectorField node in Nuke 7, it's not been a
concern now OCIO (and the OCIOFileTransform) ships with Nuke
As for LUT size: 32^3 LUT is usually visually perfect when applied in a
good log-ish space. 16^3 or 17^3 is also decent, and substantially
smaller (they seem popular with Flame, Lustre and such, I guess partly
for historical performance reasons..?)
..but, for applying linear-light data, it's not really sensible to use a
linearly sampled LUT - you'd need to make a giant LUT (e.g 64^3) to be
accurate enough in the lower range, and the file quickly become very
big. Plus a lin-to-log prelut means you can apply the LUT to a greater
range than 0-1 input values..
On 12/02/13 22:24, mboeni wrote:
@Ben:
Are you referring to the potential rounding errors in the interpolation?
Is this still an issue with 7.0v4?
@Alex:
Any recommendations for cube sizes in linear space? I hear even 17x17x17
is still quite common... good point flipping to log first, haven't
thought of that.
Cheers,
michael
PS: Haven't come across the issue with GPU vs CPU yet, have to check that..
------------------------------------------------------------------------
--
Dr. Michael Böni
IMX
by shiftTHINK GmbH
Binzmühlestrasse 5
8173 Neerach
Switzerland
Email: [email protected] <mailto:[email protected]>
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
--
ben dickson
2D TD | [email protected]
rising sun pictures | www.rsp.com.au
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
