[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