Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tobias Pietzsch
    @tpietzsch
    I'm looking now at the other file format A.ics trying to find out where the other exception with that is coming from
    Tobias Pietzsch
    @tpietzsch
    Hmm, for the ICS, it tries to read more than the available bytes in a planes array
    something might be off with the offset/size calculations there
    looks like interval.max() might be used instead of interval.dimension()
    but I'm not sure of what is supposed to happen there
    for the images that work for me that part of the code is never hit
    @ctrueden, in io.scif.TypedReader, there are various openPlane and readPlane methods
    what is the difference between open/read?
    Tobias Pietzsch
    @tpietzsch
    I'm giving up for now...
    Curtis Rueden
    @ctrueden
    @tpietzsch Sorry I wasn't around earlier. There certainly were a whole slew of bugs related to dimensional lengths vs min/maxes... I thought I had fixed them all, unifying everything to use Interval to avoid semantic ambiguity.
    But I'm not surprised to hear there might still be somewhere it's being done incorrectly.
    Curtis Rueden
    @ctrueden
    @hinerm I added you to this channel, for obvious reasons. :grin: I want to introduce you to Dasong (@Xanthorapedia), who is working on the FLIMJ project. We have an ICS file from Paul Barber that writes axis metadata into the history extents metadata. Dasong may need some pointers on how best to update the ICSFormat of SCIFIO to handle this properly.
    Dasong Gao
    @Xanthorapedia

    @ctrueden Thanks Curtis. @hinerm Hi Mark, in Paul Barber's ICS file, he specifies the axis information by putting e.g. a history Labels t x y and a history Extents 1.000000e-08 128 128 entry to denote the dimensions of each axis. This information doesn't seem to be recognized by SCIFIO. My current workaround to find the time axis dimension is:

    // while parsing ics ImgPlus in FLIMJ
    PlaneSeparatorMetadata scifioGlobalProperty = (PlaneSeparatorMetadata) imp.getProperties().get("scifio.metadata.global");
    String[] extVals = ((String) scifioGlobalProperty.getTable().get("history extents")).split("\\s+");
    // find the decimal string that corresponds to "t" in "history labels"

    Can you give me some instructions as to how I can add to SCIFIO's ICS parser to handle this?

    Curtis Rueden
    @ctrueden
    @Xanthorapedia It looks like the SCIFIO ICSFormat does parse history extents to some extent (*ba dum ching*).
    Oh wait, that's the other direction, eh?
    Oh, it's here.
    So maybe put a breakpoint and see if the code is reaching that getPhysicalPixelSizes() method at all.
    It looks like nothing ever calls it... :confused:
    This code should be using getPhysicalPixelSizes(), no?
    I have to run—I hope those links help you get started.
    Mark Hiner
    @hinerm
    Hi @Xanthorapedia! Do your ICS files also have the parameter scale metadata tag?
    And are you just trying to recover the metadata? Or is there something that's trying to use physical pixel sizes and they're not being reported?
    Mark Hiner
    @hinerm
    I have to admit I don't remember the difference between pixelSize and physicalPixelSize...
    Curtis Rueden
    @ctrueden
    Pixel size = dimensional length. Physical pixel size = calibration.
    At least... I think :-)
    The FLIMJ project needs the physical calibration of the LIFETIME dimension to display a properly calibrated decay plot. We need to know if, e.g., the values range from 0 to 10 ns, or 0 to 12.5 ns, or something else. Regardless of the number of actual time bins along that dimension.
    Mark Hiner
    @hinerm
    but the axes are the dimensional lengths right?
    Curtis Rueden
    @ctrueden
    The CalibratedAxis classes of ImageJ2 support physical calibration in real space. Here we want SCIFIO to provide a LinearAxis for LIFETIME with the right calibration.
    Dasong Gao
    @Xanthorapedia
    Thanks for the explanation. Yes, CalibratedAxis is what I used to extract scales from other formats such as SDT. The ICS in question does have a parameter scale tag with 3 1.000000s, which are currently (supposedly) interpreted as the physical separation between pixels/layers. Though they are not because of a potential bug in the line reading stage, which causes this key not to be recognized and the default value of all 1.0's are used. I can supply more details if you are interested.
    Dasong Gao
    @Xanthorapedia
    Although parameter scale is meant to be the default place to define the physical sizes in the original paper, page 9, I see Bio-Formats uses history extent (overall dimensions of the dataset) to infer the physical pixel sizes if parameter scale is not present.
    if (scales != null) {
        // ...
    
        for (int i = 0; i < scales.length; i++) {
            Double scale = scales[i];
            // ...
            if (axis.equals("x")) {
                if (checkUnit(unit, "um", "microns", "micrometers")) {
                    Length x = FormatTools.getPhysicalSizeX(scale);
                    if (x != null) {
                        store.setPixelsPhysicalSizeX(x, 0);
                    }
                }
            }
            // process y and z axis in the same way
            // ...
            else if (axis.equals("t") && scale != null) {
                if (checkUnit(unit, "ms")) {
                    store.setPixelsTimeIncrement(new Time(scale, UNITS.MILLISECOND), 0);
                } else if (checkUnit(unit, "seconds") || checkUnit(unit, "s")) {
                    store.setPixelsTimeIncrement(new Time(scale, UNITS.SECOND), 0);
                }
            }
        }
    } else if (sizes != null) {
        if (sizes.length > 0) {
            Length x = FormatTools.getPhysicalSizeX(sizes[0]);
            if (x != null) {
                store.setPixelsPhysicalSizeX(x, 0);
            }
        }
        if (sizes.length > 1) {
            // process y axis
        }
    }
    from here, where scales are parsed from parameter scale and sizes are parsed from history extents.
    Curtis Rueden
    @ctrueden
    @Xanthorapedia It sounds like you have a pretty good idea what's going on. Do you need additional help from us? If so, I suggest you share the ICS file.
    Dasong Gao
    @Xanthorapedia
    @ctrueden @hinerm Sure, you may download the file from here. As for ICSFormat, do you think we should use history extents and parameter scale interchangeably?
    Mark Hiner
    @hinerm
    @Xanthorapedia I think we can do what Bio-Formats does and use history extents as the fallback if parameter scale isn't present, or is set to the default 1 x 1 x 1
    Dasong Gao
    @Xanthorapedia
    @hinerm That will do. But what about units? This ICS uses scale 1 and unit undefined for each axis and puts calibration in history extents, which has no units attached. BioFormats and the current SCIFIO assumes the default units (seconds, um, etc.) in this case.
    Dasong Gao
    @Xanthorapedia
    One hierarchy I can think of is:
    • parameter scale with parameter units
      If (parameter scale is missing or parameter units is undefined or missing) and history extents is present:
    • history extents with default units
      If nothing works:
    • Default values with default units
    Better suggestions?
    Curtis Rueden
    @ctrueden
    @hinerm I went ahead and reviewed + merged #428. The mega melt is likely to identify any downstream issues with it, but I expect nothing bad will happen. (Obligatory parenthetical note about how now something bad will happen because I said that, but because I include this fourth-wall-breaking note maybe we'll be spared the wrath of the irony gods after all.)
    Mark Hiner
    @hinerm
    :+1:
    Jan Eglinger
    @imagejan
    Are there any plans to resurrect the String and File-based methods in FilePatternService that were present in 0.37.3 but got lost when SCIFIO was changing to DataHandle with https://github.com/scifio/scifio/commit/5c11f00f519fd73ea09be6724e8543a73028d745#diff-09fdb44bddc5a27ef1f3c369ea067e9d ?
    Curtis Rueden
    @ctrueden
    @imagejan Wasn't planning on it, but we probably should, eh?
    Deborah Schmidt
    @frauzufall
    @imagejan I can do that.
    Jan Eglinger
    @imagejan
    @ctrueden @frauzufall just asking because I started using FilePatternService only now, but saw that it’s typed on DataHandle while Fiji still ships the old version. I can live with switching to DataHandle, I just need to know : )
    Curtis Rueden
    @ctrueden
    I have no strong preference!
    Hopefully we'll be out of our limbo state within another 1-2 weeks. I'm technically on vacation now, so no progress from me for the next few days.
    Deborah Schmidt
    @frauzufall
    I'll just readd the methods which were removed. Let me know if you can think of more places like this @imagejan :)
    Jan Eglinger
    @imagejan
    :+1: we could also run revapi on this to get a comprehensive list, no?
    Deborah Schmidt
    @frauzufall
    yes, I used that for specific classes like IO in the past to fix these issues, running it on the whole scifio package resulted in an endless list. But I can try again, maybe with regex to check for services