search

MicronOxford / SIMcheck

SIMcheck: ImageJ tools for assessing Structured Illumination Microscopy (SIM) data quality and reliability
GNU General Public License v3.0
28 stars 5 forks source link

MCNR Exception calling #27

Open ezemiron opened 8 years ago

ezemiron commented 8 years ago

Running SIMcheck>Raw data>Modulation contrast on an image with negative pixel values, inf or NaN's produce an Exception window to pup up with the following information:

(Fiji Is Just) ImageJ 2.0.0-rc-43/1.50g; Java 1.6.0_65 [64-bit]; Mac OS X 10.10.5; 1618MB of 7241MB (22%)

java.lang.NumberFormatException: Infinite or NaN at java.math.BigDecimal.(BigDecimal.java:797) at SIMcheck.J.d2s(J.java:111) at SIMcheck.ResultSet.report(ResultSet.java:146) at SIMcheck.Raw_ModContrast.run(Raw_ModContrast.java:106) at ij.IJ.runUserPlugIn(IJ.java:212) at ij.IJ.runPlugIn(IJ.java:176) at ij.Executer.runCommand(Executer.java:137) at ij.Executer.run(Executer.java:66) at java.lang.Thread.run(Thread.java:695)

iandobbie commented 8 years ago

No surprise there. This function is for raw data and doesn't expect negative or non-existent numbers. Maybe it should fail more cleanly but I don't think this is a serious bug.

Ian

Sent from my iPhone

On 31 Mar 2016, at 12:59, ezemiron notifications@github.com<mailto:notifications@github.com> wrote:

Running SIMcheck>Raw data>Modulation contrast on an image with negative pixel values, inf or NaN's produce an Exception window to pup up with the following information:

(Fiji Is Just) ImageJ 2.0.0-rc-43/1.50g; Java 1.6.0_65 [64-bit]; Mac OS X 10.10.5; 1618MB of 7241MB (22%)

java.lang.NumberFormatException: Infinite or NaN at java.math.BigDecimal.(BigDecimal.java:797) at SIMcheck.J.d2s(J.java:111) at SIMcheck.ResultSet.report(ResultSet.java:146) at SIMcheck.Raw_ModContrast.run(Raw_ModContrast.java:106) at ij.IJ.runUserPlugIn(IJ.java:212) at ij.IJ.runPlugIn(IJ.java:176) at ij.Executer.runCommand(Executer.java:137) at ij.Executer.run(Executer.java:66) at java.lang.Thread.run(Thread.java:695)

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/MicronOxford/SIMcheck/issues/27

ezemiron commented 8 years ago

That is what I thought. However, I am using it on raw data that has been aligned to match the alignment of my reconstructed data.

The rationale behind this is to use an aligned MCNR and create a binary mask of "trustworthy" values to overlay on to my aligned reconstructed results, excluding some results based on SIM quality not just intensity (like what happens in the modal-threshold tool).

The problem arises with how the alignment software fills the 1-pixel gap between the pixels left by the alignment shift (all zeros) and the rest of the real image pixels. What it seems to do is some interpolation between these zeros and the pixels of the image to generate a 1-pixel row/column of intermediate values, possibly to avoid a hard edge?. On some datasets these pixels are positive (perhaps like a weighted average), so no MCNR problems, but for other datasets these are small negative values (no idea how they are derived) and then MCNR can't cope.

E

graemeball commented 8 years ago

@ezemiron thanks for letting us know -- I will make a note to fix the issue. In the meantime, did you try adding a small offset to the pixel intensities to make them all positive?

Cheers, Graeme

ezemiron commented 8 years ago

Thanks, I've thought of something similar, although I can't do a standard small offset value because this changes from image to image. I was thinking of using a threshold at 0 and working from there. E

graemeball commented 8 years ago

@ezemiron you could use ImageJ's Process>Math>Min function with a value of 0