Re: Opening Stack with ImageJ and BioFormats

Posted by Michael Schmid on
URL: http://imagej.273.s1.nabble.com/Opening-Stack-with-ImageJ-and-BioFormats-tp5022585p5022600.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
>>
>

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