"Set Threshold" records incorrect values - 16bit images - Ubuntu

[Ghislain Bugnicourt]

Hi. First of all, thanks for this wonderful customizable imaging tool.

My issue is about the "set" option of the "adjust...threshold" tool, on 16-bit grey-scale images. I didn't find such a problem in the archive.
In this "set" dialog box, if I enter values that are not available with the scrolling bars, it modifies the values. For instance, 107 becomes 9, 940 becomes 104, 372 becomes 107, following a law I couldn't understand, and depending on the image. The images I obtain (even when doing 'apply') respect those wrong numbers.
But what is incredible is that sometimes it works well in exactly the same conditions (1/10 times).

This problem appeared three days ago (about after upgrading ImageJ but I'm not sure), before it worked perfectly. Is it an isolated bug ? Were there recent changes in the threshold code ?
Thanks for your attention.

Configuration :
 - Ubuntu 8.04 (There's no problem on Mac and Windows. But I couldn't try another Ubuntu 8.04)
 - The compiz bug (blank images) linked with Java was previously corrected by canceling the visual effects in Ubuntu.
 - ImageJ 1.41j, with Java 1.6.0_05
 - 16-bit images obtained with Metamorph (immuno-fluorescence on neuron cultures)

[Ghislain Bugnicourt]

Dear Wayne,

Thanks for your response. I'm sorry because I didn't expose it clearly enough : the problem with 'Threshold, set' is not present on the Windows and Mac ImageJ files.
Actually, I only found this problem on Ubuntu, and more recently on Debian. Therefore, it seems that the linux installing file has a problem. I join my previous message to explain what happens.

Thanks a lot for your care.
Ghislain Bugnicourt
CNRS - CRETA - France

Ghislain Bugnicourt wrote

Hi. First of all, thanks for this wonderful customizable imaging tool.

My issue is about the "set" option of the "adjust...threshold" tool, on 16-bit grey-scale images. I didn't find such a problem in the archive.
In this "set" dialog box, if I enter values that are not available with the scrolling bars, it modifies the values. For instance, 107 becomes 9, 940 becomes 104, 372 becomes 107, following a law I couldn't understand, and depending on the image. The images I obtain (even when doing 'apply') respect those wrong numbers.
But what is incredible is that sometimes it works well in exactly the same conditions (1/10 times).

Configuration :
 - Ubuntu 8.04 (There's no problem on Mac and Windows. But I couldn't try another Ubuntu 8.04)
 - The compiz bug (blank images) linked with Java was previously corrected by canceling the visual effects in Ubuntu.
 - ImageJ 1.41j, with Java 1.6.0_05
 - 16-bit images obtained with Metamorph (immuno-fluorescence on neuron cultures)

[John Alexander-7]

I'm using Suse 10.1 Linux 64-bit with ImageJ 1.41j and Java 1.6.0

I'm not quite sure I understand the problem you're encountering, but, I
just loaded the M51.tif sample 16-bit image.

It has a histogram of gray values between 0 and 10106 - so it is shy of
the full 16-bit range that goes up to 65535

I found that if I "set" the threshold to anything outside of that range,
it re-sets it to be within the range of pixel values.  For example: low:
0 and high: 20000 -> resets to low:0 and high: 10106.

If I add 10000 to each pixel (math->add->10000), then the range is 10000
to 20106.  Again, if I set low:5000 and high: 25000 -> resets to low:
10000 and high: 20106.

But I don't necessarily think this is a bug in that this is what I would
expect to happen - is this what you are referring to?

If not, see if you can post an image that this happens with or, better
yet, use a File->Open Samples image.

John




Ghislain Bugnicourt wrote:

> Dear Wayne,
>
> Thanks for your response. I'm sorry because I didn't expose it clearly
> enough : the problem with 'Threshold, set' is not present on the Windows and
> Mac ImageJ files.
> Actually, I only found this problem on Ubuntu, and more recently on Debian.
> Therefore, it seems that the linux installing file has a problem. I join my
> previous message to explain what happens.
>
> Thanks a lot for your care.
> Ghislain Bugnicourt
> CNRS - CRETA - France
>
>
>
> Ghislain Bugnicourt wrote:
>> Hi. First of all, thanks for this wonderful customizable imaging tool.
>>
>> My issue is about the "set" option of the "adjust...threshold" tool, on
>> 16-bit grey-scale images. I didn't find such a problem in the archive.
>> In this "set" dialog box, if I enter values that are not available with
>> the scrolling bars, it modifies the values. For instance, 107 becomes 9,
>> 940 becomes 104, 372 becomes 107, following a law I couldn't understand,
>> and depending on the image. The images I obtain (even when doing 'apply')
>> respect those wrong numbers.
>> But what is incredible is that sometimes it works well in exactly the same
>> conditions (1/10 times).
>>
>> Configuration :
>>  - Ubuntu 8.04 (There's no problem on Mac and Windows. But I couldn't try
>> another Ubuntu 8.04)
>>  - The compiz bug (blank images) linked with Java was previously corrected
>> by canceling the visual effects in Ubuntu.
>>  - ImageJ 1.41j, with Java 1.6.0_05
>>  - 16-bit images obtained with Metamorph (immuno-fluorescence on neuron
>> cultures)
>>
>

--
John K. Alexander, Ph.D.
Post-Doctoral Fellow
William Green Laboratory
University of Chicago
Dept. Neurobiology, Pharmacology, and Physiology
947 East 58th Street
Abott Hall 402
Chicago, IL 60637
(off) 773-702-9386
(fax) 773-702-3774
[hidden email]

[Ghislain Bugnicourt]

Thank you Wayne and John for your help.

 Wayne,
I meet the same problem using four java versions :  the one joined with ImageJ, sun's java 1.6.0_05, but also sun's 1.6.0_06 and 1.6.0_07, and finally the open source version, openjdk 1.6.0_0.
Nevertheless, it doesn't show that it is not a java problem. :)
I repeat (for those who are discovering this thread) that I found the bug on Ubuntu 8.04 and on an old version of Debian, NOT on Windows and Mac OS x.

 John,
When I said 'numbers not available with the scrollbars', I didn't mean outside the scale. I just meant : between the values that 'threshold' is proposing. What you described is not a bug, I agree with you.
I upload a typical image : FA1-YL.tif
On this image, please try to 'set' the lower threshold value to 107, and the upper to 500, for instance. On my computer, it works about 5 times out of 10. But I insist on this fact : sometimes it seems to work more than 10 times ! And the problem occurs in series.
Moreover, it depends on the image : on the example image M51 (16-bit), I only found the problem once out of about 100 times. That's why I uploaded my own image, to show you.

Thank you again, I 'hope' that other linux users will meet the same problem as me.
Ghislain

[Gabriel Landini]

On Tuesday 26 August 2008, Ghislain Bugnicourt wrote:
> I meet the same problem using four java versions :  the one joined with
> ImageJ, sun's java 1.6.0_05, but also sun's 1.6.0_06 and 1.6.0_07, and
> finally the open source version, openjdk 1.6.0_0.
> Nevertheless, it doesn't show that it is not a java problem. :)
> I repeat (for those who are discovering this thread) that I found the bug
> on Ubuntu 8.04 and on an old version of Debian, NOT on Windows and Mac OS
> x.

I have installed 1.6.0_07 (suse 11.0)
I can load the m51.tif, I can set the threshold to any numbers I type.

setThreshold(444, 1000);
setThreshold(445, 1000);
setThreshold(445, 1014);
setThreshold(446, 1015);

> When I said 'numbers not available with the scrollbars', I didn't mean
> outside the scale. I just meant : between the values that 'threshold' is
> proposing.

I do not see that either. I can put 359 as min (and the jump between
scrollable points are 357 and 396).

> What you described is not a bug, I agree with you.
> I upload a typical image :  http://n2.nabble.com/file/n784535/FA1-YL.tif
> FA1-YL.tif
> On this image, please try to 'set' the lower threshold value to 107, and
> the upper to 500, for instance. On my computer, it works about 5 times out
> of 10. But I insist on this fact : sometimes it seems to work more than 10
> times ! And the problem occurs in series.

I do not see that either. I can set it to 100-500 with the ij.jar 1.41k
the recorded shows setThreshold(107, 500); and so does the Threshol window.

Regards

G.

[Ghislain Bugnicourt]

Hi.
I could test the 'threshold set' option on various OS : (all from the same ij140.x86.tar.gz file)
 - on Ubuntu 8.04, Knopix 5.1, Debian (I didn't look at the version), Ubuntu 7.04, the problem appeared.
 - surprisingly, the problem did not appear on Fedora 4 (java version 1.6.0_05).
 - I couldn't try on suse
It implies that it is not a bug included into the tar.gz file, but rather a java problem. As I said, I didn't find any java version that worked better than another.
List of all the java versions I tried on my computer : 1.5.0, 1.6.0_05, 1.6.0_06, 1.6.0_07, and openjdk 1.6.

Now I hope other Ubuntu users (or other linux users) will tell us if they meet the same problem.
It seems that there is no solution for the moment, isn't it ?
Thank you all for your help.
Ghislain.

[Michael Schmid]

Hi Ghislain,

my suspicion: the sliders might somehow modify the values,
(maybe when closing the dialog window?).

My suggestion for debugging - create a user plugin from the
built-in Threshold djuster (Great that ImageJ has the same
structure for user plugins and almost all built-in commands!):

- Load
http://rsb.info.nih.gov/ij/source/ij/plugin/frame/ThresholdAdjuster.java
into the plugins directory and rename it to Threshold_Adjuster.java
- replace package ij.plugin.frame; by import ij.plugin.frame.*;
- replace all occurrences of ThresholdAdjuster by Threshold_Adjuster
- in public synchronized void adjustmentValueChanged(AdjustmentEvent e)
add as a first line:
         IJ.log("Adjustment:\n"+e+"\nBefore: "+minValue+","+maxValue);
and as a last line:
         IJ.log("After: "+minValue+","+maxValue);

Then run it with "Compile and Run". After restarting ImageJ it
should be available as a command in the Plugins menu.
You should see in the log window if the sliders get modified
and how they modify your values.

If you have problems - e.g. if you cannot compile it because I
have forgotten a modification, please contact me off-list.

I can't try for myself because I don't have ImageJ on any Linux
machine.

Michael
________________________________________________________________


On 26 Aug 2008, at 10:20, Ghislain Bugnicourt wrote:

> Dear Wayne,
>
> Thanks for your response. I'm sorry because I didn't expose it clearly
> enough : the problem with 'Threshold, set' is not present on the  
> Windows and
> Mac ImageJ files.
> Actually, I only found this problem on Ubuntu, and more recently on  
> Debian.
> Therefore, it seems that the linux installing file has a problem. I  
> join my
> previous message to explain what happens.
>
> Thanks a lot for your care.
> Ghislain Bugnicourt
> CNRS - CRETA - France
>
>
>
> Ghislain Bugnicourt wrote:
>>
>> Hi. First of all, thanks for this wonderful customizable imaging  
>> tool.
>>
>> My issue is about the "set" option of the "adjust...threshold"  
>> tool, on
>> 16-bit grey-scale images. I didn't find such a problem in the  
>> archive.
>> In this "set" dialog box, if I enter values that are not available  
>> with
>> the scrolling bars, it modifies the values. For instance, 107  
>> becomes 9,
>> 940 becomes 104, 372 becomes 107, following a law I couldn't  
>> understand,
>> and depending on the image. The images I obtain (even when doing  
>> 'apply')
>> respect those wrong numbers.
>> But what is incredible is that sometimes it works well in exactly  
>> the same
>> conditions (1/10 times).
>>
>> Configuration :
>>  - Ubuntu 8.04 (There's no problem on Mac and Windows. But I  
>> couldn't try
>> another Ubuntu 8.04)
>>  - The compiz bug (blank images) linked with Java was previously  
>> corrected
>> by canceling the visual effects in Ubuntu.
>>  - ImageJ 1.41j, with Java 1.6.0_05
>>  - 16-bit images obtained with Metamorph (immuno-fluorescence on  
>> neuron
>> cultures)
>>
>
> --
> View this message in context: <a href="http://n2.nabble.com/%22Set-Threshold%">http://n2.nabble.com/%22Set-Threshold% 
> 22-records-incorrect-values---16bit-images---Ubuntu-
> tp760077p783457.html
> Sent from the ImageJ mailing list archive at Nabble.com.

[Gabriel Landini]

On Wednesday 27 August 2008, Ghislain Bugnicourt wrote:
> I could test the 'threshold set' option on various OS : (all from the same
> ij140.x86.tar.gz file)

Is this always the same machine?

>  - on Ubuntu 8.04, Knopix 5.1, Debian (I didn't look at the version),
> Ubuntu 7.04, the problem appeared.
>  - surprisingly, the problem did not appear on Fedora 4 (java version
> 1.6.0_05).
>  - I couldn't try on suse

I could (11.0), and it does not happen.

> It implies that it is not a bug included into the tar.gz file, but rather a
> java problem. As I said, I didn't find any java version that worked better
> than another.

So what happens if you run this macro with your image:

setThreshold(445, 1000);

What does the threshold window show?
Could it be the slider resolution?

> List of all the java versions I tried on my computer : 1.5.0, 1.6.0_05,
> 1.6.0_06, 1.6.0_07, and openjdk 1.6.

Hm... this sounds very strange. What CPU do you have? There have been some
weird things going on with multiple core cpus (but none currently I am aware
of).

Have you tried with an updated version of the ij.jar? 1.40 is not new (I have
installed 1.41k) and what you see might not happen in an updated IJ.

G.

[David Randell]

Gabriel Landini wrote:

> On Wednesday 27 August 2008, Ghislain Bugnicourt wrote:
>  
>> I could test the 'threshold set' option on various OS : (all from the same
>> ij140.x86.tar.gz file)
>>    
>
> Is this always the same machine?
>
>  
>>  - on Ubuntu 8.04, Knopix 5.1, Debian (I didn't look at the version),
>> Ubuntu 7.04, the problem appeared.
>>  - surprisingly, the problem did not appear on Fedora 4 (java version
>> 1.6.0_05).
>>  - I couldn't try on suse
>>    
>
> I could (11.0), and it does not happen.
>
>  
>> It implies that it is not a bug included into the tar.gz file, but rather a
>> java problem. As I said, I didn't find any java version that worked better
>> than another.
>>    
>
> So what happens if you run this macro with your image:
>
> setThreshold(445, 1000);
>
> What does the threshold window show?
> Could it be the slider resolution?
>
>  
>> List of all the java versions I tried on my computer : 1.5.0, 1.6.0_05,
>> 1.6.0_06, 1.6.0_07, and openjdk 1.6.
>>    
>
> Hm... this sounds very strange. What CPU do you have? There have been some
> weird things going on with multiple core cpus (but none currently I am aware
> of).
>
> Have you tried with an updated version of the ij.jar? 1.40 is not new (I have
> installed 1.41k) and what you see might not happen in an updated IJ.
>
> G.
>
>  

As it happens I am currently running ImageJ 1.41j and Java 1.6.0_05
under Ubuntu 8.04...

I first loaded your image several times and had no problems setting
threshold to min/max 107/500.

However, what I did notice was that after setting the threshold to
107/500 and repeating this setting several times using the same
threshold window on the same image, (i.e. repeatedly using the "Set"
button and then OK-ing this) the max min values then changed somewhat
arbitrarily.  Is this the same behaviour you have witnessed?

For 8-bit images it seems fine: but 16-bit images seem to generate this
odd behaviour.

Dave Randell

[Ghislain Bugnicourt]

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.tif
Here, I open the Threshold, set window. Threshold_Step_1.png
Then, I click OK without even changing anything (or I move to OK with 'tab' and I press 'space'). Threshold_Step_2.png
As 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.

[David Randell]

> Finally, David Randell 's question :
> Thank you my friend ! Now I am not the only one in the world who witnessed
> the bug. :)
>  

Yes I thought you would be happy to see you are not the only one to
witness this 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.
>  

Yes sometimes it appears to happen immediately, other times after
several tries.
> 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.
>  
I logged the min/max settings returned repeating Set and OK using your
image:

97,768
97,768
5,255
84,255
0,64
84,64
0,0
0,-31
.
.
.

I cannot make much sense to this... You can see when a value reaches 0,
it does not necessarily remain 0.
> Last thing : when the values change, is the image displayed in coherence
> with this change ? In my case yes.
>  

Yes that is right, when the settings in the threshold window change, so
does the image in agreement with this.

Dave Randell

[Gabriel Landini]

On Wednesday 27 August 2008, Ghislain Bugnicourt wrote:
> I tried the 1.40 and the 1.41j version of ij.jar on my computer, both
> enable the bug.

I keep trying but it does not happen here...

> 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'.


Try starting IJ with the -Xint switch and try again.
Something like:

./jdk1.5.0_15/bin/java -Xmx1800m -Xint -cp
ij.jar:jimi.jar:./jdk1.5.0_15/lib/tools.jar ij.ImageJ

(all in one line and of course adjust the location of the jdk files). This
will switch off the JIT compiler (it will run slower, but you will then see
if it solves the problem).

Very odd...

G.

[David Randell]

Gabriel Landini wrote:

> On Wednesday 27 August 2008, Ghislain Bugnicourt wrote:
>  
>> I tried the 1.40 and the 1.41j version of ij.jar on my computer, both
>> enable the bug.
>>    
>
> I keep trying but it does not happen here...
>
>  
>> 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'.
>>    
>
>
> Try starting IJ with the -Xint switch and try again.
> Something like:
>
> ./jdk1.5.0_15/bin/java -Xmx1800m -Xint -cp
> ij.jar:jimi.jar:./jdk1.5.0_15/lib/tools.jar ij.ImageJ
>
> (all in one line and of course adjust the location of the jdk files). This
> will switch off the JIT compiler (it will run slower, but you will then see
> if it solves the problem).
>
> Very odd...
>
> G.
>
>  

Hi Gabriel,

No this switch does not solve it. Its very strange behaviour, as the
values returned by repeating the Set and OK commands to the Threshold
window seem to follow no obvious pattern. I've tried it several times
now and every time I seem to get a different sequence of values returned
using the same image on the same platform.  Very odd...

Dave Randell

[Ghislain Bugnicourt]

I confirm that David Randell and I have exactly the same problem.
I even witnessed the same list of min/max values on this image, and sometimes the list is different. Which implies that the change in the values is 'semi-arbitrary'.
David, can you tell us what CPU you use, and your memory for instance (and anything I forget...)? I witnessed the bug with 512M and 256M in the 'run' command (I've got 1GB DDR2), but nobody knows.

Gabriel :
I tried your idea (while not understanding anything).
In my 'run' file, I wrote :
./jre/bin/java -Xmx1800m -Xint -cp ij.jar:jimi.jar:./jre/lib/tools.jar ij.ImageJ
and then I tried :
./jre/bin/java -Xmx256m -Xint -cp ij.jar:jimi.jar:./jre/lib/tools.jar ij.ImageJ

I chose jre for the reason I don't find any jdk folder.
In both cases, the bug appeared. Sorry. :)

Wayne : Thanks, I try the plugin right now.

Ghislain.

[Ghislain Bugnicourt]

Very interesting...
Here is what I obtain from a plugin sent by Wayne (when the image is actually modified by the bug).
doSet1: 107.0   500.0
doSet2: 107.0   500.0
doSet3: 8.6   26.502000615574023   84.0   768.0
doSet4: 9.0   155.0

And here is what he obtained on the same image :

Wayne wrote

This is the output I always get, with your FA1-YL.tif example image,
when I click on the "Set" button in the plugin and then "OK" in the
dialog.

    doSet1: 97.0   768.0
    doSet2: 97.0   768.0
    doSet3: 4.8   255.0   84.0   768.0
    doSet4: 97.0   768.0

-wayne

I'm not sure all the people following the tread recieved this plugin, so I upload it : Threshold_Adjuster.java
The four IJ.log() are located in the "doSet" function.
Here is the key. But I still don't understand. :)

[Ghislain Bugnicourt]

I tried to understand what happens to these numbers. So, I show you 3 typical results :
doSet1: 107.0   500.0
doSet2: 107.0   500.0
doSet3: 8.6   155.08771929824562   84.0   768.0
doSet4: 107.0   500.0
-- This first time, the threshold works correctly. Like on Wayne's example. Final min/max : 107/500
doSet1: 107.0   500.0
doSet2: 107.0   500.0
doSet3: 8.6   155.08771929824562   84.0   768.0
doSet4: 107.0   500.0
-- This second time, I witnessed the bug ! Final min/max : 9/155, that is to say the 2 first numbers of line 3.
-- It may be surprising since these 4 lines are strictly identical to the 4 above.
-- Moreover, the result was the same as in my previous post, even if the fourth line is different !
-- I'm going crazy because I don't manage to get the same fourth line as in this previous post.
doSet1: 9.0   155.0
doSet2: 9.0   155.0
doSet3: 0.0   26.469298245614034   84.0   768.0
doSet4: 84.0   155.0
-- This time, I click 'set' and 'ok' without changing the values (which are the previous result : 9/155).
-- And the result is amazing : 84/155 ; the fourth line this time.

Wayne wrote

This is the output I always get, with your FA1-YL.tif example image,
when I click on the "Set" button in the plugin and then "OK" in the
dialog.

    doSet1: 97.0   768.0
    doSet2: 97.0   768.0
    doSet3: 4.8   255.0   84.0   768.0
    doSet4: 97.0   768.0

-wayne

Perhaps you're awaiting the lines I obtain with 97/768 instead of 107/500. Here they are :
doSet1: 97.0   768.0
doSet2: 97.0   768.0
doSet3: 4.8   255.0   84.0   768.0
doSet4: 97.0   768.0
-- Really like with 107/500 : these 4 lines are displayed whether there is a bug or not.

[David Randell]

Ghislain Bugnicourt wrote:
> I confirm that David Randell and I have exactly the same problem.
> I even witnessed the same list of min/max values on this image, and
> sometimes the list is different. Which implies that the change in the values
> is 'semi-arbitrary'.
>  

Hi Ghislain,

Yes its semi-arbitrary in the sense that while the list of values
changes with repeated attempts to replicate the bug, the individual
(min/max) thresholded values returned for the thresholded image have a
distinct pattern to them...

(I did note by the way for a couple of runs and values returned the
image does NOT change to reflect them, but seems to return back to the
original image and stays put?...)
> David, can you tell us what CPU you use, and your memory for instance (and
> anything I forget...)? I witnessed the bug with 512M and 256M in the 'run'
> command (I've got 1GB DDR2), but nobody knows.
>  

I'm using a vintage Fujitsu-Siemens Amilo A (CY-26) laptop:

CPU: mobile AMD Athlon (tm) 1600+
Graphics: ATi Radeon Mobility U1
RAM: 471 MB

ImageJ version 1.41j
Java.version: 1.6.0_05

Ubuntu 8.04
Kernel Linux 2.6.24-19-generic
GNOME: 2.22.3

ImageJ run settings:
~/ImageJ/jre/bin/java -Xmx512m -jar ~/ImageJ/ij.jar -ijpath ~/ImageJ

(NB. Changing the memory to 256m makes no difference to the appearance
of the bug.)

Dave Randell

[Ghislain Bugnicourt]

Thanks, Wayne, for the modified plugin. I upload it again, so that everybody can follow. David, in particular.
Threshold_Adjuster.java

First, sometimes I get exactly the same numbers as you, Wayne, and the result is correct.
Sometimes, the result is correct AND I don't get the same numbers. For instance, here, scaleDown is used twice :
  doSet1: 97.0   768.0
  doSet2: 97.0   768.0
  scaleDown1: 97.0  85.0  768.0
  scaleDown2: 4.5  85.0  768.0
  scaleDown1: 768.0  85.0  768.0
  scaleDown2: 255.0  85.0  768.0
  scaleUpAndSet1: 4.5  255.0
  scaleUpAndSet2: 97.0  768.0  85.0  768.0
  scaleDown1: 97.0  84.0  768.0
  scaleDown2: 4.8  84.0  768.0
  scaleDown1: 768.0  84.0  768.0
  scaleDown2: 255.0  84.0  768.0
  doSet3: 4.8   255.0   84.0   768.0
  scaleUpAndSet1: 4.8  255.0
  scaleUpAndSet2: 97.0  768.0  84.0  768.0
  doSet4: 97.0   768.0
  doSet5: 97.0   768.0
----- I also saw the same with 87 instead of 85

But when it is incorrect, I obtain incredible things.
Here are two examples :
  doSet1: 97.0   768.0
  doSet2: 97.0   768.0
  scaleDown1: 97.0  84.0  768.0
  scaleDown2: 4.8  84.0  768.0
  scaleDown1: 768.0  84.0  768.0
  scaleDown2: 255.0  84.0  768.0
  doSet3: 4.8   255.0   84.0   768.0
  scaleUpAndSet1: 4.8  255.0
  scaleUpAndSet2: 97.0  768.0  84.0  768.0
  doSet4: 97.0   768.0
  doSet5: 97.0   768.0
-----This time, I get 5/255

  doSet1: 97.0   768.0
  scaleDown1: 97.0  84.0  768.0
  doSet2: 97.0   768.0
  scaleDown1: 97.0  84.0  768.0
  scaleDown2: 4.8  84.0  768.0
  scaleDown1: 768.0  84.0  768.0
  scaleDown2: 255.0  84.0  768.0
  doSet3: 4.8   255.0   84.0   768.0
  scaleUpAndSet1: 4.8  255.0
  scaleUpAndSet2: 97.0  768.0  84.0  768.0
  doSet4: 97.0   768.0
  scaleDown2: 4.8  84.0  768.0
  scaleDown1: 255.0  84.0  768.0
  scaleDown2: 63.8  84.0  768.0
  scaleUpAndSet1: 4.8  63.8
  scaleUpAndSet2: 97.0  255.0  84.0  768.0
  doSet5: 97.0   255.0
----And this time, 97/255. Look at the order of the lines : scaleDown1 comes too early... I think I didn't mix the lines, since we can't do that in the 'log window' and I just copied the text (error in 'paste' ? No...).

Well, if anybody can understand something... I don't.

In France, it is 10:30 pm, so I leave work. Don't expect answers before a few hours...
I want to thank you a lot for your help.

Wayne wrote

Dear Ghislain,

The output you are getting indicates that the bug may be in the
scaleDown() and/or scaleUpAndSet() methods so I added debugging code to
these two methods in the attached version of the plugin. I also added a
5th debug line to the doSet() method, after the call to
updateScrollbars(). Here is the output I get:
    doSet1: 97.0   768.0
    doSet2: 97.0   768.0
    scaleDown1: 97.0  84.0  768.0
    scaleDown2: 4.8  84.0  768.0
    scaleDown1: 768.0  84.0  768.0
    scaleDown2: 255.0  84.0  768.0
    doSet3: 4.8   255.0   84.0   768.0
    scaleUpAndSet1: 4.8  255.0
    scaleUpAndSet2: 97.0  768.0  84.0  768.0
    doSet4: 97.0   768.0
    doSet5: 97.0   768.0

-wayne

[David Randell]

Hi Wayne and Ghislain,

I'll take a closer look at the debugging output of that modified plugin
today...

But to reiterate the somewhat arbitrary behaviour of this bug, I logged
the following behaviour on three consecutive runs this morning.

Loading Ghislain's image I repeatedly clicked the Set and OK buttons of
the Threshold window 9 times on the first run, once on the second and 18
times on the third before the displayed threshold values changed and the
image changed to reflect this. Thereafter on each occasion the min/max
values displayed changed as follows: 97/768 (original pre-set min/max
values displayed), 5/255, 0/64, 0/-7, 0/-31, and from then on seemed to
stay at these values. At the point where the values changed to 0/64, the
previously thresholded image reverted back to the original
un-thresholded image, and it remained in that state.

On the fourth test run the behaviour changed yet again: the output
values and image changed on the first Set/OK click, then it output the
following: 5/255, 84/255 (x2), 0/64, 84/64, 84/84 (x3), 0/0, 0/-31 -
where e.g. "x3" means it remained in this state for three Set/OK clicks.

Dave Randell

[Ghislain Bugnicourt]

Good morning.
I've got three messages to answer or comment.
So your help was not just a wonderful dream ?

Another time, here is Wyane's new plugin : Threshold_Adjuster.java
His message explains it :

Wayne wrote

  Dear Ghislain,
This looks like a thread synchronization problem. Here is a version of
the plugin that makes the scaleDown() and scaleUpAndSet() methods
synchronized. Does it work any better?

Well I'm sorry but the bug remained. It was a good idea (as far as I can understand), but don't take the line inversion (previous post) into consideration. I didn't manage to witness it again.
Only the scaleDown() repetition comes back frequently, like in order to correct an error (see the 85 in bold, previous message).

Michael Schmid wrote

Hi Ghislain,
sorry to bother you - 2 questions:
- Does the plugin modified with IJ.log messages have the same
   bug as the built-in Threshold command?
- Do you get messages in the log window if you move the sliders?
If the answer to both questions is "yes", we can rule out that
the problem is caused by the sliders.
(for explanation: the adjustmentValueChanged(e) methods should
be called if a user moves the sliders).
Best wishes,

I am sorry : I had not understood that this function was called when we move the sliders.
So I did your modifications again, but in Wayne's plugin.
I don't know what to expect, but it seems to work properly. And the bug remains.
I consider that the IJ.log lines could only help us find the problem, they will never solve it miraculously :).
Brief : my 2 answers are yes, but it doesn't demonstrate that the sliders have a problem.
Example of the result : in this case, I just moved the min value with its slider, to get min = 97. The max value didn't move, it is at 768 (but it could be anything else and we would get -1 also at the 'after' line).
    Adjustment:
    java.awt.event.AdjustmentEvent[ADJUSTMENT_VALUE_CHANGED,...
    ...adjType=UNIT_INCREMENT,value=5,isAdjusting=false] on scrollbar0
    Before: -1,-1
    After: 5,-1
If I chose to move the other slider, of course, I get "After: -1, 255" for instance (if I reach 768 which is the max). And the "Before" line is always : -1, -1.

David Randell wrote

At the point where the values changed to 0/64, the
previously thresholded image reverted back to the original
un-thresholded image, and it remained in that state.

I think both limits (max and min) are just colocated at the 84 grey level. So we don't get the "un-thresholded" image back, but the image thresholded with 84/84. It is normal, in fact.
Thanks for your tries. We complete each other...