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

[Kabz]

Seeing Apple Prores 444 on my 5D3 clips is great -- the latitude in color grading is amazing.

I'm going back to read through this whole thread, wanted to say thank you to Baldand.

Quick dumb question: Is there any loss/compression in going to MOV vs DNG? Also is the live color grading in the program just for reference, or are people applying LUTS on the clips before color grading further?

Again, going to read through the read unless someone would like to enlighten me. Thank you.

edited for spelling

[kgv5]

Everything fine now with LUTs, thanks

[baldand]

Is there any loss/compression in going to MOV vs DNG? Also is the live color grading in the program just for reference, or are people applying LUTS on the clips before color grading further?

ProRes is 10bit, so some of the original data has been lost in conversion. If you want to grade in e.g. Resolve. You should use DNG, no question about that.

I see 2 cases for LUTs in MLRV.
1. Quick review of takes, e.g. on set using a LUT matching the final intended style. Proper grading done later with DNG in Resolve.
2. Faster workflow with simple grading e.g. with commercial LUTs like Osiris. Only editing done later with ProRes.

Probably MLRV needs still more grading features before 2 is really viable though.

[swinxx]

as i try to work with dngs and resolve 11, i can report some struggles with ofx plugins and dng sequences.. those sequences might be so cpu and gpu hungry that my machine crashes all the time when using neat video in conjunction with dng files and some colorgrading nodes (incl power windows, alpha mattes, ect..) - i have to mention that my machine is a really strong one, and i work with a raid system and 12 -> 6 TB Video drive

so i tried different workflows and they are all not ideal at the moment, cause of the wrong primary color profiling of ml raw material.. (this will be a problem until some of the major companies start to support the Canon Raw Sensor Output of those cameras (eg. 5dMK3 - which could be  seen as best option for ml raw filmers at the moment)
when using resolve we are forced to use profiles like bmd4k or bmd, rec709, ect. and they are not working very well with all the different luts cause the colors don´t look right..

i think what the real benefit of a mlrawvierwer lut workflow could be is: porting the ml raw material to a common colorspace (perhaps with the new cinelog-c profiles) and convert the material to the best prores format for later editing and color grading with e.g. resolve 11. this could be the most resource friendly workflow and much faster than working with the dngs.. and i write those lines althought i only tried to work with the original dngs for now..
we will see.

[escho]

Hi

I just builded this program from source, using OpenSuse 13.1. I gave it a short try. Looks great!

There are some small points, I noticed for the beginning:

Building failed, because the python-headers are not installed per default in OpenSuse. The needed package is "python-devel".
Building failed, because tk not installed per default in OpenSuse. The needed package is "python-tk".

A little advice in your installing notes would be good, I guess.

Then I started mlrawviewer.

Code Select Expand

edgar@linux-indh:~/mlrawviewer> ./mlrawviewer.py
MlRawViewer v1.2.3
(c) Andrew Baldwin & contributors 2013-2014
pyAudio not available. Cannot play audio
Using GLUT instead of GLFW. Some features may be disabled.

It tells me, that audio playback in not possibe. I searched for pyAudio. This is not in the offical rpm-sources for OpenSuse. I found it in the unstable packages from OpenSuse build-service. I didn´t try to install it, because I don´t need it.

"Using GLUT instead of GLFW. Some features may be disabled." What features are these, which are disabled?

Edgar

[ToS_Maverick]

so i tried different workflows and they are all not ideal at the moment, cause of the wrong primary color profiling of ml raw material.. (this will be a problem until some of the major companies start to support the Canon Raw Sensor Output of those cameras (eg. 5dMK3 - which could be  seen as best option for ml raw filmers at the moment)
when using resolve we are forced to use profiles like bmd4k or bmd, rec709, ect. and they are not working very well with all the different luts cause the colors don´t look right..

Hi swinxx,

do you happen to have a ColorChecker chard available?
If you import cDNGs in Resolve, use BMDFilm and then use the "Color Match" function, you will get correct colors!
https://www.blackmagicdesign.com/products/davinciresolve/color

This also works with Log8 footage. BMDFilm seems to be really close to Log8, therefore this works with ProRes footage as well. I tested this and got 99 % identical results!

BTW, there's something going on behind-the-scenes as well
https://bitbucket.org/baldand/mlrawviewer/commits/406eaabb69134fd2a9189971187c7063f0a67825

[baldand]

"Using GLUT instead of GLFW. Some features may be disabled." What features are these, which are disabled?

I don't use GLUT myself any more so I can't say for sure how well it will work today. But I know that there are problems with the export process.

I would recommend you build the GLFW 3.1 shared library from git:

git clone https://github.com/glfw/glfw
cd glfw
mkdir build
cd build
cmake ..
vi CMakeCache.txt
change this line:BUILD_SHARED_LIBS:BOOL=ON
make
cp src\libglfw.so.3.1 ..\mlrawviewer\libglfw.so.3

[Andy600]

@Baldand - I haven't had a chance to properly look at the source code but have a quick question: We have a couple of Cinelog users who want to use our luts with MLRawViewer. The gamma component part is easy but what primaries does it output as default? sRGB/Rec709?

Also, I just had a look at the bits you are working on (Slog/Slog2 etc). We did a lot of work to find an idealized log gamma for MLV for output to 10bit ProRes/DNxHD using the math from Arri, Sony, Canon etc and anything above Cineon log (~13.5 f-Stops) tends to degrade the image when linearized. It's not apparent in every shot so it might not be obvious without shooting a lot of test charts, a backlit DSC Xyla DR chart etc.

For MLV, Slog and Log-C are basically wasting a lot of space. Also, they tend work best when paired with their associated gamut (i.e. Log-C with Alexa Wide Gamut RGB, S-Log with S-Gamut, Canon C-Log Wide Gamut) and always require a transform lut unless the colorist really knows what they are doing. BMD Film 4k (gamma) is close to ideal for MLV and you should be able to derive the transfer function from the BMD luts that come with Resolve.

@Tos_Maverick - BMD Film is (afaik) a proprietary, non-linear colorspace with no published information on how to get to and from it. Until Blackmagic release this info (they have no plans to do so) you will never get 100% accurate color, although it does still look nice (film-like) to a lot of users. The new Resolve Color Match tool requires you to know 100% what colorspace and gamma the source footage is and, even when this is known, it will only get you closer to photometric color and TBH this is nearly always best done manually with scopes. It currently falls apart with anything when trying to match the DSC One Shot chart (even Alexa, Red, F55 etc) and never gives uniform results with MacBeth charts. It's a nice idea but it's not quite there yet - use with extreme caution.

[baldand]

@Baldand - I haven't had a chance to properly look at the source code but have a quick question: We have a couple of Cinelog users who want to use our luts with MLRawViewer. The gamma component part is easy but what primaries does it output as default? sRGB/Rec709?

For now everything is converted to standard sRGB/Rec709 primaries. The camera->XYZ matrix is combined with an XYZ->sRGB matrix to do this. With appropriate matrices, other primaries could be supported - I'm open to suggestions or contributions.

Also, I just had a look at the bits you are working on (Slog/Slog2 etc). We did a lot of work to find an idealized log gamma for MLV for output to 10bit ProRes/DNxHD using the math from Arri, Sony, Canon etc and anything above Cineon log (~13.5 f-Stops) tends to degrade the image when linearized. It's not apparent in every shot so it might not be obvious without shooting a lot of test charts, a backlit DSC Xyla DR chart etc.

For MLV, Slog and Log-C are basically wasting a lot of space. Also, they tend work best when paired with their associated gamut (i.e. Log-C with Alexa Wide Gamut RGB, S-Log with S-Gamut, Canon C-Log Wide Gamut) and always require a transform lut unless the colorist really knows what they are doing. BMD Film 4k (gamma) is close to ideal for MLV and you should be able to derive the transfer function from the BMD luts that come with Resolve.

The internal 1D->3D->1D LUT stack is all done with full floating point maths, so there shouldn't be any degradation (apart from due to the low res of 3D LUTs) until the final bake down to 10bit ProRes.

With what is there now in MlRawViewer, do you see it possible for the first 1D LUT to be a Linear->Cinelog conversion you could produce, or would you need some additional colour space changes at that stage?

[ToS_Maverick]

Also, I just had a look at the bits you are working on (Slog/Slog2 etc). We did a lot of work to find an idealized log gamma for MLV for output to 10bit ProRes/DNxHD using the math from Arri, Sony, Canon etc and anything above Cineon log (~13.5 f-Stops) tends to degrade the image when linearized. It's not apparent in every shot so it might not be obvious without shooting a lot of test charts, a backlit DSC Xyla DR chart etc.

For MLV, Slog and Log-C are basically wasting a lot of space. Also, they tend work best when paired with their associated gamut (i.e. Log-C with Alexa Wide Gamut RGB, S-Log with S-Gamut, Canon C-Log Wide Gamut) and always require a transform lut unless the colorist really knows what they are doing. BMD Film 4k (gamma) is close to ideal for MLV and you should be able to derive the transfer function from the BMD luts that come with Resolve.

Hi Andy, thanks for chiming in!

We are aware that S-Log and Log-C cover a huge DR spectrum. S-Log2, with the DR from a 5D for example only covers 75 % of the resulting 10 bit range.
That's because of the huge range above middle gray. When the 5D3 clips, there's still 2-3 stops of additional space in S-Log2.
I think it's still useful for compatibility.

@Tos_Maverick - BMD Film is (afaik) a proprietary, non-linear colorspace with no published information on how to get to and from it. Until Blackmagic release this info (they have no plans to do so) you will never get 100% accurate color, although it does still look nice (film-like) to a lot of users. The new Resolve Color Match tool requires you to know 100% what colorspace and gamma the source footage is and, even when this is known, it will only get you closer to photometric color and TBH this is nearly always best done manually with scopes. It currently falls apart with anything when trying to match the DSC One Shot chart (even Alexa, Red, F55 etc) and never gives uniform results with MacBeth charts. It's a nice idea but it's not quite there yet - use with extreme caution.

Coming back to what's the optimal DR for our cameras or the MLV format. The log curve that hit's middle gray perfectly and uses the space most efficiently is IMHO the 8 stop variant.
I don't know what BlackMagic is doing, but they seem to have come to a similar conclusion.

Look at what Color Match has to say, when you feed it with our Log8 ProRes input:



That's not an exact science for sure, but it seems to work and you can transform it to various other gammas as well.

[Andy600]

Thanks for the primaries info. That makes it easy

We are currently building OCIO configs for the Cinelog luts and moved a lot of the transforms to FP but that's only half the problem. When the image is then transcoded to a log space in a 10bit video container, the DR of the sensor has to be taken into account or you are effectively compressing non-existent information (usually where over bright highlights reside). If the transfer is to Slog, Log-C etc this can be several f-stops of wasted space because those curves are developed for handling much greater DR than Canon DSLR's are capable of. A simple, scaled log function would be the obvious solution but then you you need to factor in where the measured black and white points 'should' be to be able to target a deliverable colorspace accurately. Cineon log, BMD Film/4K gamma does this well for MLV.

I can't see any problem in getting MLRawViewer to output Cinelog-C. I'll have a better look at it this week and see what happens. It can be fully floating point or lut based.

Cinelog-C, as is currently available for Resolve, is basically a high precision shaper lut with a BMD Film to Cineon log 1D component and a non-linear 3D BMD Film to Cinelog colorspace component. The 3D part is only usable with Resolve as it requires the footage to be debayered in BMD Film colorspace first, which is (afaik) something like, but not exactly, Cinema DNG ACES. This caused us big problems with targeting Cinelog-C in anything other than DaVinci Resolve so we have now defined a new linear matrix and log transform (either as a lut or formula) that can be used in OCIO and just about any other app if we know or can define the source colorspace. Resolve is still causing us a minor headache when we use it with debayering set to REC709/Linear but we've nearly overcome this and should have a unified release very soon. In keeping with OICO licensing, the basic Cinelog-C OCIO config, spid1d and spimtx files will be free to use. If my limited coding is up to task I'll try and compile a version of MLRawViewer with basic Cinelog functions and see if it does what I think it can do.

[baldand]

...I'll try and compile a version of MLRawViewer with basic Cinelog functions and see if it does what I think it can do.

In case you need to change the primaries, look for updateColourMatrix in Viewer.py and change the XYZtosRGB matrix.

When you have something you like, we can work out a way to make that a parameter, or something loaded from a file. One possibility would be to embed it in a special comment in a .cube file containing the 1D LUT so that everything needed would be in one file owned by you.

[Andy600]

@ToSMaverick - If you are working raw-to-deliverable in a floating point environment it makes very little difference with whatever logspace you use. The kicker is when you want render an intermediate video file for editing in another NLE or for archiving. If you waste any of the 10bits through using a more aggressive log curve than is required for the useable DR of the sensor you risk image degradation beyond whatever downsampling to 10bit introduces by default. Dan Newman from GoPro was correct to point this out in a previous ML post regarding ProTune. Canon DSLR's simply do not need the extra headroom offered by Slog, Log-C etc and it is much better for image quality (and grading) to use an optimized log curve. The Cineon Log curve is a little more than is actually needed for MLV but it has a lot of benefits and is easily transferable. With all that said, we are all still assuming the DxO figures for the various Canon DSLR raw dynamic ranges to be accurate.

I haven't had a proper look at MLRawViewer yet so my apologies for making assumptions. The 8 stop variant may appear close to BMD Film gamma but unless it is actually identical, transferring it, (assuming it is BMD film gamma) to any other predefined logspace will introduce +/- variance to the power of the target gamma and will not be the same as a direct transfer from linear raw to the target logspace. It's not a big deal for casual users but can be for VFX. If the 8 Stop variant has a linearization lut available you would first apply that then target another gamma.

[Andy600]

@Baldand - Thanks for the heads-up. I'll have a good look at it when I get back to work tomorrow

[dknechtg]

Hello,
  I'm on Win7.  A few months back I was able to build MLRawviewer v.1.1.3 and use it successfully.  I recently downloaded and tried the executable for v1.2.3 from the Bitbucket repository.  Unfortunately, it crashes after selecting a .RAW file.  It seems the build environment has changed enough where I am no longer able to compile the newer versions, either.   I did some regression testing and found that, starting with V1.1.6, the prebuilt versions all crash with similar traces listed in the logfiles.  Here is an example:

Code Select Expand

MlRawViewer v1.2.3
(c) Andrew Baldwin & contributors 2013-2014
Using GLFW
Traceback (most recent call last):
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\GLComputeGLFW", line 304, in __draw
  File "<string>", line 1100, in onDraw
  File "<string>", line 1083, in init
  File "<string>", line 337, in __init__
  File "<string>", line 145, in __init__
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\ShaderPreprocess", line 177, in __init__
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\GLCompute", line 92, in __init__
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\OpenGL.latebind", line 61, in __call__
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\OpenGL.GL.VERSION.GL_2_0", line 230, in glGetAttribLocation
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\OpenGL.error", line 208, in glCheckError
GLError: GLError(
err = 1282,
description = 'invalid operation',
baseOperation = glGetAttribLocation,
cArguments = (6, 'vertex\x00'),
result = -1
)
Traceback (most recent call last):
  File "<string>", line 2306, in <module>
  File "<string>", line 2300, in main
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\GLComputeGLFW", line 247, in run
  File "c:\Projects\MRV\build\mlrawviewer_win\out00-PYZ.pyz\GLComputeGLFW", line 336, in __idle
  File "<string>", line 1560, in onIdle
AttributeError: 'NoneType' object has no attribute 'isDirty'

  I appreciate the developer's work on such a useful program.  I have been following its development for some time.  Perhaps I am experiencing an issue with hardware support--I am running with an Intel graphics GPU.  Maybe this is an easy problem to solve--I don't have much experience with OpenGL or Python so it's hard for me to know.  If anyone can point me in the right direction, I would be very thankful.

[baldand]

I did some regression testing and found that, starting with V1.1.6, the prebuilt versions all crash with similar traces listed in the logfiles. ...

Thanks for taking the time to find the version where this started. The next thing to do would be for you to post all the details as a new issue on bitbucket, then I can ask for more info or inform you of the status.

When you do that, please give all details you can about your GPU - e.g. which exact model of Intel GPU, and which CPU model you have. Also, please make sure you have the newest possible graphics drivers for it that you can find.

https://bitbucket.org/baldand/mlrawviewer/issues?status=new&status=open

[dknechtg]

Please disregard the above issue.  The recommendation to update the display drivers worked.  Thank you very much, baldand, for the quick and effective response.   

[kgv5]

ProRes is 10bit, so some of the original data has been lost in conversion. If you want to grade in e.g. Resolve. You should use DNG, no question about that.

Are you sure that Proress 4444 isn't 12 bit?
https://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf
(see page nr 9) According to this prores white paper ProRes 4444 "support image sources up to 12 bits and preserve alpha sample depths up to 16 bits. All Apple ProRes 422 codecs support up to 10-bit image source".

[baldand]

Are you sure that Proress 4444 isn't 12 bit?
https://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf
(see page nr 9) According to this prores white paper ProRes 4444 "support image sources up to 12 bits and preserve alpha sample depths up to 16 bits. All Apple ProRes 422 codecs support up to 10-bit image source".

The ProRes encoder in ffmpeg (which MlRawViewer uses) only supports 10 bit 444 data.

[kgv5]

Ahh ok, thanks for clarification

[pettermannen]

Hi! Been working with MlvViewer for some time. Thanks developers for your work! I´ve been having problems with highlights especially with green. Have now version 1.2.3 I provide a link below to a sample picture, a screen shot from MLVviewer. https://www.dropbox.com/s/b7xjr6kb08rt67y/Sk%C3%A4rmdump%202014-09-02%2021.24.37.png?dl=0
Best Regards Petter

[escho]

I don't use GLUT myself any more so I can't say for sure how well it will work today. But I know that there are problems with the export process.

I would recommend you build the GLFW 3.1 shared library from git:

git clone https://github.com/glfw/glfw
cd glfw
mkdir build
cd build
cmake ..
vi CMakeCache.txt
change this line:BUILD_SHARED_LIBS:BOOL=ON
make
cp src\libglfw.so.3.1 ..\mlrawviewer\libglfw.so.3

Thanks. Will try this, if I run in troubles

Edgar

[pettermannen]

Forgot! I use A 5d mark III with ML for 1.1.3 firmware and a build from the 20th of may.
The pink artifacts are not there if I look at DNG´s from mlvmystic.

Best regards

[swinxx]

@baland
After experimenting a little bit with some material and some conversion luts i found out that most of them make noise visible a lot more. So being able to denoise the material before applying an input lut would be the best choice. As denoising handle some very complex algorithms it would be best to use such tools.
Within the OFX plugin frame there are some great tools available such as neat video for example. Do you think that it would be possible that this ofx plugin is available for mlrawviewer at some stage of further development. To be efficient it must process the image before the first lut is applied
I have no idea if it would be possible and how complex it is to implement that beast, but apparently you implemented lut support with ease i am really optimistic

Thank you. Greets re

[eyeoftheabyss]

Hey baldand, thank you for creating MlRawViewer. Unfortunately, I've only been able to open the program once on my macbook (OS X Maverick), and since then, it crashes before it opens, meaning, the icon is on the dock as if it's open, but it's not open. I've tried an older version too, the 1.2.2.

Also, I assume it'll work, so I'd like to ask this question now: Does it convert RAW and/or mlv files to cdng? And if it's an mlv file, will it create an audio file?

I've been having trouble with all the other free converters I scan find and none are creating cdng files that can be imported into Premiere without AE.

Thank you