14 bit a/d conversion VS. 12 bit a/d conversion (40d vs. 5d)

[ride_the_spiral]

With the release of the new Canon 40d, which boasts 14 bit analogue to digital conversion, can we expect it to match the dynamic range of the 5d (which is 12 bit)? Just throwing it out there...

[marxz]

With the release of the new Canon 40d, which boasts 14 bit analogue to digital conversion, can we expect it to match the dynamic range of the 5d (which is 12 bit)? Just throwing it out there...

not an expert here but simply increasing the bit depth won't automatically increase dynamic range, the sensor has to be capable of the wider dynamic range in the first place. Nor does bit depth automatically correspond to dynamic range as you could increase sensitivity with in the same old dynamic range (ie the ability to distinguish between two previously indistinguishable shades) without extending sensitivity past the previous extremes of the dynamic range.



I'd assume, and hope, that it it would be a boost in both dynamic range and sensitivity with in the dynamic range given that it is essentially a leap of 4 x the colour information (from 4096 different levels of each capture colour (RGB) to 16384 different levels for each colour)

note that file bit depth will stay at 16 as both 12 and 14 bit captures have their files padded out to 16 bits (with "blank" bits) in the case of RAW file formats that uses compression then file size will increase by about 15% but uncompressed files will retain the padded bits and stay the same size.

[madlights]

I might be wrong, 'cause I'm sure no expert on this...but it seems that adding more bits just gives a less compressed file...maybe with fewer artifacts when pushed to the limits etc. My older Canon 10d uses a compressed RAW algorithm while my Oly 8080 doesn't (at least not as much if I understand what I've read correctly), and I can tell no discernible difference in much of anything that isn't intrinsic to the particular camera. In fact although my Oly's files are over 12mb and my Canons around 6mb, (but 8 megapixels as compared to 6) I think the Canon has around the same dynamic range...and a lot less noise...although the Oly's jpgs are fantastic...but of course compressed greatly. I think the main benefit is probably something other than dynamic range, since as marxz says...so much depends on the sensor and processing program itself. I notice the new Nikons are going 14bit too. Guess what I'm getting at is there are so many other variables...even as far as the program you use to develop your RAW files...how many or how much of the file it sees. Say Adobe's DNG conversion, how much information does it discard, since it certainly seems to compress? I really wished the camera makers would work more on the dynamic range thing, rather than in giving more and more megapixels on a cropped sensor. I think more of us are more concerned with blown highlights and unrecoverable darks, than we are with printing out a poster to cover the side of a bus.

[marxz]

Compression used in RAW's is loss-less (it doesn't dispose information) such as LZR/ZIP type compression. As such compressing the files is not "efficient" like lossy compression but it doesn't affect sharpness, colour, gradients in anyway what so ever.

JPG compression is lossy (as it throws away information never to be seen, quite literally, again)
In JPG's case this means that excessive compression (which the camera or computer can't really judge only the human eye) you start to "jaggies" on angled lines, banding in areas of gradients (ie the sky) where it throws away intermediate colour and luminosity values, and area's that look like "puddles" of black where it pushes dark areas in to absolute black

[madlights]

Compression used in RAW's is loss-less (it doesn't dispose information) such as LZR/ZIP type compression. As such compressing the files is not "efficient" like lossy compression but it doesn't affect sharpness, colour, gradients in anyway what so ever.

JPG compression is lossy (as it throws away information never to be seen, quite literally, again)
In JPG's case this means that excessive compression (which the camera or computer can't really judge only the human eye) you start to "jaggies" on angled lines, banding in areas of gradients (ie the sky) where it throws away intermediate colour and luminosity values, and area's that look like "puddles" of black where it pushes dark areas in to absolute black

Ok I understand and have had the banding in the sky etc. on jpgs, especially if pushed hard...and the areas of dark etc. and some manufacturers have better jpg conversions than others (at least I've heard that)...but if I convert from ORF at 11.5 mb to DNG I get an 8.37 mb file. The same with Canon CRW will reduce the file size when converted. Where does 3mb go? Why are my RAW files with my Oly at 8mp nearly twice the size of my 6 mp 10d? I realize that RAW is lossless. but I don't know or understand exactly what is going on to affect the file sizes like that? There's got to be something thrown away or maybe not added?? I've always been more than a bit curious? I've read differing opinions on this, and still don't quite understand how a DNG can claim to be lossless when it throws away around 3mb of an 11.5 mb file. The same when differing camera manufacturers have differing RAW size files for the same megapixel cameras? I honestly can't understand quite how this works? A DNG couldn't be loss-less if it discards 1/4 of a file? I'm not attempting to argue the point...it's just that I don't understand where the bits go? I think now I was incorrect in calling Canons(or any other) a compressed RAW file when I think about it...since it is probably that it just differs in other ways...or even in how it handles the same information as another company's RAW file..so I stand corrected on that. That's probably the reason for some of the difference in the file sizes between manufacturers...the way in which they handle information...but the DNG conversion bothers me, since I can't understand how Adobe can make a blanket type converter without losing camera specific info, and still call it loss-less when it discards 1/4 of a file. Obviously some camera makers include more data in their RAW files too than others. So while RAW is loss-less each would be different? Then while DNG wouldn't compress, it would discard? I'm just curious if you or anyone else knows...knowing I'm a bit off topic...but topics like this make me curious about other related stuff. Well maybe it's not so off topic...since there are so many variables involved with anything complex like this. Your challenging my incorrect assumption that RAW files were somewhat compressed(to account for varying sizes) has made me think it through moreso than I had before...and ask myself exactly what is going on. Interesting.

[marxz]

ummm OK now this is computer stuff that I do "understand" (being a programer by training and a techie by slaver...err salary) ...

how ever compression is a black art, and I'd have to brush up on ... well how to word it so that it doesn't go "WOOSH" over my own head let alone those lucky enough never to have delved "under the hood" of file formats (as compression applies to every thing from pictures to databases to (now with "openXML" in office 2007) word and excel documents)

[marxz]

Right take a deep breath.... (and this is ultra basic stuff).... and follow me down the rabbit hole that is data compression ....

I'll use lossless compression of the type used in Lempel-Ziv-Welch (LZW) style compression (such as ZIP).

I'll touch on lossy at the end but without regard to specific examples like JPG as you can't really draw direct working analogies outside of the specific purpose (ie the theory behind JPeG for pictures works totally differently to MP3 for audio - which is why they use both of them, together, to compress movies ie MPeG's)

Lossless compression LZW style...
OK first thing to realise is that even though your data is a picture it is made up of the same binary "bits" (0's & 1's) that are used to store text files on disk... when several sets of binary are joined together they are said to be a "word".
When a program runs LZW type compression it builds a table of all the "words" that it finds (patterns of bits) it does this by examining all the possible contiguous combinations with in it's "word size" limit.
Now it looks at this index (called a "dictionary") and finds "words" that occur frequently and assigns a smaller "look up word" to represent this.

it then writes a file that includes the table (the original "words" and the new, smaller "look up words" that now represent the old longer "words"), it then writes the data in to the file using original "words" that didn't happen frequently enough to warrant their own "look up words" as well as the "look up words" that represent the now discarded longer "words".

when a program wises to read/display this data it looks at the table and reads all the original words and their "look up" replacements and then starts reading the actual data if a word in the data is a "look up word" instead of displaying the word written in the file it replaces it with the original "word" in the table...


ie
lets use the modern UK version of the lords prayer:

Our Father in heaven,
hallowed be your name.
Your Kingdom come,
your will be done,
on earth as in heaven
Give us today our daily bread.
Forgive us our sins,
as we forgive those who sin against us.
Lead us not into temptation,
but deliver us from evil.
For the kingdom, the power and the glory are yours.
Now and for ever. Amen

we can see that several words appear numerous times
so a table might look like this

Original word lookup word

heaven 1
your 2
in 3
be 4
our 5
give 6
sin 7
us 8
as 9

etc... etc ..etc...

running just this small sample against the original we get a file that looks like this:

table:
heaven 1, your 2, in 3, be 4, our 5, give 6, sin 7, us 8, as 9
Data:
5 Father 3 1,
hallowed 4 2 name.
2 K3gdom come,
2 will 4 done,
on earth 0 3 1
6 8 today 5 daily bread.
Forgive 8 5 7s,
0 we forgive those who 7 aga3st 8.
Lead 8 not 3to temptation,
but deliver 8 from evil.
For the k3gdom, the power and the glory are y5s.
Now and for ever. Amen


so you can see here that no data is lost... every thing is there just represented differently. running it back using a reverse look up your reconstitute the EXACT same data with no loss at all.

now in this short example you won't get any real saving, and in fact you get a bigger file : 332 characters in the original and 360 in the "compressed" file, in this case mainly because the table takes up room and the fact that while the look up words replace bigger original words they still take up some space.

further more the compression algorithm will now repeat the process to see if, in the process of compressing the file it's made any new patterns of frequent new words it can replace. this may be repeated several times (and the file keeps a record of how many times it's repeated as it has to run the replace (uncompress)process that same number of times.
Each repeat is almost always a diminishing return until there no more compression to be gained (or you set a limit of repeats based on if the user will run out of patience waiting for it)


the reason why different RAW formats can produce different files sizes is what compression algorithm they use and... well this comes down to 2 things
1: how fast can the camera's hardware run different levels/types of compression related to what is a reasonable user level of patiense of waiting (cheap powershot A model ... heck you can wait on the slow as a wet weekend cheap processor, D1nIII slamm 'em out as fast as you can with a highly optomised processor (or 2)

2: what compression algorithm can you afford to license?
ZIP/LZW is now free (out of patent) but it is slow and it is inefficient
newer faster and more efficient algorithms that can compress files faster and in to smaller sizes cost serious money to license and the bigger the company (ie Canon, Adobe) the better they can afford them (or afford to employ researchers to write their own even better ones)

in the end I would bet good money (note: all my money is bad money (ie debt)so don't call me in on this) stuff like DNG is so efficient is simply because Adobe owns their very own meanest nastiest alpha dog of all lossless compression algorithms and that Olympus and to a lesser extent Canon have their smaller beta dog algorithms that arn't quite champs (and also they have to squeeze their dogs in to a smaller kennel (your camera) than Adobe (who house it in your nice fast computer).

Now lossy compression.. like JPG and MP3

first off all you generally run a lossless algorithm on your data... now we'll use the same example so before losing anything we have:

table:
heaven 1, your 2, in 3, be 4, our 5, give 6, sin 7, us 8, as 9
Data:
5 Father 3 1,
hallowed 4 2 name.
2 K3gdom come,
2 will 4 done,
on earth 0 3 1
6 8 today 5 daily bread.
Forgive 8 5 7s,
0 we forgive those who 7 aga3st 8.
Lead 8 not 3to temptation,
but deliver 8 from evil.
For the k3gdom, the power and the glory are y5s.
Now and for ever. Amen

now we throw away anything that the user won't notice....

now here we see why the analogy can't be directly compared between media that your compressing... in pictures your _BRAIN_ sees things that eyes' don't and doesn't see things that are there.. in music your BRAIN hears things that don't exist and doesn't hear things that do exist.

with text your brain already doe's a lot of implicit "reading" you skip over without registering many grammatical and spelling mistakes, incorrect punctuation and poor formating... now imagine your brain did this to the extent that it does it with pictures and music... you can now remove all those pesky page breaks, carriage returns, turn all the "sounds the same but spelt different words (homonyms) like "to" "too" "two" and "2" in to one single word... "2"
sounds strange? just look at kids/teenagers doing mobile/cell phone, and online text messages, L33t 5p34k (leet speak (elite speak) and lolcat macro's)

all of this is throwing raw data away that is implicitly reconstructed by the the reader (given they are "in the know" of how it works)

hate "those type of kids and their curse'ed desecration of language"? well? tough, other languages have been there and done that before and "compressed" their language we no longer speak the wordy and verbose language of Shakespearian type English, Hebrew has no writen vowels, Japanese almost always leaves out subject ("you" "me" "them") in both written and spoken words in all cases the listener reconstructs them mentally with in their lingustic context.

so just a simple homonym/punctuation pass turns the example in too

table:heven1,ur2,in3,B4,our5,give6,sin7,us8,as9.Data:5Father31
helloed42name2K3gdomcome2will4doneonearth03168today5daily
breadForgive857s0weforgivethosewho7aga3st8Lead8not3to
temptationbutdeliver8fromevilforthek3gdomthepowerandtheglory
ry5sNowandforeverAmen

now THAT takes up a whole lot less space... but you've thrown out a lot of data that, if you train your brain to ignore it all in the first place (like those pesky kids), you'd have no trouble processing it the same way you look at a JPG with 4/5ths of it's data thrown out and listen to a MP3 with 9/10'ths of it's information stripped away.

[madlights]

Thank you...you have a gift for making the impossibly complex a bit easier to understand. I was somewhat aware (to a minor degree to say the least) as to how "lossy" compression worked...at least understanding on a very basic level...that things we hear, or see that we don't "need" were discarded. I had absolutely no understanding of how lossless compression worked...So I sure do appreciate the time you've taken and the clarity of your answer. I can certainly see that a computer could decipher the tables involved much more rapidly than even the best camera's with the right formula. That's also probably why my Oly digicam takes 3 or 4 years to write a Raw file, and my Canon is pop, pop, pop. and why the Oly's RAW is so large...since it would take the camera with a small processor (cheaper) a long while to decipher those tables? probably some other factors too...like R&D costs. I have heard that DNG does discard certain camera info...since it's a blanket converter...I certainly don't have the expertise to know if that's correct...and I don't think some of these conversions are exactly "open source" for obvious reasons...although it must be a pretty good conversion, since some prominent camera makers have adopted it (I always convert and save my orig. too). Very interesting, and informative. ...thanks again for explaining this lossless stuff...at least so I get the basic idea through my somewhat dense head.... On a side note: I don't know if it's both my computers gone bonkers, or these posts are 2000+ pixels wide. I'm having to scroll sideways a tremendous amount at least now, and checked on 2 separate machines.

[intermon]

Just to get back to the original question of the significance of 14-bit over 12-bit a/d conversion...
This, although encouraging, does not necessarily mean a better picture will result. Yes, it does result in greater TONAL resolution but not necessarily greater dynamic range. You would expect that reputable manufacturers like Canon and Nikon would not simply use this as a marketing gimmick. If in fact the sensor has a lower noise floor then yes, it's a very good thing. But if the sensor noise floor hasn't improved then it's unlikely you would see any improvement.
I don't have hard facts to back this but it seems that when the 5D with its 12-bit a/d can have much superior performance than a 30D with the same a/d resolution then I think the limiting factor (at least so far) has been the sensor and not the conversion resolution of the a/d.
I think the compression issue is yet another factor but with good DSLRs all using RAW, I think it may be a moot point.
Roger

[marxz]

Thank you...you have a gift for making the impossibly complex a bit easier to understand.

your welcome - it's my job so I tend to let a bit of work slipping in to my after hours

On a side note: I don't know if it's both my computers gone bonkers, or these posts are 2000+ pixels wide. I'm having to scroll sideways a tremendous amount at least now, and checked on 2 separate machines.

sorry that was my bad - the last example I used I removed carriage returns creating a 230 char long text string not realising the pbase forum software doesn't force carriage returns at any set length so blew the horizontal page width out... fixed now

[marxz]

Just to get back to the original question of the significance of 14-bit over 12-bit a/d conversion...
This, although encouraging, does not necessarily mean a better picture will result. Yes, it does result in greater TONAL resolution but not necessarily greater dynamic range. You would expect that reputable manufacturers like Canon and Nikon would not simply use this as a marketing gimmick. If in fact the sensor has a lower noise floor then yes, it's a very good thing. But if the sensor noise floor hasn't improved then it's unlikely you would see any improvement.
I don't have hard facts to back this but it seems that when the 5D with its 12-bit a/d can have much superior performance than a 30D with the same a/d resolution then I think the limiting factor (at least so far) has been the sensor and not the conversion resolution of the a/d.
I think the compression issue is yet another factor but with good DSLRs all using RAW, I think it may be a moot point.


Roger

actually that's pretty much as I implied in my first post re bit depth in regard to dynamic range and/or sensitivity of the sensor within it's dynamic range, and yes raw is good but raw format size for a given resolution is quite dependant on the compression algorithms used in camera and it's obvious that different manufacturers use different levels of efficiency there. Hence the difference in size between say Olympus RAW files and Canon RAW file sizes

[sean_mcr]

I'm far too lazy to explain it myself, so...

http://www.luminous-landscape.com/tutor ... epth.shtml

[marxz]

I'm far too lazy to explain it myself, so...

http://www.luminous-landscape.com/tutor ... epth.shtml

lazy or not, this artical actually raises a few questions for me (that I should have twigged on to before)...

I NEVER (well never since CS2 introduced adjustment layers to 16 bit images) do curves and hue/saturation adjustments on a layer it's self, only with adjustment layers....

then I save the file and dump a copy of it down to 8 bit....

I'm guessing then that changing the bit depth reduces the bit depth of the image layer(s) without regard to how the adjustment layer(s) above it affect the histogram and the adjustment layers now act on the lower bit depth image layer(s).

this could account for some weird effects like some dark area's puddling to black or near black and gradients steps becoming visable (such as with http://www.pbase.com/marxz/image/79417224 and http://www.pbase.com/marxz/image/79846049 )

If so I'm assuming should I therefor flatten the adjustment layers with the layers they interact with before knocking the bit depth from 16 to 8 bit for saving to JPG?