The CinemaDNG Discussion (raw2cdng)

[edge11]

Thanks Chmee for implementing the chromasoothing!

[dougja]

What's peoples' opinions on the best workflow using CDNG? Do you run it through Davinci first or drop it straight into PPro CC?

With the latter, my prem pro is struggling to play the files smoothly, it plays about 1-2 seconds before going jumpy/stopping. It's the same with the former method when compressed to MPEG Quicktime and dropped into PPro.

What settings do people use for sequence Preview File Format, if that makes a difference? thanks

16gb ram, i7-4770 @ 3.5ghz, gtx 660, gpu acceleration

[chmee]

what kind of harddisk(s) do you've got? my opinion: i tried to get a straight workflow inside adobe world. so, yes, its possible without DaVinci. i've got for that 2 ssd's (crucial mx100 512gb), they do at least 120mb/s on very small files and go up til 500mb/s.

[dougja]

Premiere's running off a SSD but the footage is stored on a sata 7200rpm drive, do you think that could be it then?

Although when I play the original MLV file using an mlv player, it plays around 18-19fps, much better than the jumpy premiere pro

thanks

[chmee]

test it yourself and copy some dng's-folders to the ssd. does it change? dng-sequences are not small, as you know. yes, i assume, the sata-hdd limits..

[dougja]

Didn't make a difference, however I tried converting to 12bit instead of 16bit and now it runs smoothly. Am I losing any data by doing this? Sorry if this has been answered before, did have a quick search.

thanks for a great tool by the way!

[chmee]

mathematically yes, practically no. the advantages over 8bit are still huge. (and 12bit means as well, lowering the datarate by ~25% compared to 16bit)

[chmee]

short sign of life.

(*) i embedded the chroma smoothing, as i said. with the first sample i had some problems, because i couldnt eliminate all false-pixels. then i understood, the chroma smoothing is only able to fix red and blue pixels. the green ones blur a little and rise. i'd recommend to use the badpixel-elimination inside the canon body before working with ml. the version with cs will be here next days.

M07-2201 from samplefiles (ML-RAW June 2013--EOS 550D @glubber) - a good point to start with a green hot/stucked pixel algorithm.

(*) in general i'll code a demosaicing-algorithm to be able transcoding into tif, then prores/dnxhd or other codecs (maybe i can realize the arriraw-output)

BUT

(*) my thoughts are, its time to end this tool. it works well and all effort should be put now into the mlvfs-apps. this is a clever timesaving-idea and if something's problematic with cdng i think i can help there to even make it better

regards chmee

[swinxx]

Hello Chmee, thx for all your effort!
I use mlvfs (as you probably know from the mlvfs thread) i have also some pixel problems with chroma smoothing. I decided to disable it, but perhaps it could be improved to handle the dark areas right. Mlvfs is indeed the easiest and fastest way to get generated dngs.
Greets swinxx

[chmee]

thanks to @dmilligan

* cdngs and audiofile behave under resolve as wanted autosync as a mediafile now, not only autosync-functional.
* found a 16->12bit bug. fixed.
so, give me some more days and a new version will arrive..

@swinxx
jepp, but i will have marked this tool as "complete" - and im still learning with every bug i find.

[chmee]

raw2cdng 1.6.3 beta is online

* chroma smoothing
* corrected length of wav-audio, thus it works now in resolve. (autosynced media-bins with according timecode)
* preview now scrubbing instead of playing.

http://www.phreekz.de/wordpress/2014/04/magiclantern-raw2cdng-1-5-0/

regards chmee

[andy kh]

thank q so much for implementing chroma smoothing. but i can test it only next month as im out of my town

[feureau]

OMG Thank you for chroma smoothing!

Btw, does anyone getting different K of white balance when using v1.6.3 vs v.1.6.1?

[chmee]

@feureau
could you show me a screenshot or write some more infos to it? i have rewritten much of the code, its possible i forgot something

[feureau]

Screenshot: http://i.imgur.com/PMljcpD.png

Basically, they're the same MLVs loaded on two versions of raw2cdng. The resulting DNGs seem to come out correctly though. And it seems the 1.6.1 didn't preview WB correctly.

Also: I've getting this error:

Code Select Expand

Problem signature:
  Problem Event Name: CLR20r3
  Problem Signature 01: raw2cdng.1.6.3.beta.exe
  Problem Signature 02: 1.5.0.8
  Problem Signature 03: 546f5484
  Problem Signature 04: mscorlib
  Problem Signature 05: 4.0.30319.18444
  Problem Signature 06: 52717edc
  Problem Signature 07: 442a
  Problem Signature 08: 0
  Problem Signature 09: System.IO.IOException
  OS Version: 6.1.7601.2.1.0.256.1
  Locale ID: 1033
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


Also: That chroma smoothing really slow conversions down... But I'm not complaining. :3

[chmee]

(*) thanks. assume, i know, where's the bug.
(*) there s an io-exception. are they used/opened in an app in background? it seems, it couldnt erase/rewrite them. fi with premiere?
(*) will look, if i can optimize, but yes, chromasmoothing slows down the conversion massivelly. before that, there only have been bit-shiftings and multiplications of values..

regards chmee

[Kharak]

Can you tell me the difference between 16 bit and 16 bit Maximized?


ps. this is my new Go To tool for conversion.


Thank you so much Chmee!

[chmee]

as you maybe know, the canon-rawdata has values between blacklevel (fi 2047) and whitelevel (15000). it was necessary to maximize the valuerange for premiere. subtracting the blacklevel and scaling the values to the maximum value (16bit = 65535). i'd say, in general there's no drawback, but for workflow with acr (photoshop/ae) and lightroom i assume, its good to have these sparedata, you can reconstruct more highlights and optimize the noise-recognition.

btw: i wrote this pinkhighlight-fix for premiere, but it seems, its not needed anymore, adobe-coders did something against it. prove me wrong

regards chmee

[feureau]

(*) thanks. assume, i know, where's the bug.
(*) will look, if i can optimize, but yes, chromasmoothing slows down the conversion massivelly. before that, there only have been bit-shiftings and multiplications of values..

regards chmee

You're welcome, and thank you!!

(*) there s an io-exception. are they used/opened in an app in background? it seems, it couldnt erase/rewrite them. fi with premiere?

I don't have anything else running at the time except regular background stuff like chrome background etc.

as you maybe know, the canon-rawdata has values between blacklevel (fi 2047) and whitelevel (15000). it was necessary to maximize the valuerange for premiere. subtracting the blacklevel and scaling the values to the maximum value (16bit = 65535). i'd say, in general there's no drawback, but for workflow with acr (photoshop/ae) and lightroom i assume, its good to have these sparedata, you can reconstruct more highlights and optimize the noise-recognition.

btw: i wrote this pinkhighlight-fix for premiere, but it seems, its not needed anymore, adobe-coders did something against it. prove me wrong

regards chmee

So, to verify: For ACR/lightroom/Resolve - best to convert without Maximized?

[chmee]

So, to verify: For ACR/lightroom/Resolve - best to convert without Maximized?

has to be proven as well.

@feureau
sample-pictures regarding wb above. you recorded outside, i'd say ~6000°K, and set the wb manually to 3100°K. i think, the newer picture is colder because its the wrong wb. do a test - dragdrop the file on raw2cdng-icon (not into the opened app), it should open the player. with arrows left/right, P(resets) and O(riginal) you can look on wb-changes. is it maybe fine, if you change it to something like 6000°k?

regards chmee

[feureau]

has to be proven as well.

@feureau
sample-pictures regarding wb above. you recorded outside, i'd say ~6000°K, and set the wb manually to 3100°K. i think, the newer picture is colder because its the wrong wb. do a test - dragdrop the file on raw2cdng-icon (not into the opened app), it should open the player. with arrows left/right, P(resets) and O(riginal) you can look on wb-changes. is it maybe fine, if you change it to something like 6000°k?

Using 1.6.3 - Looks about neutral with AWB preset at 4500K, filedata is at 3100K Manual WB

[feureau]

BTW, I was just converting some DNGs, and found that the latter part of the batch turned up like this:

http://i.imgur.com/gokLxhZ.png

It's not wb issue, there's nothing in the Resolve raw settings I can play with that would fix it. I tried converting the MLV with mlrawviewer and it come out just fine. I tried converting other MLVs with raw2cdng and it turns out this way all the time. I even tried re-downloading the app and it still come out this way. Any ideas?

Furthermore, about half of the DNG that came out right can't be synced with the wav in resolve. Anyone having this issue too?

[chmee]

@feureau
there's a debug button on top, enable, close, open. it will be written into the same folder as the app. send me a non-functional dng (or mlv) file to [email protected] and show me that debug.

regards chmee

[chmee]

@feureau
thanks. my tool doesnt change black- and whitelevel in this beta. thanks for hint. will be solved next hours. if you know exiftool, you can change blacklevel to 0 and whitelevel to 60.000.

[feureau]

Thank you, too!

Can't wait to use the fixed version