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.

bouncyball

@VGT

Quote from: VGT on July 09, 2018, 04:09:21 PM
Question 1: Can anyone give me an advice how to fix 7D BANDING, using the App?
And  2: How should I use Dark frame subtraction correctly - where to read about it?? - should it be a still image or video and how to guess it works or not?
Answer 1: Upload sample MLV and cap on MLV somewhere and we will see what can be done. However our mileage can vary depending on footage.
Answer 2: Record MLV with cap on (~150-250frames will be enough), after that it have to be averaged. Import this MLV as usual clip (not as dark frame) into MLV App then go to export settings and select Codec MLV with option combo box set to Averaged Frame.



Export MLV. This will give you 1 frame averaged MLV which now can be loaded as dark frame in appropriate RAW correction section.

regards
bb

IDA_ML

Hello Masc, Bouncyball and Ilia3101,

Thanks for this clarification.  I understand that Dual ISO is a processor intensive operation.  I have performed a lot of tests with shooting and MLVApp-processing Dual ISO files from the 100D and have to say, I am really amazed at the quality with this technique.  If properly exposed to the right, the dynamic range is drastically improved with almost no perceptible noise in the drarkest areas.  And most importantly, Dual ISO videos have a very natural look - way better than HDR techniques.  Here is an example from this morning shot at 2520x1304 resolution with Dual ISO 100/800, processed entirely with MLVApp v.017 and exported in H.265:

https://we.tl/eecN6HWi0O

A real achievement, CONGRATULATIONS !!!

I have a question.  Does the export format affect the render speed and if yes, would you suggest an export format with faster rendering speed?  Thanks.

VGT

Bouncyball, thank you very much for the explanation about the dark frame - I couldn't imagine such a workflow!!!))
That's great, I will test now, how it works with my footage more precisely! But I think, dark frame works best at high ISO, while my banding is most ugly at 100-200 ISO, but I'll try different settings and report.

I've just experimented with "PATTERN NOISE" button - it does a great job, removing vertical banding pattern of 7D, but in the areas of the frame with high contrast it causes strange artifacts.

That's how my banding noise looks originally




Another example below - where banding is not so visible, but it helps to see the effect of the "PATTERN NOISE" button BEFORE-AFTER:

PATTERN NOISE - OFF




PATTERN NOISE - ON - banding GONE, but new grey stripes appear.



masc

@VGT: have you tried setting "Vertical Stripes" to normal? Should work for exactly what I see in your pictures.

@IDA_ML: Oh yes, the dynamic is huge in your clip! Very nice.
Renderspeed is always the same (for the same settings chosen) because we always give the same series of uncompressed pictures via pipe to ffmpeg or to the AVFoundation class. The codec needs different time to encode this into your video file. But when dual iso is enabled, you won't recognize any difference here, because dual iso processing is so slow. On non dual iso clips ProRes 422 AVFoundation was one of the fastest codecs in my tests.
5D3.113 | EOSM.202

bouncyball

Quote from: masc on July 10, 2018, 12:19:16 PM
@VGT: have you tried setting "Vertical Stripes" to normal? Should work for exactly what I see in your pictures.
+1 :)

VGT

masc,
sure I tried "Vertical Stripes" - Normal and Force - NO changes at all. It doesn't work for my kind of stripes.:)
The only setting, that kills the noise banding is "PATTERN NOISE", but it makes it's own "stripes"/

Danne

If banding appears in shadows darkframe subtraction helps to reduce banding.

VGT

bouncyball

Did exactly as you wrote:
here is a short piece of mlv file with banding
https://drive.google.com/open?id=1OO7KM1SLF8_FMY7ztTIW-86qyk3OVsii

here is a 150 frame "dark" mlv with cap on (not averaged, just shot)
https://drive.google.com/open?id=1V_rclSwp4MCbrB54ptwjyoYhZYkQgY92

I wonder: should I increase the brightness of the dark video to see the noise visually before exporting as average dark frame or leave as it is absolutely dark?

VGT

Danne,

Thanks,
I am just trying now to reduce banding with dark frame subtraction - but not very successfully... I can't see significant differences.

masc

@VGT: thanks for the sample.
@bouncyball: do you have an idea why vertical stripes does nothing for this clip? Could you debug? Something is very different to the 7D I hold in my hands some weeks ago: whitelevel is at 16383, on my sample it was at 15500 (at least highlight reconstruction works for whitelevel slider at full 16bit - very strange). Who knows what else is different here what maybe makes vertical stripes algorithm not working...
For me the stripes themselves are looking 100% the same as on the 7D I was playing with.
5D3.113 | EOSM.202

bouncyball

Quote from: VGT on July 10, 2018, 04:46:26 PM
I wonder: should I increase the brightness of the dark video to see the noise visually before exporting as average dark frame or leave as it is absolutely dark?
You must leave it as is. When you exporting MLV it is not processed anyway (just averaging).

bouncyball

Darkframe does not help either. This vertical pattern in the shadows somewhat familiar to me. I also had 7D several years ago.

Hint: maybe ask a1ex for help/explanation?

Edit: It indeed looks like vertical stripes. And stripes detection, if I undestand correctly, happens on upper lite part of the image. Here sky is clean. SO maybe that is the problem. a1ex is the author of this algorithm that is why I think it is better to ask him.

Danne

@VGT
Are you on mac? Maybe you could try Switch and process with an older version of mlv_dump in there. Select (m) in main menu to get there. I think I use an older vertical stripes code in there. You could get lucky.

VGT

Danne,
Yes, I am on mac... but to tell the truth, I didn't get in what "main menu" should I select (m)? In MLV App? Don't see any((
Could you, please, explain!

bouncyball,
The sky in my shots is always absolutely clean without any stripes, the vertical stripes are ONLY in the darkest shadows after I pull them out increasing the exposure in post.

Danne


VGT

O, thanks, I'll try it!

Edit: oh, no, I tried it - and I changed my mind, I prefer the interface of MLV App)))) - I'd better smash my 7D against the wall :)
Thanks everyone for your attention and advice!

feureau

Bugreport: If MLVApp encounters a corrupt MLV, it will crash.

If you have a bunch of MLVs in the Session and you batch export them all, when MLVApp encounters a corrupt MLV, it will spit out an error like this:



If you click cancel, the whole thing will just crash.

Maybe allow an option to abort/retry/ignore(skip) the file?

masc

Quote from: feureau on July 11, 2018, 04:42:29 AM
Bugreport: If MLVApp encounters a corrupt MLV, it will crash.

If you have a bunch of MLVs in the Session and you batch export them all, when MLVApp encounters a corrupt MLV, it will spit out an error like this:



If you click cancel, the whole thing will just crash.

Maybe allow an option to abort/retry/ignore(skip) the file?
Thanks for the report - I fixed it two days ago. There was a a little line missing in the code, so the app was running into undefined memory what crashes the app. But I will recheck what happens on export.
5D3.113 | EOSM.202

bouncyball

Quote from: feureau on July 11, 2018, 04:42:29 AM
Bugreport: If MLVApp encounters a corrupt MLV, it will crash.
It depends on corruption type. Many cases are handled gracefully, some maybe not ;)

Quote from: feureau on July 11, 2018, 04:42:29 AM
If you have a bunch of MLVs in the Session and you batch export them all, when MLVApp encounters a corrupt MLV, it will spit out an error like this:<br
This error expected when header block name is wrong.

Quote from: feureau on July 11, 2018, 04:42:29 AM
Maybe allow an option to abort/retry/ignore(skip) the file?
Already there.

Remaining crash reason explained and fixed by masc (freeing some nonexistent mutex).

regards
bb

70MM13

It would be awesome if you guys added more demosaicing algorithms.  Here's an example of one other from rawtherapee:

https://www.magiclantern.fm/forum/index.php?topic=22483.msg203990#msg203990

masc

Quote from: 70MM13 on July 11, 2018, 02:36:20 PM
It would be awesome if you guys added more demosaicing algorithms.  Here's an example of one other from rawtherapee:

https://www.magiclantern.fm/forum/index.php?topic=22483.msg203990#msg203990

And which algorithm did you use in your example? Default in rawtherapee is AMaZE.
https://rawpedia.rawtherapee.com/Demosaicing
5D3.113 | EOSM.202

70MM13

Sorry, the filenames are the algorithms used.

It's RCD.

I've edited the linked post for clarity.

masc

Hm, okay. But is it really better? For me it looks just more blurred than AMaZE. All artifacts are still there, sometimes with more false colors.
5D3.113 | EOSM.202

70MM13

I find that different algorithms are beneficial for solving different problems.

Almost all the time, amaze is a great choice, but sometimes, it's great to have other options, especially when it solves a problem!

bouncyball

Quote from: 70MM13 on July 11, 2018, 03:26:55 PM
Almost all the time, amaze is a great choice, but sometimes, it's great to have other options, especially when it solves a problem!
That's right but... I'd rather spend time on some other bilinear debayer variant optimized for maximum speed to play high resolution clips in real time.