[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