MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

[vstrglv]

@vstrglv: can't help with compiler.app, but what was the problem on Windows? Which Qt version did you use? What compiler did you use?

Sorry for delay. I have tried to compile MLVApp on Mac and Windows.
I have installed macOSMojave10.14.6 and Qt5.12.10  through VirtualBox-6.1.38. After several attempts i have gotten MLVApp.dmg.
Then i tried to compile on Windows 11. Also Qt5.12.10. Compiled MLVApp.exe requests some dlls. Windeployqt helps to add several dlls to MLVApp.exe folder, but not all requested. After adding manually dlls (the whole number is 9) plus "platforms"folder with  qwindows.dll MLVApp.exe works. I have tried to compile MLVApp.exe with dlls inside exe many times but failed. At last i've red your masc post:

Static: uses static Qt libraries compiled into the exe. Crosscompiled from bouncyballs linux OS
Dynamic: uses dynamic Qt libraries, dll files. Compiled from my windows OS

I downloaded  MLV.App.v1.14.Win64.dynamic.zip, opened it and saw that there were more files and folders than in my case. I deleted additional files and folder (which were missing in my compilation) but MLVApp.exe works.
What is the reason for this additional files and folders?

[masc]

Yay. Congrats @vstrglv! Fine.
If you got MLVApp.dmg, it means you also used macdeployqt? windeployqt is more or less the same for Windows.
Why the folders and files: _deployqt scanns the app and searches+provides all used libraries. For the GUI functionality, we did not reinvent the world, but we used the Qt development system. This is like a puzzle. And the parts of the puzzle are in the .dlls on Win or .dylibs on macOS. The app can't work without this. When using our .dlls, take care: the app will not be stable, if you used another Qt version. The compiled app must get the libraries from the Qt used for compiling. With some luck it might work here and there, but I would not guaranty. You should find all the files I used in your Qt and minGW folder - with those you should be fine.

[vstrglv]

Thank you masc! I have deleted MLVApp.dmg already, so don't remember about using windeployqt. But I guess I did not use it. I have tried Qt 5.13.2 and 5.14.2 also. It works. I added 9 DLLs plus "platforms"folder with  qwindows.dll manually. The only problem was to find libgomp-1.dll. It was absent in Qt 5.14.2 folder
Sorry found out. C:\Qt\Qt5.14.2\Tools\mingw730_64\x86_64-w64-mingw32\lib

[togg]

I'm using MLVapp for a shooting this week and loving it as always. I was wondering is there a preset that doesn't apply the hidden +2 exposure that the software gives? Also is the transfer function only affecting the gamma part of the preset right? There are more hidden numbers about colours I guess. I'm not sure I get it right.

edit: a bug, the installed bad pixel map visually shifts place if you load it again, it fixes itself as soon as you place another correction. Also how can I export it?

[masc]

@togg: maybe Ilia can tell something about this. I remember, in the very old days there was this "cheat factor", if it still exists today - no idea. The transfer function includes the gamma and more maths.

Could you explain more about this bug? Sry, I really did not understand what you mean exactly. Could you please describe how to reproduce?

[ilia3101]

Yeah I thought MLV App has an exposure factor of +1 or 2 by default. But I couldn't find it in the code just now, so I don't know anymore, could it be in the interface??

Why do you feel a need to undo this 'hidden exposure'? You could undo this gain by setting exposure to -1 or whatever, but... there's also white balance, which in itself increases blue and red by about +1, is that not hidden exposure?... do you want to undo that? What's your definition of 'no hidden exposure'? There's also highlight reconstruction, which (unpredictably) extends the dynamic range of your data by a couple of stops (above the cameras max white level), so... are those considered a part of the dynamic range? Should you decrease exposure to fit those in? I think it's useful sometimes, so maybe. Plus the camera matrix distorts values, and the resulting RGB values are often much higher than the camera's white level, or even negative 😱

Transfer function is a better word for gamma, yes. But there's nothing stoppping you from adding an exposure multiplier in to the expression.

[togg]

Well just to have a preset by default with a "clea" option, nothing fancy. I like the loo of the tone mapped preset though.

[masc]

Yeah I thought MLV App has an exposure factor of +1 or 2 by default. But I couldn't find it in the code just now, so I don't know anymore, could it be in the interface??

Yes, Ilia, you're right:

Code: [Select]

void MainWindow::on_horizontalSliderExposure_valueChanged(int position)
{
    double value = position / 100.0;
    processingSetExposureStops( m_pProcessingObject, value + 1.2 );
...

[ilia3101]

Thanks @masc.

So the exposure offset is 1.2

Well just to have a preset by default with a "clea" option, nothing fancy. I like the loo of the tone mapped preset though.

Then you could try setting the following:
- rec709 preset (it does nothing aesthetic, it simply encodes with the rec709 transfer function, which video players should decode with)
- exposure -1.2
- disable creative adjustments
- as a bonus: you can lock the white balance to 6504K to get the most absolute colorimetry

It would be:
- techincally the most 'colour accurate' output you can get (except where it clips), in a silly absolute way
- hideously ugly
- a very inefficient encoding in terms of preserving data (unlike log )
- you'd still lose data by clipping due to the following: 1. white balance 2. the limited rec709 primaries

[togg]

I think that it is the right choice to have this boost of exposure and the tone mapping by default, but I do think that it woudl be better to have the exposure boost removes in the rec preset, at least to understand what's going on. The shadows clearly becomes noisy at +1.2, if you can get more light it's better to do so, the first result that MLV app provides and the difficulty to understand what's going on can be misleading.

Also I was wondering, could there be a way to fix the missing header error inside MLV App? I need to try to recover a few shoots that probly got corrupted because of a dying card and I will start looking for other tools.

[ilia3101]

but I do think that it woudl be better to have the exposure boost removes in the rec preset, at least to understand what's going on

Disagree. Still cameras like our Canons usually leave 1 or 2 stops of highlight headroom, so 18% on the sensor is not meant to be 18% (middle grey) on the final image. That would leave no room for any kind of smooth roll-off curve.

This headroom also ends up being different on each channel, smallest on green, highest on red/blue, depending on the white balance, so which channel would you use as a reference point? They all get boosted/reduced during white balance, you can't really have no exposure... So why not just place middle grey sorta where the manufacturer intends!

Cine cameras like the Arri Alexa (and even the sigma FP at some ISO settings) leave 7+ stops of headroom above middle grey. That requires a masive amount of 'hidden exposure' during processing to match what the operator saw on the screen, or... to realise this isn't 'hidden exposure'. It's how the camera is engineered.

[togg]

Well you're describing how digital exposure is allocated. Of course you can bring it up in post, or log allocates it better. The thing is that in this case MLV app clearly gives out a noisier picture by default. Maybe because it doesn't do any kind of smoothing that the camera would automatically do on the jpeg, I don't know. I like it because I appreciate the cheated dinamic range boost, but it still feels very noisy. It's a hidden number that you cannot discover on the program, this of itself is an issue in my opinion.

[ilia3101]

MLV is noisier than JPEG mainly because it's lower resolution with the same noise level. Signal to noise ratio ends up worse at viewing scale. And yeah, also the fact MLV App doesn't do chroma denoising by default.

Do you also want to know the values of the hidden camera matrix? It distorts all the hues if you think about it, and it means the camera's RGB channels do not correspond to the RGB channels that are output. But it's there for colour management. Without it you'd get pale colours and wrong hues.

I think of this 'hidden exposure' gain as another (admittedly less critical) form of camera calibration, just like the camera matrix.

And I still don't believe 'no exposure' is meaningful, as you must first make a choice about how you anchor the white balanced channels, which in itself, is an exposure choice. MLV App makes this choice by matching the luminance of before and after (which will produce some pink highlighs at 0 exposure, as the lowest clipping channel will end up below 1.0), but you could also make it such that the earliest clipping channel = 1.0 (this way they all clip at or above 1.0, so 0 exposure will not produce pink highlights, probably the best option for this), or you could make it so the highest clipping channel = 1 to preserve the most data, but then you'd get very visible pink highlights at 0 exposure.

Everything is relative. And there is no image in the raw file, it must be created.

[togg]

I was also comparing it with the dngs imported on photoshop camera raw, but then again I vastly appreciate the mlvapp default look.

Do someone knows where the bad pixel map is located?

[masc]

Adobe Camera RAW brings a very similar amount of noise and similar looking results, when I compared both. At least if you setup the chroma denoiser sliders to comparable values.

The bad pixel maps are in the same path as the mlvapp executable and focus pixel maps, after you created one. It has the .bpm ending.

[togg]

neat location, found it thanks

[ilia3101]

I was also comparing it with the dngs imported on photoshop camera raw

Oh ok. I wouldn't even claim MLV App matches the exposure correctly. The 1.2 stops is just an absolute guess. Adobe camera raw probably knows better about this stuff (at least on CR2s)... although in the case of DNGs generated from MLV, the exposure offset metadata may be missing, so it's possible camera raw doesn't do the 'hidden exposure' with those. Just guessing.

If you have any interest in doing it, I'd love to see a comparison between:
1. CR2 photo through camera raw
2. MLV video through MLV App
3. A DNG created from that MLV, through camera raw

Where the MLV and the CR2 use the same aperture, ISO and shutter settings. ISO 100/200/400/800, not the inbetween steps. I'd do it myself if I had Adobe software.

My (likely wrong) prediction: 1 and 2 exposure will match, but 3 will be darker.

[togg]

I can surelly do this test. I will also had Resolve to the equation, since that is the main comparison.

[gabriielangel]

Hello,

I compiled the latest MLVApp build on OSX, and rendering clips now takes roughly 2X Longer compared to the Official Version 1.14 (I compared side by side)

Is it a compiling problem on my end, or because some Quality enhancement happened? (I tried Prores 422 and H264)

I have:

OSX 10.13.6
Qt 5.15.2
Qt Creator 5.0.2

[Danne]

Probably bot compiling with openmp.

[gabriielangel]

Probably bot compiling with openmp.

Sorry, I am not familiar with the terminology. If you mean compile with the script you created here:

https://bitbucket.org/Dannephoto/mlv_app_compiler-git/downloads/mlv_app_compiler.dmg

, it says it needs osx 11 to work. Is that what you meant?

[Danne]

Try googling the term.
When you compile. Do you see the word openmp in terminal?

[gabriielangel]

Try googling the term.
When you compile. Do you see the word openmp in terminal?

As I am not a Coder, google Algo gives me unrelated responses. If you can send me one of your google query results, I'll be able to start from there.

Here is the terminal output of the compiling script (To the left) And the Qt GUI output (To the right)
The script doesn't give me an app, but I get an app with Qt (The App works, but export is slow)

[Danne]

Maybe better you configure from scratch on your system.

[togg]

Oh ok. I wouldn't even claim MLV App matches the exposure correctly. The 1.2 stops is just an absolute guess. Adobe camera raw probably knows better about this stuff (at least on CR2s)... although in the case of DNGs generated from MLV, the exposure offset metadata may be missing, so it's possible camera raw doesn't do the 'hidden exposure' with those. Just guessing.

If you have any interest in doing it, I'd love to see a comparison between:
1. CR2 photo through camera raw
2. MLV video through MLV App
3. A DNG created from that MLV, through camera raw

Where the MLV and the CR2 use the same aperture, ISO and shutter settings. ISO 100/200/400/800, not the inbetween steps. I'd do it myself if I had Adobe software.

My (likely wrong) prediction: 1 and 2 exposure will match, but 3 will be darker.

Adobe Camera RAW brings a very similar amount of noise and similar looking results, when I compared both. At least if you setup the chroma denoiser sliders to comparable values.

Well I did the tests and it looks like you were indeed right

exposure on MLVapp match both CR2 on ACR and rec709 2.4 gamma on davinci raw panel.
MLV's dng in ACR don't match, need that 1.2 boost and higlight roll off.
dng treated as blackmagic color space + bmcc to recv2 in last node of Davinci don't match, same thing.

The last case is what I am more interested in and where I was trying to get bet results by default. That's where my mistake originated. I understand now that for a non-tandard dng you need to give that boost that is done as a gamma correction by default on native solutions. Sorry for the confusion!