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

[timbytheriver]

Re ACES. Good, clear article here. https://www.lightillusion.com/aces_overview.html

I thought this quote was of note:

"The first point to be made is that compared to other workflows ACES will not improve the final image quality, or enable improved/better colours, or provided any other image related benefit. It is not a 'magic bullet' that somehow guarantees better end results."

I know there's a lot of noise surrounding ACES at present, so this was news to me.

Quick version: Have lots of different cameras, and linear VFX stuff to match on one timeline? ACES might help. If not, it probably will be the wrong choice.

[andy kh]

is it possible to add some presets in the resize export

[masc]

Like that?

[andy kh]

Like that?

yes exactly this feature wil be very usefull

[masc]

If you are able to compile... it is commited. Please test and report results. It is more complex than it looks like - no idea what else could go wrong

[andy kh]

sorry i cant compile

[Danne]

Like that?

Good stuff.

[Luther]

Sorry for the late reply.

Yes, lensfun is really nice - but very huge.

I wouldn't call 5MB huge in this day and age where a web browser is three times bigger than an entire operating system.

But what I found out: have a look here, you can see that it won't correct CA's for most lenses.

Humm. That seem to be true.

And I am not sure if it would when using a Speedbooster on a EOS M (which produces a lot of CA's in another way than the lens would without).

In case of other lenses/adapters you could profile yourself with adobe lens profile:
http://rawpedia.rawtherapee.com/How_to_get_LCP_and_DCP_profiles

But, I don't think this is compatible with the XML from lensfun.

""Complying" with a standard" isn't the intention of profiles. The original intent of the profiles was to give different looks. Back in the day, MLV APp only had standard and tonemapped, to give different looks. These profiles were never supposed to control anything like output colour spaces/logs or stuff like that. It was always planned to be separate but that's not how it turned out. Anyway, the BetterProcessing branch has separate controls for these things.

Understood.

Also fattal tonemapping looks really creepy.

Looking at the research linked, yes. But, it can be used in different intensities. It was adapted to Rawtherapee exactly for that. Read the discussion here, it is very interesting, might even give some insights for new MLVApp features:
https://github.com/Beep6581/RawTherapee/issues/3061

[Luther]

"The first point to be made is that compared to other workflows ACES will not improve the final image quality, or enable improved/better colours, or provided any other image related benefit. It is not a 'magic bullet' that somehow guarantees better end results."

This is not true. He is probably comparing ACES with ALEXA Wide Gamut. From that perspective, indeed, ACES would not offer much advantage, as with comparing with ProPhoto.
Now when comparing with sRGB/Rec.709, and that is the case of MLVApp, ACES do offer big advantages in many aspects. For example, when I tried to record a show with many colored light, MLVApp gives out of gamut and muddy colors, while on Rawtherapee (using an extracted DNG and configured to use ACES) it is smooth. Also, if you try some drastic color changes MLVApp can give color artifacts, where with ACES this would probably happen less often.
Adapting ACES to MLVApp would also enable to export in Rec.2020 and that's the industry standard now.
Some examples here:
https://webkit.org/blog-files/color-gamut/

Couldn't test the wide gamut branch yet, but when I do I'll post some examples here.

[masc]

I wouldn't call 5MB huge in this day and age where a web browser is three times bigger than an entire operating system.

The MB don't care at all. Lines of code, dependencies and coding interface cares... and this is more than huge from what I saw. (At least I didn't got how to handle it.)

[Luther]

The MB don't care at all. Lines of code, dependencies and coding interface cares... and this is more than huge from what I saw. (At least I didn't got how to handle it.)

Well, it's meant to be an all-in-one solution, I think. The only dependency would be Glib (only on windows?).
I don't think there is a simpler open implementation. I've found the OpenFX LensDistortion, works on Natron but, even though I'm not a programmer, I can notice it is more complex than lensfun.
Maybe leave this feature to another time.

[masc]

Hm... maybe it is easier to insert a openfx interface - then one could load such plugins. But I have no idea how openfx works
The good thing on CA_correct_RT (from RawTherapee) is, it is just one single C function with some easy parameters (after my modification) and no dependencies at all.

[Luther]

But I have no idea how openfx works

Seems to be really complex. Don't know why, but might be because it was designed for compositing and VFX, not for simple filters. The good thing is that it seems to be a standard now. Nuke and Resolve are associated.

[Luther]

Finally, got to test the BetterProcessing branch.
Testing with 14-bit 50D MLV's, on a 99% Rec.709 monitor.
Some notes I did while testing:

- No processing gamut is working, except for Rec.709 and XYZ.
- XYZ to Rec.709 seems to be working nicely. Still, not precise, but might be the camera matrix(?).
- Comparing with Rec.709 > Rec.709, the XYZ > Rec.709 shifts towards red and slightly cyan on shadows. Because of the shift, reds get easily clipped (skin tones, mostly). Intense reds are a bit brighter than it should. Reds also gets hue shifted a bit towards magenta.
- Is already better than the original processing. Less color artifacts when doing heavy processing. More color separation (in especial the 'sub-tones' of red, differentiation between red, oranges and magenta).
- Other functionalities seem to be affected (using XYZ > Rec.709): curve in the Red channel is very sensitive and HSL is not precise.

Using Rec.2020 output:
- XYZ to Rec.2020 doesn't seem right. Can't say for sure, though, as I don't have a Rec.2020 monitor
- AdobeRGB to Rec.2020 seems alright (even though this wouldn't make much sense, as Rec.2020 is bigger than AdobeRGB).

Old bug, but I think Ilia already knows:
- While using camera matrix, bellow 3600K give odd colors. It seems the blue channel gets pulled and the reds gets fucked up

I'll post some samples some other time. I don't have a colorchecker, but a Pantone palette might work as a unscientific experiment.

[andrew_dotdot]

I was daydreaming about my favourite ML raw processing app one afternoon and it struck me that it would be pretty useful if MLV App could burn in time code and the source file name for making small files for offline editing. I started using a program "EditReady" to convert my h.265 files (that program reminds me a lot of MLV App) and began to really like burning in that data. Has this ever been considered for ML App?

[Luther]

@masc Are you able to compile master? I think this commit broke it:
https://github.com/ilia3101/MLV-App/commit/88e803d1033640953edd284de4bccdae88645c63

frame_caching.o: In function `get_mlv_raw_frame_debayered'
undefined reference to `wb_convert'
undefined reference to `CA_correct_RT'
undefined reference to `wb_undo
error: ld returned 1 exit status

[Rewind]

In order to avoid double posting, may I ask the developer to take a look at this post?

Basically, I have a couple of suggestions regarding the treatment of focus pixels. The idea is to make resulting video more usable by affecting only areas where those focus pixels are, and not the whole frame area, and to introduce an optional alternative interpolation algorithm, which works better in most situations.

[ilia3101]

This is not true. He is probably comparing ACES with ALEXA Wide Gamut. From that perspective, indeed, ACES would not offer much advantage, as with comparing with ProPhoto.
Now when comparing with sRGB/Rec.709, and that is the case of MLVApp, ACES do offer big advantages in many aspects.
...
Adapting ACES to MLVApp would also enable to export in Rec.2020 and that's the industry standard now.

All of the colour gamuts you mention are available in BetterProcessing.

For example, when I tried to record a show with many colored light, MLVApp gives out of gamut and muddy colors, while on Rawtherapee (using an extracted DNG and configured to use ACES) it is smooth.

If it is possible could you give me a sample (s)? As I need to have good samples to see how it looks when I'm fixing the BetterProcessing branch. I don't have many good examples myself (and no working camera to create them right now). I know BetterProcessing colours are quite fucked right now. It needs improvement, I would never release in the current state.

Also...

I still have some questions about colour things (if andy600 is still around or any other experts)...

The camera matrices, do they give output with absolute colour, D65 is equal to D65? or is it something like D65 is at D50, I seem to remember andy600 mentioning that and it has been a thought in the back of my mind ever since. (I am so confused about this!!!!!!!!!!!)

Another thing.... Let's say processing will use multiple gamuts for different stages (it will, three to be exact) - some of these gamuts may have a D50 white point, some D65, and some approximately D60. When converting between these gamuts inside of processing, should the white point be adapted (relative transform) or should it use an absolute transform? I am thinking relative would be better, as it avoids white shift in some adjustments like saturation.

And: Does anyone have links to info of how perceptual gamut transforms work? (implementation, not just an explanation of how it looks)



Also thanks to everyone posting helpful things on here.

[andy kh]

in mlvApp when i resize lets say i shoot in 1920 by 818 which is 2.35:1 and export in dnxHD format in 1080p the the height is stretch which is not the same case with resolve or premiere pro
so upcaling or resizing not possible in mlvapp

[Luther]

If it is possible could you give me a sample (s)?

Here you go:



Download the MLV (90MB) here:
https://drive.google.com/open?id=1zksn3AZAZc8d0bX8V8cxHcMIlj5Y9ln4

Download PNG's with all gamut test from BetterProcessing:
https://drive.google.com/open?id=1B9Pfij9pjymNsXWCDFhhCQxbiqCB_Atd


As I said, this is not very scientific. The MLV was recorded using 50D, with WB at 5500K in direct sun light. I'm using a old Nikkor lens, so it should be a bit warmer because of the lens coat. Also, the pantone palette is quite old and the paper started to get a bit yellow. Anyway, should be enough to do some tests. I can assure you the rawtherapee is very accurate to what I see in real life.

[masc]

@masc Are you able to compile master? I think this commit broke it:
https://github.com/ilia3101/MLV-App/commit/88e803d1033640953edd284de4bccdae88645c63

frame_caching.o: In function `get_mlv_raw_frame_debayered'
undefined reference to `wb_convert'
undefined reference to `CA_correct_RT'
undefined reference to `wb_undo
error: ld returned 1 exit status

Yes, I can compile here on OSX. What OS do you use? (If it is not OSX I am sorry... I am in holiday and no Win/Linux in the near.)

in mlvApp when i resize lets say i shoot in 1920 by 818 which is 2.35:1 and export in dnxHD format in 1080p the the height is stretch which is not the same case with resolve or premiere pro
so upcaling or resizing not possible in mlvapp

dnxhd is extremely limited in options. If I remember right 2.35:1 was not possible at all. Maybe better use another codec.

[andy kh]

dnxhd is extremely limited in options. If I remember right 2.35:1 was not possible at all. Maybe better use another codec.

resizing to full hd or 2.5k or 4k is not possible in any codec if i shoot in 2.35:1 as the height of the video get stretch. i have been using the resizing option in premiere pro and resolve for many years but no problem

[Danne]

resizing to full hd or 2.5k or 4k is not possible in any codec if i shoot in 2.35:1 as the height of the video get stretch. i have been using the resizing option in premiere pro and resolve for many years but no problem

Please provide the resize settings you set in premiere and exact codec used. Describe how this differs from Mlv App. As masc says dnxhd is very picky with resizing but I sense you are mixing info here.
As always. A small sample mlv file will never hurt anyone.

[andy kh]

https://ibb.co/wwvs6Z4

here is the setting in premiere pro
its 1920 by 1080. it works in any codec both in premiere pro and resolve

[Danne]

So footage is 1920x818 and you export to 1920x1080 with a black border? That´s it? Try match sequence setting. Pretty sure it won´t export dnxhd.