[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