Dealing with Focus Pixels in raw video

[dfort]

Are these dots always the same place?

The dots always follow a defined pattern but that pattern has shifted horizontally on some builds. I believe that commit 5052fab fixed that so I should probably simplify several of my map files. I tried to have them cover all of the builds including the buggy ones but some of my maps are now huge and need multiple passes to clean up all of the possible the focus pixel locations.

[alpicat]

@dfort as discussed in the EOS M thread - below is a link to two PNGs showing focus pixels for the EOS M shooting in 2.5k crop mode (5x zoom) at 2520x1308, in 9-bit lossless raw.
Both files are the same, one is in colour and the other I've switched to b&w in case that's helpful? I had to enhance and combine images together in order to see all the focus pixels (it's very tough to see all of them at once, as certain focus pixels become invisible depending on which colour temperature and other colour settings you set):

https://drive.google.com/drive/folders/1WGDLbFGz-j1UjHnjmigQNqnw28GtpGjL?usp=sharing

[dfort]

Very nice:



I'll need a short MLV file to work on the focus pixel map file. Though one thing you can do is to check the size of the full raw buffer:

Code: [Select]

mlv_dump -v [file.MLV]
For example (just for illustration, this isn't a 5x zoom file):

Code: [Select]

Block: RAWI
  Offset: 0x00000034
  Number: 1
    Size: 180
    Time: 0.783000 ms
    Res:  1736x1120 <-- image resolution
    raw_info:
      api_version      0x00000001
      height           1150 <-- full raw buffer height
      width            1808 <-- full raw buffer width

A quick test to see if the current map file is working is to rename the '80000331_2592x1108.fpm' file to the size of your full raw buffer and try it in MLVFS.

[dfort]

...showing focus pixels for the EOS M shooting in 2.5k crop mode (5x zoom) at 2520x1308, in 9-bit lossless raw...

Never did get an MLV of that format to work on focus pixels but Danne just sent me a bunch of new crop_rec samples to work on. Included is one shot at 2520x1418 which is probably using the same size full raw buffer as the 2520x1308 MLV.

I'm also doing a big cleanup so there will be lots of changes.

The fpm files will no longer skip over the out of bounds area. It didn't save much space and with these new crop_rec samples the out of bounds areas seem to be not as fixed as they used to be. In addition, it is easier to examine something that has a pattern over the entire area instead of just a portion. We already learned that the focus pixel can show up outside of the "usual" center strip or cross shaped area. Finally, if you are going to process the image, do it to the entire image area to keep it even.

The repository has image files to make it easy to see what the patterns look like. These files were in Portable Bit Map version P1 which are about the most basic image graphics file format possible. The reason I'm using these is because you don't need a special library or dependency to work with these files, they are actually ASCII text files. Anyway, I switched over to PNG format to save space on the repository. The scripts still use PBM but rely on ImageMagic to do the file conversion.

Several of the map files were simplified because with this commit we no longer need to worry about focus pixel slippage. Well, at least we don't need to worry too much. I'm seeing some difference between the patterns of the full resolution vs. the 1:1 sampling. Shouldn't the patterns be the same?

The way I test out new resolutions is by creating layers in Photoshop and manually map out the focus pixels then use a script to convert it to a map file that can be used in MLVFS. Once it works in MLVFS I modify a script that can create the map files "on the fly" and the algorithm can be used in other applications.

One issue that came up with MLVFS is that it looks up which map file to use by the full raw buffer size. When dmilligan coded it that way he was aware that there might be a problem if two settings use the same buffer size but require different map files. That's what happened with the "basic" crop_rec settings so we had to create two-pass map files to work with MLVFS. I'm still working on updating these two-pass map files but the ones that are currently there are working fine.

To use these map files go to the ML Focus Pixels repository, grab the contents of the focus_pixel_map_files and put these files into your working copy of MLVFS. Have fun!

[IDA_ML]

Hello Dfort and thank you so much for your continued efforts on the focus pixel maps. 

I just briefly tested with a 100D file shot at 2544x1432 resolution.  Unfortunately, there are still focus pixels on it.  Here is a frame grab:




What I did was:  I downloaded the file called:

daniel_fort-ml-focus-pixels-9e3d2758530c

and extracted all 52 .fpm files into my MLVFSx86 directory after removing the old fpm files.  Then I used MLVFS fo open the 100D original MLV file in Resolve and noticed the focus pixels.  The above frame grab was just taken from the virtual DNG directory, opened in ACR and saved as a JPEG.  The focus pixels are clearly seen between the two yellow buildings after magnification.

[IDA_ML]

And here is a MLVApp shortened version of the original MLV file:

https://we.tl/t-d47exONMAE

It was shot at 10-bits lossless.  Please let me know if you may need more 100D files.

[dfort]

That resolution wasn't included in the batch Danne sent me. 10-bit lossless is hard to work with when dealing with focus pixels. Could you shoot something in that resolution using 14-bit lossless? What works best for me is if you can shoot a blank wall, somewhat underexposed. That usually helps bring out the focus pixels.

I'm currently away from home so my ML time is a little sporadic but I do plan to cover all these new resolutions as soon as I can.

[Danne]

I sent files for eosm...

[IDA_ML]

Could you shoot something in that resolution using 14-bit lossless? What works best for me is if you can shoot a blank wall, somewhat underexposed. That usually helps bring out the focus pixels.

Sure I could but 14-bit lossless is usable only at low cropped resolutions and does not really make much sense.  At the resolution of 2544x1432 (16:9) and 14-bit lossless you get less than 1 sec. recording time, while at 10-bit lossless recording is continuous at 18 to 20 fps for that same resolution.  The other resolution of practical interest is 2320x1306 (also 16:9).  At this resolution and 10-bit lossless recording is continuous at 23 and even 24 fps if slightly underexposed. 

In my opinion, if one really wishes to take advantage of the high-res crop modes, 10-bit lossless is the way to go on the 100D and the EOS-M.  Quality degradation at this bit rate is negligible compared to 12 and 14 bits lossless but continuous or long enough recording at reasonable frame rates is really a game changer on these small cameras.   

[IDA_ML]

Even Dual ISO provides excellent results in these high cropped resolutions, greatly improving shadow noise.  So, further investigations on the focus pixel problem in these modes is well worth the efforts.

[dfort]

What I did was:  I downloaded the file called:

daniel_fort-ml-focus-pixels-9e3d2758530c

Huh? There is no such file in the repository. What you are pointing to is a commit that isn't even the one containing the fpm files.

I'm not arguing over what bit depth or compressed/uncompressed setting is best to use. All we're interested in here is to get those focus pixels to show up the best we can in order to make sure we can map all of them. What I was asking for is something that is known to work quite nicely for focus pixel hunting and it only requires one frame so don't worry about continuous recording.

Here is a frame from one of the EOSM files that Danne sent me. Notice that even without pixel peeping it is obvious there is some sort of pattern on the image:



I pushed the color and contrast to the max for the focus pixels to pop out so when zooming in to look at the pattern it is very obvious.



Now let's look at the example that you sent:



My first impression was, where are the focus pixels? On first glance they were hard to see, even when zoomed in. I had problems finding focus pixels on reduced bit depth lossless compressed files and I didn't have much time today to fiddle around with this so I asked for something that would be easier to work with. A while back I posted a tutorial on exactly how to create a fpm file for MLVFS--did you bother reading it? With just a little bit of initiative and absolutely no coding you could have created the file that you need for this.

What file do you need? Let's check your MLV file with mlv_dump, I cut out all the irrelevant stuff:

Code: [Select]

mlv_dump -v 100D_2544x1432_Focus_Pixels.MLV
...
Block: RAWI
...
    Res:  2544x1432
    raw_info:
...
      height           1460
      width            3072
...
Block: RAWC
...
      sampling        1x1 (read every line, read every column)
Block: IDNT
...
     Camera Name:   'Canon EOS 100D'
...
     Camera Model:  0x80000346
...
Block: VIDF
...
    Crop: 72x28
     Pan: 72x28
...
Your image size is 2544x1432 but MLVFS looks up the full raw buffer size which is 3072x1460. You shot this with a 100D but MLVFS looks for the Canon code which is a hex number: 0x80000346. So what MLVFS is looking for is a file named: 80000346_3072x1460.fpm. Not in your MLVFS package? Not in my repository? Then instead of complaining about focus pixels, make a map file and share it with the ML community! Someone else finds it doesn't work for them? Great--they can complain to you because every line in the repository is annotated with your name, for example:

Code: [Select]

hg annotate -u 80000346_2592x1332.fpm
dan: 6   0
dan: 18          0
dan: 30          0
dan: 42          0
dan: 54          0
dan: 66          0
dan: 78          0
...

You get the idea.

This is the first sample I've gotten from Danne's new crop_rec resolutions for the 100D. I'm sure there will be lots of others so how about we let it simmer for a while before making the next batch of map files but in the meantime, let's see if there's anything we can do with this sample.

First of all, push the image to make the focus pixels stand out. I'm using mlv_dump to make the DNG files using the --no-fixfp opton to make sure it doesn't attempt to fix the focus pixels and Adobe Camera Raw but you can also do this with MLV App or MLVFS or just about any app that can work with MLV files.



Don't critique the color grading, we're only looking for focus pixels and there they are!



This file was shot with 1x1 sampling so if we look at one of the 1:1 sampling files for the 100D it should match that pattern, right?



Doesn't look right, does it? What is going on? I was trying to combine the map files for every sample I could get. This was fixed rather recently but I left the map files like this for a while until I get new samples like I just got for the EOSM:

Several of the map files were simplified because with this commit we no longer need to worry about focus pixel slippage.

Looks like this pattern is a better match:



Anyway, it is getting late. I spent too much time explaining and too little time working on the new map file -- sort of how you spent too much time writing about the virtues of reduced bit depth and lossless compression and too little time reading up on how to deal with focus pixels.

To be continued...

[IDA_ML]

Huh? There is no such file in the repository. What you are pointing to is a commit that isn't even the one containing the fpm files.

Dfort,

This is not true!  The file called:

daniel_fort-ml-focus-pixels-9e3d2758530c.zip

that I downloaded from your download area, is in my download directory.  It is a ZIP file, 12.4 MB of size.  Inside, there is a directory called:

focus_pixel_map_files

which contains all 52 .fpm files that I used.

Please excuse my ignorance regarding the focus pixel issue.  I do read a lot, but coming from a completely different background, I find it quite hard to understand what you guys are writing.  And yes, I read your tutorial several times and got the idea.  I even tried to create a fpm file but, unfortunately, did not come very far.  And this is not a question of initiative.  It's just that my knowledge and experience in the area are quite limited.  Sorry about that.  Nevertheless, by sharing my findings on this forum, I try to help as best as I can.

Anyway, I shot a plain surface with the 100D, as you requested.  I did that at the maximum 3000x1432, 2520x1418 and 4056x2554 resolutions - all found in the 100D crop menu.  These MLV files were filmed at all lossless bit depths available: 14, 12, 10, 9 and 8.  I will shorten and rename the files and if you need them, I can send them to you later today.  Please let me know if you would like me to do that.

[IDA_ML]

For Dfort and anyone else who wishes to give it a try and create focus pixel maps for the 100D, here are a few test MLV files of a plain textured surface:

https://we.tl/t-QZNKv04pKQ

They were shot slightly underexposed at the 3 maximum resolutions and 5 bit depths described in my previous post #587.  Please let me know if these files work for you and if yes, I will shoot and provide test files at all remaining modes in the crop menu.

[dfort]

...The file called:

daniel_fort-ml-focus-pixels-9e3d2758530c.zip

that I downloaded from your download area, is in my download directory...

Ah--my bad. Didn't know that downloading the entire repository from Bitbucket names the zip file like that. Pretty clever actually. That hex number at the end tells you the latest changeset included in that download.

A much better way to download the repository is to use the revision control system that we're using on Magic Lantern which is called Mercurial or hg for short. This you should know, it is the symbol for the the metal mercury from the periodic table of elements. Note that hg is a command line application--I take it you are using command line applications, right?

Did you know that you can run MLVFS from the command line? Why would you want to do that? So you can see which map file, if any, it is using. You can read more about it here and on dmilligan's repository. By the way, this is a GIT repository which is somewhat different from hg but very similar.

...I do read a lot, but coming from a completely different background, I find it quite hard to understand what you guys are writing...

Open source projects like this welcomes input from users from all sorts of backgrounds. My understanding is that you come from a science background so you should have an advantage over most users. I studied photography, Danne is a guitar instructor. Do you think we understand this stuff? Still, not knowing what we're doing isn't keeping us from diving into the deep end.

...Anyway, I shot a plain surface with the 100D, as you requested.  I did that at the maximum 3000x1432, 2520x1418 and 4056x2554 resolutions - all found in the 100D crop menu.  These MLV files were filmed at all lossless bit depths available: 14, 12, 10, 9 and 8....

You are working too hard and aren't following the instructions I gave you--

...Could you shoot something in that resolution using 14-bit lossless? What works best for me is if you can shoot a blank wall, somewhat underexposed. That usually helps bring out the focus pixels.
I'm currently away from home so my ML time is a little sporadic but I do plan to cover all these new resolutions as soon as I can.

Sure, I know you prefer to work with other bit depths but--

...All we're interested in here is to get those focus pixels to show up the best we can in order to make sure we can map all of them. What I was asking for is something that is known to work quite nicely for focus pixel hunting and it only requires one frame so don't worry about continuous recording....

What would really help is to shoot every crop_rec resolution possible. I'd also like to get the basic ones, mv720, mv1080, mv1080crop and zoom modes for the 100D using a recent build because I'd like to see if we can simplify the map files. Make sure to label them so I know what we're working with. Here's what Danne sent me for the EOSM:

Code: [Select]

Rosie-Forts-Computer:focus_pixel_MLV_all_presets_eosm rosiefort$ gls -v
 01_anamorphic.MLV                       '014_4K 4038x2558_2351.MLV'
 02_anamorphic_2351.MLV                  '015_4K 4038x2558_169.MLV'
 03_anamorphic_169.MLV                   '016_3K 3032x1436.MLV'
'04_mv720p 1736x694 50fps.MLV'           '017_3K 3032x1436_2351.MLV'
'05_mv720p 1736x694 50fps_2351.MLV'      '018_3K 3032x1436_169.MLV'
'06_mv720p 1736x694 50fps_169.MLV'       '019_2.5K 2520x1418.MLV'
'07_mv1080p 1736x976 46:48fps.MLV'       '019_2.5K 2520x1418.wav'
'08_mv1080p 1736x976 46:48fps_2351.MLV'  '019_2.5K 2520x1418_000002.dng'
'09_mv1080p 1736x976 46:48fps_169.MLV' '019_2.5K 2520x1418_000003.dng'
'010_mv1080p 1736x1158.MLV'              '019_2.5K 2520x1418_000004.dng'
'011_mv1080p 1736x1158_2351.MLV'         '019_2.5K 2520x1418_000005.dng'
'012_mv1080p 1736x1158_169.MLV'          '020_2.5K 2520x1418_169.MLV'
'013_4K 4038x2558.MLV'                   '020_2.5K 2520x1418_2351.MLV'

Oops--this just in:

Code: [Select]

Rosie-Forts-Computer:WORK rosiefort$ gls -v
2520x1418_8bitLL.MLV   3000x1432_8bitLL.MLV   4056x2554_8bitLL.MLV
2520x1418_9bitLL.MLV   3000x1432_9bitLL.MLV   4056x2554_9bitLL.MLV
2520x1418_10bitLL.MLV  3000x1432_10bitLL.MLV  4056x2554_10bitLL.MLV
2520x1418_12bitLL.MLV  3000x1432_12bitLL.MLV  4056x2554_12bitLL.MLV
2520x1418_14bitLL.MLV  3000x1432_14bitLL.MLV  4056x2554_14bitLL.MLV

There are only three resolutions here. According to Danne's latest:

Code: [Select]

static const char * crop_choices_100d[] = {
    "OFF",
    "2.5K 2520x1418",
    "3K 3000x1432",
    "4K 3x1 24fps",
    "5K 3x1 24fps",
    "4K 4056x2552",
    "2K 2520x1080p",
    "mv1080p_mv720p mode",
    "3x3 720p",
    "1x3 binning",
    "3x crop mode",

To be continued...

[dfort]

...here are a few test MLV files of a plain textured surface:

Textured surface? That just makes it harder to see the focus pixels. What I asked for was:

...What works best for me is if you can shoot a blank wall...

Check what Danne's samples look like compared to yours:



Also note that these latest samples don't include the settings you used for the first shot that you sent me. How about I start with that one while you sort out all the resolutions on the 100D. Note that this is something that I would do myself but I don't have access to a 100D at the moment.

To be continued...

[dfort]

New 100D focus pixel map files for the samples submitted by IDA_ML are now ready in the repository. These were all 1:1 sampling and the same pattern were used on all of the samples. A couple of the samples shared the same map files. That's why there are only three new map files for the four different settings.



Note that if you click on the image to get to my flickr account and take a very close look you'll notice a pattern on some areas that should be smooth. That's just the way MLVFS combined with ACR looks. Once these maps are working with MLV App we should be able to get even better results.

[Danne]

Beautifully done!

[IDA_ML]

Nice work, Dfort.  The image really looks clean and free of focus pixels.

Please note that shooting a "blank wall" as you suggested, is not a good idea at all.  There are countless blank walls out there but very few of them make the focus pixels pop.  I shot several walls, including white and dark ones and none of them worked.  Finally, I went through our home library and after shooting test files of several dozens of book covers of different colors and texture, I finally found an old book that did a very good job.  Here are a few test files shot at different resolutions in the 3k crop mode of the 100D using that book target:

https://we.tl/t-tnfeKJNJLn

The files were shot slightly underexposed and at 14-bit lossless, as you requested but in my experience, lower bit rates (e.g. 10bits LL) make the focus pixels pop up a little bit better.  This is the reason why I shot my previous set of files at all 5 bit depths for you to check and see which one works best for you.  If you open the above files in MLVApp, set exposure to -4, saturation and dark strength to 100%, dark range to 80% and play a bit with the curves, all focus pixels will be clearly visible on a dark background.

[DeafEyeJedi]

Marvelous work, @dfort! 

[dfort]

When I borrowed a 100D from @DeafEyeJedi and got my first look at the focus pixels from that camera I thought this was quite a different animal. The area that the focus pixels covered and the pattern was quite different from the EOSM and 700D that I was just familiar with. However, now that I've seen lots of samples and some of the bugs in ML that caused the focus pixels to randomly change positions have been addressed, it is looking like all of these cameras that show focus pixels in raw video work pretty much the same. In some settings the focus pixels show up in plain flat colored areas while other settings seem almost focus pixel free until you take a close look at high contrast boundaries.

Please note that although it may seem that I'm only having a discussion with @IDA_ML, if anyone with a 100D would like to help out please do!

Please note that shooting a "blank wall" as you suggested, is not a good idea at all.

My preference is to work with something that doesn't interfere with the pattern. Very early on in one of my first posts of this topic I shared this image:



That's a flat white wall shot at 14-bit no compression -- we didn't even have reduced bit or lossless compression back then. Creating an image like this is still possible so why isn't it a good idea? It certainly is easier to work with than a heavily textured image like the ones you are shooting:

...in my experience, lower bit rates (e.g. 10bits LL) make the focus pixels pop up a little bit better....

My experience is mostly with the 700D and EOSM and those cameras show the focus pixels only on high contrast boundaries when shooting with the reduced bit depth compressed settings. In fact it was nearly impossible to figure out where the focus pixels were until @theBilalFakhouri came up with a moving pattern that made it easy to locate the focus pixels and map them out.

The reason this happens is because with reduced bit depth we're using a different "raw type" @a1ex can explain it better:

With reduced bit rate, we are using a different raw type (i.e. not the "minimally processed" Bayer stream we are used to). Just double-checked and had a little surprise - raw type 0x12 (what we use for reduced bit depth) is actually "lv_af_raw" (known to show this kind of dots even on the old 5D2). This is also labeled as DEFCORRE or DEFOE in some firmwares.

The 100D might be different but from your samples I don't see any advantage of using reduced bit depth settings for mapping focus pixels.

Now let's take a look at your latest samples. It looks like we already have a focus pixel map for these files. In fact all of these samples have the same full raw buffer size so they are using the same map file:

Code: [Select]

for f in *.MLV; do mlv_dump -v "$f" | grep 'Input MLV file\|height\|width'; done
   - Input MLV file: '100D_3k_2288x1288_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2304x1296_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2320x1306_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2336x1314_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2352x1324_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2512x1414_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2528x1422_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2544x1432_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2560x1432_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_2576x1432_14bitLL_1.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_3k_3000x1432_14bitLL_1.MLV'
      height           1460
      width            3072
Looks to me like these are all different image sizes of the same crop_rec setting. In fact the 80000346_3072x1460.fpm map file that is in my repository is working fine on these samples.

I might not have made it clear but what I'm looking for is a sample from each of these settings if you are using Danne's bleeding edge build:

Code: [Select]

static const char * crop_choices_100d[] = {
    "OFF",
    "2.5K 2520x1418",
    "3K 3000x1432",
    "4K 3x1 24fps",
    "5K 3x1 24fps",
    "4K 4056x2552",
    "2K 2520x1080p",
    "mv1080p_mv720p mode",
    "3x3 720p",
    "1x3 binning",
    "3x crop mode",
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.

You don't need to give me all the various bit depths or compression settings. You don't even need to shoot different image sizes or aspect ratios. What we have learned so far is that the pattern doesn't change though the area where the pixels appear does change somewhat. That's part of the reason why I'm now mapping the entire raw buffer, including the out of bounds areas because those areas seem to be changing with some of these new crop_rec settings.

By the way, the reason we can get away with using one focus pixel map file per setting when changing the image size is because the crop/pan position is telling us what part of the full raw buffer is being used. Going back to those latest samples, the crop and pan metadata tells you where the upper left corner of the image is in relationship with the full raw buffer:

Code: [Select]

for f in *.MLV; do mlv_dump -v "$f" | grep 'Input MLV file\|Crop\|Pan'; done
   - Input MLV file: '100D_3k_2288x1288_14bitLL_1.MLV'
    Crop: 104x48
     Pan: 100x49
   - Input MLV file: '100D_3k_2304x1296_14bitLL_1.MLV'
    Crop: 96x44
     Pan: 92x45
   - Input MLV file: '100D_3k_2320x1306_14bitLL_1.MLV'
    Crop: 88x40
     Pan: 84x40
   - Input MLV file: '100D_3k_2336x1314_14bitLL_1.MLV'
    Crop: 80x36
     Pan: 76x36
   - Input MLV file: '100D_3k_2352x1324_14bitLL_1.MLV'
    Crop: 72x30
     Pan: 72x31
   - Input MLV file: '100D_3k_2512x1414_14bitLL_1.MLV'
    Crop: 72x28
     Pan: 72x28
   - Input MLV file: '100D_3k_2528x1422_14bitLL_1.MLV'
    Crop: 72x28
     Pan: 72x28
   - Input MLV file: '100D_3k_2544x1432_14bitLL_1.MLV'
    Crop: 72x28
     Pan: 72x28
   - Input MLV file: '100D_3k_2560x1432_14bitLL_1.MLV'
    Crop: 72x28
     Pan: 72x28
   - Input MLV file: '100D_3k_2576x1432_14bitLL_1.MLV'
    Crop: 72x28
     Pan: 72x28
   - Input MLV file: '100D_3k_3000x1432_14bitLL_1.MLV'
    Crop: 72x28
     Pan: 72x28

Interesting how those last several settings share the same crop/pan settings. This means they all start at the same point in the raw buffer but the lower right point is at a different location. If anyone cares to follow my tutorial on creating focus pixel map files you will get a better understanding of how this works.

Finally--wouldn't it be great if focus pixels magically just vanished? There are some users and developers here on the ML forum working on that. Let's hope they succeed!

[dfort]

Finally--wouldn't it be great if focus pixels magically just vanished?

We might have gone as far as we can go, at least for now. Danne has come up with a setting that is almost focus pixel free on the EOSM:



Looks pretty good but if you look closely, zoom in and adjust vibrance, you'll see there are still some stubborn pixels there:



So did we find an intermediate stage where the focus pixels are processed in camera or maybe this is as far as it goes? I have a theory that perhaps the rest of the focus pixel removal might be done when the image is resized and compressed to H.264. Shooting an H.264 and comparing it to a raw image the compression artifacts blur out the image so just as an experiment what happens if we process this image into H.264?



Looking at the full frame it is hard to tell the difference but zooming in:



Pushing the vibrance way up they are still barely visible. Compressing it just a little bit more will blur them out. This image has gone from MLV to TIFF (via dcraw) to H.264 (via Adobe Media Encoder) and back to TIFF to upload on flickr. There may be some additional chroma smoothing or other processing going on in camera but you get the idea, maybe the in camera process to remove the focus pixels is not quite perfect because the resize and compression processes will blur out whatever is left over.

Speaking of imperfect processes, I've been a bit grumpy with a few of you and have not been very tactful with some of my posts. Please accept my apologies if I have offended anyone. On the other hand, please remember that we're all free to work on whatever we feel like. Not following instructions and posting over and over with what you want done is just going to push that item further down the developers' todo list.

[Danne]

Good theory. We could also rerun some of the raw_types/streams. Maybe this time an alternate one will work better.

[IDA_ML]

Dfort,

I am sorry to see that the test files that I provided did not meet your expectations.  I thought that something like this:





reveals the focus pixels quite well.

Here is a new set of focus pixel test files shot according to your instructions - this time of a plain white untextured surface at 14-bits uncompressed:

https://we.tl/t-SXg5P97HMO

The files were shot with Danne's January 25-th build which is not the latest but was stable enough for the shots.  They cover all normal and cropped modes currently available on the 100D.  I hope, I didn't miss any.  If I did, please let me know which ones they are and I will prepare them for you.  Also, please let me know if the above files work for you.

Over the weekend, I will prepare more test files using the older builds as you suggested.  It would be helpful if you provide download links to the specific builds that you want me to use for the preparation of those files.

[dfort]

The new crop_rec settings are in active development so we're trying to hit a moving target. What I'm interested in seeing is if there are a limited number of full raw buffers and if once we make a map file for a full raw buffer will it work on a different setting that uses the same sized raw buffer.

Ok--let's see what we got:

Code: [Select]

100D_Files_for_FPM_15_02_2019 rosiefort$ for f in *.MLV; do mlv_dump -v "$f" | grep 'Input MLV file\|height\|width'; done
   - Input MLV file: '100D_1736x1184_14bit_1x3_binning.MLV'
      height           1217
      width            1808
   - Input MLV file: '100D_1736x576_14bit_60fps.MLV'
      height           726
      width            1808
   - Input MLV file: '100D_1736x720_14bit_60fps.MLV'
      height           726
      width            1808
   - Input MLV file: '100D_1736x976_14bit_3x_crop_mode.MLV'
      height           1189
      width            1808
   - Input MLV file: '100D_1736x976_14bit_Normal.MLV'
      height           1189
      width            1808
   - Input MLV file: '100D_1736x976_14bit_mv1080p_mv720p_mode.MLV'
      height           1189
      width            1808
   - Input MLV file: '100D_1800x1008_14bit_Movie_Crop_Mode.MLV'
      height           1059
      width            1872
   - Input MLV file: '100D_2520x1076_14bit_Normal_5xMag.MLV'
      height           1107
      width            2592
   - Input MLV file: '100D_2520x1080_14bit_2k.MLV'
      height           1108
      width            2592
   - Input MLV file: '100D_2520x1416_14bit_2k5.MLV'
      height           1447
      width            2592
   - Input MLV file: '100D_3000x1432_14bit_3k.MLV'
      height           1460
      width            3072
   - Input MLV file: '100D_4000x750_14bit_4k.MLV'
      height           779
      width            4072
   - Input MLV file: '100D_5008x708_14bit_5k.MLV'
      height           738
      width            5080

These are the current 100D map files in the repository:

Code: [Select]

ls 80000346*
80000346_1808x1189.fpm 80000346_1872x1059.fpm 80000346_2592x1332.fpm
80000346_1808x1190.fpm 80000346_1872x1060.fpm 80000346_2592x1447.fpm
80000346_1808x726.fpm 80000346_2592x1107.fpm 80000346_3072x1460.fpm
80000346_1808x727.fpm 80000346_2592x1108.fpm 80000346_4128x2582.fpm
On first glance it looks like the map files are working so we only have to deal with a few new settings. Great!

Like the design in the middle of these samples, it actually helps show the pixels without getting in the way.



@Danne -- The other theory is that the focus pixels are mapped out somewhere in the firmware and we haven't found it yet. My understanding is that sensors often have defective pixels and instead of rejecting the chips the dead pixels can be mapped out. Your EOSM has some problem pixels and I've got an idea to take care of that.

Just not yet--got to run off now and take care of other business.

[dfort]

Went through the new samples from IDA_ML and as expected several of them work out of the box with the map files that are already in the repository. There were a few new resolutions that will require new map files but one in particular turned out to be a problem. It has the same full raw buffer size as standard mv1080 (3x3 sampling) but this one is 1x1 sampling. In addition, the focus pixels looked like they were in a different pattern than other 1x1 settings so I started with this one:

100D_1736x976_14bit_3x_crop_mode


This is after I put in about 3 hours into it starting over from scratch several times. No matter what I did, the focus pixels were still there. Once I thought I had it but upon closer inspection they were still there. In addition, processing the DNG files through ACR and dcraw gave completely different looking focus pixel patterns.

So I put it aside and tried another challenging file -- Danne's cat picture using his latest EOSM setting. This one also has a different pattern so I had to start from scratch. Looks pretty good from here:



This is what the pattern looks like:



The focus pixels are quite subtle, this is without any focus pixel fixing:



However, upon closer inspection with the new focus pixel map file it looks like there are still some very faint focus pixels still left in the image:



Hum, should have read my horoscope and hid under the covers today.

Feb 15, 2019 - Some unsettling news from far away could have you stressed out, Aquarius. This might affect your work if you aren't careful. Your mind may stray back and forth from work to the news and its implications. Stay focused. All signs are that whatever you've heard is likely to be far less troublesome than it appears right now. Don't fly off the handle until you know the facts.

Oh well, maybe tomorrow the stars will be in alignment.