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 6 Guests are viewing this topic.

DeafEyeJedi

Quote from: masc on March 09, 2019, 11:25:19 AM
Btw: for everybody who is able to compile: MLVApp can export HDR footage now. You won't see what you get in the viewer, but ffmpeg export will blend it, if this new option is chosen.

Yes! Will compile the latest MLV App and definitely have a go w the HDR features... Thanks so much to @Danne & @masc!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

70MM13

yeah, jedi master...  i can't wait to see what you come up with!

theBilalFakhouri

Quote from: masc on March 09, 2019, 11:25:19 AM
No idea how we could "extract" only one of the isos in dual iso clips. What happens with the unused lines? Skipping won't work (-> black lines). So do I copy the 1st two lines to line 3&4 and so on? I think this would look not very nice.

How Dual ISO processing works?

As I know it averages the two first lines and the two third lines to generate the missing two second lines in the Base ISO lines and make one whole image for the Base ISO, then the the same thing happens with the two second lines and two fourth lines to generate the missing lines for the Second ISO and also build a whole image with the Second ISO . . After filling the Missing lines for Base and Second ISOs now the two generated images for base ISO and Second ISO will merge together?

If I am wrong please someone tell us how the processing works .

Okay can we averge the two first lines and the two third lines to fill the in-between these lines instead of just copying it? It look the same process how Twixtor plug-in in After Effects works when doing *fake* Slow Motion it creates frames by blending frame A and frame B then it put the generated frame in-between these A and B frames . . But in our case we have pixels lines  :D

Starclassic

Quote from: masc on March 09, 2019, 05:46:58 PM
Cinelog is commercial and I don't have it. So I am not able to see what you are doing. What kind of LUT is that? Is it a .cube 3D LUT? As I understood cinelog is more than just a LUT. Could you open that in a browser and see if it is correct to the specification?
If MLVApp tells "File with invalid header or file is too long.", this means that the LUT is not correct: there are more values included than the header of the file told before, or no value at all is included.

It is a .cube 3D LUT intended to convert BMD Film to Cinelog. It's intended use is for Davinci. I'll upload images later.

masc

Quote from: Starclassic on March 11, 2019, 09:32:25 PM
It is a .cube 3D LUT intended to convert BMD Film to Cinelog. It's intended use is for Davinci. I'll upload images later.
The intended program should not matter. There is a spec from Adobe for cube files. This spec should be implemented. If the header of the cube does not fit to the attached data, MLVApp brings the error. You could count the exact number of lines of data and compare to the number inside the header. I bet it doesn't fit.

This is the corresponding code I am talking about:

...
        else if( sscanf(line, "LUT_3D_SIZE%*[ \t]%hu%*[^\n]", &lut->dimension) == 1) //LUT is 3D
        {
            lut_size = (uint32_t)lut->dimension * (uint32_t)lut->dimension * (uint32_t)lut->dimension * 3;
            lut->is3d = 1;
            lut->cube = malloc( lut_size * sizeof( float ) );
            continue;
        }
        else if( sscanf(line, "%f%*[ \t]%f%*[ \t]%f%*[^\n]", &r, &g, &b ) == 3) //Read data
        {
            if(!lut_size || i >= lut_size) //File with invalid header or file is too long
            {
                sprintf(error_message, "File with invalid header or file is too long.");
                unload_lut( lut );
                fclose( fp );
                return -1;
            }
            lut->cube[i+0] = r;
            lut->cube[i+1] = g;
            lut->cube[i+2] = b;
            i+=3;
        }
...
5D3.113 | EOSM.202

Andy600

It's not a normal 3D cube lut. It's a hybrid format specific to Resolve and can't be parsed in other apps. It also doesn't conform to the Adobe .cube lut specification although it is based, in part, on it.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

masc

Thanks Andy600. Then I need this hybrid format spec, or MLVApp has no chance in reading such files ;) ...and even then... somehow this has to be processed?!
5D3.113 | EOSM.202

Andy600

There is no published spec that I know of but it's basically a high precision 1D lut concatenated with a high precision 3D lut. It's quite rare.

This specific lut will only work in BMD Film colorspace and unlike other shaper+3D luts it samples an additional transform in unbound linear space but maintains linear greyscale in the 3D part. It's pretty complex to create and ordinarily this type of colorspace transform would require an additional 1D lut after the linear matrix transform to get from linear to log space. Cinelog (Resolve) does it all in one lut but at the expense of limiting the colorspace (as all luts do), albeit to a space far larger than any real-world colors exist in (similar to ACES). You don't lose anything but technically speaking it does impose a limit because it's a lut.

As I've mentioned before it would probably be better to implement a proper CMS (ACES, OCIO etc) into MLVApp as it would be more efficient and infinitely expandable. Lut color transforms, especially ones like this are quite heavy in terms of file size and would require several GBs of luts to cover transforms to/from most typical colorspaces.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

Danne

Andy600, we missed you and colorspace discussions 8). Ilia3101 been working on aces transform for a while. Seems hard.

timbytheriver





Hi! This grab is from a 1080p/45fps clip on 5D31.2.3 in MLVapp 1.5 using AMaZe debayer. Lens is Canon L 16-35mm 2.8.

The aliasing/fringing around the leaves looks bad to me! Oddly enough, LMMSE debayer seems to make it worse!

Is this normal for a 5D3? Any ideas on how to treat this in MLVapp? Looks more like my old 5D2!

Many thanks.
5D3 1.1.3
5D2 2.1.2

masc

Quote from: timbytheriver on March 13, 2019, 12:09:04 PM




Hi! This grab is from a 1080p/45fps clip on 5D31.2.3 in MLVapp 1.5 using AMaZe debayer. Lens is Canon L 16-35mm 2.8.

The aliasing/fringing around the leaves looks bad to me! Oddly enough, LMMSE debayer seems to make it worse!

Is this normal for a 5D3? Any ideas on how to treat this in MLVapp? Looks more like my old 5D2!

Many thanks.
For me it just looks extremely overexposed (window is completely white). This causes artifacts at details. Bringing details out of overexposed areas is a hard job for all debayers.
5D3.113 | EOSM.202

timbytheriver

Thanks @masc Good catch, but the exposure appears to be just on the edge!





Forgot about Chroma smoothing; here with value=6 applied. Much better now! :)

I love MLV App!
5D3 1.1.3
5D2 2.1.2

DeafEyeJedi

Quote from: Andy600 on March 11, 2019, 11:14:56 PM
...as mentioned before it would probably be better to implement a proper CMS (ACES, OCIO etc) into MLVApp as it would be more efficient and infinitely expandable.

+1  8)

Quote from: Danne on March 11, 2019, 11:29:32 PM
Andy600, we missed you and colorspace discussions 8).

Big time!

Quote from: Danne on March 11, 2019, 11:29:32 PM
Ilia3101 been working on aces transform for a while. Seems hard.

Hopefully @Andy600 could bring us hints, if any.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

Jonit

I've been watching some of my old vids and was thinking how good that footage looked even in early days. I've been shooting with 600D back then and I was processing in MLRawViever. I loved that convertor so much. It gave me awesome results and especially I loved the C-Log look. I've been using it as a final output without any aditional grading or color correction. But MLRawViever is no longer being maintained (unfortunately :( ) so it doesn't support newer 10-12bit and lossless compressions. Also it didn't have black point repair capability (which I greatly appreciate in MLVApp) and it also had a problem with overexposed footage where it would put color stripes over that area.

So I thought that I may try to "recreate" that C-Log look in MLVApp and I think, I've got pretty close, but I noticed one thing in that process and that is that video files produced by MLRawViewer have much less aliassing in them. Like the debayer algorithm is doing much better job there. Which is strange as both programs were set to AMaZE.

Do any of you guys have any idea why?
The difference is quite staggering in the final output.




(there is even more difference in another clips)


   

masc

RAW data has to be preprocessed to be able to debayer correctly. Maybe this is solved in different ways (sure it is). Don't find in the MlRawViewer's code how it is done there... was searching for hours, also in past already.
The AMaZE code is different too, but I exchanged it for test with the MlRawViewers code, and the result (also aliasing artifacts) was identical in my test pics.
5D3.113 | EOSM.202

ilia3101

@Jonit This is due to how white balancing is done before debayering, MLRawViewer seems to do it better for that shot. Could you see if MLV App 1.4 is different or better please? there was a small change made between the two in debayer white balance, that improved things, but sometimes didn't.  I want to add an option for debayer white balance, hopefully that will fix your issue.

Also I'm shocked how close the two look... but they're both wrong, as they use sRGB ;)

ilia3101

Quote from: Danne on March 11, 2019, 11:29:32 PM
Andy600, we missed you and colorspace discussions 8). Ilia3101 been working on aces transform for a while. Seems hard.

Idk if what I'm doing is an 'aces transform' - the main goal is just to use a bigger gamut for processing. I am also considering ProPhoto RGB, it seems like the primaries on that colour space may be more close to our perception of 'red' 'green' and 'blue' so it would be better for RGB curves and things like that.

Those discussions were fun but I was so clueless back then :D

Jonit

Quote from: Ilia3101 on March 16, 2019, 10:46:16 PM
@Jonit This is due to how white balancing is done before debayering, MLRawViewer seems to do it better for that shot. Could you see if MLV App 1.4 is different or better please? there was a small change made between the two in debayer white balance, that improved things, but sometimes didn't.  I want to add an option for debayer white balance, hopefully that will fix your issue.

Here is the output from MLVApp 1.4. Looks the same to me.




Quote from: Ilia3101 on March 16, 2019, 10:46:16 PM
Also I'm shocked how close the two look...
Took me about an hour to fiddle with the sliders and curves to match it relatively close to that MLVRawViewer C-Log  :D.

Quote from: Ilia3101 on March 16, 2019, 10:46:16 PM
but they're both wrong, as they use sRGB ;)
Can you please elaborate a bit on this statement? I'm not very knowledgeable in that area so would be cool to understand a bit more :). Thanks!

ilia3101

Ok then this issue will need some more work. Maybe wait until I add a white balance slider.

Quote from: Jonit on March 16, 2019, 11:11:36 PM
Took me about an hour to fiddle with the sliders and curves to match it relatively close to that MLVRawViewer C-Log  :D.
Ah right...

Quote from: Jonit on March 16, 2019, 11:11:36 PM
Can you please elaborate a bit on this statement? I'm not very knowledgeable in that area so would be cool to understand a bit more :). Thanks!

Well, MLV App's C-Log doesn't use the C-Log gamut yet, it only matches the C-Log log curve. Proper log profiles are coming with the colour space improvements mentioned earlier.

My assumption was based on how similar they look... so it's possible that only MLV App is wrong, or both are wrong in different ways. Maybe @andy600 about if MLRV does log colour right?

I don't know if this is too much ask, but could you make a direct comparison of MLV App and MLRawViewer in C log and rec709? I just want to see how different they look... also see if unchecking use camera matrix in MLV App brings them closer or anything.

DeafEyeJedi

Quote from: Ilia3101 on March 16, 2019, 11:36:39 PM
Ok then this issue will need some more work. Maybe wait until I add a white balance slider.

Whoohoo!

Quote from: Ilia3101 on March 16, 2019, 11:36:39 PM
Well, MLV App's C-Log doesn't use the C-Log gamut yet, it only matches the C-Log log curve. Proper log profiles are coming with the colour space improvements mentioned earlier.

Good to know.

Quote from: Ilia3101 on March 16, 2019, 11:36:39 PM
... also see if unchecking use camera matrix in MLV App brings them closer or anything.

Great call @Ilia3101! (if needed I tend to use 'Uncolorscience Fix' by @Danne in the compiled versions)

5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

Jonit

Quote from: Ilia3101 on March 16, 2019, 11:36:39 PM
I don't know if this is too much ask, but could you make a direct comparison of MLV App and MLRawViewer in C log and rec709? I just want to see how different they look... also see if unchecking use camera matrix in MLV App brings them closer or anything.

There is no CLog profile in MLVApp (at least I don't see any), so I used Log-C instead.
There are different whitebalances between the two apps (MLVApp - I didn't touch anything, MLRawViewer - I pressed WB presset number "3" (the default one was way off)).





Here are the original PNG frames: https://mega.nz/#!jJ1iGSZZ!Im80SRBNw6XewT3x0_y3pIsOdv_ZAcq1-sNkZ8MzZuQ

Quote from: Ilia3101 on March 16, 2019, 11:36:39 PM
Proper log profiles are coming with the colour space improvements mentioned earlier.
Yay!!  :P :)

lostfeliz

Anyone having an issue where my exports cut off after 29 seconds? I've been using Resolve for years. Wanted to switch to MLV App, but having this problem.

Danne

At least tell your settings used or even better. Export all your settings into file and upload it here. Tell us your computer specs.
http://www.catb.org/esr/faqs/smart-questions.html#beprecise

ilia3101

@Jonit thanks for the comparisons!

I will try and grt MLRV set up to do my own tests. I wonder how much closer they would or would not be with adjusted balance/exposure

masc

Quote from: lostfeliz on March 19, 2019, 04:01:55 AM
Anyone having an issue where my exports cut off after 29 seconds? I've been using Resolve for years. Wanted to switch to MLV App, but having this problem.
Nope. Can convert hundreds of GB all over the day without crash here. More information needed, to be able to reproduce.
5D3.113 | EOSM.202