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

[baldand]

Hi @baldand et al

I'm a regular user of the Cineform codec. Would it be a massive complication to add this to the export options some time?

Many thanks for your continued great work.

I had a quick look at this and I'm not sure it would make sense. Easiest approach would be call the existing "raw2gpcf" convertor elsewhere on the forums, but, that would require first converting the file entirely into a .RAW file on disk. Since, for MLVs, that can be done now using mlv_dump, I'm not really sure what value MlRawViewer would be bringing other than a little bit of convenience.

It would be a different story if Cineform would be an (open, documented) "standard" codec, supported already by ffmpeg.

[baldand]

I have a few questions regarding the default exposure of the log curve.

...(lots of good analysis here)...

Hi Michael,

My goal with the log curve was simply to have a reversible mapping function which prevents some of the detail in the darker areas being lost during the reduction from 14bits to 10bits that happens when encoding to ProRes. In theory, the data could be linearised afterwards with a matching inverse function. However, I haven't made such an inverse function (e.g. in a LUT file) to do this, so it's still just a theory.

It would be possible to change the existing log implementation, or add new ones, or add LUT support so that this could be made part of a tested workflow. But I would probably need some help with in terms of requirements, code contribution and testing.

[baldand]

I think the problem is the mov convertion of mlrawviewer. Recently used raw2cdng and process in after effects. exported to mov prores and the problem is not present.

https://www.dropbox.com/s/yrdap681f7smiap/M02-1703_000001_DNG.rar

I had a look at your data. I don't think there is anything functionally wrong here. It's all working as expected.

You are applying the log curve, which compresses the data in all regions of the brightness curve. The sky gradient is already very shallow, and then you convert from the original 14bit source, to 10bit ProRes. That combination of shallow gradient + log curve + 14->10 bit is where the banding is introduced.
Finally you apply a strong post processing curve which expands the colour range in the sky area you just compressed, so the banding becomes visible.

The solution here, for now, is to do the colour grading with the full 14bit range, e.g. with a tool that works with the DNGs.

(In the future, if MlRawViewer would gain LUT support, you might be able to apply your LUT to the original data with no quantising).

[swinxx]

I think the most important feature is gpu support, vertical stripes correction, in out points and cdng or dng export, perhaps 16 bit conversion like rawmagic provides and toolbox description of the different symbols. Great program. Thank you

[swinxx]

Baland, i really like the idea to drag and drop multiple files to the batch process (rawmagic). Is this also working within mlrawviewer?  Cause for my understanding, you put all the files to the batch process one by one..
What i mean is:
Drag and drop to a queue, then all files are in a list where i can select e.g. Video1, set my in and out points, then video2,... Then select output format globally and the directory. Then convert button and voila.. That would be a great addition.

[baldand]

Baland, i really like the idea to drag and drop multiple files to the batch process (rawmagic). Is this also working within mlrawviewer?  Cause for my understanding, you put all the files to the batch process one by one..
What i mean is:
Drag and drop to a queue, then all files are in a list where i can select e.g. Video1, set my in and out points, then video2,... Then select output format globally and the directory. Then convert button and voila.. That would be a great addition.

@swinxx have you tried the "magic export" key "C"?

That adds all files in the same directory as the currently-viewed file to the export queue using the current settings.

So, to get almost the same results as you want, you would just drag one of the files to the viewer, choose the white balance, then press C.

(The current limitation is that you can't edit the in/out points of entries already in the export queue).

[swinxx]

Magic C!! Great. So do you think it would be possible to implement in out points to that queue?

[MA Visuals]

@baldand I have been revisting importing the cDNG files that MlRawViewer creates using the new version of Premiere CC 2014.  Since the last time I tried this, the experience seems much better than before.  There still remains some magenta highlight issues but there is a workaround for this (using the Video Limiter effect).   Also, it seems that finally, Adobe has acknowledged the pink highlights issue and are actively working a on a fix... see the Adobe forum thread here... https://forums.adobe.com/thread/1500841.

In the new Premiere, the new source settings window does give as least some level of control for exposure, while balance, tint.  It's really great that the white balance set in MLRawViewer carries over pretty accurately in the cDNG files imported into Premiere.  I have read in a few places that Premiere appears to by applying rec.709 upon import of the cDNG files (shame that is doesn't allow selection of a LOG space upon import). 

I'm now trying to figure out the best way to retain the full 14-bit information in Premiere so I ran a few tests.   I purposely significantly overexposed a clip via the new source settings window in Premiere.  I then proceeded to try to bring back the highlight info as much as possible using Colorista II repeated this test using the new Speedgrade CC 2014.  Colorista could not retrieve much of the overexposed information but Speedgrade was able to recover dramatically much more of the highlight info.   I am guessing that Speedgrade is accessing the full 14 bits while Colorista may be limited by a the rec.709 imposed by Premiere upon import.  Here's a video test someone recently performed on Speedgrade which claims that Speedgrade is able to access the full 14 bits of information.... https://www.youtube.com/watch?v=0LFwNs6BDNg.  Since Premiere now has the Lumetri LUT effect which utilizes the Speedgrade engine, it seems like the best option for maximizing the full 14bit of information would be to first apply a LOG-like LUT using Lumetri effect on all cDNG clips imported into Premiere. Then I would use Colorista for the rest of my grading.  I think what we need now is a good LUT for convert ML Raw to LOG.

I was just curious to know your thoughts about all this with regards to using a cDNG workflow.

[hdclip]

Hi Baldand!!!!maybe a Histogram or something like that to view the real exposure?

[Gerrit]

Thank you Baldand. The Viewer is a very, very good tool.

Like my predecessor, I think a histogram and the whitebalance displayed in Kelvin would be a very good next step.
Without the color and exposure is always a little sloppy and sometimes off.
With exact control over these parameters a conversion to DNG would be obsolete in most productions
and you could go straight to editing with the log-gamma-applied-10 bit-almost-linear .movs.

That would be so great

[aace]

Thank you Baldand. The Viewer is a very, very good tool.

Like my predecessor, I think a histogram and the whitebalance displayed in Kelvin would be a very good next step.
Without the color and exposure is always a little sloppy and sometimes off.
With exact control over these parameters a conversion to DNG would be obsolete in most productions
and you could go straight to editing with the log-gamma-applied-10 bit-almost-linear .movs.

That would be so great

If you want to have a feature added submit the request here: https://bitbucket.org/baldand/mlrawviewer/issues?status=new&status=open

[Jbowdach]

Has anyone tested how the log converted prores files react when converted to VISIONLOG\ Cinelog? Im curious if we are still able to use that workflow for grading if we convert toREC709 or LOG Prores in the viewer (as that would save LOTs of space), then convert to standardize VISIONlog, and hand grade or add OSIRIS\Impulz LUTs as desired?

Anyone had success with that?

[ToS_Maverick]

Hi Michael,

My goal with the log curve was simply to have a reversible mapping function which prevents some of the detail in the darker areas being lost during the reduction from 14bits to 10bits that happens when encoding to ProRes. In theory, the data could be linearised afterwards with a matching inverse function. However, I haven't made such an inverse function (e.g. in a LUT file) to do this, so it's still just a theory.

It would be possible to change the existing log implementation, or add new ones, or add LUT support so that this could be made part of a tested workflow. But I would probably need some help with in terms of requirements, code contribution and testing.

Hi Andrew,

thank you for your kind reply!

Could you get back to me regarding the default exposure compensation in log mode?
It would be really helpful to have it preset so that 18 % grey is at 40 IRE without adjusting

At the moment I have to press 13 times the UP key, which should be a factor of 3,45 if my math is correct (1 press = 1.1 times increase, right?).

The appropriate curve would look like that:

Has anyone tested how the log converted prores files react when converted to VISIONLOG\ Cinelog? Im curious if we are still able to use that workflow for grading if we convert toREC709 or LOG Prores in the viewer (as that would save LOTs of space), then convert to standardize VISIONlog, and hand grade or add OSIRIS\Impulz LUTs as desired?

Anyone had success with that?

We will be shooting a short movie where we will be going RAW => ProRes w/log curve => Edit => Color grade.
I'd like to keep things simple and still retain most of the quality. So far this workflow super easy once you are in ProRes and the quality due to the log space is amazing.
Also the color matrix seems to be really good! A liberation compared to the builtin H264 video

Why would you go from Andrew's log implementation to Cinelog? Is it really that different?

[arrinkiiii]

I think already some one talk about this but im having pink dot's in the highlight, probably in the overexpose areas. Even if i press 0 (zero) don't solve the problem. Recording directly to the sun it gives me a circle, if i down the brightness in MlRamViewer 1.1.6. If i upper the brightness this pink stuff disappear.

It's not also good to have something saying in the screen of the app the state (on or off) wend you press 0 (zero)? 

Sorry if im saying some dumb stuff here or if this already have been discuss but any help would be cool =)

Canon 7D

 

[rungunshoot]

Hi, my ProRes conversion is very slow.  Probably 3-4 fps.  Is that normal, or is there something I'm not doing here?  I'm running v1.16 and converting 5dmkIII 1920x818 24fps footage on a Macbook Pro Retina with 16GB Ram.  Recording to internal SSD, so there shouldn't be a bus or read/write speed issue.

I get realtime transcoding from DNG with Resolve, so the issue must be the program.

Should I be expecting faster transcoding, or is this as good as it gets?

[baldand]

Hi, my ProRes conversion is very slow.  Probably 3-4 fps.  Is that normal, or is there something I'm not doing here?  I'm running v1.16 and converting 5dmkIII 1920x818 24fps footage on a Macbook Pro Retina with 16GB Ram.  Recording to internal SSD, so there shouldn't be a bus or read/write speed issue.

I get realtime transcoding from DNG with Resolve, so the issue must be the program.

Should I be expecting faster transcoding, or is this as good as it gets?

ProRes conversion using the high quality AMaZE demosaicer which is CPU instead of GPU based. It does a very good job at recovering detail and reducing aliasing on shots with no aliasing filter (e.g. anything other than 3x crop or 5d3). But that's as fast as it goes I'm afraid.

Unfortunately I don't have a high quality GPU-based demosaicer yet.

[FBongcam]

Hi,

First of all, great application and a great concept!

Sorry if this has been mentioned or asked before but does MlRawViewer correct the vertical stripes? I couldn't find any info about in the feature list.

Thanks,
Filip

[arrinkiiii]

It can, if you press 0 (zero)  but this method it's only with an algorithm that baldand made ( i think). For better removing the vertical strips you need to upload a dark clip... hope baldand integrate this option in the app =)

Read the manual of the app.

[baldand]

Sorry if this has been mentioned or asked before but does MlRawViewer correct the vertical stripes?...

Some more notes on the stripe removal:

- Press zero key to turn the correction on or off. There will be an icon for this in later versions.
- When enabled, it will be applied for playback, DNG and MOV exporting.
- It's mostly tested & optimised for 7D low ISO stripes. It might be less effective for other models such as 5d3.

@arrinkiiii I think dark frames cannot help 7D vertical stripes because the pattern changes during a few frames. The current algorithm re-measures the stripe pattern for *every* frame, so it can correct for this change.

[arrinkiiii]

There will be an icon for this in later versions.

That will be nice =)

@arrinkiiii I think dark frames cannot help 7D vertical stripes because the pattern changes during a few frames. The current algorithm re-measures the stripe pattern for *every* frame, so it can correct for this change.

That is good, that the algorithm re-measures the stripe pattern in each frame =)  I think each camera got there noise stripes, wend i say for upload a dark frame is like 5 or 10 seconds of video, the patern change but maybe after 5 or 10 seconds is the same. Wth this we can change the ISO and shutter speed and have a more correct subtract noise stripes maybe is not enough, maybe what im saying don't make sense but would like to try =) 

Anyway's, thanks for this tool, amazing!!! Good quality and easy to work... next update will be even better =D Hope be soon =))

[timbytheriver]

Hi @Baldand

I'm suddenly experiencing a bug where thin magenta vertical lines appear on the viewer (see pic below) whenever I click on a GUI icon, which then subsequently appear on the render. Have tried both 1.1.5 and 1.1.6 and they are both doing it. Is this a known bug to yourself or anyone else?

Thanks again.

Tim

Mac OSX 10.7.5
5D MK2

[Midphase]

I'm suddenly experiencing a bug where thin magenta vertical lines appear on the viewer (see pic below) whenever I click on a GUI icon, which then subsequently appear on the render.

Did MLRawViewer always do this or was it working just fine a few days ago? I have to wonder if it has anything to do with the OS you're using, but obviously not if it was working just fine a few days ago.

[timbytheriver]

Hi @Midphase

Fair call, but it's been working fine up 'til about a week ago! 

[baldand]

I'm suddenly experiencing a bug where thin magenta vertical lines appear on the viewer (see pic below) whenever I click on a GUI icon, which then subsequently appear on the render. Have tried both 1.1.5 and 1.1.6 and they are both doing it. Is this a known bug to yourself or anyone else?

I haven't see anything quite like that before.

If you resize the window do you still see the lines?
Did you change any camera recording settings recently, for instance the frame size?
Do all files - old ones that have worked ok earlier - and new ones have the same problem?

[nick.p]

Hi @Midphase

Fair call, but it's been working fine up 'til about a week ago! 

If I had to have a wild guess, I'd say your gpu is on the way out