Notification of File Save

[Michael P Ellis]

Is it possible to get notified or hook into when an image is saved?

The ImageListener interface allows notifications only for Open/Close and Updated.

My reason for wanting this extra functionality is that I wish to save a thumbnail JPEG image whenever an image is saved.

My current strategy is for my plugin to cache a BufferedImage when I receive an ImageListener Updated event through and then have Java File System watch service notice whenever a file is created or modified in a watched directory, recall the cached BufferedImage and write the thumbnail then. It's an inefficient strategy.

If there is an existing means of doing this then I would be grateful to learn of it!

If not, then, as I understand it, the "ImagePlus:: protected void notifyListeners(final int id)" is only called from ImagePlus and the derivative CompositeImage.

Because notifyListeners() is also protected so not callable from the code that saves images such as in FileSaver.java

Is there anyone else who would like to see a new interface added:
 public interface ImageListenerNew {
 public notifyListeners(final String id);
 }

Which could be used for some additional notifications (such as Save, and perhaps Closing - gets called just before the images is closed) and potentially could be used for user-extensible events (say with a reverse domain string with your own event name as the string ID parameter)

My thinking is that some standard IDs could be added for the existing "OPENED", "CLOSED", "UPDATED" that get called in addition to the existing notifyListeners(final int id)" so backward compatibility is maintained for existing plugins but PluginDeveloppers could choose the old ImageListener or the ImageListenerNew interface if they needed the extra functionality.

Thanking anyone in advance and seasons greetings to you all

-- Michael Ellis

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

[Michael Schmid]

Hi Michael,

ImageJ has a CommandListener interface. You could check whether the
command is "Jpeg..." and then do whatever you want.

The problem with it: I fear that the commandExecuting is called before
the user actually saves the file (the file save dialog), so this is too
early; you will have to remember the foreground image and wait until the
file is actually saved.
After saving is done, the FileInfo of the image will be updated with the
new filename and directory, and the 'changes' of the ImagePlus will be
set to false.
You also have to allow for the user pressing <cancel> and not saving it,
so you should stop waiting some time after the next command.
This will be somewhat a hack, not a very clean solution, however.

Unfortunately, I think that your suggestion of adding additional
callbacks to ImagePlus does not work: The ImageListener of ImagePlus
cannot be extended because its callback functions are not something like
imageOperationDone(image, whatOperation) but the notifyListeners has
separate
   imageOpened,
   imageClosed, and
   imageUpdated
calls to the listener. One can't add more without breaking compatibility
with existing plugins.

The RoiListener would be better in this respect, its callback
   roiModified(image, id)
would allow adding additional possibilities for the 'id', but saving an
image is not related to Rois.


Michael
________________________________________________________________
On 23.12.20 13:59, Michael Ellis wrote:

> Is it possible to get notified or hook into when an image is saved?
>
> The ImageListener interface allows notifications only for Open/Close and Updated.
>
> My reason for wanting this extra functionality is that I wish to save a thumbnail JPEG image whenever an image is saved.
>
> My current strategy is for my plugin to cache a BufferedImage when I receive an ImageListener Updated event through and then have Java File System watch service notice whenever a file is created or modified in a watched directory, recall the cached BufferedImage and write the thumbnail then. It's an inefficient strategy.
>
> If there is an existing means of doing this then I would be grateful to learn of it!
>
> If not, then, as I understand it, the "ImagePlus:: protected void notifyListeners(final int id)" is only called from ImagePlus and the derivative CompositeImage.
>
> Because notifyListeners() is also protected so not callable from the code that saves images such as in FileSaver.java
>
> Is there anyone else who would like to see a new interface added:
>   public interface ImageListenerNew {
>   public notifyListeners(final String id);
>   }
>
> Which could be used for some additional notifications (such as Save, and perhaps Closing - gets called just before the images is closed) and potentially could be used for user-extensible events (say with a reverse domain string with your own event name as the string ID parameter)
>
> My thinking is that some standard IDs could be added for the existing "OPENED", "CLOSED", "UPDATED" that get called in addition to the existing notifyListeners(final int id)" so backward compatibility is maintained for existing plugins but PluginDeveloppers could choose the old ImageListener or the ImageListenerNew interface if they needed the extra functionality.
>
> Thanking anyone in advance and seasons greetings to you all
>
> -- Michael Ellis
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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

[Kenneth Sloan-2]

Is it possible to squeeze this functionality into "ImageUpdated"?  Perhaps add calls to ImagePlus to ask about the nature of the update?  This would not break  existing  code, I think.
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.




>  
> Unfortunately, I think that your suggestion of adding additional callbacks to ImagePlus does not work: The ImageListener of ImagePlus cannot be extended because its callback functions are not something like imageOperationDone(image, whatOperation) but the notifyListeners has separate
>  imageOpened,
>  imageClosed, and
>  imageUpdated
> calls to the listener. One can't add more without breaking compatibility with existing plugins.
 
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Albert Cardona-2]

Best would be a default interface method imageSaved that does nothing, added to ij.ImageListener. Wouldn’t break anything and it’s supported since at least java 8.

Albert

> On Dec 23, 2020, at 9:21 PM, Kenneth Sloan <[hidden email]> wrote:
>
> Is it possible to squeeze this functionality into "ImageUpdated"?  Perhaps add calls to ImagePlus to ask about the nature of the update?  This would not break  existing  code, I think.
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>>
>> Unfortunately, I think that your suggestion of adding additional callbacks to ImagePlus does not work: The ImageListener of ImagePlus cannot be extended because its callback functions are not something like imageOperationDone(image, whatOperation) but the notifyListeners has separate
>> imageOpened,
>> imageClosed, and
>> imageUpdated
>> calls to the listener. One can't add more without breaking compatibility with existing plugins.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

[Michael P Ellis]

Dear Michael,

Firstly many thanks for suggesting the CommandListener plugin interface.  That may well suit my needs. I will investigate!

Regarding my suggestion, I apologise for not making my suggestion more clear.

My suggestion is to leave the existing ImageListener interface and the code that supports the registering of handlers and the notification of events entirely unchanged.

I was proposing an entirely new, but very similar ImageLiseterNew interface with ent entirely separate handler registration and event distribution method.

The ImageLiseterNew interface would differ from the original ImageLiseter interface in that it would have a single method that was passed in a String ID. Being a Single Abstract Method interface (aka functional interface) would also mean registering handlers could also be done neatly in Java 8 and beyond as a lambda.

(To provide easy forward compatibility, the existing notifyListeners(final int ID) could also make a call to the new notifyListeners(final String ID) with appropriate String constants and no compromise to backward compatibility at all).

Anyway, it is now for me to explore your grand suggestion the CommandListener interface as that bodes well for what I may need.

Many thanks and have a grand Christmas.

-- Michael Ellis


December 23, 2020 6:03 PM, "Michael Schmid" <[hidden email]> wrote:

> Hi Michael,
>
> ImageJ has a CommandListener interface. You could check whether the command is "Jpeg..." and then
> do whatever you want.
>
> The problem with it: I fear that the commandExecuting is called before the user actually saves the
> file (the file save dialog), so this is too early; you will have to remember the foreground image
> and wait until the file is actually saved.
> After saving is done, the FileInfo of the image will be updated with the new filename and
> directory, and the 'changes' of the ImagePlus will be set to false.
> You also have to allow for the user pressing <cancel> and not saving it, so you should stop waiting
> some time after the next command.
> This will be somewhat a hack, not a very clean solution, however.
>
> Unfortunately, I think that your suggestion of adding additional callbacks to ImagePlus does not
> work: The ImageListener of ImagePlus cannot be extended because its callback functions are not
> something like imageOperationDone(image, whatOperation) but the notifyListeners has separate
> imageOpened,
> imageClosed, and
> imageUpdated
> calls to the listener. One can't add more without breaking compatibility with existing plugins.
>
> The RoiListener would be better in this respect, its callback
> roiModified(image, id)
> would allow adding additional possibilities for the 'id', but saving an image is not related to
> Rois.
>
> Michael
> ________________________________________________________________
> On 23.12.20 13:59, Michael Ellis wrote:
>
>> Is it possible to get notified or hook into when an image is saved?
>> The ImageListener interface allows notifications only for Open/Close and Updated.
>> My reason for wanting this extra functionality is that I wish to save a thumbnail JPEG image
>> whenever an image is saved.
>> My current strategy is for my plugin to cache a BufferedImage when I receive an ImageListener
>> Updated event through and then have Java File System watch service notice whenever a file is
>> created or modified in a watched directory, recall the cached BufferedImage and write the thumbnail
>> then. It's an inefficient strategy.
>> If there is an existing means of doing this then I would be grateful to learn of it!
>> If not, then, as I understand it, the "ImagePlus:: protected void notifyListeners(final int id)" is
>> only called from ImagePlus and the derivative CompositeImage.
>> Because notifyListeners() is also protected so not callable from the code that saves images such as
>> in FileSaver.java
>> Is there anyone else who would like to see a new interface added:
>> public interface ImageListenerNew {
>> public notifyListeners(final String id);
>> }
>> Which could be used for some additional notifications (such as Save, and perhaps Closing - gets
>> called just before the images is closed) and potentially could be used for user-extensible events
>> (say with a reverse domain string with your own event name as the string ID parameter)
>> My thinking is that some standard IDs could be added for the existing "OPENED", "CLOSED", "UPDATED"
>> that get called in addition to the existing notifyListeners(final int id)" so backward
>> compatibility is maintained for existing plugins but PluginDeveloppers could choose the old
>> ImageListener or the ImageListenerNew interface if they needed the extra functionality.
>> Thanking anyone in advance and seasons greetings to you all
>> -- Michael Ellis
>> --
>> 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 P Ellis]

Dear Kenneth,

Alas, imageUpdated() is currently not called after an image has been saved. To effect that change would need a few changes. The notifyListerners method in ImagePlus would need making public (so it could be called from outside of ImagePlus).

Since imageUpdated does not take any context parameter, overriding the imageUpdated() for handling new events such as save or any other event, could conceivably (though very unlikely) break some plugins that were not expecting these extra calls on Save events.

As for the "additional callbacks to ImagePlus", I enclose my reply to Michael Schmid that I submitted earlier and hope this makes clearer what failed to explain before...

> Regarding my suggestion, I apologise for not making my suggestion more clear.
>
> My suggestion is to leave the existing ImageListener interface and the code that supports the registering of handlers and the notification of events entirely unchanged.
>
> I was proposing an entirely new, but very similar ImageLiseterNew interface with ent entirely separate handler registration and event distribution method.
>
> The ImageLiseterNew interface would differ from the original ImageLiseter interface in that it would have a single method that was passed in a String ID. Being a Single Abstract Method interface (aka functional interface) would also mean registering handlers could also be done neatly in Java 8 and beyond as a lambda.

> (To provide easy forward compatibility, the existing notifyListeners(final int ID) could also make a call to the new notifyListeners(final String ID) with appropriate String constants and no compromise to backward compatibility at all).

With best regards and seasons greetings Michael Ellis

December 23, 2020 10:44 PM, "Kenneth Sloan" <[hidden email]> wrote:

> Is it possible to squeeze this functionality into "ImageUpdated"? Perhaps add calls to ImagePlus to
> ask about the nature of the update? This would not break existing code, I think.
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>> Unfortunately, I think that your suggestion of adding additional callbacks to ImagePlus does not
>> work: The ImageListener of ImagePlus cannot be extended because its callback functions are not
>> something like imageOperationDone(image, whatOperation) but the notifyListeners has separate
>> imageOpened,
>> imageClosed, and
>> imageUpdated
>> calls to the listener. One can't add more without breaking compatibility with existing plugins.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

[Michael P Ellis]

Albert, hi,

Cool suggestion, though I am hoping for a change to ImageJ that can be adopted in the central release and I am not sure if minimal Java version 8 is at present expected?

A similar Java 1.6 compliant approach could be adopted (but a bit messier) could be achieved by extending ij.ImageListener with an extra interface say, ij.ImageListener2 that had the extra method then the notifyLister could runtime check the class and call the imageSaved only if the registered handler was a ij.ImageListener2 interface.

The question I have now, I suppose is, who decides what goes into the central distribution of ImageJ1?

P.S. I still like the idea of these handles being rewritten as Single Access Methods (Functional Interfaces) passing a context of some sort, that would also allow for handlers to be implemented as lambdas :-)

Many thanks for the default interface method idea though, it's a more attractive way of providing compatibility!

Merry Christmas.

-- Michael Ellis


December 23, 2020 11:26 PM, "Albert Cardona" <[hidden email]> wrote:

> Best would be a default interface method imageSaved that does nothing, added to ij.ImageListener.
> Wouldn’t break anything and it’s supported since at least java 8.
>
> Albert
>
>> On Dec 23, 2020, at 9:21 PM, Kenneth Sloan <[hidden email]> wrote:
>>
>> Is it possible to squeeze this functionality into "ImageUpdated"? Perhaps add calls to ImagePlus to
>> ask about the nature of the update? This would not break existing code, I think.
>> --
>> Kenneth Sloan
>> [hidden email]
>> Vision is the art of seeing what is invisible to others.
>>
>>> Unfortunately, I think that your suggestion of adding additional callbacks to ImagePlus does not
>>> work: The ImageListener of ImagePlus cannot be extended because its callback functions are not
>>> something like imageOperationDone(image, whatOperation) but the notifyListeners has separate
>>> imageOpened,
>>> imageClosed, and
>>> imageUpdated
>>> calls to the listener. One can't add more without breaking compatibility with existing plugins.
>>
>> --
>> 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 P Ellis]

Dear Michael Schmid,

Having explored CommandListener I found it meets my needs well enough.

My use case is a plugin that displays a gallery of thumbnails for the saved ImageJ (TIFF) file within a specified directory.

My CommandListener commandExecuting() methods watches for the "Close" command and then creates and stores a
preview images if there is not one already there or if the modified date of the TIFF file is newer than the preview.

Many thanks for pointing CommandListerner out to me!

I hope to release this CaseView plugin along with a CompositeAdjuster plugin for convenient adjustment of multichannel Composite images early next year.

Regards -- Michael Ellis



December 23, 2020 6:03 PM, "Michael Schmid" <[hidden email]> wrote:

> Hi Michael,
>
> ImageJ has a CommandListener interface. You could check whether the command is "Jpeg..." and then
> do whatever you want.
>
> The problem with it: I fear that the commandExecuting is called before the user actually saves the
> file (the file save dialog), so this is too early; you will have to remember the foreground image
> and wait until the file is actually saved.
> After saving is done, the FileInfo of the image will be updated with the new filename and
> directory, and the 'changes' of the ImagePlus will be set to false.
> You also have to allow for the user pressing <cancel> and not saving it, so you should stop waiting
> some time after the next command.
> This will be somewhat a hack, not a very clean solution, however.
>
> Unfortunately, I think that your suggestion of adding additional callbacks to ImagePlus does not
> work: The ImageListener of ImagePlus cannot be extended because its callback functions are not
> something like imageOperationDone(image, whatOperation) but the notifyListeners has separate
> imageOpened,
> imageClosed, and
> imageUpdated
> calls to the listener. One can't add more without breaking compatibility with existing plugins.
>
> The RoiListener would be better in this respect, its callback
> roiModified(image, id)
> would allow adding additional possibilities for the 'id', but saving an image is not related to
> Rois.
>
> Michael
> ________________________________________________________________
> On 23.12.20 13:59, Michael Ellis wrote:
>
>> Is it possible to get notified or hook into when an image is saved?
>> The ImageListener interface allows notifications only for Open/Close and Updated.
>> My reason for wanting this extra functionality is that I wish to save a thumbnail JPEG image
>> whenever an image is saved.
>> My current strategy is for my plugin to cache a BufferedImage when I receive an ImageListener
>> Updated event through and then have Java File System watch service notice whenever a file is
>> created or modified in a watched directory, recall the cached BufferedImage and write the thumbnail
>> then. It's an inefficient strategy.
>> If there is an existing means of doing this then I would be grateful to learn of it!
>> If not, then, as I understand it, the "ImagePlus:: protected void notifyListeners(final int id)" is
>> only called from ImagePlus and the derivative CompositeImage.
>> Because notifyListeners() is also protected so not callable from the code that saves images such as
>> in FileSaver.java
>> Is there anyone else who would like to see a new interface added:
>> public interface ImageListenerNew {
>> public notifyListeners(final String id);
>> }
>> Which could be used for some additional notifications (such as Save, and perhaps Closing - gets
>> called just before the images is closed) and potentially could be used for user-extensible events
>> (say with a reverse domain string with your own event name as the string ID parameter)
>> My thinking is that some standard IDs could be added for the existing "OPENED", "CLOSED", "UPDATED"
>> that get called in addition to the existing notifyListeners(final int id)" so backward
>> compatibility is maintained for existing plugins but PluginDeveloppers could choose the old
>> ImageListener or the ImageListenerNew interface if they needed the extra functionality.
>> Thanking anyone in advance and seasons greetings to you all
>> -- Michael Ellis
>> --
>> 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

[Albert Cardona-2]

Hi Michael,

Last I checked, Java 6 stopped getting public security updates in 2013:

https://blogs.oracle.com/java/end-of-public-updates-for-java-se-6

Also, MacOSX doesn’t even support java 6 at all, and it’s the preferred OS of a vast fraction of ImageJ users and developers.

While Fiji has gone to great lengths to support java 6, its well past time to move on. Would simplify the Code base, and we’d welcome the move.

Whether ImageJ core stops supporting java 6 is of course Wayne’s decision.

Best,

Albert

> On Dec 24, 2020, at 11:27 AM, Michael Ellis <[hidden email]> wrote:
>
> Dear Michael Schmid,
>
> Having explored CommandListener I found it meets my needs well enough.
>
> My use case is a plugin that displays a gallery of thumbnails for the saved ImageJ (TIFF) file within a specified directory.
>
> My CommandListener commandExecuting() methods watches for the "Close" command and then creates and stores a
> preview images if there is not one already there or if the modified date of the TIFF file is newer than the preview.
>
> Many thanks for pointing CommandListerner out to me!
>
> I hope to release this CaseView plugin along with a CompositeAdjuster plugin for convenient adjustment of multichannel Composite images early next year.
>
> Regards -- Michael Ellis
>
>
>
> December 23, 2020 6:03 PM, "Michael Schmid" <[hidden email]> wrote:
>
>> Hi Michael,
>>
>> ImageJ has a CommandListener interface. You could check whether the command is "Jpeg..." and then
>> do whatever you want.
>>
>> The problem with it: I fear that the commandExecuting is called before the user actually saves the
>> file (the file save dialog), so this is too early; you will have to remember the foreground image
>> and wait until the file is actually saved.
>> After saving is done, the FileInfo of the image will be updated with the new filename and
>> directory, and the 'changes' of the ImagePlus will be set to false.
>> You also have to allow for the user pressing <cancel> and not saving it, so you should stop waiting
>> some time after the next command.
>> This will be somewhat a hack, not a very clean solution, however.
>>
>> Unfortunately, I think that your suggestion of adding additional callbacks to ImagePlus does not
>> work: The ImageListener of ImagePlus cannot be extended because its callback functions are not
>> something like imageOperationDone(image, whatOperation) but the notifyListeners has separate
>> imageOpened,
>> imageClosed, and
>> imageUpdated
>> calls to the listener. One can't add more without breaking compatibility with existing plugins.
>>
>> The RoiListener would be better in this respect, its callback
>> roiModified(image, id)
>> would allow adding additional possibilities for the 'id', but saving an image is not related to
>> Rois.
>>
>> Michael
>> ________________________________________________________________
>>> On 23.12.20 13:59, Michael Ellis wrote:
>>>
>>> Is it possible to get notified or hook into when an image is saved?
>>> The ImageListener interface allows notifications only for Open/Close and Updated.
>>> My reason for wanting this extra functionality is that I wish to save a thumbnail JPEG image
>>> whenever an image is saved.
>>> My current strategy is for my plugin to cache a BufferedImage when I receive an ImageListener
>>> Updated event through and then have Java File System watch service notice whenever a file is
>>> created or modified in a watched directory, recall the cached BufferedImage and write the thumbnail
>>> then. It's an inefficient strategy.
>>> If there is an existing means of doing this then I would be grateful to learn of it!
>>> If not, then, as I understand it, the "ImagePlus:: protected void notifyListeners(final int id)" is
>>> only called from ImagePlus and the derivative CompositeImage.
>>> Because notifyListeners() is also protected so not callable from the code that saves images such as
>>> in FileSaver.java
>>> Is there anyone else who would like to see a new interface added:
>>> public interface ImageListenerNew {
>>> public notifyListeners(final String id);
>>> }
>>> Which could be used for some additional notifications (such as Save, and perhaps Closing - gets
>>> called just before the images is closed) and potentially could be used for user-extensible events
>>> (say with a reverse domain string with your own event name as the string ID parameter)
>>> My thinking is that some standard IDs could be added for the existing "OPENED", "CLOSED", "UPDATED"
>>> that get called in addition to the existing notifyListeners(final int id)" so backward
>>> compatibility is maintained for existing plugins but PluginDeveloppers could choose the old
>>> ImageListener or the ImageListenerNew interface if they needed the extra functionality.
>>> Thanking anyone in advance and seasons greetings to you all
>>> -- Michael Ellis
>>> --
>>> 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
> <CaseView.jpg>

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

[Wayne Rasband-2]

> On Dec 23, 2020, at 7:59 AM, Michael Ellis <[hidden email]> wrote:
>
> Is it possible to get notified or hook into when an image is saved?

The ImageJ 1.53h17 daily build adds an imageSaved() method to the ImageListener interface. This method is defined using the "default” keyword (added in Java 8), so ImageJ now requires Java 8 or later. The Event Listener (Plugins>Utilities>Monitor Events) now reports image saved events.

-wayne

> The ImageListener interface allows notifications only for Open/Close and Updated.
>
> My reason for wanting this extra functionality is that I wish to save a thumbnail JPEG image whenever an image is saved.
>
> My current strategy is for my plugin to cache a BufferedImage when I receive an ImageListener Updated event through and then have Java File System watch service notice whenever a file is created or modified in a watched directory, recall the cached BufferedImage and write the thumbnail then. It's an inefficient strategy.
>
> If there is an existing means of doing this then I would be grateful to learn of it!
>
> If not, then, as I understand it, the "ImagePlus:: protected void notifyListeners(final int id)" is only called from ImagePlus and the derivative CompositeImage.
>
> Because notifyListeners() is also protected so not callable from the code that saves images such as in FileSaver.java
>
> Is there anyone else who would like to see a new interface added:
> public interface ImageListenerNew {
> public notifyListeners(final String id);
> }
>
> Which could be used for some additional notifications (such as Save, and perhaps Closing - gets called just before the images is closed) and potentially could be used for user-extensible events (say with a reverse domain string with your own event name as the string ID parameter)
>
> My thinking is that some standard IDs could be added for the existing "OPENED", "CLOSED", "UPDATED" that get called in addition to the existing notifyListeners(final int id)" so backward compatibility is maintained for existing plugins but PluginDeveloppers could choose the old ImageListener or the ImageListenerNew interface if they needed the extra functionality.
>
> Thanking anyone in advance and seasons greetings to you all
>
> -- Michael Ellis

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

[Michael P Ellis]

Dear Wayne,

A very Merry Christmas and a thousand thank yous for this excellent Christmas present.

The imagedSaved() addition solves my problems with implementing out CaseView plugin. I hope
to release this plugin as a free to use ImageJ plugin early next year.

With best regards -- Michael Ellis


December 25, 2020 10:09 PM, "Wayne Rasband" <[hidden email]> wrote:

>> On Dec 23, 2020, at 7:59 AM, Michael Ellis <[hidden email]> wrote:
>>
>> Is it possible to get notified or hook into when an image is saved?
>
> The ImageJ 1.53h17 daily build adds an imageSaved() method to the ImageListener interface. This
> method is defined using the "default” keyword (added in Java 8), so ImageJ now requires Java 8 or
> later. The Event Listener (Plugins>Utilities>Monitor Events) now reports image saved events.
>
> -wayne
>
>> The ImageListener interface allows notifications only for Open/Close and Updated.
>>
>> My reason for wanting this extra functionality is that I wish to save a thumbnail JPEG image
>> whenever an image is saved.
>>
>> My current strategy is for my plugin to cache a BufferedImage when I receive an ImageListener
>> Updated event through and then have Java File System watch service notice whenever a file is
>> created or modified in a watched directory, recall the cached BufferedImage and write the thumbnail
>> then. It's an inefficient strategy.
>>
>> If there is an existing means of doing this then I would be grateful to learn of it!
>>
>> If not, then, as I understand it, the "ImagePlus:: protected void notifyListeners(final int id)" is
>> only called from ImagePlus and the derivative CompositeImage.
>>
>> Because notifyListeners() is also protected so not callable from the code that saves images such as
>> in FileSaver.java
>>
>> Is there anyone else who would like to see a new interface added:
>> public interface ImageListenerNew {
>> public notifyListeners(final String id);
>> }
>>
>> Which could be used for some additional notifications (such as Save, and perhaps Closing - gets
>> called just before the images is closed) and potentially could be used for user-extensible events
>> (say with a reverse domain string with your own event name as the string ID parameter)
>>
>> My thinking is that some standard IDs could be added for the existing "OPENED", "CLOSED", "UPDATED"
>> that get called in addition to the existing notifyListeners(final int id)" so backward
>> compatibility is maintained for existing plugins but PluginDeveloppers could choose the old
>> ImageListener or the ImageListenerNew interface if they needed the extra functionality.
>>
>> Thanking anyone in advance and seasons greetings to you all
>>
>> -- Michael Ellis
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

[Michael P Ellis]

Now that ImageJ is Java8 savvy would it be a good idea to make ImagePlus implement the AutoCloseable interface?

This would allow try with resources to be used e.g.


   try (ImagePlus imp = IJ.openImage(itemPath.toString())) {
     .
     .
     .
     << do lots of stuff with imp that may or may not throw exceptions>>
     .
   } // Autoclose imp

Same applies to any other ImageJ resources that have some close functionality.

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

[Wayne Rasband-2]

> On Dec 27, 2020, at 6:55 AM, Michael Ellis <[hidden email]> wrote:
>
> Now that ImageJ is Java8 savvy would it be a good idea to make ImagePlus implement the AutoCloseable interface?

Having ImagePlus implement the AutoCloseable interface would require adding “throws Exception” to the close() method, which would cause plugins that call ImagePlus.close() to fail.

-wayne

> This would allow try with resources to be used e.g.
>
>
>   try (ImagePlus imp = IJ.openImage(itemPath.toString())) {
>     .
>     .
>     .
>     << do lots of stuff with imp that may or may not throw exceptions>>
>     .
>   } // Autoclose imp
>
> Same applies to any other ImageJ resources that have some close functionality.

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

[Michael P Ellis]

Wayne, Thanks as always for your very prompt reply!

AIUI despite the AutoCloseable interface declaring close() as throwing Exception, instantiations may specify a close() method that does not declare this Exception, even if the method has the @Override annotation!

This seems to be corroborated in this StackOverflow posting here: https://stackoverflow.com/a/49515309/1389877

It is also in my personal experience, although I am running with java 14 and so cannot be 100% this is the case with Java 8
(though I would be surprised if it were different in Java8)

If this is the case, then the try with resources pattern is an attractive and easy way to protect against memory leaks due to unclosed ImagePlus's especially when you are writing a plugin that processes lots of images.

This is not high on my list of desirable Christmas presents, there are easy ways around it, but if what I write above does not have holes in it, then perhaps it would help ImageJ developers write more robust code.

With best regards and thanks as always -- Michael Ellis

P.S. I had to log into the web interface at https://list.nih.gov/ as the email interface to this list appears to have stopped working.

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

[Wayne Rasband-2]

> On Dec 30, 2020, at 10:58 AM, Michael Ellis <[hidden email]> wrote:
>
> Wayne, Thanks as always for your very prompt reply!
>
> AIUI despite the AutoCloseable interface declaring close() as throwing Exception, instantiations may specify a close() method that does not declare this Exception, even if the method has the @Override annotation!

The ImagePlus class in the ImageJ 1.53h19 daily build implements AutoCloseable, and the close() method is not declared as throwing an Exception, avoiding a lot of backward compatibility problems.

-wayne

> This seems to be corroborated in this StackOverflow posting here: https://stackoverflow.com/a/49515309/1389877
>
> It is also in my personal experience, although I am running with java 14 and so cannot be 100% this is the case with Java 8
> (though I would be surprised if it were different in Java8)
>
> If this is the case, then the try with resources pattern is an attractive and easy way to protect against memory leaks due to unclosed ImagePlus's especially when you are writing a plugin that processes lots of images.
>
> This is not high on my list of desirable Christmas presents, there are easy ways around it, but if what I write above does not have holes in it, then perhaps it would help ImageJ developers write more robust code.
>
> With best regards and thanks as always -- Michael Ellis
>
> P.S. I had to log into the web interface at https://list.nih.gov/ as the email interface to this list appears to have stopped working.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

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

[Wayne Rasband-2]

> On Dec 25, 2020, at 3:41 PM, Wayne Rasband <[hidden email]> wrote:
>>
>> Is it possible to get notified or hook into when an image is saved?
>
> The ImageJ 1.53h17 daily build adds an imageSaved() method to the ImageListener interface. This method is defined using the "default” keyword (added in Java 8), so ImageJ now requires Java 8 or later. The Event Listener (Plugins>Utilities>Monitor Events) now reports image saved events.

The 1.53h25 and later daily builds are again built for Java 6 since the daily builds built for Java 8 caused Fiji to fail to launch.

For anyone willing to try to figure out why Fiji can’t work with an ij.jar built for Java 8, here is the exception:

Error while executing the main() method of class 'net.imagej.Main':
java.lang.NullPointerException
at net.imagej.legacy.ui.LegacyUI.ij1Helper(LegacyUI.java:119)
at net.imagej.legacy.ui.LegacyUI.show(LegacyUI.java:130)
at org.scijava.ui.DefaultUIService.showUI(DefaultUIService.java:158)
at org.scijava.ui.DefaultUIService.showUI(DefaultUIService.java:143)
at org.scijava.AbstractGateway.launch(AbstractGateway.java:110)
at net.imagej.Main.main(Main.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:291)
at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:198)
at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:89)

-wayne


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

[Michael P Ellis]

Dear Wayne,

The AutoClose feature is not a show stopper for me that can easily be worked around.

The FileSave functionality is necessary for my application and without that support
I can only ship my PlugIns with my own modified version of Image which I am loath to do
as I want to make at least some of my plugins free to use for the community. (I do believe
in putting something back)

Can I put to you the idea of supporting the FileSaved functionality in a Java 1.6
compliant way as follows:

=== Added ij.ImageListenerAux.java ===

package ij;

/**
 * An extension of the {@code ImageListener} Interface that provides
 * notification when and ImagePlus is saved.
 *
 * Note this interface is deprecated and will be removed as soon as ImageJ is
 * using Java 8 whereupon {@code imageSaved()} will be added as a default method
 * to the original {@code ImageListener}
 *
 * @deprecated
 */
public interface ImageListenerAux extends ImageListener {

    public void imageSaved(ImagePlus imp);

}

=== Modified ImagePlus.java ===

        protected void notifyListeners(final int id) {
            final ImagePlus imp = this;
                EventQueue.invokeLater(new Runnable() {
                        public void run() {
                                for (int i=0; i<listeners.size(); i++) {
                                        ImageListener listener = (ImageListener)listeners.elementAt(i);
                                        switch (id) {
                                                case OPENED:
                                                        listener.imageOpened(imp);
                                                        break;
                                                case CLOSED:
                                                        listener.imageClosed(imp);
                                                        break;
                                                case UPDATED:
                                                        listener.imageUpdated(imp);
                                                        break;
                                                case SAVED:
                                                       if (imp instanceof ImageListenerAux){
                                                  (ImageListenerAux)listener).imageSaved(imp);
                                                       }
                                                       break;
                                        }
                                }
                        }
                });
        }


Users needing the FileSaved functionality can just implement the newer ImageListenerAux interface.

Also, when ImageJ finally settled on Jave 8 I'd suggest that all the method interface to ImageListener are defaulted so plugIn developers need
only implement the ones they are interested in.

With best regards -- Michael Ellis

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

[Wayne Rasband-2]

> On Jan 6, 2021, at 3:18 AM, Michael Ellis <[hidden email]> wrote:
>
> Dear Wayne,
>
> The AutoClose feature is not a show stopper for me that can easily be worked around.
>
> The FileSave functionality is necessary for my application and without that support
> I can only ship my PlugIns with my own modified version of Image which I am loath to do
> as I want to make at least some of my plugins free to use for the community. (I do believe
> in putting something back)
>
> Can I put to you the idea of supporting the FileSaved functionality in a Java 1.6
> compliant way as follows:

I think we should wait for Fiji to be fixed so that it works with ij.jar files built for Java 8. You can monitor and/or contribute to this fix on the Image.sc Forum at

https://forum.image.sc/t/fiji-fails-to-launch-after-upgrade-to-imagej-daily-build/47125/6

and on GitHub at

https://github.com/imagej/ij1-patcher/issues/50

-wayne

>
> === Added ij.ImageListenerAux.java ===
>
> package ij;
>
> /**
> * An extension of the {@code ImageListener} Interface that provides
> * notification when and ImagePlus is saved.
> *
> * Note this interface is deprecated and will be removed as soon as ImageJ is
> * using Java 8 whereupon {@code imageSaved()} will be added as a default method
> * to the original {@code ImageListener}
> *
> * @deprecated
> */
> public interface ImageListenerAux extends ImageListener {
>
>    public void imageSaved(ImagePlus imp);
>
> }
>
> === Modified ImagePlus.java ===
>
> protected void notifyListeners(final int id) {
>    final ImagePlus imp = this;
> EventQueue.invokeLater(new Runnable() {
> public void run() {
> for (int i=0; i<listeners.size(); i++) {
> ImageListener listener = (ImageListener)listeners.elementAt(i);
> switch (id) {
> case OPENED:
> listener.imageOpened(imp);
> break;
> case CLOSED:
> listener.imageClosed(imp);
> break;
> case UPDATED:
> listener.imageUpdated(imp);
> break;
> case SAVED:
>                                                       if (imp instanceof ImageListenerAux){
>                                                   (ImageListenerAux)listener).imageSaved(imp);
>                                                       }
>       break;
> }
> }
> }
> });
> }
>
>
> Users needing the FileSaved functionality can just implement the newer ImageListenerAux interface.
>
> Also, when ImageJ finally settled on Jave 8 I'd suggest that all the method interface to ImageListener are defaulted so plugIn developers need
> only implement the ones they are interested in.
>
> With best regards -- Michael Ellis
>

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