Badpixel Mapping for Different Exposures - page 2 - Feature Requests - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2] 3 4 5   Go Down

Badpixel Mapping for Different Exposures

  • 48 Replies
  • 20356 Views
*

Offline Sess

  • *
  • 28
Re: Badpixel Mapping for Different Exposures
« Reply #10 on: 06 / July / 2008, 22:14:17 »
Advertisements
Quote from: fudgey on 30 / June / 2008, 17:32:04
Umm...well... my initial reaction was... I never thought dead pixels would be exposure time dependent. If you get more dead pixels in a long exposure, I would have thought that was just because there are a number of pixels that behave badly and for a long exposure the probability to get a certain pixel appear dead is greater and thus more of them would be seen?

The physical pixels are the same for every exposure time after all.

I never referred to dead pixels in my original explanation.


Quote from: RaduP on 01 / July / 2008, 01:03:02
Yeah, I think there are two kind of 'bad' pixels:
1. Truly dead (or always on) pixels that stay like that the whole time, regardless of exposure.
2. The noise pixels, which are random, and can not be mapped out.

The types of pixels I'm trying to address are those that cause problems due to consistent power leakage. A pixel that has a large and constant power problem can result in a hot pixel that shows up white on all shots. However a pixel with only a slight problem may not show up on most shots, but with longer exposures, that slight power error in that pixel can be compounded to create a hot pixel on your image that has an absolutely consistent position and only shows up on exposures exceeding a certain length.

In other words, while there is a great deal of random noise that can result from long exposures, there are also pixels that will consistently cause problems at various exposures. With that information, it should be possible to map them out.

Please remember that Badpixel Mapping is a feature that already exists within CHDK, it just isn't widely known since there is no reference to it in menus and you have to fully read the documentation to find it. I am merely suggesting an upgrade to this feature that would allow the selection of mapped out pixels to be based on shutter speed. Dark frame subtraction is of course very useful for combating the random noise generated by multi-second exposures, but what I'm suggesting could greatly improve the quality of noise reduction by automatically removing those pixels that are consistently problematic at certain shutter speeds.

And as for Vignetting, while I do appreciate people's interest in this thread, please don't hijack it with an unrelated topic.
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Badpixel Mapping for Different Exposures
« Reply #11 on: 07 / July / 2008, 07:49:03 »
Well, it's easy to implement in and of itself.

There is one little issue. From the AllBest usage page, I read:
"For lengthy shutter speeds you might want to experiment with that X tolerance value, as you don't want to remove slightly warmer pixels that now look very bright. They might be containing useful data which can be dealt with better by using noise-removal techniques to quiet them down"

We could just ignore this, and do as the page says - i.e. let them be dealt with in post-processing -, or we could set the pixels straight. It should be possible, especially if we have the bad pixels list also for the two neighboring exposure times.

What would the best algorithm to do that be, though?
If the pixel is "not very warm", I suppose one could just subtract the warmness, then re-normalize the brightness by multiplying for (Warmness+MaxPixelValue)/MaxPixelValue.
If the pixel is "very warm", though, a sizeable part of the real information in it would already be lost, so it should still be partly reconstructed by interpolating the neighboring pixels.

What about this:


MaxPixelValue=255 or 1024 or whatever
if(Pixel is in the warm pixels list) {
  // Subtract bias and renormalize
  PixelValue=(PixelValue-Warmness)*(Warmness+MaxPixelValue)/MaxPixelValue
  // Average with a nearest neighbor interpolation, weighed by amount of bias
  PixelValue=(PixelValue*(MaxPixelValue-Warmness)+NeighborPixelValue*Warmness)/MaxPixelValue
}
« Last Edit: 07 / July / 2008, 07:53:44 by LjL »
Logged
*

Offline Sess

  • *
  • 28
Re: Badpixel Mapping for Different Exposures
« Reply #12 on: 07 / July / 2008, 16:55:11 »
Quote from: LjL on 07 / July / 2008, 07:49:03
There is one little issue. From the AllBest usage page, I read:
"For lengthy shutter speeds you might want to experiment with that X tolerance value, as you don't want to remove slightly warmer pixels that now look very bright. They might be containing useful data which can be dealt with better by using noise-removal techniques to quiet them down"

I read this as well and it is this problem that my idea is intended to solve. As the quote says, you cannot just take a really long exposure and just map out the bad pixels for all shutter speeds, because at faster speeds you will have lost the information from a lot of pixels that only cause problems with longer exposures.


Quote from: LjL on 07 / July / 2008, 07:49:03
We could just ignore this, and do as the page says - i.e. let them be dealt with in post-processing -, or we could set the pixels straight. It should be possible, especially if we have the bad pixels list also for the two neighboring exposure times.

What would the best algorithm to do that be, though?
If the pixel is "not very warm", I suppose one could just subtract the warmness, then re-normalize the brightness by multiplying for (Warmness+MaxPixelValue)/MaxPixelValue.
If the pixel is "very warm", though, a sizeable part of the real information in it would already be lost, so it should still be partly reconstructed by interpolating the neighboring pixels.

Well the bad pixel list is generated by a little program that runs in a command window. You feed it the file name of a raw and the X tolerance and it generates the list of pixels which are too bright. Not only that, but next to the coordinates of the pixel is what I believe to be the strength (or warmness) of that pixel. If that is indeed what that number represents then the warmness data is indeed available for all the bad pixels and could therefore be used in your algorithm.


Quote from: LjL on 07 / July / 2008, 07:49:03
What about this:


MaxPixelValue=255 or 1024 or whatever
if(Pixel is in the warm pixels list) {
  // Subtract bias and renormalize
  PixelValue=(PixelValue-Warmness)*(Warmness+MaxPixelValue)/MaxPixelValue
  // Average with a nearest neighbor interpolation, weighed by amount of bias
  PixelValue=(PixelValue*(MaxPixelValue-Warmness)+NeighborPixelValue*Warmness)/MaxPixelValue
}


Well I suppose this could be done. But here's the thing... I've asked to make an existing feature just slightly more robust in the hopes that it would not be too difficult and so one of the developers would just go ahead and implement it. While your idea isn't bad, it's just a little more complicated and therefore a little less likely to be implemented. For one thing, your idea seems very similar to the existing noise reduction features of the cameras, so some developers might not be interested in reinventing the wheel. I do like your idea and I think a combination of bad pixel data at various shutter speeds combined with the strength (or warmness) of those pixels could help produce a better method of cleaning bad pixels than my idea alone. But again, I just want a developer to look at this idea as an easy little project and just go for it.
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Badpixel Mapping for Different Exposures
« Reply #13 on: 07 / July / 2008, 19:44:52 »
Well, ok, let's get hands dirty then - or one never does anything.

Attached are two versions of core/gui.c and core/raw.c (branched from DataGhost, no idea if they'd compile on AllBest or anything), with your idea implemented, but ABSOLUTELY NOT TESTED (right now, it crashes my camera half the times). Too late in the night to test it now.

Anyway, the idea is that you create a directory called "BADPIXELS" inside your card, and inside it, you put bad-pixels lists for every exposure you want to have one for, named like the "tv96" value for that exposure time (which should be propcase 262 and/or 264, at least on DIGIC III).


Another problem I fathom, anyway... My A720 (and I think many other cameras) display a blue glow on the top left side with long exposures. How are we telling that apart from bad pixels? (It is bad pixels in a sense, but erm, the list length is hardcoded to 4096...)


EDIT: Here it is, uploading works again.
« Last Edit: 08 / July / 2008, 07:26:21 by LjL »
Logged
*

Offline Sess

  • *
  • 28
Re: Badpixel Mapping for Different Exposures
« Reply #14 on: 07 / July / 2008, 22:29:30 »
I didn't realize you knew how to work on this code. I myself do not so please don't expect me to be able to edit or compile anything. Anyway, did you write your code such that it will look for the nearest shutter speed in case a file does not exist for the specific shutter speed of the camera? In other words, if it is set to 1/2 second, but I only have a file for 1/8 second and 1 second, it will choose the file for 1 second instead of just doing nothing.

As for the blue glow, that happens on my A650 as well on exposures starting at 16 or maybe 8 seconds. I'll double check later. However I've taken very long exposure of actual objects and that glow has never appeared. It only seems to show up on dark field tests. Perhaps within the glow the bad pixels are apparent, so there could be some way to subtract it out before processing for bad pixels. But the program works directly on camera raw files... I'm not sure if it will work on a DNG. So this bad pixel method may only work on shutter speeds before the glow appears.
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Badpixel Mapping for Different Exposures
« Reply #15 on: 08 / July / 2008, 07:25:11 »
No, I haven't done that. It will just print "No badpixels list found for tv x".

It's very preliminary as I said - to be very honest, I haven't used the badpixels mapping feature at all, yet!

As for compiling, it's not that difficult at least if you're on Linux, the instructions are here. I could probably try to make a binary build for the A650, but I'm afraid the forum wouldn't let me host it, since it's not letting me host a 20Kb file ;)

In any case, what's important is the source code, so that someone can eventually integrate it into a mainstream build...

Anyway, sorry if I insist, but I think that, if anything, when a file for a given exposure is missing, the code should look at the two nearest ones, and interpolate a badpixels list from them - and then if the pixel is not 100% bad, renormalize and average the result with a nearest neighbor interpolation.

I'll try to do that now, although the part of the code that reads the badpixels file is pretty annoying to parse...


EDIT: Uhm, I'd like to use the AllBest code, since I think DataGhost has an older badpixels routine, and possibly doesn't work on the A650... but where do I get it? The link I've found posted is down.
« Last Edit: 08 / July / 2008, 07:58:48 by LjL »
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Badpixel Mapping for Different Exposures
« Reply #16 on: 08 / July / 2008, 09:56:00 »
Ok, this version perhaps still doesn't work (the old version definitely didn't), but at least it's using the files I give it for a given shutter speed. And I've now checked that the bad pixels actually get averaged out.

It does the weighed average between the renormalized pixel value and the nearest neighbor, but it doesn't try to work for exposure times it doesn't have a badpixels list for.

The really annoying thing is that there is no access to the shutter speeds table (and to its parameters, SS_SIZE, etc), so while the previous version tried to allocate a vector of 65536 pointers (yuck! ... and failed), I now allocate a small table and then loop through it to find the current exposure.

It's still far from ideal, though... it's weird, because platform.h does at least export some values/functions for the aperture sizes table - not so for shutter speeds.

Anyway, here you go... it's still for the DataGhost branch, mind. I'm sorry, but it doesn't compile for the A650, as it misses all the functions that DataGhost added (IS, etc). I need to find AllBest's source code...
« Last Edit: 08 / July / 2008, 10:17:35 by LjL »
Logged
*

Offline Sess

  • *
  • 28
Re: Badpixel Mapping for Different Exposures
« Reply #17 on: 08 / July / 2008, 14:59:46 »
The version I'm running on my A650 is allbest-a650-100d-51-421. All I have is the .BIN file, I don't have the source code and I'm having trouble finding it as well. When I've looked recently at the list of Allbest releases, I haven't actually seen 51 there. I think I actually downloaded it from a link in a thread where someone said they were using that build on their own A650. I would certainly prefer Allbest being used since (unless I missed something) isn't Allbest the general purpose/base line type build and the others branch off into specialties?

Anyway, great job so far. I'm glad someone with talent has finally taken an interest in my thread. As I've said before, I really think the ability for users to map out their camera's bad pixels on their own (as opposed to sending it to Canon) is one of the best features of CHDK.
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Badpixel Mapping for Different Exposures
« Reply #18 on: 08 / July / 2008, 15:54:39 »
Well, no, the "collaborative" build is also pretty generic.

The "DataGhost" build that I'm using is a sort of developer-friendly branch. You can download it using SVN from a link in the thread.

I'd give you an AllBest compile, really, but I can't do that unless I manage to get hold of the AllBest source code...
Logged
*

Offline Bg~

  • *
  • 27
Re: Badpixel Mapping for Different Exposures
« Reply #19 on: 08 / July / 2008, 17:15:08 »
Quote from: LjL on 08 / July / 2008, 15:54:39
I'd give you an AllBest compile, really, but I can't do that unless I manage to get hold of the AllBest source code...

Isn't the svn trunk the AllBest source? (svn server is down for me though right now)
Logged
Pages: 1 [2] 3 4 5   Go Up
« previous next »
 

Related Topics