[CinePaint] Really basic script for batch converting.

[email protected] Tue, 24 Nov 2009 13:29:19 -0000 (GMT)
Newsgroups gmane.comp.video.cinepaint.user
Message-ID <49916.82.37.43.160.1259069359.R0MUQmxZTEF/[email protected]>
Once again guys thank you for your time and input, I'm here again. :-)

I've being doing a bit of research to see how Photoshop/After Effects has
been interpreting 8bit -> 16bit

I apologize in advance about another long mail and reproducing a quantity
of bulk but I don't want to assume anyone has time to go following web
page threads when I can hopefully capture the essence in a few lines here
below, I've tried to condense. :-)

This thread: http://photo.net/digital-darkroom-forum/00H1OS

Outakes:

Kevin Connery , Jun 21, 2006; 06:41 a.m.

Photoshop's 16-bit mode is really 15-bits + 1 bit of noise.


Karl Martin , Jun 21, 2006; 10:52 a.m.

Correct. As your tests have shown, if the original data is in 8bit, the
only benefit of converting to 16bit would be for editing (involving
significant changes in dynamic range).

Regarding noise, I'm not sure what you are seeing in your last test, but
it would have nothing to do with this 15bit+1bit noise. Noise in the last
bit of data for 16bit colour channels would be absolutely imperceptible,
not just because of the limits of human vision, but because the video card
and monitor never display such information (it would require a 48bit
display system). Again, 16bit channels (48bit total) is only for editing.
You never see that precision in a single displayed image.


Andrew Rodney , Jun 22, 2006; 08:27 a.m.

From: Marc Pawliger Subject: RE: 16 bit and the info palette

Message: The high-bit representation in Photoshop has always been "15 1"
bits (32767 (which is the total number of values that can be represented
by 15 bits of precision) 1).

This thread was also interesting:

http://www.northlight-images.co.uk/article_pages/16_bit_black_and_white.html

Outakes:

Converting Colour to Greyscale


If you take the 8 bit RGB file to 16 bit RGB then:
20/20/20 goes to 5120/5120/5120 > L=5120
21/20/20 goes to 5376/5120/5120 > L=5205

That's 2 levels of grey where in 8 bit you would only have one

With the simple averaging conversion 5376/5120/5120 gives the same as say
5120/5376/5120.

With the channels mixed in the proportions 30%:60%:10% (simple
'Image>Mode>Greyscale') we get

20/20/20 goes to 5120/5120/5120 > L=5120
21/20/20 goes to 5376/5120/5120 > L=5197
20/21/20 goes to 5120/5376/5120 > L=5274
20/20/21 goes to 5120/5120/5376 > L=5147

That's 4 levels of grey where in 8 bit you would have two (20/21/20 goes
to L=21).

If you include the full range of values between 20/20/20 and 21/21/21. The
16 bit conversion gives 8 different L values instead of two -- that's
effectively a 10 bit greyscale rather than 8 bit.

So, as you'd expect, the RGB value for a pixel that is slightly 'greener'
comes out a bit brighter in the greyscale conversion, due to the 60%
weighting for that channel.

Note, I've ignored the fact that Photoshop '16 bit' is actually signed 15
bit i.e. +-32k rather than 0-64k)

The difference comes from the fact that an 8 bit RGB file represents 24
bits of information which, depending on your choice of conversion
technique, can represent more levels of greyscale that the 256 allowed in
an 8 bit greyscale image.

Thus for the example in the table above, and using a simple conversion to
greyscale (at 16 bit), you could get up to 80 levels of greyscale
information in the 5th Stop, rather than the 20 in the 8 bit file.

Bearing in  mind that when I use my camera I am trying to capture the
maximum tonal range by manually controlling exposure. And the principle
that I am not concerned particularly about getting a 'pretty' video frame
straight off the camera, tonal range is far more important and that
following aquiring the video, compositing and colour correction is going
to happen, I've been considering whether it may be better to work with
image sequences in a 'YUV' type format and convert to 16bit then to RGB?
Is there anything in the above greyscale workflow that I could be doing to
improve values perhaps in 'YUV', 4:2:0.

Once again thank you for your time on this. Frank & Bob I have read your
previous comments and taken advice from them, however I thought this mail
was long enough without responding to those comments as well. :-)






------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july