Dealing with Focus Pixels in raw video

[IDA_ML]

Dfort,

I am about to shoot the other test samples that you requested as follows:

"I'd also like to get samples of the old standards, mv1080, mv720, mv1080crop and zoom. Finally, using one of the crop_rec_4k builds from the experiments download page I'd like a sample for the "basic" 3x3 sampling using the mv720 buffer. The reason is because I'd like to see if I can simplify some of these map files. There was a fix rather recently so I need new samples to work with."

I have already downloaded from the Experimental page the build called:

magiclantern-crop_rec_4k.2018Jul22.100D101

"for the "basic" 3x3 sampling using the mv720 buffer" but I am not sure which build works with the "old standards, mv1080, mv720, mv1080crop and zoom".  I don't want to send you wrong samples, so please link the appropriate build to me that will provide the samples that you need.

Thanks.

[dfort]

To make sure you are using the "old standards" for the 100D, download the build from here:

https://builds.magiclantern.fm/100D-101.html

Shoot with the Canon menu set to 1280x720--that's ml720, then switch to 1920x1080--that's mv1080, press the magnifying glass button to get to 5x--that's zoom mode and finally turn on Movie crop mode--that's mv1080crop.

All of these settings should work with every app but what I'm looking to do is to see just how much we can simplify the focus pixel map files.

For the mv720 with 3x3 sampling, I believe that can be found in the crop_rec_4k build on the experiments downloads page. Canon menu on 1280x720, crop_rec on and that should be the only crop_rec setting on that branch for the 100D.

[IDA_ML]

Thanks for the clear and detailed instructions, Dfort.

Here you go:

https://we.tl/t-tEk7H1t90w

These are 5 more test samples shot with the two old builds that you suggested.  Please let me know if you need more samples.

Very innovative work on the focus pixel issue, Danne and Dfort.  The FPs on the cat image are barely seen.  Congratulations!

[dfort]

Much better start today--all of the old standard settings are still working with the current map files. Note that with mv720 (5x3 sampling) the aliasing is severe and those green artifacts won't go away even with chroma smoothing turned on. This might be the result of extreme aliasing and not necessarily caused by focus pixels.



Speaking of chroma smoothing, one of my recommendations to getting rid of stubborn focus pixels that can't be mapped out is to turn on the chroma smoothing option. Let's make those remaining focus pixels on Danne's cat pop as much as possible:



Now turn on 2x2 chroma smoothing:



Looks like the chroma smoothing recommendation still applies.

I'd like to see if we can simplify some of the map files that have gotten very complicated. However, before possibly messing up something that is working, I'll finish up with the resolutions that still need map files.

In the meantime, enjoy this picture of Danne's cat--without focus pixels. Feel free to download the file and pixel peep.

[dfort]

@Danne - tell me more about this resolution:

100D_1736x976_14bit_3x_crop_mode.MLV

Code Select Expand

Block: RAWI
  Offset: 0x00000034
  Number: 1
    Size: 180
    Time: 0.788000 ms
    Res:  1736x976
    raw_info:
      api_version      0x00000001
      height           1189
      width            1808
      pitch            3164
      frame_size       0x0039674C
      bits_per_pixel   14
      black_level      2047
      white_level      16200
      active_area.y1   28
      active_area.x1   72
      active_area.y2   1189
      active_area.x2   1808
      exposure_bias    0, 0
      cfa_pattern      0x02010100
      calibration_ill  1
Block: RAWC
  Offset: 0x000000e8
  Number: 2
    Size: 32
    Time: 0.796000 ms
    raw_capture_info:
      sensor res      5184x3456
      sensor crop     1.62 (APS-C)
      sampling        1x1 (read every line, read every column)


The metadata says that it is using 1x1 sampling but there are two focus pixel patterns that overlap. This will require a two pass map file like we're using for the EOSM basic crop_rec - mv720 raw buffer with 3x3 sampling.



Finally figured this out by using dcraw to debayer the image. This is why all my attempts to fix it with a one-pass map file failed.

[dfort]

Finally got that problem file cleaned up:



It needed a pass of both a 3x3 sampling pattern and a 1:1 sampling pattern -- how can that happen?

80000346_1808x1189_1.png


80000346_1808x1189_2.png


Here is what the image looked like adjusted for the out of bounds area, set to the correct crop/pan position on the full raw buffer size and ready to start working on the focus pixel map:



I made separate fpm files using one of the scripts that is in the repository:

Code Select Expand

./img2fpm.sh -v 80000346_1808x1189_1.png
./img2fpm.sh -v 80000346_1808x1189_2.png

Then combined the fpm files like this:

Code Select Expand

cat 80000346_1808x1189_1.fpm 80000346_1808x1189_2.fpm > 80000346_1808x1189.fpm

Just thought I'd document the process in case anyone comes up with yet another resolution and I'm too busy--or just don't feel like working on it.

By the way, you can actually download the original sized files from flickr.com if you want to work through the tutorial I posted on Reply #564. Here's a tip, once you get a pattern working on a section of the image you can just duplicate the layer, move it to another position using the previous layer to line it up, merge layers, rinse, repeat and you'll be done short order--just like the wheat and chessboard problem.

I'm thinking about re-working the scripts to make it easier to work with multi-pass focus pixel map files. In the meantime I'm pressing on trying to get all the new resolutions working in MLVFS before moving on to the other apps.

We're getting to a point where we should make a decision. Do we make multi-pass map files for all possible settings or do we modify the algorithm to better match the map file to use? As it is MLVFS was the first app to deal with focus pixels and it uses pretty much the simplest method possible to match up the map file with the image. Camera ID and full raw buffer size. The newer builds show sampling methods so it is possible to make a better choice over which map file to use. However, how to deal with a problem like this particular example? Maybe throw every possible pattern at it? Some developers would probably cringe at that because all this processing must be affecting the image in some way. Maybe have a user selectable switch to decide how aggressively to work on the focus pixels like we have with chroma smoothing and bad pixel fix?

[Danne]

Looking good! ANd maybe not so strange after all:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg212214#msg212214

[dfort]

Keeps getting stranger and stranger.

100D_5008x708_14bit_5k


Push it to clearly see yet another focus pixel pattern:


Ok, so I went through the steps but when it came to finding the full raw buffer size:

Code Select Expand

    raw_info:
...
      height           738
      width            5080


However, no matter how I processed the MLV file the height was 1180 so there is no way this fits in a full raw buffer that is only 738 pixels high!

Think I'll put this one aside for now. Anyone actually using this setting?

[EDIT] Ok--couldn't resist the challenge. Turns out that mlv_dump showed the actual size. ACR and dcraw were doing some aspect ratio resizing. Readjusting in Photoshop did the trick.



Here's a closeup -- no focus pixels!



@IDA_ML -- Your turn. See if these latest map files work with any setting and resolution you can come up with. This is still a work in progress so things might will change.

[IDA_ML]

Downloaded your today's FP maps and shot a first set of test files in real-life conditions.  I believe, this one is problematic:

https://we.tl/t-Q83GMJwuhS

It is a 4k (4056x2582) file that stll has a few FPs left - look around the chimney.  Please let me know if you would like me to reshoot the sample with a white target.

I will keep testing and providing problematic files.

[dfort]

Let's take a look at this. At first it looked pretty good but my screen was dirty:



Right, that's not on my screen, those are some leftover focus pixels. My experience is if we do "mlv_dump --dng --no-fixfp" followed by "dcraw -T" it usually brings out the focus pixels quite clearly:



Now what does the pattern look like on the map file?



That doesn't look right but that's the pattern I've been using on all of the 1:1 sampling and nobody seems to be complaining -- until now. What is going on? Not sure but since this image clearly shows the focus pixels I thought I'd build up the map file from scratch. The way I do it is start with a small area in Photoshop, copy the layer and move it until the pattern matches up. Looks like some time ago I must have mismatched the pattern.

That's better:





A little bit of color grading and voilà!



Now I need to go back and replace all those 1:1 map files with the right pattern.

[IDA_ML]

Excellent work, Dfort!  It is amazing to see how you manage to hunt down the FPs even without a white target.  Obviously, you have falcon's eyes.

[DeafEyeJedi]

Beautiful work done by @dfort!

Obviously, you have falcon's eyes.

That's exactly right!

[dfort]

Some cross reference from the EOSM M topic:

@Jonit: funny, that really works - overexposing by far, and then EV=-4, Highlight Reconstruction = on. You can see the focus pixels.
@Jonit: this does only work, when leaving Focus Pixel Fix enabled. When switching it Off, those pink dots are away.

@dfort: I also recorded some frames, one clip overexposed (@10bit), another with normal exposure (@14bit) using Danne's rewire preset @ 1736x1158. I uploaded the clips with an receipt, so you can see them good in MLVApp. Does this help? It seems there are different types of focus pixels - some are very good to see (white, center), others not so good to see (dark grey, everywhere). The dark ones are good visible in the overexposed clip, processed like Jonit did.

Things aren't what they first seems to be. Confusing?

I took another look at the samples Jonit posted to see if they work with the latest focus pixel map files I've been working on. The thing is, when something is so overexposed that there is no recognizable image and you max out saturation, contrast, vibrance and whatever it takes to see the focus pixels, the map file itself will start affecting the image. In other words, this overexposing trick isn't working out that well for me.

However, the normal exposure image masc uploaded is easy to work with. Here it is stretched to the max to get those focus pixels to pop. Looks like something that should be hanging in an art gallery:



Looking at the entire frame you can see that familiar cross shape pattern that we've been seeing on the EOSM, 700D and 650D:



Note that I have this set up in Photoshop as per the tutorial I posted a few weeks ago.

This is a full raw buffer size I've never seen before so of course I don't have a map file for it. However, it looks very much like another pattern and here's where the plot thickens.

mlv_dump -v

Code Select Expand

Block: RAWI
...
      height           1190
      width            1872
...
Block: RAWC
..
      sampling        1x1 (read every line, read every column)
Block: IDNT
...
     Camera Name:   'Canon EOS M'
...
     Camera Model:  0x80000331


The width of this full raw buffer is 1872 which is also the width when using Movie crop mode (mv1080crop) -- not to be confused with the crop_rec module. The height is 1190 which is the height of the mv1080 raw buffer. Now things are going to get crazy because the sampling says it is 1x1 (same as mv1080crop) but the focus pixel pattern looks exactly the same as the 3x3 sampling of an mv1080 file. In fact all I had to do was to pull in an image of the 80000331_1808x1951 map file, line it up, convert it to a fpm file and it works -- in MLVFS for now.

Here's what the normally exposed image looks like -- no focus pixels.



It looks like my idea of looking at the sampling in order to help determine which map file to use won't work in this case. The inventory of map files keeps growing because MLVFS needs a file for every possible full raw buffer size for each of the cameras that show focus pixels. If you're using MLVFS and want to play around with the latest experimental crop_rec module settings make sure you're using the latest focus pixel map files from the ML Focus Pixels repository. I've still got some more work to do before coding the script that can be adapted for other MLV apps.

I've been reworking my scripts, updating map files and have switched from huge inefficient P1 type Portable Bit Map files to tiny Portable Network Graphic files. Well the scripts still work with pbm but if ImageMagic is installed on the system the scripts throw them out and save png files. This is helping speed things up when a new setting come up that requires a focus pixel map file, though admittingly my scripts are as slow as molasses.

[DeafEyeJedi]

Remarkable stuff @dfort and this is all great news so far!

[dfort]

As some of you know I've been adding map files for the latest bleeding edge crop_rec module experiments. Most of the new resolutions have been coming from the EOSM experiments but there has also been experiments done on the 100D and 700D. At this point it looks like we've got all the current settings covered so I thought it would be a good time to take a step back and reflect on where we are at with this focus pixel project.

Where are these so-called focus pixels on my camera's sensor -- Everywhere!

When I started this topic it seemed that the focus pixels were bunched up in the center of the sensor in a cross shaped pattern.



Next we found out that the patter stretched across the entire sensor.



This makes sense because it would be very difficult to manufacture a sensor with different types of receptors in a cross pattern. The main difference between the "older" 650D, 700D and EOSM sensor and the "newer" one used on the 100D and EOSM2 was the area covered by the focus pixels.



At first there also seemed to be a difference in the color and pattern of the focus pixels of the newer sensor but after seeing many sample files it looked more and more like these sensors all shared the same pattern and showed up in images in pretty much the same way. Just like the discovery that the focus pixels weren't confined to a small cross of the older sensor or large box of the newer sensor, focus pixels started appearing in areas outside of these boundaries.



There is an area we call the out of bounds area of the full raw buffer. That can be clearly seen using the raw_diag module from the ISO research tools branch.



Up until now I've been careful to keep from mapping the out of bounds areas but on this latest round of updates I started mapping the entire full raw buffer because some of the experimental crop_rec settings might have different OB zones and it made comparing the image files easier by lining up the upper right corners of the images and finally because it was easier. The savings in the number of mapped coordinates is rather insignificant. I mean we're already defining up to 154,440 coordinates on these map files, what's a few thousand extra dots between friends?

So to conclude this section--the map files are covering the entire area of the full raw buffer.

What is the focus pixel pattern? -- There's more than one.

When I first started I wanted to eventually map out all of the focus pixels on the full sensor then calculate all the pattern for the various settings. However, getting a good look at focus pixels on the full sensor wasn't possible until recently when @theBilalFakhouri came up with a setting that gave us access to the full 5280x3508 raw buffer--and it showed focus pixels. This is the pattern:



Notice that the pixels on the horizontal axis repeat every 24 pixels. File that because we'll come back to it.

The first 1:1 sampling options we had with these cameras was the zoom mode which is activated with the magnifying glass button and the Movie crop mode setting which is something that is unique to these cameras that show focus pixels. What I noticed when testing zoom mode was that the pattern would shift 8 pixels left or right. Why this happens is probably due to the way the "crop" value is determined. If you run mlv_dump -v you will see that each frame has a crop and pan setting. We're using the crop value to line up the map file. A while back there was a bug with the way crop was calculated and fairly recently a similar issue came up with the lossless compression settings. When I wrote the fpm.sh script I took this into account and calculated the crop setting from the pan values like this:

Code Select Expand

##
# Allow for legacy MLV files with cropX, cropY bug
#
cropX=$((panPosX + 7 & ~7))
cropY=$((panPosY & ~1))


This should no longer be necessary so I'll be taking it out.

Alright, so where am I headed with this and why did I ask you to remember 24? Because in the zoom setting you can move the capture area around the sensor and the pixels will jump left right in 8 pixel increments as it switches between the 21 full raw buffers used in that mode.



To compensate for this I copied the map file so that the same map would still work even if the focus pixels moved left or right by 8 pixels.



Now I'm starting to question if this is necessary because on my new map files I didn't do this on the 100D yet it worked on all the samples that I received. Looks like more testing on the zoom settings are in order. My question is does this also affect the Movie crop mode setting? Yet more testing. Perhaps the code should be changed so that crop is forced into 24 pixel increments? (There's that number again.)

Maybe like this?

Code Select Expand

raw_info.width, (skip_x + 23) & ~23, skip_y & ~1,

Moving on to the 3x3, 5x3 and the new 1x3 sampling settings -- at one point @a1ex looked at the focus pixels as part of his pixel binning research. I played around with his octave scripts and using the 1x1 sampling pattern we were able to recreate the 3x3 and 5x3 patterns. Here they are:

3x3 sampling (mv1080) focus pixel pattern


5x3 sampling (mv720) focus pixel pattern


Here's the latest setting that is getting attention:

1x3 sampling focus pixel pattern


Ok now, those of us who are better at remembering images than numbers might have just gotten an "ah ha" moment. That's the same pattern as the one we're using on the 1x1 sampling adjusted to take into account the 8 pixel left/right shifting. For those of you better with numbers, 24/3=8. Alright, I may not be a math wiz but I did pass elementary school.

This brings up an off topic point -- the horizontal binning pattern probably should be evenly divisible by 3 but we are forcing the crop setting to be evenly divisible by 8. Maybe that's another reason to change the code so that it forces the crop value to be evenly divisible by 24? I don't know, just a shot in the dark on this.

But wait, there's more! (Is this starting to sound like an infomercial?)

Recently @Danne came up with a setting that showed a different focus pixel pattern. Not that surprising if you have ever played around with the various PREFERRED_RAW_TYPE:

raw.c

Code Select Expand

#undef RAW_DEBUG_TYPE   /* this lets you select the raw type (for PREFERRED_RAW_TYPE) from menu */

Here's the focus pixel pattern for his "reconfig_cat" setting or whatever he calls it:



What's with these "multi-pass" map files? -- When one pattern isn't enough.

When we were experimenting around trying to get mv1080 (3x3 sampling) working on the EOSM we started getting images where the map files weren't working and focus pixels were starting to make a strange pattern, like two patterns were layered on top of each other. We also had a situation where the same full raw buffer size was used for both 3x3 and 5x3 sampling so what to do?



At first I made a map file that combined the focus pixel patterns but that didn't work because the coordinates were too close to each other and they started picking up the color from adjacent focus pixels and it turned into quite a mess. The solution was discovered by @bouncyball which was to make a separate pass, one for each focus pixel pattern.

This trick also worked for situations where the same sized full raw buffer was used for different sampling, like what happened on that crop_rec setting. So even though other cameras didn't show both focus pixel patterns superimposed over each other like the EOSM, they did benefit from multi-pass map files. Now we've got to ask, isn't all this extra processing affecting the image? Yes, though it is much better than having focus pixels on your video. For the most part the image doesn't seem to suffer unless you clipped the highlights and bring the exposure way down in post so they turn grey. At that point, the focus pixel map starts showing up on the image but at that point the image is quite a mess anyway. A little bit of chroma smoothing helps. I've suggested that several times on this topic.

Now with these latest crop_rec settings I looked at MLV files that had the 1x1 sampling focus pixel pattern superimposed over the 3x3 pattern. Again, a multi-pass map file was able to deal with that.

Where do we go from here? A light touch or throw everything including the kitchen sink at it?

Here's the problem, we will continue to find new resolutions that require one or more of the focus pixel patterns. Right now which one(s) can't be predicted. So do we try to find a way to figure out which pattern is needed? With this latest round of testing it looks like that would be very difficult to do. How about making a pass with each of the known patterns? That might work as long as we can figure out how to line up the map files for every possible setting though it does seem like overkill.

Another problem is that the inventory of map files is growing exponentially because for every new resolution there are five cameras that might need that new map file. The good news is that it appears that every camera seems to be using the same patterns. Yes, even the "old" and "new" sensors are using the same patterns. That means that we shouldn't need to make a separate map file for each camera.

Well this post turned out much longer than I anticipated but if you got to this point perhaps you have some idea you might want to share?

(NOTE: Please, oh please don't quote this entire post on your reply!)

[dfort]

Danne's EOSM has some hot pixels. He found a way to deal with them in camera but what about the footage you might have already shot? Like the old saying goes, "we'll fix it in post."

Let's see what we can do about this:





That one "hot" pixel is screaming for attention. I like using dcraw -T to create a tiff file that doesn't hide these defects like ACR does then use that tiff file in Photoshop or any other image editing application that has a ruler you can set to show pixels. Here's the ultimate in pixel peeping:



That is one big red hot pixel! If you look closely you'll notice we're looking at a group of 9 pixels. The debayering algorithm is blending the color of the neighboring pixels so the pixel we want to map out is in the center of that cluster - 1384x690. With mlv_dump and a little bit of basic arithmetic we can easily modify the focus pixel map file.

mlv_dum -v

Code Select Expand

Block: RAWI
...
      height           1060
      width            1872
...
Block: IDNT
...
     Camera Model:  0x80000331
...
Block: VIDF
...
    Crop: 72x84


The full raw buffer size is 1872x1060 so we add the Camera Model to that to find out that we will need to work with the 80000331_1872x1060.fpm file. To map out that pixel we add the location of the hot pixel to the crop values like this:

Code Select Expand

Width = 1384+72=1456
Height = 690+84=774


Now plug that into the .fpm file, it is an ascii tab delimited file that can be modified with any text editor:



Done.



From now on the modified map file will map out that hot pixel along with the focus pixels.

[Levas]

Does anyone know if there are raw streams that don't show Focus Pixels ?
Can imagine that somebody already tried out, but in case not, I can imagine that there are raw streams that don't have Focus Pixels.

There's this debug option in magic-lantern/src/raw.c file.

Code Select Expand


#define RAW_DEBUG_TYPE   /* this lets you select the raw type (for PREFERRED_RAW_TYPE) from menu */


This gives a raw stream value select option in debug menu.
If you use ML preview with half shutter press, you can quickly see how the raw stream looks, without the need to record.
So change raw type value, and check how it looks with half shutter press.

Not all values give valid raw stream, in that case it shows the 'raw detect' error.

[Danne]

Been down that path many times. Short answer. No better stream has emerged yet.

[Danne]

Managed to elminate red pixels by tweaking cmos 6:
Before:

after:


It´s not unproblematic. Image seems sometimes "weakened" on top. Black level and some vignetting but most of the times image is just as with untouched cmos 6. Part of the bottom is cut maybe 20 pixels(less of a problem).

Test files(MLV):
https://bitbucket.org/Dannephoto/magic-lantern/downloads/fp_eosm.zip

[dfort]

There's this debug option in magic-lantern/src/raw.c file.

Been there, done that. At one point I thought I found a setting where there were no focus pixels showing but it turned out they were still there and were even harder to remove.

Danne's coffee cup looks great at first glance.



Stretching the images to make the focus pixels pop shows that they are still there. Maybe fewer and in a different location but still there.

"normal" setting


after tweaking cmos 6


The issue that I see is that the current focus map file works fine here:

"normal" setting


but not on this one:

after tweaking cmos 6 [EDIT] Yes it looks exactly like the previous one but this one was run through with the current map file.


Running a second pass with that pattern will "fix" it.

I doubt there is any way we can predict if the settings were tweaked in such a way that it would require that second pass with a different map file so maybe being super aggressive and throwing all the possible patterns into the mix is the only way to guarantee focus pixel removal?

(Looking for some developers' feedback here -- hint hint)

[Danne]

One of these days we will hit the right reg 

[Danne]

Talking focus pixels. Take a look at eosm when running regular mv720p raw in 6400 iso. A reg is set which causes a vast amount with pixels. Levas found the reg. Disabling it completely gets rid of the pixels. Added here to crop rec presets:
https://bitbucket.org/Dannephoto/magic-lantern/commits/2aa08f8e974c53dab8ad461cc2b680b95f3cf492

[Jonit]

Probably no longer relevant, as dfort already mapped out these pixels, but I managed to get this picture by accident. I took a photo while crop_rec raw was enabled and this came out.




EDIT: here is the .cr2 if anyone is interested https://mega.nz/#!PUF3nIaa!hjOU46_s7mXEA86B1j9c5KJP3YxybokBMdxYAbKfR-E

[dfort]

This is actually an interesting case. It is only the second CR2 file with focus pixels that I've seen. The other one was shared by a1ex on Reply #569.

Let's take a closer look at these. First the one a1ex posted:



This is from a 700D and it clearly shows that familiar cross shape. The grey border is the full raw buffer and the image is properly lined up over that full buffer.

I wanted to take a look at the full raw buffer by running it through dcraw with the "-4 -E" options. We can't use mlv_dump on CR2 files so we'll turn to exiftool to see what we can learn from this.

Code Select Expand

Canon Image Width               : 5184
Canon Image Height              : 3456

Image Width                     : 5184
Image Height                    : 3456


There's quite a bit of redundancy in the metadata. The applications that support CR2 files confirms the size of the image as 5184x3456. Note that if we look at any MLV file (that wasn't shot with the silent module) in mlv_dump using the "-v" option it will this:

Code Select Expand

Block: RAWC
  Offset: 0x000000e8
  Number: 2
    Size: 32
    Time: 0.776000 ms
    raw_capture_info:
      sensor res      5184x3456
      sensor crop     1.62 (APS-C)
      sampling        1x1 (read every line, read every column)


As long as we're being redundant, let's check the user guide:

Code Select Expand

Recorded pixels: L (Large)    : Approx. 17.90 megapixels (5184 x 3456)
                 M (Medium)   : Approx. 8.00 megapixels (3456 x 2304)
                 S1 (Small 1) : Approx. 4.50 megapixels (2592 x 1728)
                 S2 (Small 2) : Approx. 2.50 megapixels (1920 x 1280)
                 S3 (Small 3) : Approx. 350,000 pixels (720 x 480)
                 RAW          : Approx. 17.90 megapixels (5184 x 3456)

Ok--so the size of a CR2 file from the 700D and all of the cameras that show focus pixels for that matter is 5184 x 3456. (I kept the various JPEG sizes from the user guide for future reference--maybe there is something that we can learn from the way Canon came up with these dimensions.)

Now let's verify the full raw buffer. The file produced by running "dcraw -4 -E" is 5280x3528. Here is what exiftool shows:

Code Select Expand

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


If we treat the Sensor Left and Sensor Top Border like the Crop in mlv_dump the image lines up perfectly on the full raw buffer. The Sensor Right and Bottom Border is the location of the lower right corner of the image when it is lined up on the full raw buffer.

So at long last we can accurately map the focus pixels on the entire sensor. Note that the focus pixels extend over the entire sensor so we can't just map what is visible on this example.

Now let's take a look at the example @Jonit posted:



This was shot on an EOSM while crop_rec was enabled and the image is 5184 × 2916. The full raw buffer came out to the same 5280 × 3528 and this was verified in exiftool. However, there seems to be a disagreement between the image size and what is reported in the EXIF data:

Code Select Expand

File Type Description           : Canon RAW 2 format
Image Size                      : 5184x3456


The Sensor Border numbers were the same as a1ex's sample so this obviously wasn't working. Going by the numbers it would line up like this:



Look familiar? If we would have used that map file that I threw out because it was obviously a mistake it would have worked:



Of course I could line it up by eye using the focus pixels as a reference which is what I eventually did but how would you code something that would work in this case? Maybe we need to allow for possible vertical offsets? Maybe that pattern I threw out was not a mistake?

I mentioned in Reply #615 why the zoom mode map file is copied over every 8 pixels horizontally even though the pattern repeats every 24 pixels. On the vertical axis the pattern repeats every 60 pixels. By copying the same pattern and sifting it 30 pixels vertically it might be able to better handle this particular situation. Maybe this is also needed for zoom mode where the full raw buffer jumps around to different locations on the sensor as you pan around the magnification box? Nope, I tested that theory and it doesn't seem to be necessary. Now I'm not sure if copying the pattern 8 pixels horizontally is really necessary for "normal" situations. Maybe we need two sets of map files, a "normal" set and an aggressive set where we try to cover all the possible situations we have seen so far?

Another post that has turned into a novel -- this one has a surprise ending. Turns out that even with a proper map file dcraw cannot eradicate the focus pixels out of these CR2 sample files.



See that cluster of 9 pixels--the focus pixel is sitting in the center of that cluster and the map file clearly has that location defined. The focus pixel apparently didn't get the eviction notice.

Maybe it will work for full resolution silent pictures (FRSP)? It isn't really necessary because FRSP don't show focus pixels. I just ran a fact check on that and couldn't find any focus pixels though I did find something interesting:

mlv_dump -v

Code Select Expand

Block: RAWI
...
    Res:  5280x3528
    raw_info:
...
      height           3528
      width            5280
...
Block: VIDF
...
    Crop: 0x0
     Pan: 0x0


This is telling us that the image is the same size as the full raw buffer and there is nothing cropped out. However, opening up an exported DNG file in Photoshop shows the image file as 5208x3476. Tried it with a FRSP saved directly to DNG in camera and came up with the same mismatched sizes in exiftool and Photoshop. Note that this is from a bleeding edge build so it should have all the latest fixes.

[dfort]

The day after April Fool's Day announcement. A boatload of focus pixel map files that covers all of the new 700D and a few new EOSM bleeding edge crop_rec settings. Put these next to the executable file in MLVFS or MLV App and enjoy the new resolutions.



https://bitbucket.org/daniel_fort/ml-focus-pixels/src/default/