Vertical stripes revisited (5D Mark III)

[a1ex]

Topic split from http://www.magiclantern.fm/forum/index.php?topic=17021.0

Old discussion about vertical stripes: http://www.magiclantern.fm/forum/index.php?topic=5614.50

With crop_rec, these stripes also appear in H.264. They can be fixed in post, but it would be best if we could avoid them in the first place.

Vertical stripe fix for H.264:

stripe-fix-h264.html

Note: the stripes we are talking about in this thread are visible in highlights (e.g. sky at low ISO).

Is the vertical banding present in the highlights or shadows?

If the banding is in the highlights, darkframe subtraction won't help. Banding in the highlights is a sign of a multiplicative defect (the column gains are off slightly, which is fixed by multiplying pixels values by some correction factor).

If the banding is in the shadows, the "vertical stripe fix" won't help. Banding in the shadows is a sign of an additive defect (there is some linear offset, which is fixed by simply subtracting some correction value from the pixel values).

Original message:
[...]
I'd say let's review the vertical stripe fix on 1.1.3, and if it's everything alright, I'll include it in the main builds (and fix the 1.2.3 crop build) soon.

[GutterPump]

I just did a test,

You can see the video there :

pass : ML

Of course images are overexposed and underexposed for a best view of the stripes, it's not a final grade.

Hope it will help.

My conclusion is, the vertical stripes fix is working, the strips are softer. But in fact, it is invaded by the evil pixels. Is there a more effective solution than PixelPatcher that leaves no trace after correction ?

[a1ex]

I'm unable to see the video; can you upload some small 1:1 crops?

Was the test done in crop mode or not? I actually expect some problems in crop mode, similar to the H.264 issue from above. What software did you use for raw conversion? I thought most of them already handle bad pixels very well.

[GutterPump]

crop3x.2016Apr02.5D3113
Extract MLV with raw2cdng v 1.7.5 | Vertical banding correction : On
1920x1080 | 200 ISO




crop3x.2016Aug23.5D3113
Extract MLV with raw2cdng v 1.7.5 | Vertical banding correction : On
1920x1080 | 200 ISO



crop3x.2016Aug23.5D3113
Extract MLV with raw2cdng v 1.7.5 | Vertical banding correction : On
PixelPatcher OFX : On
1920x1080 | 200 ISO
(red arrow are showing PixelPatcher traces issues)



The test was did without crop mode, but i can do the same with it.

What software did you use for raw conversion? I thought most of them already handle bad pixels very well.

What softwares do you have in mind for correct bad pixels ? I always use raw2cdng 1.7.5 but i dont saw any options for correct it.

[a1ex]

Since the vertical stripe fix is in camera, you must not also correct it in post-processing. I thought this was obvious.

For the bad pixels, can you try MLVFS or mlv_dump?

[GutterPump]

Since the vertical stripe fix is in camera, you must not also correct it in post-processing. I thought this was obvious.
For the bad pixels, can you try MLVFS or mlv_dump?

Yes i know, but i did the test with vertical stripes correction ON and OFF with raw2cdng 1.7.5 and MLV file from 23aug build, there is really no difference.


Vertical banding correction : On



Vertical banding correction : Off


MLVFS make my computer crashing, i'm not on my computer's work, it's my laptop for this time, i will try later. But i can already say bad pixels are gone very well with MlRawViewer v1.4.3

[Kharak]

Vertical Stripe Fix, in camera??

Wow, how is this done @Alex?

[a1ex]

Canon code does it, see the pull request description.

This was probably a bad decision taken back in 2013 (see the comments in raw.c).

[GutterPump]

Do you think it will be possible to design a new version of raw2cdng with the option to correct the bad pixels ?
Unless this is already the case but I did not see the option provided for this purpose ..

[a1ex]

It's very easy, but you need to ask chmee. I thought it's already done on most converters because some cameras (60D for sure) have such bad pixels in their raw output. Not to be confused with focus pixels.

[Danne]

Hi! Recorded a small clip mlv and 3x crop mode to check in the new dots. Exciting stuff. Mlv_dump --fixcp(fix cold pixels) does indeed a good job. Processing comes with a cost. It takes longer and I believe it has to be optimized. Check especially the shadowy parts in the pushed exposure photo. This dng was also opened up in acr which usually takes care of cold pixels.
Hard to see the improvement in the overall image since a1ex vertical banding code always given me stellar results but could this other raw stream deliver even better images you say?

DNG orginals(13mb)
https://drive.google.com/file/d/0B4tCJMlOYfirV2FvRjFQYWRTOGM/view?usp=sharing













Original size

[Danne]

hm, another issue came up with mlv_dump when I tried processing through scripting in MLP. I usually process a mlv file with four streams in parallell t o speed up things. When selecting fixcp mlv_dump only seems to work if it does the sequence starting from zero. When running something like mlv_dump -f 2-30 --dng --fixcp M24-1930.MLV dng is spitted out but without fixcp applied. This breaks parallel processing.

Original script looks like this

Code: [Select]


if ls "$jo"A_lut_hold/"MLV_mlv_dump_settings.txt"
then
mlv=$(cat "$jo"A_lut_hold/"MLV_mlv_dump_settings.txt" | head -1)
fi

~/Library/Services/MLP.workflow/Contents/mlv_dump -f 0-1 --dng $mlv -o "$output_dng"${BASE}_1_"$date_01"_ $FILE | awk '/Processed/ { print $2; }' > /tmp/magic_l_prores/framecount
    frct=$(cat /tmp/magic_l_prores/framecount) ;
    rm /tmp/magic_l_prores/framecount
~/Library/Services/MLP.workflow/Contents/mlv_dump -f 2-$(($frct/4)) --dng $mlv -o "$output_dng"${BASE}_1_"$date_01"_ $FILE &
~/Library/Services/MLP.workflow/Contents/mlv_dump -f $(($frct/4+1))-$(($frct/4+1+$frct/4)) --dng $mlv -o "$output_dng"${BASE}_1_"$date_01"_ $FILE &
~/Library/Services/MLP.workflow/Contents/mlv_dump -f $(($frct/4+1+$frct/4+1))-$(($frct/4+1+$frct/4+1+$frct/4)) --dng $mlv -o "$output_dng"${BASE}_1_"$date_01"_ $FILE &
~/Library/Services/MLP.workflow/Contents/mlv_dump -f $(($frct/4+1+$frct/4+1+$frct/4+1))-$frct --dng $mlv -o "$output_dng"${BASE}_1_"$date_01"_ $FILE

[axelcine]

Hooray! Chapeau!

[a1ex]

When selecting fixcp mlv_dump only seems to work if it does the sequence starting from zero.

Just pushed a change that hopefully solves it (didn't actually try). It's in the bad_pixels branch.

Also did a few other related changes to mlv_dump:
- cold pixel fix is now enabled by default
- vertical stripe fix is now disabled by default
- option to scan every single frame for cold pixels (slow, but I remember some reports with moving cold pixels, for example with very bright specular highlights)

Processing comes with a cost. It takes longer [...]

Unless you have LOTS of hot pixels, processing time should not be noticeable. This step only processes a tiny percentage of the entire image (unlike the stripe fix, which processes every single pixel).

Benchmarks on a 1GB full-res MLV I had around (with only a few cold pixels), after a few test runs to cache the file:

Code: [Select]

time mlv_dump 59600001.MLV --dng
real 0m6.457s
user 0m1.260s
sys 0m2.912s

time mlv_dump 59600001.MLV --dng --no-fixcp
real 0m6.393s
user 0m1.044s
sys 0m2.984s

time mlv_dump 59600001.MLV --dng --fixcp2
real 0m14.115s
user 0m6.652s
sys 0m3.032s

time mlv_dump 59600001.MLV --dng --fix-stripes
real 0m29.101s
user 0m12.200s
sys 0m2.756s


[Danne]

Just compiled mlv_dump from the bad_pixel branch. Tried shortly and you fixed parallell processing and fixcp is on by default. Great!
Here is the mlv_dump binary for anyone who wants to test out.
*updated 29/8 2016
mlv_dump

[Danne]

Just reran my test dng sequence and the fixcp seems to clean up the photos more or less perfectly to this sequence. Pushed the exposure and no color cracking color blotches to be seen hiding. (Opened up in acr which probably cleaned up the dng a little bit more by default).

[Danne]

I posted a MLP version which will work with files coming from the crop_rec.mo module.
http://www.magiclantern.fm/forum/index.php?topic=13512.msg171272#msg171272

Tested with time command and cold pixel fix is way faster than vertical stripes correction. Probably around twice the speed.Maybe even faster. My mistake before was I had both vertical stripes and cold pixel fix turned on so of course slower.

Just tested briefly with h.264 material and it had some pixels showing on higher isos. Found a filter from ffmpeg which probably can get rid of those in post.
https://ffmpeg.org/ffmpeg-filters.html#delogo

dmilligan talked about metadata to find out what stream is doing what , mv720, mv1080. Could the modes be specified something like
crop_mode_1
crop_mode_2
crop_mode_3

or

crop3xmode_1
crop3xmode_2
crop3xmode_3

Maybe even shorter

crop3xm_1
crop3xm_2
crop3xm_3

Thanks a lot for this great module.

[GutterPump]

I just discover an issue between the 2 april and 23 aug version.

I can't properly recovery  hightlight with the 23aug version in Resolve, highlight stay pink.

Exemple :


02 april build


23aug build


With the same setting (Balance color, tint etc..)

[Danne]

Put up a dng file? Could you check white levels with exiftool?

[GutterPump]

Yes i always work with DNG files in Resolve.

Here DNG from  02 apr and 23 aug builds

https://www.dropbox.com/s/lc7w0caliwc55s1/M24-1019_23augapr00000.dng?dl=0

https://www.dropbox.com/s/2xwo4w3jtepm9hl/M24-1024_2apr00000.dng?dl=0

MLV :

https://www.dropbox.com/s/h4nbsqkujmil6ue/M24-1019_23augapr.MLV?dl=0

https://www.dropbox.com/s/e6igo1ivfo97b4g/M24-1024_2apr.MLV?dl=0

With level is the same for both : 65535
Extraction was done with raw2cdng 1.7.5

[a1ex]

In the first DNG from above, the white level is at 60375 (this DNG was promoted to 16-bit data). However, I cannot reproduce this behavior - white level on my camera, with the latest build, is at 16383 (for 14-bit data). ISO 100, 1/33, 3x crop, 1080p25.

Just in case - can you upload DNGs created with mlv_dump? The above DNGs were scaled by the converter.

I don't expect this issue because I didn't change the register configuration. The problem might be random and appearing on both builds - can you rule out this case?

To recover existing footage, reduce the white level in the DNGs with exiftool (for the above DNG, 60374 should do the trick).

[GutterPump]

I can't use mlv_dump, i don't work on MAC, and MLVFS don't work well with my PC (this is why i use raw2cdng)

But i have upload MLV, if someone has the courage to download 700 mb ..

I will made others test with highligt and see and see how it goes.


EDIT :

I don't expect this issue because I didn't change the register configuration. The problem might be random and appearing on both builds - can you rule out this case?

After have done some new tests i think it was a false alert too, especially if you have not changed the portion of code that might generate this error, but in case I prefer to report if others people encounter this problem.

[a1ex]

I can't use mlv_dump

You can.

After have done some new tests i think it was a false alert too

Well, you've got a DNG with the white level incorrect. Can you find out what settings trigger the issue?

[GutterPump]

You can.

Thanks I did not know there was a windows version !

DNG from mlv_dump here :

https://www.dropbox.com/s/twruf4cc9jbsr9p/M24-1019_23aug_frame_000000.dng?dl=0

Well, you've got a DNG with the white level incorrect. Can you find out what settings trigger the issue?

It will be a long and laborious work for find it

But i will try because i want see this new build working well

[Quentin]

Tried with my 5D 1.1.3, R/G/B pixels here and there.
Need to do some more experiments
Thanks for the efforts