http://imagej.273.s1.nabble.com/Opening-Stack-with-ImageJ-and-BioFormats-tp5022585p5022601.html
> Dear Herbie,
>
> well, I think you can't rely on an ImageStack opened by plain ImageJ not
> to have any slice labels.
> ImageJ saves the slice labels with the stack, so if you get slice labels
> in ImageJ from whereever and then save the stack, you will get the
> labels back when opening that stack.
> You get slice labels e.g. after "images to stack", or a user plugin or
> macro may have added labels (many of my local plugins and macros that
> create stacks do so).
>
> Thus, a macro that runs "Stack to Images" and then assumes image titles
> like "stck-0001" etc. is unsafe in any case; one would better use the
> last (most negative) nSlices ImageIDs to address these images.
>
> I agree that the slice labels created by the BioFormats importer are a
> bit unfortunate, because they contain characters that must not be
> present in file names, and in most cases one would also like to have the
> slice numbers (channel/z/t etc.) following the file name, not preceding
> it, for easier sorting.
> I am not sure, however, whether it is a good idea to change this, to
> avoid breaking existing code that may rely on it.
>
> Good ideas how to solve the problem without the danger of breaking
> existing macros etc. are welcome...
>
>
> Michael
> ________________________________________________________________
> On 28.10.19 15:46, Herbie wrote:
>> Dear Michael,
>>
>> I fear what you write is not the solution to a confusing naming of
>> stack images after applying run("Stack to Images"); .
>>
>> What you write is perfectly OK but doesn't help much if you are not in
>> the know.
>>
>> Assume a macro that calls run("Stack to Images"); and then deals with
>> the resulting images.
>> The coder assumes that the stack in question (with title stck.xyz) was
>> opened by plain ImageJ. Consequently, the coder knows that a certain
>> image, i.e. slice, of this stack is named "stck-000i". Not so if the
>> stack was opened by "Bio-Formats Importer".
>>
>> One way to circumvent this problem is to rename or remove names of the
>> slices of a stack in *any* case.
>>
>> This is far from convenient.
>>
>> Many greetings
>>
>> Herbie
>>
>> ::::::::::::::::::::::::::::::::::::::::::::
>> Am 28.10.19 um 15:19 schrieb Michael Schmid:
>>> On 28.10.19 10:19, Herbie wrote:
>>>> a current discussion here on the ImageJ-list leads me to post a
>>>> question about opening stacks either with "Plain ImageJ" or by using
>>>> "Bio-Formats Importer" from plain ImageJ.
>>>
>>>
>>> Hi everyone,
>>>
>>> after half a dozen more contributions, in case this has not been
>>> clearly answered:
>>>
>>> If you split a stack into images, the image titles are determined by
>>> the labels of the stack, if any. Otherwise, the images are named
>>> title-0001, etc. with "title" being the title of the stack.
>>>
>>> E.g. try this macro with any two-image stack like the sample stack
>>> "confocal-series_2Ch.tif" from this thread
>>>
>>> setSlice(1);
>>> run("Set Label...", "label=my_slice1");
>>> setSlice(2);
>>> run("Set Label...", "label=my_slice2");
>>> run("Stack to Images");
>>>
>>> The images will be named "my_slice1" and "my_slice2".
>>>
>>> So the difference between opening by ImageJ and the Bio-Formats
>>> Importer seems to be that the latter adds labels (presumably only if
>>> there are no labels in the file).
>>>
>>> You can use a macro like the one above to set the labels to anything
>>> of your choice. This will determine what the image names after "Stack
>>> to Images".
>>> If you don't like the slice labels created by the Bio-Formats
>>> Importer, you can also get rid of them with the following macro:
>>>
>>> for (i=1; i<=nSlices(); i++) {
>>> setSlice(i);
>>> setMetadata("Label", "");
>>> }
>>>
>>> [Instead of run("Set Label..." ...) one has to use the equivalent
>>> command setMetadata("Label", ...) in this case, as the run("Set
>>> Label..." ...) command cannot be used to set the label to an empty
>>> String.]
>>>
>>>
>>> Michael
>>>
>>> --
>>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>>>
>>
>