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

Started by ilia3101, July 08, 2017, 10:19:19 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

wety67e

MLV App is a great app... :D

Please add support for Adobe color profile dcp.
Rawtherapy, irident support dcp profile

Thanks

Sorry for my bad English

masc

Quote from: wety67e on October 05, 2018, 10:35:27 AM
MLV App is a great app... :D

Please add support for Adobe color profile dcp.
Rawtherapy, irident support dcp profile

Thanks

Sorry for my bad English
DCP = DNG camera profile. We are working on MLV files. Input should be DNG, generated by Adobe Tools (in order to get correct output).
5D3.113 | EOSM.202


Danne

Thanks masc for your link to my repost  :P.
I have deepest respect for Ilia3101 work getting colors as good as they are atm. With that said It´s almost a shame that we don´t seem to match color perfectly for all cams. Reading posts from mostly Andy600 it seems there can be more here to get a perfect color match. How? I have no idea but looking into processing.c it seems most calculations is derived from that code?
Unlike some other at this forum I look at Mlv App as a very mature project and mostly bug free thanks to nitpick work from mostly masc atm but color output seems to be the very heart of it all, right?
So, is there energy and time to finalize this most vital piece of the puzzle getting color matrices and color space correctly or should we start doing 3D calibration luts?

masc

Quote from: Ilia3101 on July 26, 2018, 08:21:24 PM
Ok calm down I've heard a lot of complaints about the wrong colours.

Some things:
1. I would like to bust a myth - MLV App does not use any colour matrices at all right now, no "5D2 matrix for all cameras" things going on, that is just not true and I'm not sure how the myth started. Maybe it's because the white balance multipliers are generated by data I extracted from 5D mark II photos using exiftool, however that does not affect colour in any deep 5D mark II way, they simply specify the channel multiplication factors and that is it. I'm really surprised they even work considering it is unknown what colour space they are for.
2. That(fixing the colours) is actually the processing improvement I was talking about some time ago. I have been a bit demotivated though, as every time I start working on it it just gets fiddly or crashy or something is wrong with the colour(most often this). The extreme hotness of summer combined with that makes for a perfect giving up vibe.
...
Here another post from Ilia for this topic. I do what I can; but with this topic I absolutely don't know what to do ;) Only one thing is sure: it is not easy.
5D3.113 | EOSM.202

bouncyball

Quote from: masc on October 05, 2018, 01:43:56 PM
I do what I can; but with this topic I absolutely don't know what to do ;) Only one thing is sure: it is not easy.
+1 :D

masc

@Ilia: can you describe how you got these values out of the RAWs exif? Did you calculate it with the values, e.g. Color Temp Daylight = 5200, WB RGGB Level Daylight = 2052 1024 1024 1572. So this brings the factors: 5200K: 2.0039, 1.0, 1.5351. (CR2 from a 700D). But also in a 5D2 CR2 I get slightly different values than yours. I made a quick test with some values from 700D CR2s around this and got slightly other colors with that (use only between 3200 and 6000K!)...
static const int wb_kelvin[]   = {     3200,     5200,     6000 };
static const double wb_red[]   = { 1.762695, 2.003906, 2.146484 };
static const double wb_green[] = { 1.000000, 1.000000, 1.000000 };
static const double wb_blue[]  = { 2.316406, 1.535156, 1.410156 };


@everybody: try reading these values, adapting the code and try with your own cameras... maybe it gets better, maybe not... no idea what I am doing  :P
5D3.113 | EOSM.202

Danne

Quote from: masc on October 05, 2018, 03:07:03 PM
@everybody: try reading these values, adapting the code and try with your own cameras... maybe it gets better, maybe not... no idea what I am doing  :P
haha, I know the feeling. What is the code in mlrawviewer doing? Seems color space crappola is kind of working in that one? Yeah, I know, WHy am I asking and not checking for myself  :P

masc

I played a bit around with the values I got from the 700D CR2. Okay - I need other WB settings now - but then, the pictures look 100% identical I think. Tested mostly with my 5D2 clips and some others I got here in the forum. It seems Ilia is right - if it is this, what he meant.
5D3.113 | EOSM.202

masc

Quote from: Danne on October 05, 2018, 06:34:10 PM
haha, I know the feeling. What is the code in mlrawviewer doing? Seems color space crappola is kind of working in that one? Yeah, I know, WHy am I asking and not checking for myself  :P
Have you found something? I haven't. :(

Edit: found the default in MlRaw.py line 298 balance = (2.0,1.0,1.5) # Reasonable default
With this numbers MlRawViewer = MLVApp. BUT I did not find which Kelvin this shall correspond to... cares MlRawViewer at all about it!?

Edit2 here it is...  :D from Viewer.py
elif k==self.KEY_ONE or k==self.KEY_KPONE:
            if m==0:
                self.changeWhiteBalance(2.0, 1.0, 2.0, "WhiteFluro")  # ~WhiteFluro
            elif m==1:
                self.deleteLut1D()
        elif k==self.KEY_TWO or k==self.KEY_KPTWO:
            self.changeWhiteBalance(2.0, 1.0, 1.5, "Daylight")    # ~Daylight
        elif k==self.KEY_THREE or k==self.KEY_KPTHREE:
            if m==0:
                self.changeWhiteBalance(2.5, 1.0, 1.5, "Cloudy ")     # ~Cloudy
            elif m==1:
                self.deleteLut3D()

        elif k==self.KEY_FOUR or k==self.KEY_KPFOUR:
            self.changeWhiteBalance(self.setting_rgb[0]*0.99, self.setting_rgb[1], self.setting_rgb[2], "red-")
        elif k==self.KEY_SEVEN or k==self.KEY_KPSEVEN:
            self.changeWhiteBalance(self.setting_rgb[0]*(1.0/0.99), self.setting_rgb[1], self.setting_rgb[2], "red+")
        elif k==self.KEY_SIX or k==self.KEY_KPSIX:
            self.changeWhiteBalance(self.setting_rgb[0], self.setting_rgb[1], self.setting_rgb[2]*0.99, "blue-")
        elif k==self.KEY_NINE or k==self.KEY_KPNINE:
            self.changeWhiteBalance(self.setting_rgb[0], self.setting_rgb[1], self.setting_rgb[2]*(1.0/0.99), "blue+")

        # Green control is now done by modifying R/B/brightness together
        elif k==self.KEY_FIVE or k==self.KEY_KPFIVE:
            self.changeWhiteBalance(self.setting_rgb[0]*(1.0/0.99), self.setting_rgb[1], self.setting_rgb[2]*(1.0/0.99), "green-")
            self.scaleBrightness(0.99)
        elif k==self.KEY_EIGHT or k==self.KEY_KPEIGHT:
            self.changeWhiteBalance(self.setting_rgb[0]*0.99, self.setting_rgb[1], self.setting_rgb[2]*0.99, "green+")
            self.scaleBrightness(1.0/0.99)


So MlRawViewer does not care about Temperature and Tint values. They just change the single channels. This may not be bad, it is very simple, but very different from what we try to do.
5D3.113 | EOSM.202

masc

Okay, funny. I implemented the WB strategy from MlRawViewer to MLVApp for testing - that was not difficult... and you know what? The colors are the same as before :P (with different settings on the sliders). All red tones from non5D2 or 5D2 footage are identical for example. Maybe it has more to do with colorspace and not with whitebalance?! If someone else want to try out (not nice, but working):
/* Set white balance by kelvin + tint value */
void processingSetWhiteBalance(processingObject_t * processing, double WBKelvin, double WBTint)
{
    processing->kelvin = WBKelvin;

    /* Avoid changing tint if just changing kelvin */
    if (WBTint != processing->wb_tint)
    {
        /* Non-linear tint makes control finer in the middle */
        int is_negative = (WBTint < 0.0);
        if (is_negative) WBTint = -WBTint;
        WBTint /= 10.0;
        WBTint = pow(WBTint, 1.75) * 10.0;
        if (is_negative) WBTint = -WBTint;

        processing->wb_tint = WBTint;
    }
   
    /* Kalkulate channel (yes in cone space... soon) multipliers */
    //get_kelvin_multipliers_rgb(WBKelvin, processing->wb_multipliers);

    /* Do tint (green and red channel seem to be main ones) */
    //processing->wb_multipliers[2] += (WBTint / 19.0);
    //processing->wb_multipliers[0] += (WBTint / 19.0);

    processing->wb_multipliers[0] = 2.0 + (WBKelvin-6000)/5000.0;
    processing->wb_multipliers[1] = 1.0;
    processing->wb_multipliers[2] = 1.5 + WBTint/10.0;

    /* Make all channel multipliers be >= 1 */
    /*double lowest = MIN( MIN( processing->wb_multipliers[0],
                              processing->wb_multipliers[1] ),
                              processing->wb_multipliers[2] );

    for (int i = 0; i < 3; ++i) processing->wb_multipliers[i] /= lowest;*/

    /* White balance is part of the matrix */
    processing_update_matrices(processing);
    if( processing->gradient_enable != 0 ) processing_update_matrices_gradient(processing);
}
5D3.113 | EOSM.202

ilia3101

Quote from: masc on October 05, 2018, 09:35:05 PM
Maybe it has more to do with colorspace and not with whitebalance?!
👍

All this colour stuff is nothing to do with white balance (well, it is a bit, but not just white balance)

I would need to implement colour matrices, like I did in the WhiteBalance branch (yes, it's called white balance because I also implemented more scientific white balance algorithm but no big deal)

The biggest problem with implementing this matrix stuff is the fact that all processing is integers. I have really struggled every time I've tried this to avoid floating point while keeping highlight reconstruction working. Using float in the most core part of processing would make it slow at its fastest.

MLRawViewer does have proper colour matrices - it uses floating point too. It's fast because it uses fancy OpenGL vertex fragment shaders, but seems they might not work with older opengl hardware(?)

Danne

Well, just did a revisit to white balance branch and wow, we get colors back! When I was testing this branch the first time I had issues with indoor lighting but testing file below we get amazing output:

Master branch(setting "Standard")


White balance branch(setting "Standard" tweaked white balance and added some exposure)


You can get into the white balance branch in Mlv_app_compiler.app by the way. Select (b) to get into branches in main menu then:
Select 4


Hit c for compiling


Or download a compiled white balance version here for testing(mac):
https://bitbucket.org/Dannephoto/magic-lantern/downloads/MLV%20App_WB.app.zip

Test MLV file:
https://drive.google.com/file/d/1wb1kdXkshjXmZvJn3zhIw7M7GPLtjMhP/view


Now here´s proof Ilia3101 more or less already solved the issues. @masc. How about trying to implement and test this into master branch?

@Ilia3101. Are matrices included now in white balance branch or is the code in processing.c doing something else before even adding the matrices? Checking the test file seems we are getting more proper color. Even without matrices I think we still get better results here.

EDIT: Testing more files and yes this version is problematic. Highlights gets pinkish so a lot of testing/refining of code needed.(Maybe it´s my test file, probably filmed with 10bit mode or so) Would love to see the code in master.


EDIT 2:
A few more examples(eos 100D):
Test file here:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M06-0931_short.MLV
Master branch:


White balance branch(oh, lovely colors):


White balance branch highlight issue(maybe solved already in master branch)



bouncyball

@Danne

Liked that branch color huh? :)
I was like: wow! this is it! when 1st tried that code.

Yes it has not only highlight issue but wb issues with other than daylight kelvin.

The half of the job is really done there by Ilia. Multiplier deriving needs some changes to support other temperatures correctly.

Well, Ilia knows better what's really needed to be changed.

Edit: Here is related discussion.

Danne

Oh, quite the thread. By the way. Your modification of Ilias3101 code looks really nice.
Color science is a mess!

bouncyball

Yes it looked not bad (color wise) but had it's quirks. I think it is better to finish Ilia's version. I like it very much.

IDA_ML

Very important discussion on the tricky color science problem!  Magic Lantern seems to boost science and become an academic effort.  I hope, this discussion will initiate new progress and improvements on color in this amazing product and we will see a new build including them soon! 

Levas

This software is getting better and better.
I'm wondering, is it possible to add the option of importing dng sequence (extracted from MLV's) instead of a MLV file ?
I have made the choice to keep only dng sequences as backup and throw away the original mlv's  :P

Another question, it's about the color stuff, does anyone of you know if there is any difference in the two green channels in Canon camera's ?
Just curious if Canon uses two different greens in the bayer filter.

masc

Quote from: Danne on October 06, 2018, 08:44:54 AM
Now here´s proof Ilia3101 more or less already solved the issues. @masc. How about trying to implement and test this into master branch?

EDIT: Testing more files and yes this version is problematic. Highlights gets pinkish so a lot of testing/refining of code needed.(Maybe it´s my test file, probably filmed with 10bit mode or so) Would love to see the code in master.
We did many test, sometimes the result was better, sometimes the result was very bad (<3500K). That's why this branch did not come into master yet. Now, a long time later (in terms of our development) the code has changed a lot and merging will not be very easy. On the other side Ilia wanted to try some other things on WB (if I remember right).
It would be very cool, to be able to toggle between the two different processing vesions. But I think this will just remain a wish... (double development effort in future).

Our old highlight revovery concept won't work at all with the new WB branch, if I understood right. So here we will have to develop something new... if someone knows how to do... your welcome.

Quote from: Levas on October 07, 2018, 02:13:12 PM
I'm wondering, is it possible to add the option of importing dng sequence (extracted from MLV's) instead of a MLV file ?
I have made the choice to keep only dng sequences as backup and throw away the original mlv's  :P
Unfortunately no. That means ... yes, but we would have to rewrite nearly everything.
Quote from: Levas on October 07, 2018, 02:13:12 PM
Another question, it's about the color stuff, does anyone of you know if there is any difference in the two green channels in Canon camera's ?
Just curious if Canon uses two different greens in the bayer filter.
I don't think so. All our debayers use both green pixels, but with different methods. The pictures should look very different or wrong, if these channels were different (in terms of green).
5D3.113 | EOSM.202

Levas

Quote from: masc on October 07, 2018, 04:22:56 PM
Unfortunately no. That means ... yes, but we would have to rewrite nearly everything.

Too bad, but no problem.

ilia3101

I would not want to merge that branch. Rewriting it is not that hard. I have some ideas for how it could be done with 16 bit ints and look up tables.

masc

Quote from: Ilia3101 on October 07, 2018, 06:28:08 PM
I would not want to merge that branch. Rewriting it is not that hard. I have some ideas for how it could be done with 16 bit ints and look up tables.
Sounds good! Take care: all your functions are there twice now (2nd slightly changed only) because of gradient calculation. But if we touch it, we have to change both. :)
5D3.113 | EOSM.202

Enrico

Hello everyone, is there something I can use to deal with a 10bit HDR mlv file on windows? I use to export uncompressed DNG from MLVApp and import the sequences in Davinci what could I do? :'(

masc

Quote from: Enrico on October 08, 2018, 08:29:59 PM
Hello everyone, is there something I can use to deal with a 10bit HDR mlv file on windows? I use to export uncompressed DNG from MLVApp and import the sequences in Davinci what could I do? :'(
Puh... on windows there is no solution yet. What could work, but is some work for you: select every 2nd dng and put it into another folder. I am not sure if Resolve can handle 1,3,5,7,... and 2,4,6,8... sequence numbers or if you get an error. If it works, you should have two sequences and can try to blend it somehow in Resolve.
5D3.113 | EOSM.202

Enrico

Quote from: masc on October 08, 2018, 08:49:20 PM
Puh... on windows there is no solution yet. What could work, but is some work for you: select every 2nd dng and put it into another folder. I am not sure if Resolve can handle 1,3,5,7,... and 2,4,6,8... sequence numbers or if you get an error. If it works, you should have two sequences and can try to blend it somehow in Resolve.
Hmm I'm still learning to use Davinci, but is there a clean tutorial for MacOs? Becouse I could use my friend's macbook or even a virtual machine.