[ome-devel] ScanR importer and well labels
Melissa Linkert
melissa at glencoesoftware.com
Thu Feb 2 18:05:54 GMT 2012
Hi Rubén,
> Thanks a lot, for your reply and the for ticket.
>
> I understand that the only way to determine the number of columns/rows in the ScanR dataset are the labels.
>
> However, regarding the users, theres the possibility of editing the labels in the system manually. It is unlikely but possible that someone would change the predefined formats.
>
> Would it be possible to sort by the label table ("well selection table")?
I don't see any problem in doing it that way. The ticket has been
updated accordingly.
Regards,
-Melissa
On Wed, Feb 01, 2012 at 11:29:30AM +0100, Rubén Muñoz wrote:
> Hi Melissa,
>
> Thanks a lot, for your reply and the for ticket.
>
> I understand that the only way to determine the number of columns/rows in the ScanR dataset are the labels.
>
> However, regarding the users, theres the possibility of editing the labels in the system manually. It is unlikely but possible that someone would change the predefined formats.
>
> Would it be possible to sort by the label table ("well selection table")?
>
> Otherwise as suggested,
>
> Thanks a lot,
>
> Rubén
>
> On Feb 1, 2012, at 2:56 AM, Melissa Linkert wrote:
>
> > Hi Rubén,
> >
> >> Using ScanR importer I found a more recent problem. The dataset I use has labels at the beginning off the file names (A1, A2, A3, ..., A10, A11, A12, B1, ...)
> >>
> >> I believe that your code sorts the images alphabetically at some point: (A1, A10, A11, A12, A2, ...)
> >>
> >> Please note that the following loop didn't work for that dataset. It expects the images to be in a different order, as it remembers the lastListIndex for the next cycle, assuming always increasing well index.
> >
> > As always, thanks for this. I can see this as well with one of the datasets
> > that you sent previously. While reverting to the old looping strategy does
> > work, the real culprit is line 365 of ScanrReader.java, which as you say does
> > an alphabetic sort of the file names. Changing how sorting is performed
> > (alphabetically by first character, then numerically by digits up until the
> > "--") should solve the problem and allow us to keep the more efficient loop
> > strategy.
> >
> > I haven't had quite enough coffee at the moment to reliably fix the
> > sorting, but I've filed a ticket here so that the problem will get sorted
> > out in the next few days:
> >
> > http://trac.openmicroscopy.org.uk/ome/ticket/7950
> >
> > Regards,
> > -Melissa
> >
> > On Mon, Jan 30, 2012 at 04:00:10PM +0100, Rubén Muñoz wrote:
> >> Dear Melissa, how are you?
> >>
> >> Using ScanR importer I found a more recent problem. The dataset I use has labels at the beginning off the file names (A1, A2, A3, ..., A10, A11, A12, B1, ...)
> >>
> >> I believe that your code sorts the images alphabetically at some point: (A1, A10, A11, A12, A2, ...)
> >>
> >> Please note that the following loop didn't work for that dataset. It expects the images to be in a different order, as it remembers the lastListIndex for the next cycle, assuming always increasing well index.
> >>
> >> 386 for (int c=0; c<nChannels; c++) {
> >> 387 for (int i=lastListIndex; i<list.length; i++) {
> >> 388 String file = list[i];
> >> 389 if (file.indexOf(wellPos) != -1 && file.indexOf(zPos) != -1 &&
> >> 390 file.indexOf(posPos) != -1 && file.indexOf(tPos) != -1 &&
> >> 391 file.indexOf(channelNames.get(c)) != -1)
> >> 392 {
> >> 393 tiffs[next++] = new Location(dir, file).getAbsolutePath();
> >> 394 if (c == nChannels - 1) {
> >> 395 lastListIndex = i;
> >> 396 }
> >> 397 break;
> >> 398 }
> >> 399 }
> >> 400 }
> >>
> >>
> >> Back in 4.1 the code was inefficient but worked fine in terms of construction of the tiff list.
> >>
> >>
> >> 309 for (int c=0; c<nChannels; c++) {
> >> 310 for (String file : list) {
> >> 311 if (file.indexOf(wellPos) != -1 && file.indexOf(zPos) != -1 &&
> >> 312 file.indexOf(posPos) != -1 && file.indexOf(tPos) != -1 &&
> >> 313 file.indexOf(channelNames.get(c)) != -1)
> >> 314 {
> >> 315 tiffs[next++] = new Location(dir, file).getAbsolutePath();
> >> 316 break;
> >> 317 }
> >> 318 }
> >> 319 }
> >>
> >> I have temporally fixed our copy using the upper loop, which is still inefficient for large datasets, it would be interesting to have a quicker importer though.
> >>
> >> Thaanks and best regards,
> >>
> >> Rubén Muñoz
>
More information about the ome-devel
mailing list