Posted by
Michael Schmid on
Oct 08, 2010; 8:20am
URL: http://imagej.273.s1.nabble.com/Why-are-images-automatically-renamed-tp3686678p3686687.html
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