<div dir="ltr"><div><div><div>Hi Burkhard,<br><br>>That being said, I've tried this strategy (in an unrelated project) to
override a format implementation in SCIFIO with our own implementation.
Back then (a few months ago), it did not work reliably in my hands.<br><br></div>If you're still unable to override formats using Plugin priority then that's certainly worrisome - please let me know how it goes. I'm happy to look at code samples to help identify problems; this is fundamental functionality that we want to ensure is both working properly, and easy for users/developers to implement.<br><br>>Another question is whether there is an option to turn off the automatic
min-max computation. Thanks to SCIFIO, we've found a nice way to
integrate our format with ImageJ, but using this comes at the price of a
pretty <br>>substantial IO performance hit that frankly is a source of
constant dissatisfaction.<br><br></div>Yes; I actually did some performance profiling in February and thought automatic min-max computation had been disabled. But it does seem like it may not be working as intended[1]. The desire is that if SCIFIO is used via "File > Open" or drag and drop, we won't force min-max computation. If SCIFIO is used explicitly (via File > Import > Image...) there should be a checkbox to use it, which I will add[2].<br><br></div><div>If you still have performance issues after any min-max computation fixes, please continue to let us know!<br><br></div><div>Thanks again,<br></div><div>Mark<br></div><div><br></div>[1] <a href="https://github.com/scifio/scifio/issues/269">https://github.com/scifio/scifio/issues/269</a><br><div>[2] <a href="https://github.com/imagej/imagej-plugins-commands/issues/23">https://github.com/imagej/imagej-plugins-commands/issues/23</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 13, 2015 at 2:23 PM, Burkhard Hoeckendorf <span dir="ltr"><<a href="mailto:burkhard.hoeckendorf@web.de" target="_blank">burkhard.hoeckendorf@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Mark,<br>
<br>
Thanks a lot for your help. I'll try playing with the format priority. That being said, I've tried this strategy (in an unrelated project) to override a format implementation in SCIFIO with our own implementation. Back then (a few months ago), it did not work reliably in my hands.<br>
<br>
Another question is whether there is an option to turn off the automatic min-max computation. Thanks to SCIFIO, we've found a nice way to integrate our format with ImageJ, but using this comes at the price of a pretty substantial IO performance hit that frankly is a source of constant dissatisfaction. I suspect deactivating the min-max computation may be an easy way to improve things, presumably without breaking anything else (?)<br>
<br>
Best,<br>
Burkhard<div><div class="h5"><br>
<br>
<br>
<br>
On 4/13/2015 2:37 PM, Mark Hiner wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Burkhard,<br>
<br>
>I apologize in case I am posting this mail twice. The first attempt at<br>
the end of last week came with an attachment and I assume it was<br>
probably scrubbed (and rightly so).<br>
<br>
No worries - there actually was a technical issue with the mailing list<br>
that's now fixed. Sorry about that!<br>
<br>
>As it turns out, even before looking at its file name extension,<br>
SCIFIO opened the file and tried to detect whether its header is in<br>
DICOM format<br>
<br>
DICOM is an unfortunate example that has some history in Bio-Formats<br>
(extensionless DICOM images, DICOM images with no magic string) that<br>
carried over to the SCIFIO implementation with potential for false<br>
positives. However, I think the best solution right now is to set your<br>
format to a higher priority. Formats are checked in plugin priority order.<br>
<br>
For example, see a sample format that uses a higher priority[1]. DICOM<br>
uses the normal priority (0), so you can use any of the higher<br>
constants[2] or set it manually[3] to a value > 0 for your format to be<br>
detected first.<br>
<br>
>More generally though, this experience has led me to wonder whether<br>
the order in which file formats are detected could be tweaked such that<br>
the ones requiring the most work are only attempted when the easier ones<br>
fail.<br>
<br>
Agreed completely. Plugin priority was a starting point, but we have<br>
started discussing how exactly to do things better[4] with some ideas<br>
very similar to what you outline.<br>
<br>
Thanks for the feedback, let us know if you have any more suggestions or<br>
questions.<br>
<br>
Best,<br>
Mark<br>
<br>
[1]<br>
<a href="https://github.com/scifio/scifio-bf-compat/blob/scifio-bf-compat-1.11.0/src/main/java/io/scif/bf/BioFormatsFormat.java#L79-80" target="_blank">https://github.com/scifio/<u></u>scifio-bf-compat/blob/scifio-<u></u>bf-compat-1.11.0/src/main/<u></u>java/io/scif/bf/<u></u>BioFormatsFormat.java#L79-80</a><br>
[2]<br>
<a href="https://github.com/scijava/scijava-common/blob/scijava-common-2.40.0/src/main/java/org/scijava/Priority.java#L48-55" target="_blank">https://github.com/scijava/<u></u>scijava-common/blob/scijava-<u></u>common-2.40.0/src/main/java/<u></u>org/scijava/Priority.java#L48-<u></u>55</a><br>
[3]<br>
<a href="https://github.com/scijava/scijava-common/blob/scijava-common-2.40.0/src/main/java/org/scijava/plugin/Plugin.java#L108-129" target="_blank">https://github.com/scijava/<u></u>scijava-common/blob/scijava-<u></u>common-2.40.0/src/main/java/<u></u>org/scijava/plugin/Plugin.<u></u>java#L108-129</a><br>
[4] <a href="https://github.com/scifio/scifio/issues/39" target="_blank">https://github.com/scifio/<u></u>scifio/issues/39</a><br>
<br>
On Mon, Apr 13, 2015 at 12:59 PM, Burkhard Hoeckendorf<br></div></div><div><div class="h5">
<<a href="mailto:burkhard.hoeckendorf@web.de" target="_blank">burkhard.hoeckendorf@web.de</a> <mailto:<a href="mailto:burkhard.hoeckendorf@web.de" target="_blank">burkhard.hoeckendorf@<u></u>web.de</a>>> wrote:<br>
<br>
Dear List,<br>
<br>
I apologize in case I am posting this mail twice. The first attempt<br>
at the end of last week came with an attachment and I assume it was<br>
probably scrubbed (and rightly so).<br>
<br>
We recently ran into an issue with DICOM format detection. We use a<br>
custom file format that is completely unrelated to DICOM and that is<br>
implemented for SCIFIO such that the file name extension alone is<br>
necessary and sufficient to recognize it. This works well, except<br>
for a single file which we couldn't open in Fiji. Reading it by<br>
other means (C++, MATLAB) worked fine.<br>
<br>
As it turns out, even before looking at its file name extension,<br>
SCIFIO opened the file and tried to detect whether its header is in<br>
DICOM format. I am unfamiliar with the DICOM standard and not a<br>
professional Programmer, but from the SCIFIO implementation<br>
(io.scif.formats.DICOMFormat) it appears to me that the magic 'DICM'<br>
string in the header is treated as optional. If it is not found,<br>
SCIFIO tries to read a single header field, and if successful<br>
considers the file a DICOM file. In our case, we got unlucky and by<br>
accident SCIFIO retrieved a valid-enough result when reading the<br>
corresponding position in the non-DICOM file. Hence, it was wrongly<br>
detected as a DICOM file.<br>
<br>
For the time being, we are now running our own, locally modified<br>
SCIFIO that does not try harder when the 'DICM' string is missing,<br>
and this solved our problem. For reference, we modified line 1079 in<br>
io.scif.formats.DICOMFormat. I am also happy to send this as a pull<br>
request, but I am not a DICOM user, so can not comment whether or<br>
not this is actually a workable solution.<br>
<br>
More generally though, this experience has led me to wonder whether<br>
the order in which file formats are detected could be tweaked such<br>
that the ones requiring the most work are only attempted when the<br>
easier ones fail. DICOM format detection would thus only occur when<br>
the file name extension does not match that of any format where the<br>
extension alone is necessary and sufficient. This may help prevent<br>
similar conflicts in the future and may additionally contribute a<br>
little bit to a much needed performance increase.<br>
<br>
Cheers,<br>
Burkhard<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
______________________________<u></u>_________________<br>
SCIFIO mailing list<br>
<a href="mailto:SCIFIO@scif.io" target="_blank">SCIFIO@scif.io</a><br>
<a href="http://scif.io/mailman/listinfo/scifio" target="_blank">http://scif.io/mailman/<u></u>listinfo/scifio</a><br>
</blockquote></div><br></div>