SCientific Image Format Input & Output: a flexible, extensible framework for image I/O. *EXPERIMENTAL* All API is subject to change, so depend at your own risk! See also @openmicroscopy/bioformats.
@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.
@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?
@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.
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?
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.
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.
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
}
}scales are parsed from parameter scale and sizes are parsed from history extents.
@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?
@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.
Better suggestions?
@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.)
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 ?
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.
Hi all, I'm looking at making the
imagej-server code compatible to pom-scijava 29 and need some advice. It's e.g. calling locationService.mapFilehere from io.scif.services.LocationService which does not exist any more. It maps files to e.g. ByteArrayHandle, another gone class. There does not seem to be a similar feature available in org.scijava.io.location.LocationService so I was wondering where that went / how it could be addressed.
@frauzufall The
LocationService knows how to resolve strings to Location objects using LocationResolver plugins. The DataHandleService knows how to wrap Location objects in DataHandles. (In case it wasn't already clear: a location is just an indicator of data source/destination, whereas a data handle knows how to do random/direct access byte extraction from a location.)
There is no mapping functionality anymore; it's not necessary.
You just make the
Location you want, and then open it (for reading or writing) with the DataHandleService.
For byte arrays, create a
BytesLocation. No need for mapFile or mapId or any of that hacky stuff.
@frauzufall @ctrueden it seems the new
scifio served by the latest update is lacking the FormatService.getFormat(String) method in favor of the DataHandle-based methods. I didn't notice so far, but have a script using that method. I can update my script of course, but I guess we should also bring back that method signature (deprecated) for backwards compatibility, no?