mlv_dump on steroids

Started by bouncyball, February 16, 2017, 07:10:10 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Gleaned on bash in windows 10. Will check out power shell definetaly :).
Seems there is need for a second vert stripe option, "always on" to be able to overide automation code and at the same time avoid forcing it on every dng.


Well... it "always on" when no stripe related switch is specified:

no switch        - analyze 1st frame, process all frames according to gathered data (code decides and prints out whether correction 'NEEDED' or 'UNNEEDED')
--no-stripes     - do not correct stripes at all
--force-stripes  - analyze every frame, process current frame according to gathered data (code decides and prints out whether correction 'NEEDED' or 'UNNEEDED')

Did you mean something else? :)


Always on, sure about that? Kharak is reporting bad results when force stripes isn´t selected? I think he needs to put up some demo pics here...


Yes normal correction is on by default. Look at output with --show-progress. There was a serious bug in there, stripe correction was done only to 1st frame. Sorry about that... will upload new fixed binaries soon. Thanks to Danne for the hint :)

Sure :) I already asked him about it.


Fixed binaries are uploaded. Link is the same @ 1st post.


You still need examples?

I jumped to the new script and mlv_dump Danne posted here:
once you go raw you never go back



Well. What would be good is to compare latest vertical stripes code in unified and crop_rec_4k versions of mlv_dump to a1ex older vertical stripes code. If there are a lot of footage that doesn´t get the stripe treatment we need to know. Could you check and compare Kharak and see what you come up with? You can simply do this test by exchanging mlv_dump in batch_mlv.


Well good idea. I don's have havily striped footage at the moment to test with.

@Kharak: If you do the test anyway test this mlv_dump as well. Also cut original mlv file(s) to have 1st 5-10 frames and put up them somewhere please.


Sure can do, but how do I cut the MLV's?

I used to use MLV_Diag from Chmee to cut the files, but it does not work with the lossless MLV's.
once you go raw you never go back


mlv_dump -f 5 -o OUTPUT.MLV INPUT.MLV

Beware output name must be different from input name or you end up with a 0 byte file.


once you go raw you never go back


I am uploading 3 Folders with DNG's from 3 separate mlv_dumps all containing 6 DNG's each, hope it enough. Bouncyball's mlv_dump, Danne's dump and latest Crop_rec dump (june 19th). All on the same mlv. The one I posted jpeg examples of in the crop_rec 4k thread. Good to have a standard.


I can not use your latest mlv_dump, it requires cygwin1.dll or tells me to "please reinstall the program". You mentioned something about win 10, I am on win 8.1 maybe that is why. So I used the previous version that I was using before.

This crazy connection. Download 4-5 kb/s and upload 130-150 kb/s. Thought I had to postpone these uploads 10 days from now.

I send you PM's when it is done.
once you go raw you never go back


Fixed the mlv_dump issue Kharak.
Can you post examples of the difference between vertical stripe code among the mlv_dump versions? A few close ups here would do the trick. Also link to your dng files. Would be great to also have the shortened MLV files. If we need to do some retests we could easliy recheck against the same files.


Yes I can, but I can not post the originals I sent you, publicly. I could send the DNG/mlv's to the relevant Devs, but that is not very open source.

So I have some other examples like this one I posted already in crop 4k thread once, much more visible stripes too.!8YIHGIJB!hzewH2JBX55vELsy2MPdp3gPSo2mTzlNKe_CQIVqu_o
But maybe this particular issue has more to do with highlight stripes. The other examples I gave you were stripes in the shadows. anyways, yours and Bouncyballs mlv_dumps fixed these stripes aswell, so if you like, I can send this. I got a very shady connection at the moment, but I will try and upload dng's and mlv's.

I have to cut the mlv in the middle somewhere to get this example in a 6 frame MLV, some code? suggestions?

This example has no flaring the first few seconds and that made, according to a1ex, the crop_rec4k mlv_dump to not remove it. (yours do though).
once you go raw you never go back


You can cut anywhere in the MLV file thanks to g3gg0 indexing code. For example:
mlv_dump -f 25-30 -o output.MLV input.MLV


Only took 50 attempts! but here it is.

Experimental Crop_rec4k MLV_dump - DNG's (June 19th Build):!pURzVaJQ!jGGhzZAWtHXRm-gX7LEfhQ

Danne's Batch MLV_dump - DNG's:!hZREiJZK!2j1SfZGur31XZJ0p2gvsbA

Bouncyball's MLV_dump on Steroids - DNG's:!9dZm3QSA!Q2XhjUCzWSWR5nE8NkEc4A

The cut MLV:!cF43DDqQ!z1J-HlaQscli88b0BeCzxfBRrV6HC6X-i1L1o88Kob0

I hope these can help. Let me know if the Scene should be different somehow. This example was my initial foré in to Vertical Stripe fix with the experimentals, but later I found out that I was having severe issues in the shadows aswell.

once you go raw you never go back


@Kharak: Thank you. Downloaded MLV.


Thanks K. Will check asap.


I am posting another example showing Vertical Stripes in the shadows, no matter what MLV_dump I use they are there. FYI: of the bat in this case I see no difference in the shadow stripes between MLV_dump from Bouncyball/Danne or A1ex's Experimental MLV_Dump (june 19th). I did not pull all of them together in to and editor to check differences. No matter, stripes are there.

On a static scene the Vertical Stripes are well hidden, but as soon as movement is going on, either camera movement or subject movement across shadows, they become very visible.

Look Camera Right, the shadow on his cheek and throat, MLV Example:!sAZCABKK!XHWF4aGHue6Uu1356gufLS7_7NALDx5D5ucQG3iZPJs

Set MLRawViewer Curve to Log-c add a punchy LUT of your choosing. Preferably one that just barely crushes blacks and raises highlights to almost blow out. Raise the EV to +1.51 (or there abouts) to emulate the Cinelog-C Workflow, where you increase the Signal Strength, this should highlight the stripes. And ofcourse play at 24 FPS.

These stripes are not just visible to the Pixel Peepers but for the "normal" audience too. And hiding the stripes in blacks is not a workable solution, way too much DR is lost to crush them out.

The problems persists after Noise Reduction as the algorithms "think" it's important information, atleast noise dithers the stripes somewhat, but I don't like 5D noise in those medium dark shadows, and stripes are still visible with or without NR. I took some screenshots with NR and full grade, but on the screenshots they disappear because no movement, I hope you can replicate, if not let me know.

When playing the converted DNG's in MLRawViewer and having Vertical Stripe fix ON, the Vertical Stripes that MLV_dump could not get rid of, disappear. At first it looks perfect! But at a closer look I see it introduces Horizontal stripes in its place instead, not as severe as the Vertical Stripes, but Horizontal Stripes are there. MLRawViewer will most of the time remove the Vertical Stripes that MLV_dump could not, but at total random will leave chunky Vertical Lines through the frame where any Black or high contrast source is in an image or these Horizontal small lines in medium to dark shadows.

Unfortunately I can't export Prores from MLRawViwer, that just stopped working for me many months ago.

Let me know if I can do something else.
once you go raw you never go back


This is called pattern noise, and it's unrelated to what we call "vertical stripes". If a dark frame doesn't fix it, there is an experimental algorithm in MLVFS, although, for best results, you may have to adjust things directly in the source code.

Try exposing properly next time. Since the highlights are not critical in this case, you should have increased the exposure by 2 stops (which would make a big difference in shadows and midtones, but will also require some highlight recovery capabilities from your raw processor). To clip the skin tones (near the window), you would need +3.5 stops on top of your current exposure level, so there's plenty of headroom.

To recap:
- pattern noise in shadows -> use a dark frame
- vertical stripes in highlights (sharp, not noisy) -> use a flat frame
- both kind of defects -> use both calibration frames.

For exposure:
- clouds, sky, buildings, out of focus backgrounds: clipping 1 or 2 channels should be OK
- skin tones: do not clip anything

(unfortunately Auto ETTR doesn't have face detection)

For existing footage, you should be able to record the calibration frames afterwards.


Pattern noise setting is ported to mlv_dump for steroids.


Thanks for pointing out - will definitely experiment with this option as soon as my PC will be able to play videos again.


And @Kharak. Also try out chroma smooth settings. 2x2 with darkframes works wonders on eosm for instance.



What are the dis/advantages of using Chroma Smoothing? I must have read something about it years ago, that it crushes details or something, because I've been avoiding it like the plague. Besides, if Chroma Smoothing is a fix for these issues and has no obvious caveats, shouldn't it be On as standard for every converter? For me, anything that destroys detail I avoid, especially on 5D3 because the perceived resolution is so small as is.

And how do I do FPN fix in mlv_dump? Do I need to make FPN Frames like Darkframes ?


Okey thank you, so its FPN. So now the silly questions. MLRawViewer manages to get rid of them with its vertical Stripe fix, but introduces artifacts like horizontal stripes and Chunky vertical stripes in black/dark spots and/or high contrast sources instead. Is it in anyway possible to combine the best of both worlds? It is my understanding that MLRawViewer uses OpenGL shaders with combination of different coding languages, ty @bouncyball, but it does a fine job at removing these vertical FPN except for generating other artifacts. Thoughts?

I find the exposure to be fine for my style, I like creamy soft highlight roll-offs and ETTR'ing too much usually ruins that, especially blowing out two channels, that is just not recoverable. This shot could have been +0.5 EV higher, maybe +1, that's a big maybe. But for my shooting style it's good enough. The shadows hold a lot of information underneath the noise, something Temporal NR is good at extracting. I just can't get rid of the FPN.
Quick grade:!FVwXSSpI!4lyl105BGrLCU7fcPEJVxqoX1jVxVaGZpl5MzhU2gbY .jpeg

Or maybe I need to learn to Pull exposure better in post.

This FPN in the shadows was not a problem for me with this shooting style in Vanilla 24p 3x3 1080p. I think the sensor is pushed too much in 60p mode, introducing more FPN than normal. Just a hunch I have.

btw bit off topic, a line above in the link you posted:
QuoteThe read noise can be isolated by taking a "black frame" image, an exposure with the lens cap on and the highest available shutter speed; there are thus no photons captured, and only the electronic noise from reading the sensor remains.
Is this the actual proper way of doing a Darkframe ? Setting shutter speed to the highest available?

And yet again, everything points to Darkframe+Flatframe for the ultimate image. But for any kind of production that is not possible as is, on Windows atleast. Its just way too much manual work, decompressing, sorting ISO's, sorting lenses, reprossesing for Darkframe+Flatframe, to me it just doesn't seem feasible. Not the Flatframe thing atleast. I have some Vintage lenses that have quite big variations in the Vignetting at the different F-stops, from 1.4 up to 5.6 and they are all Manual. Here's crossing fingers for Danne's venture in to Windows Darkframe automation. ;)

As always, let me know what else I can help with.
once you go raw you never go back