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

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.
5D3 1.1.3
5D2 2.1.2

andy kh

5D Mark III - 70D

masc

5D3.113 | EOSM.202

andy kh

5D Mark III - 70D

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 :D
5D3.113 | EOSM.202

andy kh

5D Mark III - 70D


Luther

Sorry for the late reply.

Quote from: masc on May 17, 2019, 11:09:07 AM
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.

Quote
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.

Quote
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.

Quote from: Ilia3101 on May 17, 2019, 11:30:33 PM
""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.

Quote
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

Quote from: timbytheriver on May 18, 2019, 06:07:39 PM
"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

Quote from: Luther on May 23, 2019, 06:27:13 PM
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.)
5D3.113 | EOSM.202

Luther

Quote from: masc on May 23, 2019, 07:14:06 PM
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. 8)
5D3.113 | EOSM.202

Luther

Quote from: masc on May 23, 2019, 08:38:02 PM
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

Quote from: Luther on May 23, 2019, 06:43:41 PM
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.

Quote from: Luther on May 23, 2019, 06:43:41 PM
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
5D Mark III - 70D

Luther

Quote from: Ilia3101 on May 26, 2019, 03:35:27 PM
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

Quote from: Luther on May 25, 2019, 02:09:35 AM
@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.)

Quote from: andy kh on May 26, 2019, 04:07:38 PM
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.
5D3.113 | EOSM.202

andy kh

Quote from: masc on May 26, 2019, 09:08:39 PM
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
5D Mark III - 70D

Danne

Quote from: andy kh on May 26, 2019, 09:18:04 PM
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
5D Mark III - 70D

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.