imagej-servercode compatible to
pom-scijava 29and need some advice. It's e.g. calling
io.scif.services.LocationServicewhich 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.LocationServiceso I was wondering where that went / how it could be addressed.
LocationServiceknows how to resolve strings to
DataHandleServiceknows how to wrap
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.)
Locationyou want, and then open it (for reading or writing) with the
BytesLocation. No need for
mapIdor any of that hacky stuff.
scifioserved 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?
imagesfolder. The data itself is served from
samples.scif.iowhich is not hosted on GitHub Pages, because some of the samples are too large for GitHub. I can put the image in place in response to your PR. Coincidentally, I'm working on the SCIFIO samples page today anyway, adding some FLIM image data. I will also look into adding a "License" column to clarify the license of each image, since it will no longer be CC0/PD for everything anymore.
imagej-server- with the new Location API, how does one handle an
InputStream? I can't figure out a way to wrap it with a
Location, which I would need to call
datasetIOService.open(..). Differently formulated - how to use SCIFIO to open an image from an
IOService(that only forwards to
DatasetIOServicein case of images)?
Locationbut I would like to (e.g. for the deep learning stuff to read models from URL) so I am somewhat motivated to rather work on understanding and using it than having to spend time to readd deprecated stuff. But I'm not sure how much work it is in total.
IOPlugincan't implement both
HandlerPlugintypes, we have to decide for one main one? Does this have more implications? The only difference I see is that
boolean supports(final String descriptor)is then an
boolean supports(final Location descriptor)would not be one
open(String)method supporting more data types than the
open(Location)method, until all
IOPlugins have adapted to the new API.
IOService.open, that works, but it will not make use of the
locationService.resolvemethod to support Strings which are not local file paths. In order to use this, the method would have to be able to throw an exception.. I think it would be great to add this and finally get a way to catch if saving or loading fails. This is all not backwards compatible though.