MlRawViewer 1.3.3 (CDNG/MLV/RAW Viewer & Encoder, Linux/Mac/Win)

[senzazn12]

Regarding the bad colour in highlights: try disabling the stripe correction for those clips. That code path has a different highlight reconstruction approach which sometimes avoids this problem.

Will do.

[kgv5]

@baldand - I asked Andy600 about implementing cinelog-c into mlrawviewer to have fast, easy solution of true cinelog-c prores444,

http://magiclantern.fm/forum/index.php?topic=10151.msg137051;topicseen#msg137051

this is the answer:

"@kgv5 - If @Baldand can implement a little change to the backend in MLRavViewer and impliment an alternative 3x3 matrix and lin to log formula just for Cinelog-C we should be able to debayer straight to Cinelog-C colorspace without using LUTs. At the moment it uses DCRaw's REC709 primaries. I will happily provide the matrix and log formula if he wants to do it. LUT handling in MLRawViewer is ok but the colorspace limits what we can do using LUTs - I've tested it with some custom Cinelog-C transform luts and there are issues with out of gamut colors and overbrights, plus a 3D transform is needed for the colorspace transform which means you cant then use the 3D lut slot for a viewing LUT - which is needed for assessing exposure compensation and white balance. "

Do you think you could do that?

[arrinkiiii]

It would be very nice to have this  =))

[baldand]

"If @Baldand can implement a little change to the backend in MLRavViewer and impliment an alternative 3x3 matrix and lin to log formula just for Cinelog-C..."

Do you think you could do that?

Though this would be possible to add, I do not currently plan to make any more binary releases of MlRawViewer. As I informed previously, this is due to the lack of contributors to help with testing and support on the different platforms.

[kgv5]

Yes, i know, but with cinelog (which seems better and better, especially with the upcoming huge, very nice update) possibility to have an instant real cinelog-C prores444 would be a great option, even in comparison with MLVFS (which is great on Mac and ok on PC) and resolve workflow. I am just making movie and using mlvrawviewer all the time instead mlvfs and resolve. It is really great app, please consider this baldand, it could be next milestone. I am sure that with such a complete solution there will be many new testers and contributors. MLVFS its not really a competition, your app is some different and very useful tool which has its important place in some workflows. PLEASE

[dhpdigital]

I'd be a glad tester on my kit. Mac & PC, canon 5D mk3. D

[baldand]

I'd be a glad tester on my kit. Mac & PC, canon 5D mk3. D

Thanks for the offer.

To be clear, my problem has not been due to lack of people ready to try out the builds I have made.

My problem has been lack of any other people willing to try and make their own builds for Mac or Win directly from the latest source stored in git on bitbucket. In my ideal world, the responsibility for making, testing, releasing and debugging the Mac and Win builds should be with people who use those platforms as their main system for real world video processing and hence can give it a thorough and realistic test before each release. I primarily use Linux, and I mainly test on there, not on Mac/Win.

Building MlRawViewer releases for either of those platforms is not very difficult (though sadly not well documented right now). Debugging of course requires some familiarity with python programming. And you need to be able to make basic use of git.

[dhpdigital]

I'm a visual person and work with captured and generated image, so unfortunately can't offer any support with anything code based sorry. Would it help if you had donations towards your software as support instead? I know some people run a donation ware type of deal for their work.

[DeafEyeJedi]

As always, I'm a happy tester (although I'm no prgrammer) but starting to get the hang of compiling and coding with MacHg (still learning it's kinks though).

PM me @baldand anytime if you ever decide to get back on releasing your marvelous app once again!

Happy New Year, Andrew!

[baldand]

Would it help if you had donations towards your software as support instead?

Sorry, but no.

[kgv5]

I think there is an oportunity to make mlvrawviewer to be seen as more "professional" tool by more people, when they will know that raw footage can be very fast processed and - what is important - professionally color-transcoded (and people will know cinelog-c thanks to andys marketing work). With the ability to instant review the footage, easly set in/out points it could be no-brainer for many. Even using MLVFS along with resolve is often more time consuming, especially when working in a field. Many people on forums like eoshd and similar very often mention mlvrawviewer as a new tool which made raw shooting easy as never before. Andy600 -cinelog-c developer- said he is willing to help. Maybe i am wrong but this looks like an important oportunity for mlvrawviewer to become a more frequently used tool than it is now.

[terranaut]

if mlrawviewer is frozen in development, does this leave just raw2cdng left in the world of processing  mlv in windows thats still being developed?
seems like a year ago there were a few windows choices, and now its hard to find one still in dev. as future builds of ML come out in 2015, new features for mlv might be added, some might change, and then i don't know what options we will have when older converters begin showing their limits of newer changes/additions of mlv formats

[Lars Steenhoff]

When cinelog is implemented I will happily try to build a binary on the mac

[DeafEyeJedi]

That would be excellent @Lars Steenhoff -- hope you're listening @Andy600 

[feureau]

My problem has been lack of any other people willing to try and make their own builds for Mac or Win directly from the latest source stored in git on bitbucket.

Teach us how, and I'll build for win.

[Andy600]

@DeafEyeJedi - I'm listening of course and like I said previously I'll provide the formula and matrix information to the dev. The tricky part is in integrating Cinelog-C as a separate colorspace option in MLRawViewer. At present MLRV uses REC709 primaries and white point for everything. The lin to log transfers for each option are just simple, 12bit, 1D luts, generated from coded formulas.

It's easy to put different fuel in the engine but the engine itself needs a little modification

[DeafEyeJedi]

Absolutely! Point taken and yes I knew you would be listening...

It's just more of a friendly reminder!

[emoji1]

[tomekk]

Hi guys,
What's the correct curve for exporting to prores if I want to apply either filmconvert or osiris later on?

[arrinkiiii]

Having Cinelog curve for export in ProRes would be a great shortcut   =D

[Andy600]

@tomekk - REC709 in MLRV and sRGB (default) input in FilmConvert! (but you will have already clipped the signal)

FilmConvert expects the input to be the full colorspace (transfer curve and gamut). MLRV outputs everything with REC709 primaries. Only the transfer curve part of the colorspace options in MLRV is used.

Having said that, you will probably get good results using Canon Log in MLRV but the color will still be a little off in FilmConvert.

[tomekk]

@Andy600, thx very much for great reply .

[feureau]

Having Cinelog curve for export in ProRes would be a great shortcut   =D

That and technicolor cinestyle. And that adobe DNG color matrix thingy.

[Andy600]

@feureau - The color matrices for Neutral, Portrait, Standard, Faithful and Landscape are the same (Camera RGB to CIE XYZ). It is a HSV table in ACR or an ICC profile in Canon DPP that gives you the colors of each Picture Style.

Technicolor Cinestyle is an 8bit linear-to-log conversion. It's actually a very close relation of Cineon but less technical and created by Josh Pines of Technicolor. You have 14bit raw files and will output at 10bit or higher in MLRV so even if you could output Cinestyle you would be throwing away a ton of useful information. The Cinestyle curve is nothing special.

[mkrjf]

I am glad to test / support for 5DMk3 firmware 113
I am using the older version of ML currently outputting .raw file
Switched from raw2dng app to MLRawViewer
thanks very very much for reading our minds
So nice to preview before grinding out the transcode
If you can provide link / process for building on OSX (mavericks apple dev env) I am glad to build and give feedback.
One thing I noticed is that the same footage converted using raw2dng and mlrawviewer - the mlrawviewer with sRGB out (and sRGB or AdobeRGB - I forget) elected in camera (and neutral camera color style) - the MLRawViewer converted skin tone seems just so slightly greener. No one would notice except I was editing and had both clips loaded for a cut between.
Not sure color science for raw2dng was documented - and there was no pick list. But maybe you could provide thoughts. Raw2dng did have a pink problem at one point so maybe that clip was pinker as opposed to MLRawViewer being greener. No idea.
Also, can you support AdobeRGB? I usually select that in camera and for photography it definitely covers a larger color space. I would like to do no color transformations before post - keep it all AdobeRGB if possible. (I post photos to AdobeRGB and film to P3 with a calibrated monitor). It sound like you have access to LUT for conversions - home grown? Just ask as most post houses don't share that info (secret sauce).
Lastly, can you confirm the bits of significant data in and out for MLRawViewer? In another post you mention prores 4:4:4 is 10 bits depth, so you are doing simple truncation of low order bits?
When outputting to DNG - you are outputting 14bits of data into 16bit words?
Have you found that the ML Raw output actually uses 14bits? Any idea if older version (right before HDR version and new file format) and newest version provide full 14 bits of data?
Curious to quantify what is actually the input to color grading when using ML and MLRawViewer with both ProRes4:4:4 and DNG flows.
Mike

[mrtobycook]

Hi everyone

I've tried to read this entire thread - yes, 58 pages - but still am coming up empty with why MLrawviewer isn't working on my Windows 7 64-bit system.

Anyone have any ideas? This is the log:
MlRawViewer v1.3.3
(c) Andrew Baldwin & contributors 2013-2014
Using GLFW
Opening CinemaDNG G:\_MY FOOTAGE\01 CINEMA DNG\M131458O_C0001_B16
(24028, 1000)
FPS: 24.028 (24028, 1000)
brightness 1.0
Black level: 0 White level: 65535
BitsPerSample: 16
Compression: 1
(0, 1, 1, 2)
rgb [2.1201173696975864, 1.0, 1.4755856968527232]
((0, 1), (0, 1))
((1280, 1), (544, 1))
(0, 0, 544, 1280)
Crop origin: ((0, 1), (0, 1))
Crop size: ((1280, 1), (544, 1))
Active area: (0, 0, 544, 1280)
Traceback (most recent call last):
  File "<string>", line 128, in main
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\MlRaw", line 1527, in loadRAWorMLV
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\MlRaw", line 1211, in __init__
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\MlRaw", line 1279, in _loadframe
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\DNG", line 425, in stripsCombined
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\DNG", line 404, in strips
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\DNG", line 327, in readFrom
EOFError
Could not open file G:\_MY FOOTAGE\01 CINEMA DNG\M131458O_C0001_B16\M131458O_C0001_B16.000000.dng. Error: