[Tig] Re: LOG [was Re: DI workflow, capabilities and requirements ]

Kevin Shaw kevs
Thu Mar 31 11:56:41 BST 2005

Hi Steve
As usual your post is very informative and I think we have similar views on
many things.
OK there are some buts...

> In this way LOG encoding is a lossless form of compression.
Its only lossless one way. 10 bits is 1024 steps 14 bits is 16384
You can accurately map 14 bits to 10, but there is not enough information in
10 bit to accurately reproduce the original 16384 steps (14 bit)
> 16bit linear is way beyond the human eye's perception, taking up additional
> space without image benefit.
True if you are only concerned with final output. The same argument could be
used against 4:4:4 or even good jpg compression. The point is that the extra
information is critical for color correction where the image is manipulated
> I just asked the vfx team at one of my clients to 'show' me differences
> between performing vfx work in 10bit LOG space vs. 16bit Linear, asking them
> to define areas where things went wrong.
In empirical testing I noticed improved shadow detail in log transfers, but
visually better highlight detail (after enhancement ) in a conventional
transfer (with CRT gamma included). The math certainly supports this
observation. Might be important when shooting snow?

My comment however was based on a situation where the neg was significantly
over exposed, and a standard log transfer would assign very many bits to an
area that now has no information. The solution as I am sure you know is to
recalibrate the transfer to allow for the increased density.

Log works well but like everything it needs to be used intelligently

> The reason for saying all this? There is no right and wrong way to do this
> stuff. If the result looks good, it is good...

I agree absolutely.

Kevin Shaw                 consultant colorist
kevs at finalcolor.com          www.finalcolor.com

More information about the Tig mailing list