I have a feeling the latest mlv_dump has the vertical stripe fix broken. With an older one (mlv_dump_4k branch, 906696acccb7, before bouncyball's massive rework):
mlv_dump --dng M03-2206-short.MLV
...
Vertical stripes correction:
1.00000 1.03970 0.97908 1.02393 0.99438 1.03635 0.97523 1.02068
With that correction enabled, the image looks good to me.
The first bad revision is:
changeset: 18872:78c4e8f422ff
branch: crop_rec_4k
parent: 18635:01fc07461da5
parent: 18870:1723fc397404
user: g3gg0
date: Tue Jan 16 20:57:02 2018 +0100
summary: Merged in bouncyball/magic-lantern/mlv_dump_cdng (pull request #841)
I've tried --force-stripes on 78c4e8f422ff; it doesn't seem to work, but it appears to run slower; what's going on?!
With stripe correction disabled, and "-b 14" on the new version, both mlv_dump versions (78c4e8f422ff aka "new" and 01fc07461da5 aka "old" or "right before bouncyball's changes) are writing the same raw data in the DNG (compared in octave). EXIF metadata is different, so I get different looks if I render them in ufraw for a comparison...
With stripe correction enabled, the raw output is different:
prctile((A-B)(:), [0 1 10 50 90 99 100])'
ans =
0 0 0 3 35 57 251
Looks like dcraw renders both old and new DNGs in the same way (it doesn't care about different metadata). So, here it goes:
old-ns.ppm /
jpg (old mlv_dump, no stripe correction)
new14-ns.ppm /
jpg (new mlv_dump, 14-bit output, no stripe correction; same as above; identical MD5)
old.ppm /
jpg (old mlv_dump, default settings)
new.ppm /
jpg (new mlv_dump, default settings)
new14.ppm /
jpg (new mlv_dump, 14-bit output)
I can see the fine pattern in the output from new mlv_dump after zooming to 300%. The stripe fix is working to some extent, but doesn't fully correct the issue.
I can not see any pattern in the output from old mlv_dump, but my pixel peeping skills are not the best.
Double-checking:
a = read_raw('new14-ns.dng');
# extract green channel for each column group
g1 = a(2:2:end,1:4:end);
g2 = a(1:2:end,2:4:end);
g3 = a(2:2:end,3:4:end);
g4 = a(1:2:end,4:4:end);
# compute the column gains (match everything to first column group)
black = 1792;
k = [1 median(((g1-black)./(g2-black))(:)) median(((g1-black)./(g3-black))(:)) median(((g1-black)./(g4-black))(:))];
# 1.00000 1.04030 0.97964 1.02433
# apply the correction
for i = 2:4, a(:,i:4:end) = (a(:,i:4:end) - black) * k(i) + black; end
# render the image (extremely hackish)
imwrite(uint16(a), "cor.pgm"); system("pgm2dng cor.pgm"); system('exiftool cor.DNG -ColorMatrix1="0.4716 0.0603 -0.083 -0.7798 1.5474 0.248 -0.1496 0.1937 0.6651" -ColorMatrix2= -ForwardMatrix1= -ForwardMatrix2= -AsShotNeutral="0.473635 1 0.624" -CalibrationIlluminant1=D65 -CalibrationIlluminant2='); system("dcraw -v -b 4 -g 1 1 -k 1792 -S 16200 cor.DNG");
# output nearly identical to old.ppm => the vertical stripe algorithm from old mlv_dump handles this particular image as expected.
cc @bouncyball (that's a bug report for mlv_dump on steroids).