sorting bug in ij.plugin.FolderOpener?

[Xavier Tizon]

Hi all,

There seems to be a bug in FolderOpener. I tried to import a sequence
of NEMA images (using File\Import\Image Sequence...), and I tested the
sorted versus non-sorted version of the returned file list (by
commenting the following line in FolderOpener and displaying the
result) :

list = sortFileList(list);

The two lists are different, which does not seem strange, but the
unsorted list is sorted according to conventions, and the sorted list
is not. Anybody seen this before?

Two important details: my file names are especially long, and they are
not all the same length. I noticed those 2 properties were tested in
the code, but I could not reproduce the problem with simpler file
names.

Thanks in advance for any help,


Xavier

[Albert Cardona]

Xavier,

I've noticed the same problem, and I know it has to do with how the
ij.plugin.FolderOpener sorts the file list whenever any of the file
names are not of equal length.

What the ij.plugin.FolderOpener does is to prepend zeros to the file
name whenever it is shorter than the longest file name, which then when
applying the ij.util.StringSorter, will result in very unexpected sortings.

I always work it around by either making special plugins that read the
listing numbers specifically in the file name, putting them in a
Hashtable and then sorting the table by its keys; or by copying
FolderOpener code, modifying the class name and modifying the
sortFileList method.

All this hassle could be easily solved by making the sortFileList method
public in ij.plugin.FolderOpener, which would allow to create very
simplified extended versions of this class.

Now if we ask Wayne very kindly ... :)


Albert

[Wayne Rasband]

> I've noticed the same problem, and I know it has to do with how the
> ij.plugin.FolderOpener sorts the file list whenever any of the file
> names are not of equal length.
>
> What the ij.plugin.FolderOpener does is to prepend zeros to the file
> name whenever it is shorter than the longest file name, which then
> when applying the ij.util.StringSorter, will result in very unexpected
> sortings.

File>Import>Image Sequence correctly sorts names of unequal length as
long is each name contains only one number. For example, the names

a14.jpg
aa202.jpg
aaa201.jpg
aaaaaa2.jpg

will be correctly sorted in numeric order. This works because ImageJ
prepends zeros only after removing all non-numeric characters. What it
can't handle is file names that are not of equal length and that also
contain more than one number. This is because the digits from all the
numbers in the name are combined to form a single number that is
sorted.

> I always work it around by either making special plugins that read the
> listing numbers specifically in the file name, putting them in a
> Hashtable and then sorting the table by its keys; or by copying
> FolderOpener code, modifying the class name and modifying the
> sortFileList method.
>
> All this hassle could be easily solved by making the sortFileList
> method public in ij.plugin.FolderOpener, which would allow to create
> very simplified extended versions of this class.

The sortFileList() method in the FolderOpener class is public in ImageJ
1.38.

-wayne

[Albert Cardona]

Wayne,

> will be correctly sorted in numeric order. This works because ImageJ
> prepends zeros only after removing all non-numeric characters. What it
> can't handle is file names that are not of equal length and that also
> contain more than one number. This is because the digits from all the
> numbers in the name are combined to form a single number that is sorted.

It would help if there was some automagic on: when more than numeric
chunk is detected in any of the file names, a Choice could be added to
the dialog which would ask for sorting by first numbers or last numbers.

In TrakEM2, for importing sequences as montages I have some such magic
but more manual: one has to specify, with 'd' characters, which part of
the name string is relevant to numbering.


> The sortFileList() method in the FolderOpener class is public in
> ImageJ 1.38.

Thank you!

Albert