Re: Opening Stack with ImageJ and BioFormats

Posted by Sebastien Besson (Staff) on
URL: http://imagej.273.s1.nabble.com/Opening-Stack-with-ImageJ-and-BioFormats-tp5022585p5022607.html

Dear Herbie and all,

Thanks for raising the issue of the slice label and providing a reproducible scenario including test data. Answering a few questions from the thread:

- we fully agree that breaking downstream code should never be done lightly. In the case of Bio-Formats, this will always be communicated via an increment of the major version number
- I retested your example using both the current (6.3.0) and older (down to 5.3.0) releases of Bio-Formats and I can confirm the slice label behaviour you are describing in all cases
- looking into the code base, the formatting of the slice label including the prefixes has always been the behavior since the implementation of the plugin over a decade ago

The Stack to Images workflow you are describing makes sense.  Other consumers of the plugin have separately asked for the ability to further customize the slice label with additional metadata in the context of a completely different workflow[1].

Bio-Formats 5.7.0 introduced the ability to control the pattern used for controlling the slice label which I expect helps addressing both use cases. You should be able to set its value from the configuration window (Plugins > Bio-Formats > Bio-Formats Plugins Configuration) under the General panel.
The default value has been kept to "%c%z%t- %n" to prevent a breaking change of the plugin. Setting this value to empty results in the label of your test file displayed exactly like in plain ImageJ which should fix your workflow.
Please give us a try and let us know if you find any issue.

Best,
Sebastien

[1] https://github.com/ome/bioformats/pull/2670

On 28/10/2019, 15:35, "ImageJ Interest Group on behalf of Herbie" <[hidden email] on behalf of [hidden email]> wrote:

    Dear Michael,

    if this is so, and I know it is, then it is of utmost importance to tell
    the community.

    My test-stack has no slice labels, so how comes that "Bio-Formats
    Importer" invents them (according to what?) and uses them to name the
    slices?
    This is the problem, not plain ImageJ.

    Frankly speaking the approach of "Bio-Formats Importer" is not
    reasonable in several respects.
    No one will use slashes and colons in a file name or is this the new
    style in informatics? Did I miss something?

     From my point of view the problem is severe and if any reasonable
    changes will break old code: So what?
    Nobody cared about silly prefixes, so let's break code that uses those.

    We shall see what the leading persons have to contribute and I really
    should like to know who came up with the idea of using such prefixes.

    Kind regards

    Herbie

    ::::::::::::::::::::::::::::::::::::::::::::
    Am 28.10.19 um 16:15 schrieb Michael Schmid:
    > 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



The University of Dundee is a registered Scottish Charity, No: SC015096

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