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

[baldand]

1.3.3 is now the stable & recommended version of MlRawViewer. See the top post for links and usage.

http://www.magiclantern.fm/forum/index.php?topic=9560.msg91165#msg91165

[DeafEyeJedi]

1.3.3 is now the stable & recommended version of MlRawViewer. See the top post for links and usage.

http://www.magiclantern.fm/forum/index.php?topic=9560.msg91165#msg91165

COPY that @baldand -- is it recommended to redownload 1.3.3 or is that not necessary? Also how were you able to get the histogram tool implemented on the mac version or is that never going to happen?

I noticed that the Windows version has it built in... which looks really nice and extremely helpful!

**EDIT**
Actually nevrmind that as I noticed there was a tinted window on the top right corner of the app itself... it was blank until I clicked on top of it with the cursor and VOLIA here comes the beauty of histogram!


THANKS AGAIN!

[DavidSh]

Thank you Baldand,

Any idea why premiere cc cannot read the CDng?
It says "The file appear to have no media data"

[baldand]

Any idea why premiere cc cannot read the CDng?
It says "The file appear to have no media data

Can you give more details please.
Is it a problem with all DNGs or just one file?
Did the same MLV file work when exported to DNG with 1.2.3?

[DavidSh]

Can you give more details please.
Is it a problem with all DNGs or just one file? - All DNG
Did the same MLV file work when exported to DNG with 1.2.3? - Yes

Also preview on mac look bad (Pinkish distortion), but i read that it because mac cannot read the new format correctly? 

Macbook Air, OSX 10.9.3
Premiere pro cc,
files came from 5dm3

[baldand]

It sounds like Premiere CC doesn't like compressed DNGs, or at least it doesn't like MlRawViewer's compressed DNGs (even though they are fine in ACR, Resolve and all Linux/dcraw-derived tools).

Can anyone else confirm the same problem?

[DavidSh]

It sounds like Premiere CC doesn't like compressed DNGs, or at least it doesn't like MlRawViewer's compressed DNGs (even though they are fine in ACR, Resolve and all Linux/dcraw-derived tools).

Can anyone else confirm the same problem?

Indeed, I can confirm that it opens great in acr.
The problem is for anyone who use the premiere with speed grade workflow.

Another thing not less important...
is it a way to hide the overlays when playback pause? MlRawViewer is the best on set previewer solution, But when i want to see actor face when playback is pause it is a problem with histogram background on face

Thanks for reply so fast and for your beautiful app.

[baldand]

It sounds like it's probably a bug in Premiere. If that's the case, I won't be fixing it.

[DavidSh]

another trigger to move for resolve
Thanks Baldand.

[DeafEyeJedi]

It sounds like it's probably a bug in Premiere. If that's the case, I won't be fixing it.

Currently testing this 'issue' with both PP CS6 & PP CC (pre-2014) and PP CC (2014) as well.

Stand by...

EDIT:

PP_CS6 stopped responding as soon as I opened the DNG folder created by MlRawViewer 1.3.3


PP_CC (pre-2014) <--- I didn't want to pay for this due to the 2014 version. My fault on this one! 


PP_CC (2014) works FLAWLESSLY so far... pretty remarkable!

[baldand]

@DeafEyeJedi many thanks for testing that. It's very useful to know that the most recent version of PPCC is working ok with MlRawViewer 1.3.3 compressed DNGs

@DavidSh which version of Premiere CC are you using? If not the latest, can you upgrade?

[DavidSh]

Thank you @DeafEyeJedi and thank you @Baldand,
Good to know that the 2014 version of pp support mlRawViewer 1.3.3, I'll try to put my hand on this.

Btw @DeafEyeJedi, It looks like the 2014 is still suffer from pink highlights?

[DeafEyeJedi]

Thank you @DeafEyeJedi and thank you @Baldand,
Good to know that the 2014 version of pp support mlRawViewer 1.3.3, I'll try to put my hand on this.

Btw @DeafEyeJedi, It looks like the 2014 is still suffer from pink highlights?

@DavidSh -- I believe that could be due to Unconverted Dual-ISO DNG's (shot w EOS-M)... I just exported them directly from MlRawViewer because I notice if I use @Danne's Cr2hdr-r or @dmilligan's MLVFS (both combined & solo) for some reason it won't be able to recognize the converted Dual-ISO DNG's in PP_CC (2014) unless I'm doing something incorrect that may be causing this?

Will try the LR5 Cr2hdr 20-bit plug-in and post about it soon.

Thanks!

[Danne]

the cr2hdr20bit binary probably won,t produce metatags or whatever information needed in the dng for pp cc 2014. I think both lightrom and cr2hdr-r uses the same 20bit cr2hdr. I use Kitchehofs compilation so should be the same.
Anyway.
Cool that pp cc 2014 worked with latest Mlrawviewer. I have adobe cc at work and will try it tomorrow.

[mohanohi]

Can you implement other types of encoding formats like dnxhd or photo-jpeg codec formats? photo-jpeg format will be useful for proxy editing workflow. And also a timecode and filename burn-in (overlay) in the final exported mov file?

[TKez]

I've been digging around more for getting the most out of our prores exports. Some info on DCP if you should ever find the time and interest!
Here's some correspondance from VisionColor

Is there a way to get or convert these LUTs to .cube format so they could be used with MLRawViewer to export MLV video as Prores4444 with visionLog profile?

thank you for reaching out to us! Unfortunately conventional 3D LUT formats can not hold the data neccessary to convert linear light RAW sensor data to VisionLOG. AFAIK, a more complex camera profile which has Hue/Sat deltas and an independent tone curve is required for such operations.
I guess that the MLRawViewer uses the embedded camera profile to convert the raw data to images at which point it is too late in the process to use a  LUT to extract more information from the image.
Essentially MLRawViewer would need an option to load external dcp profiles for proper conversion...

But then I though I remembered..

However, I don't know how to support DCP files, since those are a binary file format intended for Adobe products. So to use VisionLOG, or CineLOG, you would need to get "simple" LUT versions of those, or else help me find a spec for the DCP file format.

So incase you never could find it....

The developer has mentioned possibly supporting dcp profiles if he could get the spec.
Could you point us in the right direction?

Sure, you can download the DNG specification and SDK on Adobe's website which lays out the dcp profile structure which should be all your developer needs. Here's the link: http://helpx.adobe.com/photoshop/digital-negative.html

[Andy600]

@TequilaKez - FYI MLRawViewer does not use an embedded DNG profile. It uses or assigns a set of XYZ to Camera RGB color matrices (these were developed for each camera by Adobe Labs) and then applies a chromatically adapted transform matrix from XYZ to sRGB primary chromacities with a D65 white point (these should match DCRaw - but BTW, they are not 100% accurate) so, to cut a long story short, it is actually possible (but quite complicated) to get VisionLog out of MLRawViewer

VisionColor are correct in saying that a 3D cube lut does not hold enough code vales for the full lin-to-log transform but MLRawViewer has fairly useful 1D/3D lut support and this means the log and color components can be handled separately (this is important, especially if the color component is non-linear, as it is in any DCP with a HSV table).

It's not easy to parse the color values that are stored in a DCP (although we have a prototype script that can attempts to do this) BUT, assuming VisionColor's BMDFilm to VisionLog lut produces the same end result as their DCP, I'm pretty confident that we can build a lut for MLRawViewer because we now know precisely, the coordinates of BMD Film colorspace. I'm confident because we've been testing some MLRV versions of our own luts.

If VisionColor are ok with it, I'll look to include their Resolve version of VisionLog as part of a basic (free) Magic Lantern pack that we're putting together (I cant give an ETA). This will give you some basic but accurate transforms/transfers that you can use in MLRawViewer and a couple of the other open source apps that support luts.

edit: I should add that the above is only relevant when using MLRV to render video, not when using it to extract DNG files - that would require MLRV to fully support DNG profiles (dcp).

[TKez]

Thanks for the info Andy. I've been trying to read up a little on color space etc on Wikipedia but once I hit the lengthy transform equations it starts getting beyond the scope of 'need to know' for me. So tbh a lot of it goes over my head! I've just been working with mlv and Resolve and while dng has some nice advantages, for indie rec709 stuff, it seems to me that a prores workflow could be faster, more efficent for disk and cpu/gpu and more compatible with other apps and OSX (quick look). Ideally I would drag a folder of MLVs on mlrawviwer and it would spit out log encoded prores suitable for resolve with a single 3d output LUT. That could be a film stock LUT or plain old rec709.
I've just not had any lucky with the included log luts for mlvrawviewer, I think mainly because an additional input LUT seems to be required for the Output luts to make sense. So it ends up going thru 3 lossy luts and info appears to get lost or clipped along the way.
Apologies for any naiveity there, I'm still learning:) is this what prores from BMD cameras is?
Anyhow, your luts look equally promising for this application. I'd happily let go of a few bucks to realise this kind of workflow.!

[bluewater]

Hi, baldand

1.3.3 has some errors running on Windows 8.1. x64.
I think you only test it on WINDOWS 7.

I used 3 PCs using windows 8.1 x64 genuine.
EVERY 3 PCs showed the same results. (No starting)


I found some clue. I hope this will help.

Windows 8.1 Event viewer
SideBySide Error (even ID 35)

Can not make an activation context on "mlrawviewer_1_3_3\mlrawviewer.exe.Manifest" file.
There are errors in Manifest or 4th line on "mlrawviewer_1_3_3\mlrawviewer.exe.Manifest" policy file.
The Component ID in manifest is not identified with required ID.

Reference: Microsoft.VC90.MFC,provessorArchitecture="x86,publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"

Definition: Microsoft.VC90.MFC,provessorArchitecture="x86,publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.6161"

For more information use sxstrace.exe.


Thank you for you hard working.

[Andy600]

@TequilaKez - Log encoding is simply part of getting raw data into a smaller container (i.e. stored in a lower bit rate video file) so it's basically a form of compression. If it's done right you can reverse it to linear light without introducing any contouring (banding) and as nice side effect, a log image is more representative to how your eyes see light, and how film responds to light. Colorscience can indeed get very complex but you really don't need to know the fine points.

The numbered Log luts in MLRawViewer are based on very simple math and can be inverted to linear light easily, but they are not the easiest to work with. The other luts (Slog, LogC etc) are a bit more complicated because they assign (or should assign) very specific code values to the black, white and middle grey points. These luts can't simply be inverted (ok, technically they can but they will not look correct). They must be inverted and scaled (and may need a black point offset applied) so that a diffuse white reflector would have a floating point value of 1.0. This is what returns specular highlights to more realistic values (i.e. looks more like reality). A great many profiles don't do this so still you end up with a flat looking image, even when viewing in Rec709.

Technically speaking, Slog, LogC, Clog etc can not be represented in a single lut. There would be a separate one for each exposure (EI) or IRE value (set in the camera) and this is how Slog, LogC, Clog work in-camera. Each virtual lut is adjusted to compensate for the +/- gain of increasing/decreasing ISO. As this is not very practical the formulas used are based on the camera's native EI (in the case of LogC it is for EI800).

Part of the problem people may have in getting a good, workable log image comes from playing with the exposure slider. This can cause all kinds of issues because it is affecting the relationship between the log code values that are assigned to the black, white and middle gray values and this gets compounded further when the 'as shot ISO' is anything other than the chose EI value of the log formula - so basically try not to use the exposure slider.

As for getting MLRV to spit out log images that you can apply a 3D lut to, well yes, it already does that BUT the 3D lut itself must be based on the formula of whichever log profile you selected in MLRV. If it isn't, another lut will be needed to bridge the 2. We will provide a set of corrective 1D transfer luts for all the most useable of the options offered by MLRV, so that at least you'll be in the right ballpark and can use your other luts more effectively.

[baldand]

Hi, baldand

1.3.3 has some errors running on Windows 8.1. x64.
I think you only test it on WINDOWS 7.

I used 3 PCs using windows 8.1 x64 genuine.
EVERY 3 PCs showed the same results. (No starting)


I found some clue. I hope this will help.

Windows 8.1 Event viewer
SideBySide Error (even ID 35)

Can not make an activation context on "mlrawviewer_1_3_3\mlrawviewer.exe.Manifest" file.
There are errors in Manifest or 4th line on "mlrawviewer_1_3_3\mlrawviewer.exe.Manifest" policy file.
The Component ID in manifest is not identified with required ID.

Reference: Microsoft.VC90.MFC,provessorArchitecture="x86,publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"

Definition: Microsoft.VC90.MFC,provessorArchitecture="x86,publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.6161"

For more information use sxstrace.exe.


Thank you for you hard working.

I don't believe this is a generic win8.1 issue as I am building and testing on Win8.1 these days. I'm not an expert on Windows app issues, but it sounds like a kind of site app policy checking issue. It's anyway not something I'm able to reproduce or debug.

[togg]

I'm having a big issue.
When I convert to dng or watch my raw file taken with differents cards and differents resolutions in MlRawViewer 1.3.3 I get a lot of black/corrupted frame. If I convert the raw file with rawmagic everything goes fine. If I try to use 1.2.3 the conversion stop at the first black frame (I haven't tested with a corrupted one)

Here you can find two example, https://www.mediafire.com/?ukgavha2bqgtf5g one is taken from a video shooted a few days ago and the other from a test that I've done today while trying to understand the whole stuff.



What could be the problem? 


My specs:

MacBook Pro Retina, Mid 2012
2,3 GHz Intel Core i7
8 GB 1600 MHz DDR3
NVIDIA GeForce GT 650M 1024 MB
OS X 10.9.5 (13F34)

[baldand]

I'm having a big issue.
When I convert to dng or watch my raw file taken with differents cards and differents resolutions in MlRawViewer 1.3.3 I get a lot of black/corrupted frame. If I convert the raw file with rawmagic everything goes fine. If I try to use 1.2.3 the conversion stop at the first black frame (I haven't tested with a corrupted one)

Here you can find two example, https://www.mediafire.com/?ukgavha2bqgtf5g one is taken from a video shooted a few days ago and the other from a test that I've done today while trying to understand the whole stuff.

What could be the problem? 

My specs:

I checked the black frame DNG, and there is nothing wrong with it. Apart from being black.

MlRawViewer should insert black frames when it thinks there is a frame missing from the original file (to keep audio sync correct).

The question here for me is whether MlRawViewer is making a mistake, and not finding a frame that is there in the file, or if other tools are just masking missing frames in a different way, e.g. skipping them or duplicating previous frames. But I can't answer that without having the original raw file to check.

[togg]

I had think of that and checked if rawmagic just duplicate a frame but no. And sadly the corrupted one is there to prove the problem
But I knew you would need a raw file, it will take a little bit to upload it since it needs to be one minute long.

[DeafEyeJedi]

I ran into a similar situation regarding a black frame would pop out of nowhere on some of my .Mov exports whereas I know from the original raw file that there is no missing frames. I ran it twice or three times and I think the black frame would pop up in different timeframe in each export.

Hope this makes sense... But then again sometimes I won't get them.

Will do some more troubleshooting at work today in order to confirm this.