ImageJ

Weird behavior with GenericDialog.addImage

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

CARL Philippe (LBP)

Weird behavior with GenericDialog.addImage

Dear all (probably Wayne),
When I'm compiling a GenericDialog with an addImage method loading a picture of a given size and I decrease later on the picture size, the method often "remembers" the previously compiled size.
And in the case this issue happens, the only solution I found is to kill ImageJ and launch it again.
I have noticed this issue only going from a bigger sized picture to a smaller one not the inverse way.
And if I go from a small picture to a bigger one and then back to the first one I won't have the issue as well.
Wayne: Thanks a lot for the addDirectoryField and addFileField methods update.
The Drag&Drop feature addition is really cool!!!
My best regards,
Philippe

Philippe CARL
Laboratoire de Bioimagerie et Pathologies
UMR 7021 CNRS - Université de Strasbourg
Faculté de Pharmacie
74 route du Rhin
67401 ILLKIRCH
Tel : +33(0)3 68 85 42 89

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Gabriel Landini

Re: Weird behavior with GenericDialog.addImage

On Thursday, 30 July 2020 10:29:36 BST you wrote:
> Dear all (probably Wayne),
> When I'm compiling a GenericDialog with an addImage method loading a picture
> of a given size and I decrease later on the picture size, the method often
> "reme> mbers" the previously compiled size.

Strange things happen, but a newly compiled program remembering a past life
sounds like impossible :-)

Do you Refresh Menus each time you compile the code?
You might not be running the latest compiled version but one held in memory if
you call it from the plugins menu and did not refresh the menus.

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

CARL Philippe (LBP)

Re: Weird behavior with GenericDialog.addImage

Dear Gabriel,
Thanks a lot for your replay, nevertheless I'm not really sure what you want to point me out here.
Thus let me go slightly deeper into my description.
I'm playing around with an "About..." window I would like to create within a PlugIn.
So I have:
public void run(String arg)
{
arg = "about"; // I have temporary added this line for easy testing of my showAbout() method.
if (arg.equals("about"))
{
showAbout();
return;
}
on one side, and on the other side:
public void showAbout()
{
...
gd = new GenericDialog("My_plygin - About...");
...
gd.addImage(imp);
...
gd.showDialog();
And for compiling (using the last daily build version of ImageJ) I use Plugins>Compile_and_run...
Did I answer your reply?
My best regards,
Philippe

----- Mail original -----
De: "Gabriel Landini" <[hidden email]>
À: "imagej" <[hidden email]>
Envoyé: Jeudi 30 Juillet 2020 12:05:56
Objet: Re: Weird behavior with GenericDialog.addImage

On Thursday, 30 July 2020 10:29:36 BST you wrote:
> Dear all (probably Wayne),
> When I'm compiling a GenericDialog with an addImage method loading a picture
> of a given size and I decrease later on the picture size, the method often
> "reme> mbers" the previously compiled size.

Strange things happen, but a newly compiled program remembering a past life
sounds like impossible :-)

Do you Refresh Menus each time you compile the code?
You might not be running the latest compiled version but one held in memory if
you call it from the plugins menu and did not refresh the menus.

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Gabriel Landini

Re: Weird behavior with GenericDialog.addImage

On Thursday, 30 July 2020 11:39:42 BST you wrote:
> Thanks a lot for your replay, nevertheless I'm not really sure what you want
> to point me out here.

Hi, what I said before: once we compile a plugin, we should "refresh menus"
or restart IJ otherwise if you use the menus to call a recently compiled file,
the old version might still remain on memory and that would run instead of the
recently compiled sitting on disk.
Isn't this what you reported?: a newly compiled plugin "remembering" an image
size of the old version?

If I misunderstood the problem, sorry, just ignore this.
Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

CARL Philippe (LBP)

Re: Weird behavior with GenericDialog.addImage

Hi again Gabriel,
I agree that the issue you are describing may indeed arise in the case you are compiling a code "outside" ImageJ (and then want to run it inside).
But not when using the Plugins>Compile_and_run... tool directly within ImageJ (which is the way I always work).
And if so, this would really be the first time I see such a "memory behavior" (unless of course there is already another compiled version within the plugins folder or one of its subfolder which isn't the case here).
Take care,
Philippe

----- Mail original -----
De: "Gabriel Landini" <[hidden email]>
À: "imagej" <[hidden email]>
Envoyé: Jeudi 30 Juillet 2020 13:35:33
Objet: Re: Weird behavior with GenericDialog.addImage

On Thursday, 30 July 2020 11:39:42 BST you wrote:
> Thanks a lot for your replay, nevertheless I'm not really sure what you want
> to point me out here.

Hi, what I said before: once we compile a plugin, we should "refresh menus"
or restart IJ otherwise if you use the menus to call a recently compiled file,
the old version might still remain on memory and that would run instead of the
recently compiled sitting on disk.
Isn't this what you reported?: a newly compiled plugin "remembering" an image
size of the old version?

If I misunderstood the problem, sorry, just ignore this.
Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Gabriel Landini

Re: Weird behavior with GenericDialog.addImage

On Thursday, 30 July 2020 12:53:32 BST you wrote:
> I agree that the issue you are describing may indeed arise in the case you
> are compiling a code "outside" ImageJ (and then want to run it inside). But
> not when using the Plugins>Compile_and_run... tool directly within ImageJ
> (which is the way I always work).

I thought that the menu is not automatically refreshed, because new plugins
run and compiled from within IJ do not magically appear under the plugins
menu.
Perhaps I have been refreshing menus unnecessarily for many years? :-)
Hopefully somebody can clarify whether the menu points to the newly compiled
class.

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

CARL Philippe (LBP)

Re: Weird behavior with GenericDialog.addImage

Hi again,

> Perhaps I have been refreshing menus unnecessarily for many years? :-)

So what you you are doing is:
1 - modify the .java code
2 - save the .java code
3 - launch plugins>compile_and_run...
4 - close the obtained interface
5 - launch Help>Refresh_Menus
6 - launch the compiled plugin from plugins>your_plugin?
When I'm working on a plugin, I loop the described workflow from 1 to 3, that is all...
The only time you "normally" need to do Help>Refresh_Menus (or alternatively close ImageJ) is when you want tu run a given plugin from the Plugins menu and just saved it within the plugins folder or alternatively started with a brand new .java file that had never been compiled before.
Plugins>compile_and_run... is always overwriting the previously compiled .class file and launching the new compiled one (unless of course you don't have another .class file lost somewhere within your plugins folder that you don't remember about - which I have to admit happen to me a couple times already!!!).
My best regards,
Philippe

----- Mail original -----
De: "Gabriel Landini" <[hidden email]>
À: "imagej" <[hidden email]>
Envoyé: Jeudi 30 Juillet 2020 14:17:42
Objet: Re: Weird behavior with GenericDialog.addImage

On Thursday, 30 July 2020 12:53:32 BST you wrote:
> I agree that the issue you are describing may indeed arise in the case you
> are compiling a code "outside" ImageJ (and then want to run it inside). But
> not when using the Plugins>Compile_and_run... tool directly within ImageJ
> (which is the way I always work).

I thought that the menu is not automatically refreshed, because new plugins
run and compiled from within IJ do not magically appear under the plugins
menu.
Perhaps I have been refreshing menus unnecessarily for many years? :-)
Hopefully somebody can clarify whether the menu points to the newly compiled
class.

Cheers

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Michael Schmid

Re: Weird behavior with GenericDialog.addImage

Hi Philippe,

if you Compile&Run a class that is also in a .jar or .zip file in your
plugins and that .jar or .zip was loaded when ImageJ was started, the
following wil happen:
It will compile the new version (and check for errors), but not replace
the version from the .jar or .zip file, so it will execute the code from
the .jar or .zip.

If the previous version is only a .class file in the plugins, the
replaced version will be used. I am not sure whether this is intentional
or not (replacing one class in a .jar might lead to incompatibilities).

Could this explain your problem?

Michael
________________________________________________________________
On 30.07.20 14:54, CARL Philippe (LBP) wrote:

> Hi again,
>
>> Perhaps I have been refreshing menus unnecessarily for many years? :-)
>
> So what you you are doing is:
> 1 - modify the .java code
> 2 - save the .java code
> 3 - launch plugins>compile_and_run...
> 4 - close the obtained interface
> 5 - launch Help>Refresh_Menus
> 6 - launch the compiled plugin from plugins>your_plugin?
> When I'm working on a plugin, I loop the described workflow from 1 to 3, that is all...
> The only time you "normally" need to do Help>Refresh_Menus (or alternatively close ImageJ) is when you want tu run a given plugin from the Plugins menu and just saved it within the plugins folder or alternatively started with a brand new .java file that had never been compiled before.
> Plugins>compile_and_run... is always overwriting the previously compiled .class file and launching the new compiled one (unless of course you don't have another .class file lost somewhere within your plugins folder that you don't remember about - which I have to admit happen to me a couple times already!!!).
> My best regards,
> Philippe
>
> ----- Mail original -----
> De: "Gabriel Landini" <[hidden email]>
> À: "imagej" <[hidden email]>
> Envoyé: Jeudi 30 Juillet 2020 14:17:42
> Objet: Re: Weird behavior with GenericDialog.addImage
>
> On Thursday, 30 July 2020 12:53:32 BST you wrote:
>> I agree that the issue you are describing may indeed arise in the case you
>> are compiling a code "outside" ImageJ (and then want to run it inside). But
>> not when using the Plugins>Compile_and_run... tool directly within ImageJ
>> (which is the way I always work).
>
> I thought that the menu is not automatically refreshed, because new plugins
> run and compiled from within IJ do not magically appear under the plugins
> menu.
> Perhaps I have been refreshing menus unnecessarily for many years? :-)
> Hopefully somebody can clarify whether the menu points to the newly compiled
> class.
>
> Cheers
>
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

CARL Philippe (LBP)

Re: Weird behavior with GenericDialog.addImage

Hi Michael,
I already explained how I deal when working with .jar within my Jun 19, 2020 post of the following thread:
http://imagej.1557.x6.nabble.com/Compiling-directories-and-jar-files-rules-td5023539.html
I'm indeed modifying what was originally a .jar file, but I had previously moved the .jar out within the root folder (where the ImageJ.exe file can be found) and in my plugins folder I have only the .java and .class files of the the given plugin left.
Also I only get the "memory issues" for the used picture size of the addImage method (when it is smaller), that is all.
At last and not at least for all the other changes I make within the .java file, my code updates are correctly taken into account (which wouldn't be the case either if I would still have a .jar file containing the given .class file that could still "be seen" by ImageJ).
Kindest regards,
Philippe

----- Mail original -----
De: "Michael Schmid" <[hidden email]>
À: "imagej" <[hidden email]>
Envoyé: Jeudi 30 Juillet 2020 15:32:48
Objet: Re: Weird behavior with GenericDialog.addImage

Hi Philippe,

if you Compile&Run a class that is also in a .jar or .zip file in your
plugins and that .jar or .zip was loaded when ImageJ was started, the
following wil happen:
It will compile the new version (and check for errors), but not replace
the version from the .jar or .zip file, so it will execute the code from
the .jar or .zip.

If the previous version is only a .class file in the plugins, the
replaced version will be used. I am not sure whether this is intentional
or not (replacing one class in a .jar might lead to incompatibilities).

Could this explain your problem?

Michael
________________________________________________________________
On 30.07.20 14:54, CARL Philippe (LBP) wrote:

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Fred Damen

Re: Weird behavior with GenericDialog.addImage

In reply to this post by Michael Schmid

Greetings,

I suspect that this does not address the OP issue since the information
that the OP is saying is carried over though compiles is not compiled in,
at least given the source example that was posted.

The Compile&Run *should* always run the java class that is in its editor
window, and if it does not then this should be considered broken. As far
as I can tell this is what Compile&Run...(^R) is doing, i.e., its working
correctly in this regard, albeit the jar stuff seems to have issues.

Using the following who_am_i.java source as a starting point I ...
import ij.*;
import ij.process.*;
import ij.gui.*;
import java.awt.*;
import ij.plugin.*;
import ij.plugin.frame.*;

public class who_am_i implements PlugIn {

public void run(String arg) {
IJ.log("I am from the editor");
}

}
1) entered this java program and ran it.
Plugins>Macros>Edit... who_am_i.java
^R
log: I am from the editor
2) produced .class file to run after restart.
s/editor/.class file/
^R
s/.class file/editor/
^S
exit imagej and restart
Plugins>who_am_i
log: I am from the .class file
Plugins>Macros>Edit... who_am_i.java
^R
log: I am from the editor
3) produce whoami.jar file and run after restart.
s/editor/.jar file/
^R
log: I am from the .jar file
linux: jar cvfM whoami.jar who_am_i.class
s/.jar/.class/
^R
log: I am from the .class file
s/.class file/editor/
^S
exit imagej and restart
Plugins>who_am_i
log: I am from the .class file
Plugins>Macros>Edit... who_am_i.java
^R
log: I am from the editor
4) convert whoami.jar to who_am_i.jar and start imagej
linux: mv whoami.jar who_am_i.jar
start imagej
imagej complains about two who_am_i's
There are two Plugins>who_am_i
and both produce
log: I am from the .class file
Plugins>Macros>Edit... who_am_i.java
^R
log: I am from the editor
and both menu entries now produce
log: I am from the editor

Where the java compilier(linker/loader) is supposed to get all the
unresolved references was one of my previous issues.

Enjoy,

Fred

On Thu, July 30, 2020 8:32 am, Michael Schmid wrote:

> Hi Philippe,
>
> if you Compile&Run a class that is also in a .jar or .zip file in your
> plugins and that .jar or .zip was loaded when ImageJ was started, the
> following wil happen:
> It will compile the new version (and check for errors), but not replace
> the version from the .jar or .zip file, so it will execute the code from
> the .jar or .zip.
>
> If the previous version is only a .class file in the plugins, the
> replaced version will be used. I am not sure whether this is intentional
> or not (replacing one class in a .jar might lead to incompatibilities).
>
>
> Could this explain your problem?
>
>
> Michael
> ________________________________________________________________
> On 30.07.20 14:54, CARL Philippe (LBP) wrote:
>> Hi again,
>>
>>> Perhaps I have been refreshing menus unnecessarily for many years? :-)
>>
>> So what you you are doing is:
>> 1 - modify the .java code
>> 2 - save the .java code
>> 3 - launch plugins>compile_and_run...
>> 4 - close the obtained interface
>> 5 - launch Help>Refresh_Menus
>> 6 - launch the compiled plugin from plugins>your_plugin?
>> When I'm working on a plugin, I loop the described workflow from 1 to 3,
>> that is all...
>> The only time you "normally" need to do Help>Refresh_Menus (or
>> alternatively close ImageJ) is when you want tu run a given plugin from
>> the Plugins menu and just saved it within the plugins folder or
>> alternatively started with a brand new .java file that had never been
>> compiled before.
>> Plugins>compile_and_run... is always overwriting the previously compiled
>> .class file and launching the new compiled one (unless of course you
>> don't have another .class file lost somewhere within your plugins folder
>> that you don't remember about - which I have to admit happen to me a
>> couple times already!!!).
>> My best regards,
>> Philippe
>>
>> ----- Mail original -----
>> De: "Gabriel Landini" <[hidden email]>
>> Ã: "imagej" <[hidden email]>
>> EnvoyÃ©: Jeudi 30 Juillet 2020 14:17:42
>> Objet: Re: Weird behavior with GenericDialog.addImage
>>
>> On Thursday, 30 July 2020 12:53:32 BST you wrote:
>>> I agree that the issue you are describing may indeed arise in the case
>>> you
>>> are compiling a code "outside" ImageJ (and then want to run it inside).
>>> But
>>> not when using the Plugins>Compile_and_run... tool directly within
>>> ImageJ
>>> (which is the way I always work).
>>
>> I thought that the menu is not automatically refreshed, because new
>> plugins
>> run and compiled from within IJ do not magically appear under the
>> plugins
>> menu.
>> Perhaps I have been refreshing menus unnecessarily for many years? :-)
>> Hopefully somebody can clarify whether the menu points to the newly
>> compiled
>> class.
>>
>> Cheers
>>
>> Gabriel
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Michael Schmid

Re: Weird behavior with GenericDialog.addImage

In reply to this post by CARL Philippe (LBP)

Hi Philippe,

ok, I see, I have misunderstood it.

So where does your image come from?

Are you loading it as a Java as a resource? I.e. something like
URL url = this.getClass().getResource(path);

But then, how are you reading the image? Like this?
imp = new ImagePlus(url.toString); or
imp = opener.openURL(url.toString);

Just trying with JavaScript and scaled versions of blobs.gif like this,
I have no problem with images getting cached.

Michael
________________________________________________________________
On 30.07.20 16:05, CARL Philippe (LBP) wrote:

> Hi Michael,
> I already explained how I deal when working with .jar within my Jun 19, 2020 post of the following thread:
> http://imagej.1557.x6.nabble.com/Compiling-directories-and-jar-files-rules-td5023539.html
> I'm indeed modifying what was originally a .jar file, but I had previously moved the .jar out within the root folder (where the ImageJ.exe file can be found) and in my plugins folder I have only the .java and .class files of the the given plugin left.
> Also I only get the "memory issues" for the used picture size of the addImage method (when it is smaller), that is all.
> At last and not at least for all the other changes I make within the .java file, my code updates are correctly taken into account (which wouldn't be the case either if I would still have a .jar file containing the given .class file that could still "be seen" by ImageJ).
> Kindest regards,
> Philippe
>
> ----- Mail original -----
> De: "Michael Schmid" <[hidden email]>
> À: "imagej" <[hidden email]>
> Envoyé: Jeudi 30 Juillet 2020 15:32:48
> Objet: Re: Weird behavior with GenericDialog.addImage
>
> Hi Philippe,
>
> if you Compile&Run a class that is also in a .jar or .zip file in your
> plugins and that .jar or .zip was loaded when ImageJ was started, the
> following wil happen:
> It will compile the new version (and check for errors), but not replace
> the version from the .jar or .zip file, so it will execute the code from
> the .jar or .zip.
>
> If the previous version is only a .class file in the plugins, the
> replaced version will be used. I am not sure whether this is intentional
> or not (replacing one class in a .jar might lead to incompatibilities).
>
>
> Could this explain your problem?
>
>
> Michael
> ________________________________________________________________
> On 30.07.20 14:54, CARL Philippe (LBP) wrote:
>> Hi again,
>>
>>> Perhaps I have been refreshing menus unnecessarily for many years? :-)
>>
>> So what you you are doing is:
>> 1 - modify the .java code
>> 2 - save the .java code
>> 3 - launch plugins>compile_and_run...
>> 4 - close the obtained interface
>> 5 - launch Help>Refresh_Menus
>> 6 - launch the compiled plugin from plugins>your_plugin?
>> When I'm working on a plugin, I loop the described workflow from 1 to 3, that is all...
>> The only time you "normally" need to do Help>Refresh_Menus (or alternatively close ImageJ) is when you want tu run a given plugin from the Plugins menu and just saved it within the plugins folder or alternatively started with a brand new .java file that had never been compiled before.
>> Plugins>compile_and_run... is always overwriting the previously compiled .class file and launching the new compiled one (unless of course you don't have another .class file lost somewhere within your plugins folder that you don't remember about - which I have to admit happen to me a couple times already!!!).
>> My best regards,
>> Philippe
>>
>> ----- Mail original -----
>> De: "Gabriel Landini" <[hidden email]>
>> À: "imagej" <[hidden email]>
>> Envoyé: Jeudi 30 Juillet 2020 14:17:42
>> Objet: Re: Weird behavior with GenericDialog.addImage
>>
>> On Thursday, 30 July 2020 12:53:32 BST you wrote:
>>> I agree that the issue you are describing may indeed arise in the case you
>>> are compiling a code "outside" ImageJ (and then want to run it inside). But
>>> not when using the Plugins>Compile_and_run... tool directly within ImageJ
>>> (which is the way I always work).
>>
>> I thought that the menu is not automatically refreshed, because new plugins
>> run and compiled from within IJ do not magically appear under the plugins
>> menu.
>> Perhaps I have been refreshing menus unnecessarily for many years? :-)
>> Hopefully somebody can clarify whether the menu points to the newly compiled
>> class.
>>
>> Cheers
>>
>> Gabriel
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

CARL Philippe (LBP)

Re: Weird behavior with GenericDialog.addImage

Hi Michael,
Your first suggestion was the good one!
Please find my code below:
try
{
url = getClass().getResource("/image/logo.jpg");
icon = Toolkit.getDefaultToolkit().getImage(url);
imp = new ImagePlus("Error message", icon);
gd .addImage(imp);
}
catch (Exception e)
{
IJ.showMessage("Loading the icon picture", "The icon picture \"/image/logo.jpg\" could not be found!");
}

The pictures were stored on the HD and I had 3 pictures (logo.jpg, logo2.jpg and logo3.jpg).
Also let me partially correct what I said this morning.
So going from a big picture to a smaller one, the issue was quite obvious since on the next compilation I (often = not always) got a big black frame (corresponding to the previous big picture size) within which the new (smaller) picture is pasted in and this magnetized at the top right border.
But going from a small picture, mostly the new picture gets correctly inserted, but sometimes (it seems to me when the size change is not too different) it gets also croped to the previous picture size.
I thank you very much for your help on this!
My best regards,
Philippe

PS: If you want to get my complete code I can as well send it to you if needed.

----- Mail original -----
De: "Michael Schmid" <[hidden email]>
À: "imagej" <[hidden email]>
Envoyé: Jeudi 30 Juillet 2020 19:54:52
Objet: Re: Weird behavior with GenericDialog.addImage

Hi Philippe,

ok, I see, I have misunderstood it.

So where does your image come from?

Are you loading it as a Java as a resource? I.e. something like
URL url = this.getClass().getResource(path);

But then, how are you reading the image? Like this?
imp = new ImagePlus(url.toString); or
imp = opener.openURL(url.toString);

Just trying with JavaScript and scaled versions of blobs.gif like this,
I have no problem with images getting cached.

Michael
________________________________________________________________
On 30.07.20 16:05, CARL Philippe (LBP) wrote:

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html