Dealing with Focus Pixels in raw video

[otherman]

How can I help?

[Oswald]

So I tried to use the mlv_dump, but it got error.


C:\Users\Oswald\My Documents\new folder>mlv_dump -m -v [M17-2218.mlv]

 MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: '[M17-2218.mlv]'
   - Verbose messages
   - Verify file structure
   - Dump all block information
[ERROR] Failed to open file '[M17-2218.mlv]'

C:\Users\Oswald\My Documents\new folder>

And I have mlv_dump and M17-2218.mlv on the same folder and it dont work

but here is information of exiftool.

Sensor Width                    : 5280
Sensor Height                   : 3528
Sensor Left Border              : 84
Sensor Top Border               : 64
Sensor Right Border             : 5267
Sensor Bottom Border            : 3519

Original Image Width            : 5184
Original Image Height           : 3456

Image Size                      : 5184x3456

[Walter Schulz]

Try without brackets.

[dfort]

yes it features crop mode hack

Great!

How can I help?

I already mapped the focus pixels for the EOSM but it would be great if you could verify the accuracy using your method. I've got a full sized pixel map image but I've got to do some more work on it to make sure it lines up properly.

https://flic.kr/p/BYmBxR

I was thinking of making a "master" that covers the entire sensor. That way I can figure out the "crops" of the various video mode raw buffers. Problem is I'm getting different dimensions depending how I measure the sensor.

Running exiftool on a CR2:

Code: [Select]

Sensor Width                    : 5280
Sensor Height                   : 3528

A full resolution silent picture should use the entire sensor but exiftool reports no sensor size information and the image size as:

Code: [Select]

Image Width                     : 5280
Image Height                    : 3529

mlv_dump agrees with that:

Code: [Select]

    Res:  5280x3529
But that same full resolution silent picture in Photoshop is 5208x3477

My master pixel map is 5208x3476 so it doesn't match any of these dimensions.

So sure, I could use some help figuring this stuff out.

[dfort]

So I tried to use the mlv_dump, but it got error.


C:\Users\Oswald\My Documents\new folder>mlv_dump -m -v [M17-2218.mlv]

You put brackets around your file name? Sorry, guess I didn't explain not to put in the brackets. Do it just like you did with exiftool.

[Oswald]

yes, now I got it.
My camera is bought from germany. I'll do it tomorrow that I'll shoot against white wall. And also check out what was the camera name on mlv_dump.
 Filmed with 3x crop mode (what was in the ml menu)

Code: [Select]

Block: RAWI
  Offset: 0x00000034
    Size: 180
    Time: 197.058000 ms
    Res:  1280x720
    raw_info:
      api_version      0x00000001
      height           1060
      width            1872
      pitch            3276
      frame_size       0x0034FCB0
      bits_per_pixel   14
      black_level      2045
      white_level      15000
      active_area.y1   28
      active_area.x1   72
      active_area.y2   1060
      active_area.x2   1872
      exposure_bias    0, 0
      cfa_pattern      0x02010100
      calibration_ill  1


Code: [Select]

Block: VIDF
  Offset: 0x000002f0
    Size: 1616752
    Time: 562.979000 ms
   Frame: #0000
    Crop: 328x184
     Pan: 328x184
   Space: 3920

and here with zoom (5x i quess) button:

Code: [Select]

Block: RAWI
  Offset: 0x00000034
    Size: 180
    Time: 167.789000 ms
    Res:  1280x720
    raw_info:
      api_version      0x00000001
      height           1108
      width            2592
      pitch            4536
      frame_size       0x004CB060
      bits_per_pixel   14
      black_level      2046
      white_level      15000
      active_area.y1   28
      active_area.x1   72
      active_area.y2   1108
      active_area.x2   2592
      exposure_bias    0, 0
      cfa_pattern      0x02010100
      calibration_ill  1

Code: [Select]

Block: VIDF
  Offset: 0x05e1f260
    Size: 1616896
    Time: 5187.933000 ms
   Frame: #0139
    Crop: 584x336
     Pan: 584x335
   Space: 4064

[dfort]

Ah ha--got the full resolution of the sensor. (Within 1 pixel of the y axis.)

Shoot a full resolution silent picture, either dng or mlv converted to dng with mlv_dump --dng, and run dcraw -4 -E  on the dng. The resulting .pgm file will be the full size of the sensor. For the EOSM/650D it is 5280x3529. The extra pixels are on the top and left, just like on the simple silent picture showing the video raw buffer.

So going back to the exiftool report on the full res silient picture:

Code: [Select]

Default Crop Origin             : 0 0
Default Crop Size               : 5208 3477
Active Area                     : 52 72 3529 5280

5208 + 72 = 5280 width -- Check

The height is completely off:
3477 + 52 = 3549 height -- Wrong!

Taking a close look in Photoshop:

It appears to confirm that 72 pixels are taken off the x axis at the left but 50 pixels are taken off the top. Yet the image measures a total of 3529 high so that's what we can probably assume to be true.

That brings up the issue of what is going on with CR2 files? Running dcraw -4 -E on a CR2 file results in:

Code: [Select]

Image Size                      : 5280x3528

Both exiftool and Photoshop agree on this size. So where is the row shaved off on CR2 files, the top or the bottom? The only way to find out for sure is through more tests but we are close, very close and if you think about it--it doesn't really matter for raw video but as long as we're examining the full sensor we might as well find out.

Canon 100D / SL1 and Canon 700D / T5i testers, are you following along? What does exiftool report as the full sensor size of a CR2 and the image size of a full resolution silent picture (for DNG files) or mlv_dump -m -v (for mlv files) ? Are you also seeing a 1 pixel discrepancy in the vertical resolution?

BTW, I know that I mix things up a bit to keep it interesting but:
Vertical resolution = Y axis = Height
Horizontal resolution = X axis = Width

[Oswald]

100d crashes when taking full res picture. But i got it recording full res mlv to memory card.

Code: [Select]

Default Crop Origin             : 0 0
Default Crop Size               : 5208 3477
Active Area                     : 52 72 3529 5280
and

Code: [Select]

Image wight: 5280
Image height: 3529
and when using it to cr2 file it shows:

Code: [Select]

Canon image wight: 5184
Canon image height: 3456
And mlv_dump shows camera model as:

Code: [Select]

Block: IDNT
  Offset: 0x000000e8
    Size: 84
    Time: 2339.034000 ms
     Camera Name:   'Canon EOS 100D'
     Camera Serial: '30B08C252'
     Camera Model:  0x80000346
I have B model firmware on this camera. (I installed magic lantern for b models)

[dfort]

100d crashes when taking full res picture. But i got it recording full res mlv to memory card.

Code: [Select]

Image wight: 5280
Image height: 3529

Interesting, same size as the EOSM.

Walter, could you verify this on the 650D? Anyone able to check the 700D?

So the 100D crashes when shooting full resolution still pictures to DNG but it works with MLV?

And mlv_dump shows camera model as:

Code: [Select]

Block: IDNT
  Offset: 0x000000e8
    Size: 84
    Time: 2339.034000 ms
     Camera Name:   'Canon EOS 100D'
     Camera Serial: '30B08C252'
     Camera Model:  0x80000346
I have B model firmware on this camera. (I installed magic lantern for b models)

This is also very interesting. Here's the same mlv_dump information from DeafEyeJedi's camera, A model firmware.

Code: [Select]

Block: IDNT
  Offset: 0x000001ac
    Size: 84
    Time: 0.004000 ms
     Camera Name:   'Canon EOS REBEL SL1'
     Camera Serial: '9CBC0568A'
     Camera Model:  0x80000346

I looked up the cameras that we know have the focus pixel issue in the exiftool source code -- lib/Image/ExifTool/Canon.pm:

Code: [Select]

    0x80000301 => 'EOS Rebel T4i / 650D / Kiss X6i',
    0x80000326 => 'EOS Rebel T5i / 700D / Kiss X7i',
    0x80000331 => 'EOS M',
    0x80000346 => 'EOS Rebel SL1 / 100D / Kiss X7',

"Kiss X7" is what the EOS Rebel SL1 / 100D is called in Japan. Maybe this camera has yet another firmware version?

We're gathering some good information here. Looks like it is best to identify cameras with "Camera Model" instead of "Camera Name" in mlv_dump. It also looks like all the affected cameras have the same sized sensor. So far it appears that there are two different patterns, one for the EOSM/650D another for the 100D/700D.

[Walter Schulz]

Walter, could you verify this on the 650D?

I will try but need some clarification. What do you need? FRSP is not a problem but I have no idea what "full res mlv" means in this context.

[dmilligan]

3477 + 52 = 3549 height -- Wrong!

3477 + 52 = 3529

The one pixel off could be an ML "bug" (incorrectly auto-detecting the raw buffer height). It doesn't really make a whole lot of sense to me to have an odd height. Or perhaps the physical sensor actually does have an odd height and Canon code chops it off for CR2s. Or maybe there's an extra row at the top that is skipped because it's GBGBGB row. IDK.

Here's the relevant code in for computing image size and active area for photo raw in raw.c (the one for LV raw is just above it):

Code: [Select]

        /* autodetect image size from EDMAC */
        width  = shamem_read(RAW_PHOTO_EDMAC + 8) * 8 / 14; /* size B */
        height = shamem_read(RAW_PHOTO_EDMAC + 4) + 1;     /* size N */
       
        /* in photo mode, raw buffer size is from ~12 Mpix (1100D) to ~24 Mpix (5D3) */
        /* (this EDMAC may be reused for something else, usually smaller, or with a different size encoding - refuse to run if this happens) */
        if ((width & 0xFFFFE000) || (height & 0xFFFFE000) || (width*height < 10e6) || (width*height > 30e6))
        {
            dbg_printf("Photo raw size error\n");
            return 0;
        }
       
        /**
         * The RAW file has unused areas, called "optical black" (OB); we need to skip them.
         *
         * To check the skip offsets, load raw_diag.mo (from the CMOS/ADTG ISO research thread),
         * select the "OB zones" option, and adjust the skip offsets until the picture looks like this:
         * http://a1ex.magiclantern.fm/bleeding-edge/iso50/ob/ob-zones-5d3-6400.png
         *
         * Use even offsets only, otherwise the colors will be screwed up.
         */
       
        #ifdef CONFIG_5D2
        skip_left = 160;
        skip_top = 52;
        #endif

        #ifdef CONFIG_5D3
        skip_left = 138;    /* this gives a tight fit */
        skip_right = 2;
        skip_top = 80;      /* matches dcraw */
        #endif

        #ifdef CONFIG_500D
        skip_left = 62;
        skip_top = 24;
        /* skip one line */
        raw_info.buffer += width * 14/8;
        height--;
        #endif

        #if defined(CONFIG_550D) || defined(CONFIG_60D) || defined(CONFIG_600D)
        skip_left = 142;
        skip_top = 52;
        #endif

        #ifdef CONFIG_1100D
        skip_top = 16;
        skip_left = 62;
        raw_info.buffer += width * 14/8;
        height--;
        #endif

        #ifdef CONFIG_6D
        skip_left = 72;
        skip_right = 0;
        skip_top = 52;
        #endif
     
        #if defined(CONFIG_50D)
        skip_left = 64;
        skip_top = 54;
        #endif


        #if defined(CONFIG_650D) || defined(CONFIG_EOSM) || defined(CONFIG_700D) || defined(CONFIG_100D)
        skip_left = 72;
        skip_top = 52;
        #endif

        #ifdef CONFIG_7D /* very similar to 5D2 */
        skip_left = 158;
        skip_top = 50;
        #endif

I'd recommend running raw_diag.mo as per the comment in the code. You can also play with the height to see if there's more below the last row or if it's just garbage (raw_info.buffer -= width * 14/8; will also add a row at the top, note that doing this will flip flop the RG/GB rows, so colors will be wrong).

Note that for LV raw sizes for EOSM (and others) there's a

Code: [Select]

        #warning FIXME: are these values correct for 720p and crop modes?


I will try but need some clarification. What do you need? FRSP is not a problem but I have no idea what "full res mlv" means in this context.

I think it just means FRSP using the MLV format.

[Walter Schulz]

Thanks!

DNG 650D FRSP

Code: [Select]

Image Width                     : 5280
Image Height                    : 3529

Default Crop Size               : 5208 3477
Active Area                     : 52 72 3529 5280

Image Size                      : 5280x3529

MLV 650D FRSP

Code: [Select]

Block: RAWI
  Offset: 0x00000034
    Size: 180
    Time: 14.999000 ms
    Res:  5280x3529
    raw_info:
      api_version      0x00000001
      height           3529
      width            5280
      pitch            9240
      frame_size       0x01F18ED8
      bits_per_pixel   14
      black_level      2043
      white_level      12000
      active_area.y1   52
      active_area.x1   72
      active_area.y2   3529
      active_area.x2   5280
      exposure_bias    0, 0
      cfa_pattern      0x02010100
      calibration_ill  1


[dfort]

@Walter_Schulz
Perfect--just I expected. So far the EOSM and 650D are the same.

@dmilligan
Thank you so much for the detailed explanation. Guess if I studied computers instead of photography in college it wouldn't be taking me so long to figure this stuff out.

The height is completely off:
3477 + 52 = 3549 height -- Wrong!

3477 + 52 = 3529

Ha!! Got to frame that to keep me humble.

For those trying to follow along:

To make a Silent Picture (doesn't actuate the shutter and thus makes no noise) first you need to scroll all the way down in the modules list:

Do like the message says and reboot the camera to load the module. Then look under the still shooting menu for Silent Picture, select it and there are several options:

The options we're using are Full-res and Simple using a File Format of DNG and MLV. Note that in order to shoot MLV you also need to turn on the mlv_rec module.

Full-res Silent Picture is marked "Experimental" so expect some unexpected behavior like crashes. The Simple mode is proving very useful for examining the full raw buffer. Think of it as the area that the camera "sees" before it is cropped to size and saved as a video file. In order to save the "uncropped" raw video buffer for these tests you need to be in video mode (not picture mode) and do a shutter-half press to take a Silent Picture. If you choose MLV the frames will be saved to a single MLV file--that is until you change resolution then it will start a new file.

To find out more about Silent Picture check out these topics:
http://magiclantern.fm/forum/index.php?topic=12733.0
http://magiclantern.fm/forum/index.php?topic=12523.0

[Oswald]

So the 100D crashes when shooting full resolution still pictures to DNG but it works with MLV?

Yes, Both crashes, but MLV is recorded to card, but the dng isn't. SO FRSP is not yet working properly..

Yesterday i tried to get focus pixels showing, but i didn't succeed with it. Is it correct that the focus pixels should see when shooting with silent picture mode, simple?

[nikfreak]

@Oswald please describe steps to reproduce on the 100D thread. I'll fix it afterwards (just haven't held the 100D in hands this year) for you to be able to contribute to topic.

[dfort]

Yesterday i tried to get focus pixels showing, but i didn't succeed with it. Is it correct that the focus pixels should see when shooting with silent picture mode, simple?

Ah yes, focus pixels never appear when you want them to appear. They should show up in mlv video, raw video and Simple Silent in mlv or dng. I have never seen them in CR2 or Full-Res Silent.

What has worked best for me is to shoot a flat smooth subject like a neutral colored wall or blank sheet of white paper. Bracket the exposure so that you get a range from light grey to dark grey. The focus pixels don't seem to appear in pure white or black though they show up in some clipped highlights as green dots. Focus might also make a difference though I'm not sure. I've had them appear with both manual and EF-M lenses but I haven't found them when shooting without a lens. Hey, I tried all sorts of tricks to get them to appear. Even when you do get an image with focus pixels there's a good chance that not all of them will be visible in one frame. The most complete example I've seen was from this post in an astrophotography forum: Examining the 650D/T4i "Hybrid CMOS AF" pixels I referred to it in this post: http://www.magiclantern.fm/forum/index.php?topic=16054.msg157641#msg157641

Happy focus pixel hunting!

[dmilligan]

@dfort

Here's a focus pixel fixer for MLVFS:
https://bitbucket.org/dmilligan/mlvfs/commits/a5f271f69d977aa589d56e76d90d143a47c7df92
(you'll need to compile yourself, should be easy, you can use gcc or clang, doesn't matter, let me know if you have issues)

You must provide the maps. Name them like
[camera_model]_[raw_info.width]x[raw_info.height].fpm and put them in the current directory (directory from where you will launch mlvfs).
So for example a map for EOSM, crop hack mode would be named: 80000331_1872x1060.fpm

The contents of the maps should be a text file like

Code: [Select]

1 2
3 4
5 6
where you have the x,y location of each bad pixel on a line. My example file above has 3 bad pixels at (1,2) (3,4) and (5,6). The positions should be relative to the full raw buffer for the particular video mode (in other words, cropPosX and cropPosY will be subtracted to find the position relative to the current frame).

You need a map for each camera and video mode you want to correct (some of them will be the same or similar). If you can compile all these maps (and make sure the pixel fix actually works -> I have not tested it), I will distribute them with MLVFS and release a build.

If you run into problems with it not working, send me an example file and map for it (doesn't have to be a full map, just a few pixels), so I can test it (since I have neither of these to test with).

P.S. if we get this working and create all the maps, we can also add it to mlv_dump.

[dfort]

Happy Days!

I was reading through the source code snippets and experimenting with raw_diag.mo but now that you've gone this far I'll concentrate on creating the focus pixel maps.

Compiling MLVFS was super easy--just ran ./build_installer.sh and everything went smoothly the first time. Tested my build and it is working. I'll start putting together some pixel maps and testing them tomorrow.

By the way, here's a comparison of the "OB zones" First is the posted 5D3 image and second the EOSM image I was able to produce:

[dfort]

@dmilligan

I'm starting with 1280x720 crop mode hack because that is the setting that I'm most familiar with and have had success with dcraw and the pixel maps I have created. I believe I followed all your instructions and double checked that the pixel map lines up but haven't gotten it working yet. Note that I tried space and tab delimited files and it didn't seem to make a difference. I posted some test files in my bitbucket download area: https://bitbucket.org/daniel_fort/magic-lantern/downloads

The test files are zipped up in 2016-01-20_MLVFS_focus_pixel_fixer_test.zip.

Here are the procedures that I used.

I setup the video to "Movie crop mode ON" and "RAW video (MLV) ON, 1280x720" then shot a test target that was simply a piece of graph paper that I marked up in order to line up the layers in Photoshop. Silent Picture set to Simple, DNG. I also shot some Silent Pictures with MLV and it doesn't seem to make a difference other than some extra processing.

In Photoshop I lined up my master focus pixel map with the 1280x720 focus pixel map that I've been using with dcraw along with a frame of the movie file and the Simple silent picture. Note that the Simple silent picture was run through dcraw -4 -E as instructed by a1ex in order to show the entire raw buffer area of 1872x1060.

Once everything was lined up I trimmed the master focus pixel map to match the 1872x1060 raw buffer and exported it as a Portable Bit Map file. In order to have that file work with the script that I wrote it needed to be converted with Imagemagick: 'mogrify -colorspace gray -compress none -depth 8 [filename]' then run through a slightly modified script that I posted earlier.

pbm2_MLVFS_pixel_map.sh

Code: [Select]

#!/bin/bash

# pbm2_MLVFS_pixel_map.sh
#
# Create an MLVFS formatted focus pixel map file from
# a Portable Bit Map file.
#
# The output file can be used with MLVFS
# to remove the focus pixels from MLV video
# shot on Canon 100D, 650D, 700D and EOSM cameras.
#
# Requires bash sed and file
#
# Usage pbm2_MLVFS_pixel_map.sh [file.pbm]
# example: pbm2_MLVFS_pixel_map.sh EOSM_dead_pixels.pbm
#
# This reads the file, ignoring any blank lines or comments or lines
# that start with P1 (PBM "magic number"), extracts the image size,
# and creates an MLVFS formatted text file showing the location of the
# mapped focus pixels. This .txt file can be opened with a text editor
# for further refinement.
#
# Photoshop and perhaps other image editing programs save bitmap files
# in something other than plain text files. Imagemagick can be used to
# change these files into P1 plain text files using:
#
# mogrify -colorspace gray -compress none -depth 8 [filename]
#
# This is a very simple script and does not support filenames and
# paths with spaces. It also runs very slowly so give it time.
#
# 2016 Daniel A. Fort
# This is free and unencumbered software released into the public domain.

# First check that a file to process was specified by the user.

if [ -z "$1" ]; then
cat << EndOfMessage
pbm2_MLVFS_pixel_map.sh
Usage: pbm2_MLVFS_pixel_map.sh [file.pbm]

EndOfMessage
exit
fi

# Next check that the specified file is the correct format for this script.

if [[ $(file -b $1) != "Netpbm PBM image text" ]]; then
echo "ERROR: Wrong Filetype"
exit
fi

# Output file named the same as input with the .txt file extension

output=$1".txt"

# Remove the "magic number" comments and spaces leaving just the raw pbm data
# and load that into an array.

pbm_data=($(sed -e 's/[[:space:]]*#.*// ; s/[[:space:]]*P1.*// ; /^[[:space:]]*$/d' $1 | tr " " "\n"))

# The file starts out with the width and height of the image file.

width=${pbm_data[0]}
height=${pbm_data[1]}

# Adjust for where the pixel information starts and ends.

first_pixel=2  # first pixel at upper left - 0,0 position
last_pixel=$(($width * $height + 1)) # last pixel at lower right - width,height position

# set the counter to the first pixel

i=$first_pixel

# Loop through the pixels and write out the focus pixel locations

  for (( y=0; y<=(($height -1)); y++ )); do
    for (( x=0; x<=(($width -1)); x++ )); do
    if [[ ${pbm_data[$i]} == 1 ]]; then
        echo -e "$x \t $y" >> $output
    fi
        i=$[$i+1]
    done
  done

Here are some images from the test.

Raw buffer saved as a portable bit map file. Note that it includes the out of bounds area so it shows the entire 1872x1060 area and the focus pixels are clearly visible.

This shows the focus pixels a little better.

Now zoom in all the way and check where a focus pixel is located. The one on the upper left is at 611 139.

Which is in the 80000331_1872x1060.fpm file:

1362 138
1386 138
611 139
635 139
659 139
683 139

Good thing I checked everything--turns out one pixel was out of place in my master focus pixel file. I'll post the master file it once we're sure everything is working.

BTW--DeafEyeJedi lent me his SL1/100D so I'll start working on mapping focus pixels on that camera and I got a T5i/700D coming next week so that should keep me out of trouble for a while.

[Danne]

 

I, m buying an eos m.

Hats off to you dfort.

[dfort]

I, m buying an eos m.

I've got four of them--might be giving them away if this doesn't get resolved.

Came up with a problem with the 5x crop. I thought I'd attack that one next because when it is centered it gives pretty much the same results as the crop mode hack. The raw buffer is a different size. Here is what it looks like centered:

According to mlv_dump -m -v :

Code: [Select]

Block: RAWI
    Res:  1280x720
      height           1108
      width            2592

Block: VIDF
    Crop: 592x334

Everything checks out but when I panned the magnification to the upper left this is what happened:

Yeah, I went off the chart but the raw buffer moved along with the video frame. The mlv_dump information matches up with what I'm seeing in Photoshop:

Code: [Select]

Block: RAWI
    Res:  1280x720
      height           1108
      width            2592

Block: VIDF
    Crop: 216x374

The numbers work as far as where in the raw buffer the video frame is located but is there anything in the mlv metadata that can be used to figure out the movement of the raw buffer relative to the entire sensor? I can make a focus pixel map for a centered image but it won't automatically track when the magnified section is moved around.

I've also got a question about non-crop a.k.a. 1:1 where line skipping is involved. I could work out a new master pixel map for that but isn't there a way to adapt the master pixel map that I made for the entire sensor? Does it skip every 3rd row and column? Of course I could start over and hunt them down in Photoshop but I might be able to write a script to adjust the master. I'm also less familiar with using non-crop on these cameras and unlike the raw video I shot on the 5D3 the EOSM makes a frame that is squashed vertically or stretched horizontally--take your pick.

Looks like fun times ahead!

[dmilligan]

I believe I followed all your instructions and double checked that the pixel map lines up but haven't gotten it working yet.

You sure you put the pixel map in the right folder? It worked perfectly here:
Before

After

(NOTE: I probably didn't use exactly the same develop settings, so one of these appears darker)

The pixel maps have to be in the current working directory (not necessarily the same as the directory containing mlvfs executable). CWD is whatever directory you are in when you run mlvfs (btw, I have no idea what the CWD would be for the automator workflow, so you probably need launch mlvfs from the command line). Maybe I should make the .fpm search directory a command line parameter

[dfort]

Oops--thought it was as simple as dropping 80000331_1872x1060.fpm in the same directory as the MLV files.

I'm lost. [EDIT: Got it to mount but still don't know where to put the 80000331_1872x1060.fpm]

With pwd showing the home directory and a copy of 80000331_1872x1060.fpm in the home directory:

Code: [Select]

/Users/rosiefort/Library/Services/MLVFS.workflow/Contents/mlvfs /Users/rosiefort/Desktop/mount --mlv-dir=/Users/rosiefort/Desktop/2016-01-20_MLVFS_focus_pixel_fixer_test/mlv
Mounts the file system from the command line but the focus pixels are still there.

In any case, great that it is working! Did I hit all of them? Looks like there are still a few left on the far left side of your after picture but they aren't there in your before picture--strange.

[a1ex]

Does it skip every 3rd row and column?

I think it skips every 3rd line, but averages 3 columns of the same color:



http://magiclantern.fm/forum/index.php?topic=16516

(not 100% confirmed though; still looking for test data for cameras other than 5D3)

[dfort]

@alex

Posted tests for the EOSM and SL1 on the Pixel binning patterns in LiveView topic.

@dmilligan

Where do I stick the 80000331_1872x1060.fpm file? Be nice! I'd like to run a test using various resolution and aspect ratio settings to see if it is working as expected. Also, any thoughts on what to do about the 5x crop mode? I was thinking about just doing it centered though that would be pretty much like the crop mode hack with a different raw buffer size.

I'm still trying to understand how the full frame line skipping pixel binning thing works but it looks like I'm not the only one. Guess I could stop thinking about it and re-map the focus pixels so we can get it working.