Leginon

Saying that the bad rows and columns are "cropped" is misleading, so we will have to correct that. The method used is: A bad row will be replaced with a copy of its nearest neighboring row that is not bad. This was the quick easy way to get rid of the bad row, but there are alternatives that we can investigate, like replacing the bad row with an average of its neighbors. But to clarify the documentation, no rows or columns are actually removed, just overwritten with other data.

It would be nice to label individual pixels as being bad, and this is on our list of things to do. One worry I have is that bad pixels are often bad for only a short time. Sometimes there are hot pixels that are temporary, lasting only a few minutes or hours, or cosmic ray and x-ray hits that only show up in one image. This is why we have the despike function. The despike function works best for spikes that are only a single pixel in area. Sometimes there are small clusters of pixels that form a wide area spikes. These are more difficult to remove using our current algorithm, which looks at the local statistics around each pixel in the image, and removes pixels that are very different from its neighborhood. Again, "remove" means to replace it with something better. In the case of despike, we are replacing the bad pixel with an average of its neighbors. One way to correct larger spike areas is to use a larger despike neighborhood. It is often difficult to optimize the despike parameters because at some point you will be despiking important data in addition to the actual spikes. A larger neighborhood size has better despike results and can handle spikes with larger areas, but with a higher cost in computation time. A lower despike threshold makes it very sensitve to even minor spikes, but at the cost of maybe removing pixels that are not spikes, but important signal data.

A final solution to the bad pixel problem is to ignore it. Instead of correcting it, just make sure the image will display properly (not all black or all white). We have to determine the proper grey level mapping from pixel values to display values. The default in Leginon is to map only the values between display_min and display_max, where:

display_min = image_mean - 5 * image_stdev

display_max = image_mean + 5 * image_stdev

This can be adjusted with the sliders above the image.

This usually works in Leginon, but not in the web display, which is probably using the the default grey mapping:

display_min = image_min

display_max = image_max

which will be very bad if there is a spike. I'll talk to Denis and see if this can be made to work similar to Leginon.

"pulokas" wrote:
It would be nice to label individual pixels as being bad, and this is on our list of things to do. One worry I have is that bad pixels are often bad for only a short time. Sometimes there are hot pixels that are temporary, lasting only a few minutes or hours, or cosmic ray and x-ray hits that only show up in one image. This is why we have the despike function. The despike function works best for spikes that are only a single pixel in area. Sometimes there are small clusters of pixels that form a wide area spikes. These are more difficult to remove using our current algorithm, which looks at the local statistics around each pixel in the image, and removes pixels that are very different from its neighborhood. Again, "remove" means to replace it with something better. In the case of despike, we are replacing the bad pixel with an average of its neighbors. One way to correct larger spike areas is to use a larger despike neighborhood. It is often difficult to optimize the despike parameters because at some point you will be despiking important data in addition to the actual spikes. A larger neighborhood size has better despike results and can handle spikes with larger areas, but with a higher cost in computation time. A lower despike threshold makes it very sensitve to even minor spikes, but at the cost of maybe removing pixels that are not spikes, but important signal data.

Yes, I am concerned about removing inportant signal data and would tend to using a higher despike threshold if possible. Other types of correction might be done later in processing rather than at the Leginon stage (where most users will tend to regard the images as "raw data").

"pulokas" wrote:
A final solution to the bad pixel problem is to ignore it. Instead of correcting it, just make sure the image will display properly (not all black or all white). We have to determine the proper grey level mapping from pixel values to display values. The default in Leginon is to map only the values between display_min and display_max, where:
display_min = image_mean - 5 * image_stdev
display_max = image_mean + 5 * image_stdev
This can be adjusted with the sliders above the image.
This usually works in Leginon, but not in the web display, which is probably using the the default grey mapping:
display_min = image_min
display_max = image_max
which will be very bad if there is a spike. I'll talk to Denis and see if this can be made to work similar to Leginon.

It would be useful to be able to avoid the display problems in the web-based interface without having to apply an "aggressive" correction like a low despike threshold that might remove important data. Do you know what's happening about the web display and when this will be in Leginon? Is it in the latest Leginon already? (I don't have the new version installed yet.) What about dealing with individual bad pixels rather just entire bad rows or columns - do you know when that's likely to be in Leginon?

William

I have a basic question about Leginon fetching images from the microscope. When Leginon is running with Digital Micrograph, presumably Leginon gets the images from Digital Micrograph (with DM running like a kind of server). Does Leginon just get raw images from DM or does the gain normalisation have to be turned off in DM to avoid correcting them twice (i.e. to avoid images being gain normalised by DM, sent to Leginon and then gain normalised/ corrected in the Leginon Correction Node)?

William

Digital Micrograph option of gain normalization does not affect Leginon as far as I know. Leginon gets raw image from Digital Micrograph. You can tell by acquiring a Raw Image in Correction Node with gain normalization set to be ON in Digital Micrograph for a particular recording setup. The raw image in Leginon looks no different from Non-gain normalized Digital Micrograph image.

The Raw Image Leginon gets from Digital Micrograph does include bias level correction and requires good quadrant reference. Therefore, if you notice the gain normalized image (both in leginon and Digital Micrograph) has unequal intensity on the four quadrant of the 4k camera, you will need to set bias level and acquire quadrant references, both available in Digital Micrograph under Camera submenu.

I have some more questions about de-spiking. Does the de-spiking in the Correction Node just de-spike really large values (above the mean by some multiple of standard deviations, given by the "threshold") or does it treat really low values (below the mean by the same number of standard deviations) as well? (The reason I might want it to do the de-spiking in that way is to deal with bad pixels in the camera that are missed from the Bad Rows and Columns plan for some reason e.g. if they really are individual bad pixels or clumps rather than rows or columns. Although X-rays and cosmic rays might be expected to just give hot spots with really high values; bad pixels in the camera can produce really low values as well.) Also, while experimenting with different choices for the Neighbourhood Size and Threshold in the Correction Settings, I noticed that I can't enter a threshold less than 1 (e.g. 0.5 which I tried) although I can enter in decimals (e.g. 1.5 is okay). The Correction Settings dialog allows you to enter the value okay; but on re-entering the Correction Settings dialog the threshold is re-set to 1 if an attempt was made to change it to 0.5 or some other value lower than 1,

William

Despike works on both very high and very low values relative to the mean. The algorithm looks something like this:

- for each pixel, calculate mean and standard deviation of pixel's neighborhood

- if abs(pixel value - mean) > threshold * standard deviation

then replace pixel value with mean value

A new feature in version 1.1.3 allows you to mark individual pixels as bad, rather than whole rows and columns, so this can be a better option if you know a bad pixel is always there (unlike random events, which would require despike). The bad pixel correction is more complicated than despike. Often a whole cluster of bad pixels will be marked as bad, which requires searching a larger neighborhood for good pixels to obtain a mean value to replace the bad pixel.

I fixed that problem with it not allowing a despike threshold less than 1.0. It will be available in the next version, or if you don't want to wait, you can edit the fix directly. Find the line in Leginon/gui/wx/Corrector.py:

self.widgets['despike threshold'] = FloatEntry(self, -1, min=1, chars=9)

and change the min=1 to min=0

Jim

I have a few more questions about the user interface of the Correction Node (in the latest version 1.1.3 of Leginon). I'm not sure how the rows and columns are numbered i.e. is the first column numbered 0 or 1? Also, I'm not sure about the relation of the numbering of the rows and columns to the CCD e.g. if I'm using an 512x512 image with binning 1x presumably the numbering for the first column will start from the first column in the image rather than the entire CCD array? Finally what does the new "grab from image" button do (which is below the fields for bad columns, rows and pixels)?

William

"WVNicholson" wrote: I have a few more questions about the user interface of the Correction Node (in the latest version 1.1.3 of Leginon). I'm not sure how the rows and columns are numbered i.e. is the first column numbered 0 or 1? Also, I'm not sure about the relation of the numbering of the rows and columns to the CCD e.g. if I'm using an 512x512 image with binning 1x presumably the numbering for the first column will start from the first column in the image rather than the entire CCD array? Finally what does the new "grab from image" button do (which is below the fields for bad columns, rows and pixels)?
William

Okay, I've found out how to use the "grab from image" button. It seems to get a set of coordinates of bad pixels after they have been clicked on in the image. I'm still not sure about the other questions though,

William

Hi William,

The rows start with 0 at the top, and columns start with 0 at the left.

You can always consider the final image that you are displaying when numbering rows and columns, not the original CCD column/row that it came from. So every image starts with 0,0 in the upper right. In the same way, it doesn't matter if you used binning or not. The final image will be numbered 0,1,2,3... even if you used binning.

An extra note:

there could sometimes be some confusion about the difference between a row,column coordinate space versus a x,y coordinate space. This is not completely standardized throughout leginon as it should be. On any image display, when panning the mouse pointer over an image, you are seeing the x,y coordinates, where x = column and y = row. Most things having to do with targets refer to x,y. But in correction node and maybe other places, there are references to row,column.

Jim

In the new version 1.1.3 of Leginon, the Correction Node appears to hang when getting bright or dark references when larger numbers are used for the average - at least it hangs for the number (12) recommended by the local Gatan engineers for getting a gain reference for our camera. I've gone back to using a smaller number (4) which has the disadvantage of having a poorer quality gain reference. Also, with the smaller number used for the average, I am using the "mean" option rather than the "median" option for getting the average used for the bright or dark reference; as the notes say that the "median" option has poorer statistics than the "mean" option for smaller numbers although it has the advantage of removing spikes.

(Some recent problems noticed while trying to identify bad pixels do suggest that bright and dark references, obtained using a smaller number for the average, do tend to have some spikes that are not observed when re-obtaining the references shortly after),

William