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 |
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. |
Hi. At least one thing is sure... :) 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 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. |
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 |
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. |
In reply to this post by Ghislain Bugnicourt
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 : 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 : 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. |
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] |
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 |
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. > |
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. >> > 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 |
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. 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. |
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. |
Free forum by Nabble | Edit this page |