So I notice some of the raw to dng convertors out there will work at 16 bit and some work at 12 bit but MLraw video is 14 bit.
am I losing valuable data by converting my 14bit ML raw frames to 12 bit .dng? or do I need to go to 16bit to prevent truncation?
what's up with that? I need some expert advice.
thank you for your time!
I read somewhere that the 16bit conversion is done for some video editors who can not read/handle 14 bit (cinema)DNG's. I guess most video editors expect 12 or 16 bit dng's :P
About what you loose, quality wise, while converting to 12 or 16 bit, I'm not sure...
I also would like to know why BMCC DNG claims to be only 12bit vs Magic Lantern 14bit and have more latitude than ML RAW?
Can anyone shed some light?
Do you have a link where they claim that the 12bit DNG has more latitude ?
Maybe they mean that the sensor in their camera has better dynamic range, which results in more latitude :-\
Dynamic Range and bits is not the same.
Bits are colour information, basically how many different colours your camera can show in each pixel.
8 bit holds 256 shades of grey
12 bit 4000something shades
14 bit 16000something shades
A7s has 14 stop dynamic range in a 8 bit codec, the sensors has more latitude in shadows, but the colour information is still very low. If you are using the A7s you will have to struggle a lot more to get good skin tones and deep colours.
BMPCC has 13 stops 12 bit
The sensor of the MK III has around 12 stops. 14 bit
Though I am not entirely sure if you can bind yourself to the 12 stops of the MK III, cause you can ETTR and win a lot of information in shadows and still retain almost all detail in highlights.. To me it seems the DR of the MK III surpasses 12 stops easily. But I have no science to back this up, only a feel.
I don't have the exact math here, someone a bit smarter than me can put up the 14bits*(per pixel) * 1920x1080 = (what I am talking about) ;)
Quote from: Levas on November 11, 2014, 05:04:58 PM
Do you have a link where they claim that the 12bit DNG has more latitude ?
Maybe they mean that the sensor in their camera has better dynamic range, which results in more latitude :-\
What I meant is BMCC claims to have only 12bit DNG but from the DNG samples I've seen on below link, they are far superior compared to my 5D Mark III in terms of color:
https://fstoppers.com/video/black-magic-releases-raw-files-cinema-camera-you-color-grade-5442
Also on this link EOSHD quoted that BMCC has a bit more latitude
http://www.magiclantern.fm/forum/index.php?topic=7468.0
The difference is in the way the data is encoded into 12 bits. Canon outputs 14bit data but it is linear. The human eye sees on a logarithmic scale, so this means that there's quite a bit of "wasted" precision on the high end. BM cameras output data on a logarithmic scale, so there's much less "wasted" bit depth, and so the cameras are making much "better" use of all the values that are possible to encode into 12 bits. You can think of this as a form of lossy compression (http://en.wikipedia.org/wiki/Lossy_compression), because truly that's what it is -> throwing out "unimportant" data so as to maximize the effective use of available space.
Bits in the RAW file are necessary for a certain DR, but they are not enough. DR is limited by noise rather than by bits.
For instance the Canon 40D produces 14-bit RAW files with two totally useless bits. If you truncate to 12 bits its RAW files (by zeroing the two LSB's) and then develop them there is no quality nor information loss vs a 14-bit RAW development.
My Olympus E-P5 with 12-bit RAW files has more DR than many 14-bit Canons like the 40D, because its sensor has lower noise despite the also lower bitcount.
for most cases, you won t even see the difference between 14 bit and 10 bit... for smaller projects, i always convert my dngs into avi 10 bit 422 log, and that s enogh.
my advice as well - use 12bit/linear. its good, or simpler: its enough, if you dont have to postpro as hell.
I wonder if the dng files from mlrawviewer vs mlvfs have the same amount of bits?
MLVFS uses 16bit for a number of reasons:
1. The extra bits aren't taking up any "real" space, it's a virtual filesystem. So they don't really hurt anything.
2. 16bit is compatible with post processing apps (namely Premiere)
3. It's much much easier and faster to process and perform computations on 16 bit data (than 10, 12, or 14) because it is byte-aligned.
MLRawViewer supports lossless compression, so the "actual" bit depth is going to be variable and somewhat hard to quantify.
Excellent point @dmilligan and I second that which is why I enjoy using MLVFS & MLRawViewer... ;)
Would it be possible to implement compressed lossless dng as an option in mlvfs? For people who copy those files to other directories. Thx
That's probably not going to happen with MLVFS, it would be self-defeating: it defeats the whole purpose of MLVFS to copy files out. You can use the Adobe DNG Converter if you'd like to compress your DNGs.
@dmilligan:
alright thank you for the information.
Just to clarify:
MlRawViewer DNGs are 16bit, but this 16bit data is padded with 2 zero bits from the original 14bit Canon data.
As they use lossless JPEG compression, the file size on disk is typically less than a 12bit uncompressed DNG. No data is lost in this process. The DNGs contain every bit the camera produced.
(I still wouldn't recommend it as an archival format for MLV files - I think it would be better to integrate lossless JPEG to the MLV format. g3gg0 has done some work initial towards that approach in the mlv_rec_lj92 branch of ML but I don't know what the status is currently).
Quote from: baldand on November 14, 2014, 05:29:26 PM
(I still wouldn't recommend it as an archival format for MLV files - I think it would be better to integrate lossless JPEG to the MLV format. g3gg0 has done some work initial towards that approach in the mlv_rec_lj92 branch of ML but I don't know what the status is currently).
I noticed that in the ML changelog, is this implying that mlv_rec would write lj92 dng's to the .mlv in-camera? Wonder how that would affect cpu memory and r/w speeds....
No, not in camera. It's part of mlv_dump. You can already use mlv_dump to compress MLV files for archiving, the lj92 stuff is just a new, better lossless compression scheme.
Ahhh gotcha, thanks for the explanation. I get excited at the mention of 12 bit or compressed raw video, my poor 7d needs some computational stimulation :D
Good read!
For RAWMagic users, the difference between selecting 12-bit and 16-bit may be important. I've used the Lite version of the program to process my .RAW files, but upon upgrading to the full version I noticed I now had the option to pick between the two. Using 12-bit on dual ISO recordings I was getting some very odd results after completing the process with cr2hdr, mlvfs and mlvmystic. The final output would have magenta window views and be pitch black inside, Ramping up the exposure +4.00 would still leave the room black. Simply switching RAWMagic to 16-bit resolved this problem. I suspect the Lite version of the software automatically processed @ 16-bit, but trying every combination of setting to learn this was a bit painful. Hope that helps someone else who runs into this issue shooting dualISO and starting their processing with RAWMagic.
Any discussion about RAWmagic is banned here. See http://www.magiclantern.fm/forum/index.php?topic=13335.0
And what's wrong with MLP @nickmford?