Posted by
Ghislain Bugnicourt on
Aug 27, 2008; 3:55pm
URL: http://imagej.273.s1.nabble.com/Set-Threshold-records-incorrect-values-16bit-images-Ubuntu-tp3695217p3695220.html
I notice I should have explained more clearly my problem.
So, I took pictures so that you see exactly what I do to find the bug.
First, my example picture again :
FA1-YL.tifHere, I open the Threshold, set window.
Threshold_Step_1.pngThen, I click OK without even changing anything (or I move to OK with 'tab' and I press 'space').
Threshold_Step_2.pngAs you see, this time the values were modified : 97 became 5 and 768 became 255. But I want to highlight the fact that it doesn't occur every time. More precisely, sometimes I have to try more than 10 times before the bug appears. But afterwards, it appears almost at each 'set' call. The only way to start again is to press 'reset' or 'auto'.
I tried something that I should have tried from the beginning : running the simple macro "setThreshold(107, 400);" (107 and 400 are examples). Indeed, what happens is surprising ! First, the image displays something variable, incorrect most of the time. Second, the 'threshold' window displays variable numbers (exple : for the min value, 107 or 9), like when using the 'set' window. Third, when I click on the threshold window, everything is corrected and I can finish with apply, which means that 107 and 400 are taken into account even if 9 and 255 were displayed.
In other words, the problem could be considered as solved, but it would imply that I use a new macro each time I want a threshold. Not possible ! And in fact the bug itself is not corrected (not even understood). I am sorry because I really should have tried the 'setThreshold' command before.
Now I answer Gabriel Landini 's questions :
I mainly found the bug on my own machine, but ALSO on another machine, running Debian 4.
My machine contains AMD Turion64 x2. But the one with Debian contains Pentium 4.
I tried the 1.40 and the 1.41j version of ij.jar on my computer, both enable the bug.
I don't know what you call the "slider resolution", but if it is what I referred to as "the numbers available with the scrolling bars", then I can affirm (in opposition with what I claimed before) that the bug may appear in both cases : whether you chose a number available, or not available in this 'scale'.
Now, Michael Schmid 's suggestion :
I tried exactly what you explained to me. And there is no problem when compiling. Then, when I use the plugin, in debug mode, everything works like the built-in 'threshold' command, but just NOTHING appears in the log window, except for the line that was already present in the code. Like if adjustmentValueChanged(e) weren't called. I don't understand what it means :).
Finally, David Randell 's question :
Thank you my friend ! Now I am not the only one in the world who witnessed the bug. :)
You met the problem when repeating 'set' and 'ok' : yes, I also meet the problem doing so. But it may also appear at the first try, or even buy changing the values every time.
You say that the values change arbitrarily ; I would be interested if you told how. In my case, it always decreases. For instance, 107 becomes 9 and 9 becomes 0 and 0 stays at 0.
Last thing : when the values change, is the image displayed in coherence with this change ? In my case yes.
Thank you all, again and again.