Author Topic: mlv_dump on steroids  (Read 15438 times)

Kharak

  • Hero Member
  • *****
  • Posts: 708
Re: mlv_dump on steroids
« Reply #125 on: August 18, 2017, 01:42:36 PM »
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

  • Hero Member
  • *****
  • Posts: 3474
Re: mlv_dump on steroids
« Reply #126 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.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10447
  • 5D Mark Free
Re: mlv_dump on steroids
« Reply #127 on: August 18, 2017, 07:01:52 PM »
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

  • Hero Member
  • *****
  • Posts: 708
Re: mlv_dump on steroids
« Reply #128 on: August 18, 2017, 10:06:41 PM »
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

  • Hero Member
  • *****
  • Posts: 3045
  • 5D3 / M1 / 7D / 70D / SL1
Re: mlv_dump on steroids
« Reply #129 on: August 19, 2017, 01:56:54 AM »
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

bouncyball

  • Senior
  • ****
  • Posts: 362
Re: mlv_dump on steroids
« Reply #130 on: August 19, 2017, 12:08:25 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

  • Hero Member
  • *****
  • Posts: 708
Re: mlv_dump on steroids
« Reply #131 on: August 19, 2017, 12:24:50 PM »
I will find you some examples.
once you go raw you never go back

mothaibaphoto

  • Senior
  • ****
  • Posts: 332
  • pesky kid
Re: mlv_dump on steroids
« Reply #132 on: August 20, 2017, 04:56:52 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

  • Hero Member
  • *****
  • Posts: 708
Re: mlv_dump on steroids
« Reply #133 on: September 03, 2017, 06:46:10 PM »
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

  • Senior
  • ****
  • Posts: 362
Re: mlv_dump on steroids
« Reply #134 on: September 22, 2017, 04:57:44 PM »
@Kharak

Sorry about very late answer :)

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

  • Freshman
  • **
  • Posts: 56
Re: mlv_dump on steroids
« Reply #135 on: October 24, 2017, 10:33:30 AM »
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

  • Hero Member
  • *****
  • Posts: 2091
Re: mlv_dump on steroids
« Reply #136 on: October 24, 2017, 03:32:51 PM »
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.

Code: [Select]
mlv_dump -o output.mlv -f 5 input.mlv
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

bouncyball

  • Senior
  • ****
  • Posts: 362
Re: mlv_dump on steroids
« Reply #137 on: October 24, 2017, 07:04:48 PM »
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]
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

  • Senior
  • ****
  • Posts: 362
Re: mlv_dump on steroids
« Reply #138 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.

ErwinH

  • Freshman
  • **
  • Posts: 56
Re: mlv_dump on steroids
« Reply #139 on: October 24, 2017, 07:41:18 PM »
This.

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

  • Freshman
  • **
  • Posts: 56
Re: mlv_dump on steroids
« Reply #140 on: October 25, 2017, 11:38:02 AM »
I have a recording where the old mlv_dump-on-steroids fails and the new one works:

Old version:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
~/mlv_dump.linux --fpi 0 -f 5 --dng
I'll send the mlv file per PM.

Code: [Select]
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

  • Senior
  • ****
  • Posts: 362
Re: mlv_dump on steroids
« Reply #141 on: October 25, 2017, 12:40:11 PM »
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

  • Freshman
  • **
  • Posts: 56
Re: mlv_dump on steroids
« Reply #142 on: October 25, 2017, 02:43:15 PM »
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

  • Freshman
  • **
  • Posts: 56
Re: mlv_dump on steroids
« Reply #143 on: October 26, 2017, 03:59:17 PM »
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

  • Senior
  • ****
  • Posts: 362
Re: mlv_dump on steroids
« Reply #144 on: October 26, 2017, 06:19:49 PM »
Thanks, I'll check it out.

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

ErwinH

  • Freshman
  • **
  • Posts: 56
Re: mlv_dump on steroids
« Reply #145 on: October 27, 2017, 03:28:59 PM »
Official mlv_dump has the same issue.

bouncyball

  • Senior
  • ****
  • Posts: 362
Re: mlv_dump on steroids
« Reply #146 on: October 27, 2017, 06:45:23 PM »
OK thank you.