Why are images automatically renamed?

[Norbert Vischer-2]

Hi Wayne and others,

when I open three times in succession the same file "Coli-02.tiff", I see that image in three windows:

Coli-02.tiff
Coli-1.tiff
Coli-2.tiff

This is a confusing situation, and all three windows tell me in "Show Info" that the path ends with Coli-02.tiff -  which is only true for the first image.

Other applications would detect whether the image is already open, and if so, would bring it to front - even if it has unsaved changes. The user would understand what happens, and if he really wants to duplicate an image, he can choose "Duplicate" with a suitable name.

ImageJ does allow images to have same name, there are no restrictions after "Duplicate", "New", "Rename". I don't see any reason why in other cases equal names should be avoided. The user will understand the situation as long as there is no automatic renaming.

Automatic renaming also makes macros unreliable. If you read images from a file list, you want to be sure that they keep their names- this is currently not guaranteed.

Any comments on this?


Norbert Vischer

[Gabriel Landini]

On Thursday 07 October 2010  15:13:27  Norbert Vischer  wrote:
> when I open three times in succession the same file "Coli-02.tiff", I see
> that image in three windows:
>
> Coli-02.tiff
> Coli-1.tiff
> Coli-2.tiff

I think that here IJ confuses chopping part of the name off because there is a
"-"+number+"." in the title. So IJ thinks that this is the counter of the
replicated image.

It does add the -1, -2 to the original title if the last character is not a
number lilke: Colli-02a.tiff -> Coli-02a-1.tiff and so on.
I guess that this is to avoid adding -1 each time and increase the number
Otherwise it would be  Coli-1.tif, Coli-1-1.tiff and somehow there is a need
to keep increasing the counting.

> This is a confusing situation, and all three windows tell me in "Show Info"
> that the path ends with Coli-02.tiff -  which is only true for the first
> image.

Aa simple workaround, one can use "_" instead of "-" in the name.
I try to avoid spaces + - and [ ]  in the names because I always have the
feeling that passing names around in macros will cause problems.

Something related: when a plugin creates a new image whose name already
exists, there is a <1>, <2> etc added to the title. However, when one calls
other plugins that use a list of images, llike the Image Calculator these
appear without the <number> and it is guesswork which one is the right one.
The creation order seems to be preserved in the list, but as I said, it would
be useful if the list showed the appended <number> too.
I can't remember if the menu Window lists names with or without the <number>.
I hope this can be resolved too, if it does not.


Regards

Gabriel

[Norbert Vischer-2]

On 7. Oct. 2010, at 16:34 , Gabriel Landini wrote:
> I think that here IJ confuses chopping part of the name off because there is a
> "-"+number+"." in the title. So IJ thinks that this is the counter of the
> replicated image.

But the image is already open (the user may have forgotten this as it is hidden behind other windows) - why is it opened a second time as copy? Simply bringing it to the front wouldn't require to invent new names..

Norbert

[David Gene Morgan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Norbert,

        maybe I'm wrong, but I have always assumed that imageJ does this since
you might want to (for example) manipulate the same image in different
ways and compare the results before saving the output.  If it were
impossible to open the same image twice, this would be harder...

Norbert Vischer wrote:
> On 7. Oct. 2010, at 16:34 , Gabriel Landini wrote:
>> I think that here IJ confuses chopping part of the name off because there is a
>> "-"+number+"." in the title. So IJ thinks that this is the counter of the
>> replicated image.
>
> But the image is already open (the user may have forgotten this as it is hidden behind other windows) - why is it opened a second time as copy? Simply bringing it to the front wouldn't require to invent new names..
>
> Norbert


- --
                 David Gene Morgan
                  cryoEM Facility
                  320C Simon Hall
           Indiana University Bloomington
               812 856 1457 (office)
               812 856 3221 (EM lab)
            http://bio.indiana.edu/~cryo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFMre2hZP9hCYoz1a0RAunhAJwMCDH1Osb9uvFvvEL3/E0cifJIxQCeKG4B
xAcyCNlFqLdoC3PBf7R32f0=
=0biq
-----END PGP SIGNATURE-----

[fmonson]

I am using Win vista Business on Lenovo 'ThinkStation'

I performed the following experiment using ImageJ 1.44h

Two files

open img7_002; second open img7_002:>img7_002-1; third open img7_002:>img_002-2

open img7-002; second open ing7-002:>img7-002-1; third open img7-002:>img7-002-2

Norbert?  I may be just lucky to be working on a 'ThinkStation!'  We all know that the 'Vista' is a plug, so, at least you know that someone who doesn't require the numbering you would like can get that numbering anytime.  I cannot do this on an XP install until I get home, because our IT doesn't support more than one version at a time.

Cheers,

Fred Monson

Frederick C. Monson, PhD
Technical Director
Center for Microanalysis and Imaging, Research and Training (CMIRT)
http://cmirt.wcupa.edu
[hidden email]
________________________________________
From: ImageJ Interest Group [[hidden email]] On Behalf Of Gabriel Landini [[hidden email]]
Sent: Thursday, October 07, 2010 10:34 AM
To: [hidden email]
Subject: Re: Why are images automatically renamed?

On Thursday 07 October 2010  15:13:27  Norbert Vischer  wrote:
> when I open three times in succession the same file "Coli-02.tiff", I see
> that image in three windows:
>
> Coli-02.tiff
> Coli-1.tiff
> Coli-2.tiff

I think that here IJ confuses chopping part of the name off because there is a
"-"+number+"." in the title. So IJ thinks that this is the counter of the
replicated image.

It does add the -1, -2 to the original title if the last character is not a
number lilke: Colli-02a.tiff -> Coli-02a-1.tiff and so on.
I guess that this is to avoid adding -1 each time and increase the number
Otherwise it would be  Coli-1.tif, Coli-1-1.tiff and somehow there is a need
to keep increasing the counting.

> This is a confusing situation, and all three windows tell me in "Show Info"
> that the path ends with Coli-02.tiff -  which is only true for the first
> image.

Aa simple workaround, one can use "_" instead of "-" in the name.
I try to avoid spaces + - and [ ]  in the names because I always have the
feeling that passing names around in macros will cause problems.

Something related: when a plugin creates a new image whose name already
exists, there is a <1>, <2> etc added to the title. However, when one calls
other plugins that use a list of images, llike the Image Calculator these
appear without the <number> and it is guesswork which one is the right one.
The creation order seems to be preserved in the list, but as I said, it would
be useful if the list showed the appended <number> too.
I can't remember if the menu Window lists names with or without the <number>.
I hope this can be resolved too, if it does not.


Regards

Gabriel

[Gabriel Landini]

On Thursday 07 October 2010  17:39:24 you wrote:
> On 7. Oct. 2010, at 16:34 , Gabriel Landini wrote:
> > I think that here IJ confuses chopping part of the name off because there
> > is a "-"+number+"." in the title. So IJ thinks that this is the counter
> > of the replicated image.
>
> But the image is already open (the user may have forgotten this as it is
> hidden behind other windows) - why is it opened a second time as copy?

Sorry I misunderstood your previous mail.

> Simply bringing it to the front wouldn't require to invent new names..

Yes, but those are 2 different actions: "choose from the open images" ->select
from the Window menu entry, versus "open an image from disk" -> File menu
entry.
I think it is useful to be able to open the same image more than once
(although I sometimes forget I have some windows minimised, too) :-)

If the hidden window was brought to the front when you try to open, then it
would not be an Open command, but a SelectWindow one. That would also be
confusing when the original was processed and hidden.

Not sure if there is a better solution to this.

Regards

Gabriel

[vischer]

Thanks Gabriel, Frederick, David for your points of view.

In fact, with "already open" and "renaming" I have touched
two subjects, and my favorite scenarios would be:

if I "Open" an image file, then:

a) if it is already open, it should be brought
   to the front rather than a copy being opened

b) if it is not open yet, but some other window happens
   to have the same title, it should still open with its
   original file name rather than being renamed-
   even if now two images have the same name.


It would be clear and reproducible behaviour, be  conform to most other applications,
wouldn't create unwanted duplicates, wouldn't produce new (unpredictable) names,
wouldn't create any number suffixes at all.
Still the user can explicitely duplicate in IJ or the Finder/Explorer.

My main concern is that my plugin relies on path names when handling images.
I want to be sure that the path name of an image remains valid
after being opened.
Currently, the path name may be spoilt due to automatic renaming.

> If the hidden window was brought to the front when you try to open, then it
> would not be an Open command, but a SelectWindow one. That would also be
> confusing when the original was processed and hidden.

Gabriel, I made experiments with other applications (Word, GraphicConverter,
BBEdit, PowerPoint); they all behave logical as described in a) and b).
ImageJ is an exception.

Norbert

[Cammer, Michael]

Every image has a unique identifying number.  Therefore, in macros, I never use the selectWindow() command.  Each time a window is opened, the macro uses getImageID() to make sure that names don;t cause a conflict.

_________________________________________
Michael Cammer, Assistant Research Scientist
Skirball Institute of Biomolecular Medicine
Lab: [phone]  Cell: [phone]

________________________________________
From: ImageJ Interest Group [[hidden email]] On Behalf Of Norbert Vischer [[hidden email]]
Sent: Thursday, October 07, 2010 3:28 PM
To: [hidden email]
Subject: Re: Why are images automatically renamed?

Thanks Gabriel, Frederick, David for your points of view.

In fact, with "already open" and "renaming" I have touched
two subjects, and my favorite scenarios would be:

if I "Open" an image file, then:

a) if it is already open, it should be brought
   to the front rather than a copy being opened

b) if it is not open yet, but some other window happens
   to have the same title, it should still open with its
   original file name rather than being renamed-
   even if now two images have the same name.


It would be clear and reproducible behaviour, be  conform to most other applications,
wouldn't create unwanted duplicates, wouldn't produce new (unpredictable) names,
wouldn't create any number suffixes at all.
Still the user can explicitely duplicate in IJ or the Finder/Explorer.

My main concern is that my plugin relies on path names when handling images.
I want to be sure that the path name of an image remains valid
after being opened.
Currently, the path name may be spoilt due to automatic renaming.

> If the hidden window was brought to the front when you try to open, then it
> would not be an Open command, but a SelectWindow one. That would also be
> confusing when the original was processed and hidden.

Gabriel, I made experiments with other applications (Word, GraphicConverter,
BBEdit, PowerPoint); they all behave logical as described in a) and b).
ImageJ is an exception.

Norbert

------------------------------------------------------------
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.
=================================

[Gabriel Landini]

On Thursday 07 October 2010 20:31:48 Cammer, Michael wrote:
> Every image has a unique identifying number.  Therefore, in macros, I never
> use the selectWindow() command.  Each time a window is opened, the macro
> uses getImageID() to make sure that names don;t cause a conflict.

Yes the ID is very handy, but unfortunately that is not a solution for all
cases. One also has to rely on getTitle() so the image can be operated by many
(the majority? all?) plugins because they do not accept an ID as an argument.

Cheers

Gabriel

[fmonson]

Below:
________________________________________
From: ImageJ Interest Group [[hidden email]] On Behalf Of Norbert Vischer [[hidden email]]
Sent: Thursday, October 07, 2010 3:28 PM
To: [hidden email]
Subject: Re: Why are images automatically renamed?

Thanks Gabriel, Frederick, David for your points of view.

In fact, with "already open" and "renaming" I have touched
two subjects, and my favorite scenarios would be:

if I "Open" an image file, then:

a) if it is already open, it should be brought
   to the front rather than a copy being opened

>>>>They were opened in cascade on top of original, but if you want no copies then, we have open source and macros for special cases, though I am not a programmer, and I can't speak to internal priorities, etc.

b) if it is not open yet, but some other window happens
   to have the same title, it should still open with its
   original file name rather than being renamed-
   even if now two images have the same name.

>>>>Ah!  Now you cross my Rubicon to confusion.  I believe that ImageJ is perfectly clear that replicates of images
will be named as derivatives of the original name, and not as if the images were stored in a database with names that are NOT indices (the true 'database' names.  In my microanalysis program, if I acquire 10 spectra from 10 different locations, I am able to name them all "1", and still, each one references its own values, because the real name is:  record index(generally an integer) + table name + database name.  In an external table below a reference image, the image will show 10 locations with number "1" and the table will show ten records with number "1".  Thus, only the database will be un-confused.

It would be clear and reproducible behaviour, be  conform to most other applications,
wouldn't create unwanted duplicates, wouldn't produce new (unpredictable) names,
wouldn't create any number suffixes at all.
Still the user can explicitely duplicate in IJ or the Finder/Explorer.

>>>>That is a valid criterion, and if you want that, then the true name of the image would be:  "path+filename".  No problem, I suspect for the scriptorian.  I would probably understand the issue bettger if what I wanted to do could be easier done in another program.  Admittedly, it appears that you will have to include changes to file handling - if ImageJ will permit - so that the procedures you wish to execute can be performed as you require.

My main concern is that my plugin relies on path names when handling images.
I want to be sure that the path name of an image remains valid
after being opened.  
Currently, the path name may be spoilt due to automatic renaming.

>>>>Again as no programmer, it would seem reasonable to expect that when the user selects a PATH (i.e., a subdirectory) that the PATH is accessible for assignment.  Similarly, if one were to write a macro to extract, to another PATH, every 25th image in a stack of 1000 starting with image #0, then image 25, etc.  One would have the relationship of the extracted images dislocated from the parent stack even if they were named:  parent PATH + parent file name + 01...40.  In such a case, even if the extractions were done to the parent PATH, the extracted images could not be confused with their copies in the stack file as long as each name consisted of:  parent PATH = parent filename + 01....40.  Can a procedure work while attempting to have more than one focus at a time?  [This may have been 'terrible name dropping' and I apologize for attempting it.  For me it is a question of file management.]

> If the hidden window was brought to the front when you try to open, then it
> would not be an Open command, but a SelectWindow one. That would also be
> confusing when the original was processed and hidden.

>>>>The key is to have no 'hidden' windows on which you cannot work that take up buffer space and confuse the CPU.  Each window with a single name reference, and it seems to me that you could name a copy anything - in secret - while all had the apparent identical names.  BUT, how would you sort them after finishing your work?

Gabriel, I made experiments with other applications (Word, GraphicConverter,
BBEdit, PowerPoint); they all behave logical as described in a) and b).
ImageJ is an exception.

Norbert

[Gabriel Landini]

On Thursday 07 October 2010 20:28:22 Norbert Vischer wrote:
> two subjects, and my favorite scenarios would be:
> if I "Open" an image file, then:
> a) if it is already open, it should be brought
>    to the front rather than a copy being opened
>
> b) if it is not open yet, but some other window happens
>    to have the same title, it should still open with its
>    original file name rather than being renamed-
>    even if now two images have the same name.

Hi Norbert,
How can one differentiate between cases a) and b)?
How will plugins (and users) resolve the exact duplicate names in b)?

> Still the user can explicitely duplicate in IJ or the Finder/Explorer.

Sure, but those duplicate images have to be identifiable by their titles
somehow, as plugins use the titles to process the images.

> My main concern is that my plugin relies on path names when handling
> images. I want to be sure that the path name of an image remains valid
> after being opened.

Maybe you can resolve this in a different way. For example open the image, and
rename it with a reserved name that is unlikely to exist.
Or get the list of all the open images to check whether the image in the path
you chose corresponds to an image already open, and give a warning.
Or the plugin could just close all open images at start (similar to the Close
All command).

> Gabriel, I made experiments with other applications (Word,
> GraphicConverter, BBEdit, PowerPoint); they all behave logical as
> described in a) and b). ImageJ is an exception.

Yes, but not all programs do so. The GIMP opens new copies of the same image
with -1.0, -2.0 and so on, similarly to IJ.


Regards

Gabriel

[vischer]

Hi Gabriel

To illustrate the perfect confusion, consider this case:

You have 50 images in a folder, named:
pic_01
pic_02
..
pic_50

Today, you want to process pic_23.
Unfortunately, you are not aware that pic_23 already resides in the dock since yesterday.
You drag file "pic_23" onto the ImageJ main window, but it opens as pic_24.

You don't notice that the index has increased, process the image and save it.
You are asked "pic_24 already exists, replace?"
Yes, you want to save the processed image.

What has happened? For renaming, ImageJ has chosen the name of an existing file -
the original pic_24 is lost because it was overwritten by processed pic_23.
You don't notice this immediately (especially in time lapses), and are not aware
that you spoilt your analysis results.

>
> How can one differentiate between cases a) and b)?
> How will plugins (and users) resolve the exact duplicate names in b)?

The unique ID (as Frederick mentioned) and retrieving the path via "GetInfo"
gives complete information about an image. As mentioned earlier, "GetInfo" currently
gives incorrect information about images that are silently duplicated or renamed.

Generally it is a bad idea to silently create copies in order to solve some other
problem like a name conflict - copies create confusion.

regards, Norbert

[Michael Schmid]

Hi Norbert,

at least for saving in a macro, there should be an easy workaround:
The original file name is available in the Info, in a macro you can  
extract it with getInfo("image.filename"). You can use this as an  
argument for saveAs.


As mentioned by others, if we had the window name always equal to the  
file name there would be a problem accessing multiple images derived  
from one file, e.g. a copy of the image where I remove the foreground  
objects to create a background should have a different name.

By the way, image names like pic_50 (with underscore) are no problem.  
When opened twice, the name of the second window becomes pic_50-1.  
The problem only occurs if you have image names with a hyphen like  
pic-50 or pic-50.png, etc.
pic-50a is no problem again, the second version becomes pic-50a-1.

Changing this behavior could break existing macros that rely on that  
naming scheme.

So, in my view, the easiest option would be avoiding image names  
ending with hyphen+number.


Michael
________________________________________________________________


On 8 Oct 2010, at 09:48, Norbert Vischer wrote:

> Hi Gabriel
>
> To illustrate the perfect confusion, consider this case:
>
> You have 50 images in a folder, named:
> pic_01
> pic_02
> ..
> pic_50
>
> Today, you want to process pic_23.
> Unfortunately, you are not aware that pic_23 already resides in the  
> dock since yesterday.
> You drag file "pic_23" onto the ImageJ main window, but it opens as  
> pic_24.
>
> You don't notice that the index has increased, process the image  
> and save it.
> You are asked "pic_24 already exists, replace?"
> Yes, you want to save the processed image.
>
> What has happened? For renaming, ImageJ has chosen the name of an  
> existing file -
> the original pic_24 is lost because it was overwritten by processed  
> pic_23.
> You don't notice this immediately (especially in time lapses), and  
> are not aware
> that you spoilt your analysis results.
>
>>
>> How can one differentiate between cases a) and b)?
>> How will plugins (and users) resolve the exact duplicate names in b)?
>
> The unique ID (as Frederick mentioned) and retrieving the path via  
> "GetInfo"
> gives complete information about an image. As mentioned earlier,  
> "GetInfo" currently
> gives incorrect information about images that are silently  
> duplicated or renamed.
>
> Generally it is a bad idea to silently create copies in order to  
> solve some other
> problem like a name conflict - copies create confusion.
>
> regards, Norbert

[Gabriel Landini]

Hi Norbert,

On Friday 08 October 2010  09:25:38 Norbert Vischer wrote:
> Today, you want to process pic_23.
> Unfortunately, you are not aware that pic_23 already resides in the dock
> since yesterday. You drag file "pic_23" onto the ImageJ main window, but
> it opens as pic_24.

Shouldn't that open as pic_23-1 ? I agree that when using "-02" type names IJ
gets confused (but perhaps this was fixed in the latest daily build? see
below).

> As mentioned earlier,
> "GetInfo" currently gives incorrect information about images that are
> silently duplicated or renamed.

Maybe this was fixed yesterday? I get this info in the renamed image (using
the latest build) I opened Coli-02.tiff twice:

Title: Coli-02-1.tiff
Width:  256 pixels
Height:  256 pixels
ID: -6
Coordinate origin:  0,0
Bits per pixel: 32 (RGB)
No Threshold
Uncalibrated
Path: /home/gabriel/ImageJ/Coli-02.tiff

The info seems to be correct now. The path name is where the image was
loaded from, the title is the current one  too.

So perhaps you can solve this by retrieving the path, isolate the file name
from it, get the ID and the title. If the title changed you know which one is
the image you need to process and also how it should be called on disk. And
this allows opening more than one version of the image, if required since you
know which one is the one to process.

I think that the danger of missing an image because it was renamed due to a
duplicate name is no different than the danger of using an open image that
comes to the front but that was already processed.
In the second case, users will complain that they open the image (when they
did not), and reality is that an older image is processed instead without the
user realising it.

Best wishes,

Gabriel

[vischer]

I have to make here two corrections:

first - unintentional overwriting (e.g. of "pic-24" in my case study) indeed only occurs when using the minus sign, not with the underscore as I wrote- sorry for this mistake. I am using minus signs all the day in file names and obviously have become a special victim.

second - I expected that getTitle() and getInfo("image.filename") should be the same (as in most applications), but ImageJ obviously allows the file name to be different from the image title,  thus it neither is nor was a bug.

regards, Norbert