Posted by
dscho on
URL: http://imagej.273.s1.nabble.com/SCIFIO-issues-tp5008128p5008134.html
Hi Rainer,
On Wed, 11 Jun 2014, Rainer M. Engel wrote:
> I ran into problems running some Makros opening images.
Just for the record: they are called 'macros' in English, with a 'c' ;-)
> I understand that the SCIFIO feature in the most recent Fiji
> distribution can be disabled.
> EDIT > Options > ImageJ2
Yes, that option is intended to work around the problems we are fixing
right now. We knew that there would be problems: the code paths in ImageJ
1.x to open images are diverse and many, and we thought we had addressed
them all; however, there were a couple of surprising things that bit us,
such as the code that magically turns a color .gif/.jpg that happens to
have identical red/green/blue values per pixel into a grayscale image.
We do appreciate the patience and help of the community, assisting us to
squash all those bugs and get this support into a robust form.
> That is fine, since SCIFIO is obviously much slower than the old native
> procedure.
Yes, this is expected at the moment. We first need to make it correct,
then we can make it fast. We do not want to cut corners so much that we
cannot open valid files, or worse, forget vital metadata. For example, if
you open an OME-TIFF, we want *all* of the metadata to be available to the
user.
> ImageJ native 110ms opening a file
> SCIFIO 3770ms opening the first file after Fiji launch
> SCIFIO 2960ms opening a file
>
> ImageJ native 235ms opening/saving a file
> SCIFIO 3110ms opening/saving a file
This is consistent with the tests I performed some time ago, but we
already have experimental code proving that we can improve the speed while
still retaining the flexibility and correctness of SCIFIO.
> I do not want to say that SCIFIO isn't a good choice, but it seems to be
> very important to be flexible and able to use the native way either.
For the moment, yes. With the help of reports such as yours, we will be
able to bring SCIFIO into a robust and fast shape. Then there will be no
good reason to use "the native" method.
> Maybe it could be possible to switch between those two methods via
> command, to have the best of both worlds.
No, that would just be confusing and error-prone: when maintaining two
divergent software project trying to do essentially the same, you will
always end up with more problems than if you focus on one effort.
SCIFIO is about much more than just opening .tif files saved by ImageJ
1.x (which are really the only files that are read correctly by the code
you referred to as "native" above). SCIFIO is a general, extensible way to
load scientific images.
It is very easy to extend it with your own file format reader/writer; you
do not have to change the SCIFIO library for that at all, just drop in the
new .jar file.
To keep ourselves honest, we did not build in any "fast" routes or
"special" formats: all formats are implemented using the exact same
interfaces, using the exact same plugin type. This is what software
developers call "eating your own dog food", and it is the best way to
ensure that an extensible framework is implemented correctly.
Thus, every enhancement we introduce to make, say, TIFF support more
correct, or faster, will benefit pretty much all the formats. And
certainly also all the formats implemented by third-parties.
We will make SCIFIO robust, then fast, then there is no need for the
switch you mentioned above.
Ciao,
Johannes
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html