[ome-devel] ScanR importer

Melissa Linkert melissa at glencoesoftware.com
Thu Sep 2 17:18:11 BST 2010


Hi Rubén,

> I have tested the current LSM Importer and it is doing fine with multi-position scans.

I'm glad to hear it.

> I have introduced some changes that work for us, but might be not adecuated. You will see that:
> 	- The wellRows has to be set, otherwise the uniqueRows may not be a good count in these cases. 
> 	- "timeloop count" is used to prevent the execution of nTimepoints = list.length / (nChannels * nWells * nPos * nSlices); 
> 	- next variable is always increased even when an image is not found

In principle, these changes look fine.  They are, however, causing a few
of the datasets that I have to throw exceptions during initialization.

> With all this I get lots of black images during conversion to multiple file OME-TIF. That's not perfect but they can be deleted afterwards.

I will have to think on how best to do it, but I think we can
change the ScanR reader to prevent this problem.

> Please permit me to upload one of these to the FTP with name "scanRskippedWells.zip", and let me know if I can help with something else.

Of course you may upload as much data as you like.  Once you have
uploaded the data, just let me know - I can then work on updating your
changes so that they work with all of the datasets that we have so far.

Regards,
-Melissa

On Thu, Sep 02, 2010 at 11:36:50AM +0200, Rubén Muñoz wrote:
> Hi Melissa,
> 
> I have tested the current LSM Importer and it is doing fine with multi-position scans.
> That will be incredibly useful here to create OME.TIFs, in combination with bfconvert.
> 
> I found some possible improvement for the ScanR importer.
> We have always provided with sets that have all the wells, but one of our users skipped some wells with the microscope.
> 
> That was not converting because of two things:
> 	- The loops iterated only until the number of real acquired wells nWells.
> 	- The tiff array was filled sequentially.
> 
> Therefore the imageName is calculated always sequentially.
> 
> I have introduced some changes that work for us, but might be not adecuated. You will see that:
> 	- The wellRows has to be set, otherwise the uniqueRows may not be a good count in these cases. 
> 	- "timeloop count" is used to prevent the execution of nTimepoints = list.length / (nChannels * nWells * nPos * nSlices); 
> 	- next variable is always increased even when an image is not found
> 
> With all this I get lots of black images during conversion to multiple file OME-TIF. That's not perfect but they can be deleted afterwards.
> 
> Please permit me to upload one of these to the FTP with name "scanRskippedWells.zip", and let me know if I can help with something else.
> 
> Best regards
> 
> Rubén
> 
> 
> diff bioformats/components/bio-formats/src/loci/formats/in/ScanrReader.java bioformats.ruben/components/bio-formats/src/loci/formats/in/ScanrReader.java 
> 300,301c300,306
> <     if (wellRows * wellColumns == 0) {
> <       if (wellCount <= 96) {
> ---
> >     //if (wellRows * wellColumns == 0) {
> >     // FIXME: Three only formats are enforced
> >       if (wellCount <= 8) {
> >         wellColumns = 2;
> >         wellRows = 4;
> >       }
> >       else if (wellCount <= 96) {
> 302a308
> >         wellRows = 8;
> 305a312
> >         wellRows = 8;
> 307,309c314,316
> <       wellRows = wellCount / wellColumns;
> <       if (wellRows * wellColumns < wellCount) wellRows++;
> <     }
> ---
> >       //wellRows = wellCount / wellColumns;
> >       //if (wellRows * wellColumns < wellCount) wellRows++;
> >     //}
> 318a326
> > 
> 365a374
> > 	else next++;
> 522a532,534
> >         else if (key.equals("timeloop count")) {
> >           core[0].sizeT = Integer.parseInt(value) + 1;
> >         }


More information about the ome-devel mailing list