mlv_dump on steroids

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

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Kharak

Okey, luckily not an isuue I come across on the 5d3. Perhaps the 3x3 bayer helps get rid of it, as it has 8 other pixels to draw on in the case of a cold pixel?
once you go raw you never go back

Danne

On the 5D mark III there is seldom any use of cold pixel fix. If you use darkframes they take care of them anyway. As well as the hot pixels if any.

a1ex

Cold pixels used to be a problem before this PR; see also this analysis. I think most of them were actually pixels marked as bad by Canon firmware (they mark them as 0, so they are very easy to detect by our "cold pixel" heuristic). Some of them were not 0; they were only below the black level, although I don't remember the specific conditions one would get such artifact.

Need to double-check whether there are still cold pixels on other models (60D and 600D were troublesome, possibly also 550D and 500D, not sure about others). One has to compare a MLV (or a DNG developed with all processing turned off) from any recent build, vs any 2016 build.

Some of the "cold pixels" used to appear near very strong highlights (there were some bug reports about this for 5D3, with green artifacts: this one or this one or this one). These are dynamic and won't be fixed with default processing settings (they require scanning every frame for bad pixels, which is very slow: option --fixcp2).

Kharak

Those examples all seem to derive from bad post-processing software of the mlv/raw. No?

The only thing i see as a consistent issue with the 5D3 is with red channel in high contast to other colours, be it black or blue or green etc. there is an example on the forum from maybe 2 years ago or more where a guy showed an example from some red flowers in the foreground with a blue sky behind (red and blue channel interacting) and he had grey pixels howering over the red colours (in the blue sky) some few pixels away. I cant find it, but remember it as later I myself have seen this a lot. It comes mostly from "really" red sources.

I spend so much time on fishing vessels shooting for clients and for personal use. Here the issue comes up a lot, the bright red/orange Oil Clothes that is the typical colour of any fishermans outfit, in contrast to basically any other darker colour will exerborate this behaviour. Gray pixels hovering over the edge of the Red/orange.

I also recall back in the day shooting on boats, pre dslr, shooting with Panasonic and sony, crappy bit depths, they could not reproduce the true colours of the Outfits, they would turn in to a red blob/mess or orange mess, very difficult to work with.

Dont have my computer, so no examples to show from.

The colour is very intense, its made to be as visible as possible in case of MOB or Blackouts.

once you go raw you never go back

DeafEyeJedi

Quote from: Danne on August 18, 2017, 01:47:58 PM
On the 5D mark III there is seldom any use of cold pixel fix. If you use darkframes they take care of them anyway. As well as the hot pixels if any.

+1  8)
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

bouncyball

Quote from: Kharak on August 18, 2017, 10:06:41 PM
I also recall back in the day shooting on boats, pre dslr, shooting with Panasonic and sony, crappy bit depths, they could not reproduce the true colours of the Outfits, they would turn in to a red blob/mess or orange mess, very difficult to work with.
Yeah I remember that mess of deep saturated colors with my SONY and JVC analog and early DV cameras. :) That JVC had 25p progressive scan mode and it hooked me, funny the DR was about 5-6 stops I guess :P

If you'll find the time, post gray pixel artifact examples please.

bb

Kharak

I will find you some examples.
once you go raw you never go back

mothaibaphoto

Quote from: bouncyball on August 17, 2017, 10:46:25 AM
I guess if dark/flat frame is used there is no need to fix badpixels or stripes after that.
bb
If only that was true, but not :(
I've processed file with --no-stripes --no-fixcp twice - one time with black frame, one - without and than pixel peep the difference.
Hot pixels(bright ones) are really gone with black frame, cold/bad - no sure, i dont see any on both shots,
BUT, vertical stripes are the same on both!!! keep investigating, though...

Kharak

Here is an example with the Red Channel having difficulties with the high contrast edges.

Like in this example, look at the Boots of the guy closest to camera, the Red Oil Pants are outlining the boots around the edges. The edges get  This is pretty much consistent from 5D3.

It makes the Boot look "cut out" of the picture or placed there. The Gray pixels appear all over the edges.

When Sharpening the image which I always do, this effect becomes very obvious.

DNG:
https://mega.nz/#!1MoRjCKZ!yU7zbQFKMEpEi4VxCqYIqOdkfVLzDvfnKgOf3JKt-aQ
once you go raw you never go back

bouncyball

@Kharak

Sorry about very late answer :)

Quote from: Kharak on September 03, 2017, 06:46:10 PM
It makes the Boot look "cut out" of the picture or placed there. The Gray pixels appear all over the edges.
When Sharpening the image which I always do, this effect becomes very obvious.
Yeah you are right, now I understand what did you mean.

bb

ErwinH

I was working with the latest version of the crop_rec_4k branch on my 700D and the current linux (and windows) version of mlv_dump on steroids doesn't handle focus pixels any more. If you can update it, would be much appreciated. (I've compiled my own version for now, but I'm sure there are others with the same issue.)

dfort

Focus pixel fixing has been breaking on various experimental builds. Seen it happen on the EOSM too. Not sure what is going on but in one instance everything was shifted 8 pixels to the right.

Could you document which build, what settings, etc. you're seeing the focus pixels so we can try to reproduce the issue? Also posting a short MLV file would help. There's a way of trimming down an MLV file to only a few frames.

mlv_dump -o output.mlv -f 5 input.mlv

bouncyball

Quote from: ErwinH on October 24, 2017, 10:33:30 AM
I've compiled my own version for now, but I'm sure there are others with the same issue
What do you mean by this? Did you patched code of mlv_dump (+shift/-shift pixels) or managed to forge focus map for your particular case?

[/quote]
Quote from: dfort on October 24, 2017, 03:32:51 PM
Could you document which build, what settings, etc. you're seeing the focus pixels so we can try to reproduce the issue? Also posting a short MLV file would help.
+1

bouncyball

If you meant that only MacOS binary is updated and not Win/Linux ones - then yes, that's right ;)

Both now uploaded.

ErwinH

This.

Quote from: bouncyball on October 24, 2017, 07:12:59 PM
If you meant that only MacOS binary is updated and not Win/Linux ones - then yes, that's right ;)

Both now uploaded.

When I have a little more time I'll look at the different versions and where it goes wrong. I'll come back on this.

ErwinH

I have a recording where the old mlv_dump-on-steroids fails and the new one works:

Old version:
MLV Dumper
-----------------

Last update:  33ac267 on 2017-07-25 14:35:07 UTC by bouncyball:
pixel_proc: now supported both: newer .fpm with header or origin...
Build date:   2017-07-25 17:09:30 UTC


New version:

MLV Dumper
-----------------

Last update:  f44ffe0 on 2017-10-15 13:02:25 UTC by bouncyball:
pixel_proc: changes to focus pixel map generator
Build date:   2017-10-24 08:10:55 UTC


The command I use is:
~/mlv_dump.linux --fpi 0 -f 5 --dng

I'll send the mlv file per PM.

MLV Dumper
-----------------

Mode of operation:
   - Input MLV file: 'M17-1504.MLV'
   - Verbose messages
   - Verify file structure
   - Dump all block information
File M17-1504.MLV opened
File M17-1504.M00 not existing.
Processing...
File Header (MLVI)
    Size        : 0x00000034
    Ver         : v2.0
    GUID        : 5477059852982235116
    FPS         : 25.000000
    File        : 0 / 0
    Frames Video: 74094
    Frames Audio: 0
    Class Video : 0x00000001
    Class Audio : 0x00000000
Block: RAWI
  Offset: 0x00000034
  Number: 1
    Size: 180
    Time: 0.782000 ms
    Res:  1280x720
    raw_info:
      api_version      0x00000001
      height           1189
      width            1808
      pitch            2260
      frame_size       0x002900A4
      bits_per_pixel   10
      black_level      128
      white_level      1013
      active_area.y1   28
      active_area.x1   72
      active_area.y2   1185
      active_area.x2   1808
      exposure_bias    0, 0
      cfa_pattern      0x02010100
      calibration_ill  1
Block: RAWC
  Offset: 0x000000e8
  Number: 2
    Size: 32
    Time: 0.797000 ms
    raw_capture_info:
      sensor res      5184x3456
      sensor crop     1.62 (APS-C)
      sampling        3x3 (read 1 line, skip 2, bin 3 columns)
Block: IDNT
  Offset: 0x00000108
  Number: 3
    Size: 84
    Time: 0.811000 ms
     Camera Name:   'Canon EOS REBEL T5i'
     Camera Serial: '9C93E2F79'
     Camera Model:  0x80000326
Block: EXPO
  Offset: 0x0000015c
  Number: 4
    Size: 40
    Time: 0.823000 ms
     ISO Mode:   0
     ISO:        400
     ISO Analog: 88
     ISO DGain:  0/1024 EV
     Shutter:    20000 microseconds (1/50.00)
Block: LENS
  Offset: 0x00000184
  Number: 5
    Size: 96
    Time: 0.847000 ms
     Name:        'EF-S18-135mm f/3.5-5.6 IS STM'
     Serial:      ''
     Focal Len:   24 mm
     Focus Dist:  132 mm
     Aperture:    f/4.00
     IS Mode:     0
     AF Mode:     3
     Lens ID:     0x0000102E
     Flags:       0x00000000
Block: RTCI
  Offset: 0x000001e4
  Number: 6
    Size: 44
    Time: 0.863000 ms
     Date:        17.10.2017
     Time:        15:04:43 (GMT+0)
     Zone:        ''
     Day of week: 2
     Day of year: 289
     Daylight s.: 0
Block: WBAL
  Offset: 0x00000210
  Number: 7
    Size: 44
    Time: 1.495000 ms
     Mode:   9
     Kelvin:   5500
     Gain R:   483
     Gain G:   1024
     Gain B:   660
     Shift GM:   0
     Shift BA:   0
Block: VERS
  Offset: 0x0000023c
  Number: 8
    Size: 172
    Time: 58.597000 ms
  String: 'mlv_lite built 2017-10-16 20:22:53 UTC; commit 8ee7858 on 2017-10-16 20:21:52 UTC by alex: mlv_lite: fix 8..12-bit lossless in 720p on small cameras '

bouncyball

As you named it - "Old" mlv_dump supports focus pixel correction only by .fpm map files, while "New" one has built in map generator, hence does not require map file in the binary directory. For overriding the built in generator you should put the map file beside mlv_dump and if the name of the file matches the cameraID and raw buffer resolution it will be used instead.

Your sample MLV is recorded for mv1080 video mode and should be processed w/o issue, but... as you can see raw buffer resolution is 1808x1189, not 1190 and there is no .fpm file with that name by default. That is why "Old" version did not work for you out of the box (you had to rename the file to 80000326_1808x1189.fpm, this is the established standard used after MLVFS). On contrary "New" mlv_dump does not care about vertical resolution mismatches and will work for any Y resolution.

There is also one thing. If you're gonna process MLV recorded in crop_rec mode, then to activate correct built in map generator mlv_dump needs the switch '--is-croprec' on the command line. It is temporary solution until I implement parsing of RAWC header information to make sure this mode is indeed crop_rec.

regards
bb

ErwinH

Thank you for the explanation. Good that it wasn't anything serious.

I'll be shooting a new session tomorrow and will test it again.

ErwinH

Small bug report. If you set the output to a folder -o DNGFOLDER/ the wav file isn't exported.

If you set it to -o DNGFOLDER/prefix the wav file is exported.

bouncyball

Thanks, I'll check it out.

Edit: is that the same in official/vanilla mlv_dump?

ErwinH

Official mlv_dump has the same issue.

bouncyball


SharpieUser

Hello, I've been following these forums for over a year now, finally decided to make an account. I'm really stumped right now, and have a few questions. :D

Will (mlv dump on steroids) process my raw, dual iso files? and is there a guide on how to use this mlv dump?

the (batch mlv in out) program works great but it does not have any option for dual iso, does it? maybe i missed somthing.


I can process dual iso raw video on my macbook already through the mlvfs, but it takes WAY to long to transfer back over to my pc. around 20mins when copying a single 1g file off of the fuse mount ???.

Thank you for reading. any help will be greatly appreciated.


bouncyball

@SharpieUser

mlv_dump does not support dual iso processing, just fixing bad/focus pixels for dual iso with '--is-dualiso' switch. I wanted to implement this feature but then gave up, not worth it.

Instead I implemented it to the MLV App. Try it and and tell what do you think :)

regards
bb