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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

David Randell
Ghislain and Wayne,

For what its worth: I tried to re-create that thresholding bug on my
laptop using OpenSuse v10.3, same version of ImageJ (i.e. 1.41j) but
using Java 1.5.0_15. I could not replicate the bug. The only variables
on my platform are the version of Java used and the OS, i.e.

OpenSuse 10.3, Java 1.5.0_15, ImageJ v1.41j - no problem noted
Ubuntu 8.04, Java 1.6.0_05, ImageJ v1.41j - bug noted

Dave Randell
Reply | Threaded
Open this post in threaded view
|

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

Ghislain Bugnicourt
In reply to this post by Ghislain Bugnicourt
First of all, I discovered something I had not noticed before : sometimes, the "auto" command itself, in the threshold window, generates a little error. In fact, the numbers displayed next to the sliders are the same as when it works (97/768), but the image is displayed like if those numbers were 92/768.
It's hard to believe that it will help you understand the problem. But I think I should tell you anything I see since you can't witness the bug.
Doesn't it give you the will to try Ubuntu right now ? :)

I tried to make a classification of the resulsts displayed but Wayne's plugin (still the previous one).
Here they are (the only differences are within the bold lines) :

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: 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
----Result : 97/255

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
----Exactly the same as Wayne's (or mine when there is no error)
----Result : 5/255 !!!! (this is the most frequent bug)
----Perhaps we don't print the interesting variables, the ones that contain the error (for example "doSet5" is always the same, thus not interesting).

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
----No problem this time. 97/768

I realize you have already seen them, but I confirm that those three are the most frequent ones.
Reply | Threaded
Open this post in threaded view
|

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

Ghislain Bugnicourt
Michael wrote
Hi Ghislain,
ok, if you get the error, but there are no "Adjustment:" log
messages, then the problem is NOT due to the sliders.
So my suspicion of the sliders being a cause for the problem
was not correct, you can forget the sliders.
Hi. At least one thing is sure... :)
By the way, it would be interesting to see whether there is
an extra thread that causes the problems. If the problems are
there, do you see more than one "ThresholdAdjuster" in the list
created by Plugins>Utilities>Threads?
I tried, but I am not aware of what we sould see in this list. Anyway, I get this when the threshold window is open, before and after a bug.

  Thread Group: system  Max Priority: 10
     Thread: Reference Handler  Priority: 10 Daemon
     Thread: Finalizer  Priority: 8 Daemon
     Thread: Signal Dispatcher  Priority: 9 Daemon
     Thread: Java2D Disposer  Priority: 10 Daemon
     Thread: TimerQueue  Priority: 5 Daemon
     Thread Group: main  Max Priority: 10
         Thread: AWT-XAWT  Priority: 6 Daemon
         Thread: AWT-Shutdown  Priority: 5
         Thread: AWT-EventQueue-0  Priority: 6
         Thread: SocketListener  Priority: 5
         Thread: DestroyJavaVM  Priority: 5
         Thread: ThresholdAdjuster  Priority: 2
         Thread: Threads...  Priority: 4

One more remark, if you urgently need a quick and ugly workaround:
Here is a macro that bypasses that problem:
   getStatistics(area, mean, min, max);
   Dialog.create("Set Threshold");
   Dialog.addNumber("Lower", min);
   Dialog.addNumber("Upper", max);
   Dialog.show();
   lower = Dialog.getNumber();
   upper = Dialog.getNumber();
   setThreshold(lower, upper);
Thank you. It works, and there is no surprise. However I will try not to use it, because I still hope we will soon solve this problem.
Regards,
Ghislain.
Reply | Threaded
Open this post in threaded view
|

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

David Randell
Hi everybody,

Well I spotted something that may provide a clue to what's going on
here: the *size* of the image seems to make a difference. I re-scaled
Ghislain's original image to a 100*74 16-bit image and cannot replicate
the bug, either in the case where the result is interpolated or not.  
Incrementally scaling the image back to its original size the bug
re-appeared with a 350*26 16-bit scaled image.

Dave Randell
Reply | Threaded
Open this post in threaded view
|

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

Gabriel Landini
On Thursday 28 August 2008, David Randell wrote:
> Hi everybody,
>
> Well I spotted something that may provide a clue to what's going on
> here: the *size* of the image seems to make a difference. I re-scaled
> Ghislain's original image to a 100*74 16-bit image and cannot replicate
> the bug, either in the case where the result is interpolated or not.
> Incrementally scaling the image back to its original size the bug
> re-appeared with a 350*26 16-bit scaled image.

Ah, yes... I can confirm that.
If I scale up the M51 image by 9 (2880x4590) if get funny values just by
pressing Set and Ok. But this is happening occasional in my setup (about once
every 20).

Cheers,

G.
Reply | Threaded
Open this post in threaded view
|

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

Ghislain Bugnicourt
In reply to this post by Ghislain Bugnicourt
Wayne wrote
Dear Ghislain,
I'm sorry to hear that the bug remains but I still think it is thread
synchronization problem. Here is another version of the plugin that
updates the "Threshold" window without directly calling scaleDown() and
scaleUpAndSet(). It also waits 0.5 seconds before updating the window.
Does it work any better?
Wonderful !
Here is Wayne's plugin : Threshold_Adjuster2.java(I renamed it)
And this time it works !

I forgot to tell about this, but when compiling Wayne's plugins a message is shown :
/home/ghislain/.imagej/ImageJ/plugins/Threshold_Adjuster2.java:177: warning: [deprecation] show() in java.awt.Window has been deprecated
                show();
                ^
1 warning
Perhaps it is normal...

I decided to modify the time before updating the image : and here is the key !
Actually, if I let 500 (ms), it works perfectly. If I change it to 50 or 5, the bug occurs almost each time.

I think this is in coherence with David's idea :
Well I spotted something that may provide a clue to what's going on
here: the *size* of the image seems to make a difference. I re-scaled
Ghislain's original image to a 100*74 16-bit image and cannot replicate
the bug, either in the case where the result is interpolated or not.  
Incrementally scaling the image back to its original size the bug
re-appeared with a 350*26 16-bit scaled image.
I imagine that the little image is modified faster than the big one :). Which leads to less errors.
I would like to know if non-Ubuntu users can now witness the bug with this new plugin and a value of 5 ms instead of 500 (just because I'm curious).

Thank you Wayne. Really. Not only for resolving the problem, but for your time and consideration.
I imagine that you still need some work to correct the bug completely, and make it stable for another ImageJ version. So if I may help in order to try new threshold plugins, or anything else, there will be no problem.
Reply | Threaded
Open this post in threaded view
|

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

John Alexander-7
Not sure if this is related at all, but I've been finding various "race"
or synchrony bugs in many of my macros.

I've found them to occur only when I have setBatchMode set to false
(which I do to watch the macro to make sure it is behaving correctly).
But once I put it to setBatchMode true, then it works flawlessly.
I also found the incidence of errors to (somewhat) correlate with the
image size.


John




Ghislain Bugnicourt wrote:

> Wayne wrote:
>> Dear Ghislain,
>> I'm sorry to hear that the bug remains but I still think it is thread
>> synchronization problem. Here is another version of the plugin that
>> updates the "Threshold" window without directly calling scaleDown() and
>> scaleUpAndSet(). It also waits 0.5 seconds before updating the window.
>> Does it work any better?
>>
>
> Wonderful !
> Here is Wayne's plugin :
> http://n2.nabble.com/file/n789839/Threshold_Adjuster2.java
> Threshold_Adjuster2.java (I renamed it)
> And this time it works !
>
> I forgot to tell about this, but when compiling Wayne's plugins a message is
> shown :
>
>
>> /home/ghislain/.imagej/ImageJ/plugins/Threshold_Adjuster2.java:177:
>> warning: [deprecation] show() in java.awt.Window has been deprecated
>> show();
>> ^
>> 1 warning
>>
> Perhaps it is normal...
>
> I decided to modify the time before updating the image : and here is the key
> !
> Actually, if I let 500 (ms), it works perfectly. If I change it to 50 or 5,
> the bug occurs almost each time.
>
> I think this is in coherence with David's idea :
>
>
>> Well I spotted something that may provide a clue to what's going on
>> here: the *size* of the image seems to make a difference. I re-scaled
>> Ghislain's original image to a 100*74 16-bit image and cannot replicate
>> the bug, either in the case where the result is interpolated or not.  
>> Incrementally scaling the image back to its original size the bug
>> re-appeared with a 350*26 16-bit scaled image.
>>
> I imagine that the little image is modified faster than the big one :).
> Which leads to less errors.
> I would like to know if non-Ubuntu users can now witness the bug with this
> new plugin and a value of 5 ms instead of 500 (just because I'm curious).
>
> Thank you Wayne. Really. Not only for resolving the problem, but for your
> time and consideration.
> I imagine that you still need some work to correct the bug completely, and
> make it stable for another ImageJ version. So if I may help in order to try
> new threshold plugins, or anything else, there will be no problem.
>

--
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]
Reply | Threaded
Open this post in threaded view
|

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

David Randell
In reply to this post by Ghislain Bugnicourt
Ghislain Bugnicourt wrote:

> Wayne wrote:
>  
>> Dear Ghislain,
>> I'm sorry to hear that the bug remains but I still think it is thread
>> synchronization problem. Here is another version of the plugin that
>> updates the "Threshold" window without directly calling scaleDown() and
>> scaleUpAndSet(). It also waits 0.5 seconds before updating the window.
>> Does it work any better?
>>
>>    
>
> Wonderful !
> Here is Wayne's plugin :
> http://n2.nabble.com/file/n789839/Threshold_Adjuster2.java
> Threshold_Adjuster2.java (I renamed it)
> And this time it works !
>  

Yes, I can confirm this too.

> I forgot to tell about this, but when compiling Wayne's plugins a message is
> shown :
>
>
>  
>> /home/ghislain/.imagej/ImageJ/plugins/Threshold_Adjuster2.java:177:
>> warning: [deprecation] show() in java.awt.Window has been deprecated
>> show();
>> ^
>> 1 warning
>>
>>    
> Perhaps it is normal...
>  

I spotted this too...

> I decided to modify the time before updating the image : and here is the key
> !
> Actually, if I let 500 (ms), it works perfectly. If I change it to 50 or 5,
> the bug occurs almost each time.
>
> I think this is in coherence with David's idea :
>
>
>  
>> Well I spotted something that may provide a clue to what's going on
>> here: the *size* of the image seems to make a difference. I re-scaled
>> Ghislain's original image to a 100*74 16-bit image and cannot replicate
>> the bug, either in the case where the result is interpolated or not.  
>> Incrementally scaling the image back to its original size the bug
>> re-appeared with a 350*26 16-bit scaled image.
>>
>>    
> I imagine that the little image is modified faster than the big one :).
> Which leads to less errors.
> I would like to know if non-Ubuntu users can now witness the bug with this
> new plugin and a value of 5 ms instead of 500 (just because I'm curious).
>  

Well it already seems that Gabriel (using OpenSuse 11.0) has replicated
this bug by rescaling the example M51 image so it's clearly not
restricted to Ubuntu 8.04.

Incidently, I also replicated the bug using a 32-bit image, but I think
we already know now that this is most likely a red-herring.

> Thank you Wayne. Really. Not only for resolving the problem, but for your
> time and consideration.
>  

Yes indeed. Many thanks Wayne...

Dave Randell
Reply | Threaded
Open this post in threaded view
|

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

Wayne Rasband
In reply to this post by Ghislain Bugnicourt
This fix is in the 1.41k daily build.

-wayne

On Aug 28, 2008, at 11:08 AM, Ghislain Bugnicourt wrote:

> Wayne wrote:
>>
>> Dear Ghislain,
>> I'm sorry to hear that the bug remains but I still think it is thread
>> synchronization problem. Here is another version of the plugin that
>> updates the "Threshold" window without directly calling scaleDown()  
>> and
>> scaleUpAndSet(). It also waits 0.5 seconds before updating the window.
>> Does it work any better?
>>
>
> Wonderful !
> Here is Wayne's plugin :
> http://n2.nabble.com/file/n789839/Threshold_Adjuster2.java
> Threshold_Adjuster2.java (I renamed it)
> And this time it works !
>
> I forgot to tell about this, but when compiling Wayne's plugins a  
> message is
> shown :
>
>
>> /home/ghislain/.imagej/ImageJ/plugins/Threshold_Adjuster2.java:177:
>> warning: [deprecation] show() in java.awt.Window has been deprecated
>> show();
>> ^
>> 1 warning
>>
> Perhaps it is normal...
>
> I decided to modify the time before updating the image : and here is  
> the key
> !
> Actually, if I let 500 (ms), it works perfectly. If I change it to 50  
> or 5,
> the bug occurs almost each time.
>
> I think this is in coherence with David's idea :
>
>
>> Well I spotted something that may provide a clue to what's going on
>> here: the *size* of the image seems to make a difference. I re-scaled
>> Ghislain's original image to a 100*74 16-bit image and cannot  
>> replicate
>> the bug, either in the case where the result is interpolated or not.
>> Incrementally scaling the image back to its original size the bug
>> re-appeared with a 350*26 16-bit scaled image.
>>
> I imagine that the little image is modified faster than the big one :).
> Which leads to less errors.
> I would like to know if non-Ubuntu users can now witness the bug with  
> this
> new plugin and a value of 5 ms instead of 500 (just because I'm  
> curious).
>
> Thank you Wayne. Really. Not only for resolving the problem, but for  
> your
> time and consideration.
> I imagine that you still need some work to correct the bug completely,  
> and
> make it stable for another ImageJ version. So if I may help in order  
> to try
> new threshold plugins, or anything else, there will be no problem.
>
> --  
> View this message in context:  
> http://n2.nabble.com/%22Set-Threshold%22-records-incorrect-values-- 
> -16bit-images---Ubuntu-tp760077p789839.html
> Sent from the ImageJ mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

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

David Randell
Wayne Rasband wrote:

> This fix is in the 1.41k daily build.
>
> -wayne
>
> On Aug 28, 2008, at 11:08 AM, Ghislain Bugnicourt wrote:
>
>> Wayne wrote:
>>>
>>> Dear Ghislain,
>>> I'm sorry to hear that the bug remains but I still think it is thread
>>> synchronization problem. Here is another version of the plugin that
>>> updates the "Threshold" window without directly calling scaleDown() and
>>> scaleUpAndSet(). It also waits 0.5 seconds before updating the window.
>>> Does it work any better?
>>>
>>
>> Wonderful !
>> Here is Wayne's plugin :
>> http://n2.nabble.com/file/n789839/Threshold_Adjuster2.java
>> Threshold_Adjuster2.java (I renamed it)
>> And this time it works !
>>
>> I forgot to tell about this, but when compiling Wayne's plugins a
>> message is
>> shown :
>>
>>
>>> /home/ghislain/.imagej/ImageJ/plugins/Threshold_Adjuster2.java:177:
>>> warning: [deprecation] show() in java.awt.Window has been deprecated
>>> show();
>>> ^
>>> 1 warning
>>>
>> Perhaps it is normal...
>>
>> I decided to modify the time before updating the image : and here is
>> the key
>> !
>> Actually, if I let 500 (ms), it works perfectly. If I change it to 50
>> or 5,
>> the bug occurs almost each time.
>>
>> I think this is in coherence with David's idea :
>>
>>
>>> Well I spotted something that may provide a clue to what's going on
>>> here: the *size* of the image seems to make a difference. I re-scaled
>>> Ghislain's original image to a 100*74 16-bit image and cannot replicate
>>> the bug, either in the case where the result is interpolated or not.
>>> Incrementally scaling the image back to its original size the bug
>>> re-appeared with a 350*26 16-bit scaled image.
>>>
>> I imagine that the little image is modified faster than the big one :).
>> Which leads to less errors.
>> I would like to know if non-Ubuntu users can now witness the bug with
>> this
>> new plugin and a value of 5 ms instead of 500 (just because I'm
>> curious).
>>
>> Thank you Wayne. Really. Not only for resolving the problem, but for
>> your
>> time and consideration.
>> I imagine that you still need some work to correct the bug
>> completely, and
>> make it stable for another ImageJ version. So if I may help in order
>> to try
>> new threshold plugins, or anything else, there will be no problem.
>>
>> -- View this message in context:
>> http://n2.nabble.com/%22Set-Threshold%22-records-incorrect-values---16bit-images---Ubuntu-tp760077p789839.html 
>>
>> Sent from the ImageJ mailing list archive at Nabble.com.
>>
>
Hi Wayne,

Not wanting to be a kill-joy here, but I replicated the same bug using
the daily-build (1.41k) and simply increasing the size of the test
image... :-(

Dave Randell
Reply | Threaded
Open this post in threaded view
|

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

Ghislain Bugnicourt
David Randell wrote
Not wanting to be a kill-joy here, but I replicated the same bug using
the daily-build (1.41k) and simply increasing the size of the test
image... :-(
Hi. I am still using Wayne's plugin, and there are three reasons for that :
 - I don't want to learn how to get the daily-built version (I can't explain why),
 - well... the plugin works perfectly with my images, which all have the same size,
 - and that would allow me to change the "IJ.wait()" time, if the bug should reappear.

David wrote
Hi Ghislain,
   I had an email from Wayne yesterday about still getting that bug using
large image files. I tried another ij.jar file he sent where the delay
was increased to 1 sec, but his made no difference. In fact contrary to
what one might have expected, the bug appeared almost immediately.
   I just wondered what you are currently doing to minimise this error
arising. Are you logging file sizes to flag the possibility of errors
arising during the processing of your images?
   You have to hand it to Wayne for his support. That is quite
extraordinary. I wish I had better Java programming skills to dig deeper
into this issue, but I don't alas.
I am sorry but as I said, the bug doesn't appear on my images any more. It allows me to work, at last !
It is true that the bug comes back if I make the images... say 4 times bigger, but it is corrected if I change the time proportionally (the famous 500ms). I am wondering that it should evolve proportionally to the surface of the image, not its width and height. Anyway I don't find the bug on my image if I make it 8 times bigger (which makes a 117M image...) with a time of 2 sec. It seems reasonable (it is long of course, but who works with 117M images ?).
I am in the same state of mind as you : If I had time and skill, I would try to look at the code.
Nevertheless, all I can do is trying on my computer any change somebody else would do to the code. And I will do it if you send me something.

Thank you, to everybody who helped me.
Reply | Threaded
Open this post in threaded view
|

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

Gabriel Landini
On Friday 29 August 2008, Ghislain Bugnicourt wrote:
>  - I don't want to learn how to get the daily-built version (I can't
> explain why),


Well, I am sorry to spoil if for you:

Help>Update ImageJ>daily build

and restart IJ. You will now have the most up to date version of IJ.
It is very handy to avoid running old versions with bugs.

G.
12