[ome-devel] ScanR importer
Melissa Linkert
melissa at glencoesoftware.com
Fri Sep 10 20:57:33 BST 2010
Hi Rubén,
I'm sorry to hear that my changes have caused a problem. I have filed a ticket on our Trac:
http://www.dev.loci.wisc.edu/trac/java/ticket/554
And as usual, you have been CC'd on this ticket. Unfortunately, it will be a week or so before I will be able to fix it.
Regards,
-Melissa
-----Original Message-----
From: Rubén Muñoz <ruben.munoz at embl.de>
Date: Thu, 9 Sep 2010 13:53:04
To: Melissa Linkert<melissa at glencoesoftware.com>
Cc: <ome-devel at lists.openmicroscopy.org.uk>
Subject: Re: ScanR importer
H Melissa,
I just tested the latest trunk, the changes in ScanREader are working great.
However, the 1-big-ome.tif conversion: bfconvert plate_002/experiment_descriptor.xml test.ome.tif
seems to have some problem: during browsing (with Bioformats Importer) all the series look exactly the same...
Best regards,
Rubén
On Sep 6, 2010, at 8:12 PM, Melissa Linkert wrote:
> Hi Rubén,
>
> Thank you for uploading another dataset. r6890
> (http://dev.loci.wisc.edu/trac/java/changeset/6890) seems to handle that
> dataset properly, and does not cause problems with the other datasets
> that I have. If you could please verify that those changes work for
> you, I would appreciate it.
>
> Even with r6890, you will still see several extra wells with all black images. I have filed a ticket for this problem and CC'd you, but note that it will be a little over a week before I will be able to investigate the problem further. In case anyone else is interested, the ticket can be viewed here:
>
> http://dev.loci.wisc.edu/trac/java/ticket/550
>
> Regards,
> -Melissa
>
> On Mon, Sep 06, 2010 at 10:15:06AM +0200, Rubén Muñoz wrote:
>> Hi Melissa,
>>
>> On Sep 2, 2010, at 6:18 PM, Melissa Linkert wrote:
>>
>>> 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.
>>
>> My modifications in ScanrReader.java are not good enough, I do not exactly know to proceed.
>> I should give you information about the ScanR cDNA labels, they are only set for those wells selected for acquisition.
>>
>> Labels "A1 B1 B2" are a valid label set for a 8,96 & 384 well plates.
>> Sorry I do not know how to guess the layout of the plate (total columns and rows) in these cases. But I am after it.
>>
>> Please let me know if you have any question.
>>
>> Rubén
>>
>>>
>>>> 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.
>>
>> I recently uploaded scanRskippedWells.zip to your SFTP
>>
>>>
>>> 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