[ome-devel] smart way to open a time series of one pixel?

Munro, Ian i.munro at imperial.ac.uk
Fri Feb 13 17:02:04 GMT 2015


Hi Heinrich.

Thanks for the tips. Much appreciated  I’ll look into the passing a pointer if I get a chance it’s certainly not obvious 
how to do that in Matlab.

Regards

Ian 



On 13 Feb 2015, at 16:56, Grabmayr, Heinrich <Heinrich.Grabmayr at ph.tum.de> wrote:

> Hi Ian,
> No your code is great. 
> One step that takes long for large image files is r.setID(). I guess this cannot be sped up because the reader may need to go through all planes to create the metadata (may depend on the file type?)
> Melissa suggested to get the data by handing openBytes a pointer to an array, so it doesn't need to be initialized for each call. You don't do that either, and I believe this is because it's against the philosophy in Matlab, so it is hard to do (a few google hits looked very complicated, so I left it). But if it is possible, I expect that your code could be sped up as well.
> 
> Concerning reshaping, as I only need to identify pixels at the moment, and not form an image, I can leave the image data as a 1D array instead of reshaping it to 2D. But I expect that this is different for you.
> Best, Heinrich
> 
>> -----Original Message-----
>> From: ome-devel [mailto:ome-devel-bounces at lists.openmicroscopy.org.uk]
>> On Behalf Of Munro, Ian
>> Sent: 13 February, 2015 11:44 AM
>> To: OME External Developer List
>> Subject: Re: [ome-devel] smart way to open a time series of one pixel?
>> 
>> Hi Heinrich
>> 
>> Sounds as if I was less helpful than I hoped. Ah well!
>> Are you saying that my code reshapes more than required as well ?
>> 
>> Ian
>> 
>> 
>> On 13 Feb 2015, at 16:36, Grabmayr, Heinrich
>> <Heinrich.Grabmayr at ph.tum.de> wrote:
>> 
>>> Hi Ian,
>>> 
>>> Sorry to get back to you that late. Thanks very much for your code. I tried
>> it, and its performance was sometimes slightly better, sometimes not;
>> depending on file size and how much to read out of each plane. One big
>> thing I noticed was that I was reshaping an array one time more than
>> necessary, and that helped to speed up the process to about 2/3 the time.
>>> 
>>> Cheers
>>>  Heinrich
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: ome-devel
>>>> [mailto:ome-devel-bounces at lists.openmicroscopy.org.uk]
>>>> On Behalf Of Munro, Ian
>>>> Sent: 6 February, 2015 5:44 PM
>>>> To: OME External Developer List
>>>> Subject: Re: [ome-devel] smart way to open a time series of one pixel?
>>>> 
>>>> Hi Heinrich
>>>> 
>>>> In my Matlab  code I am attempting to do something similiar (i.e.
>>>> load many planes as as fast as possible where I can assume that  each
>>>> plane is the same in terms of size etc).
>>>> My code to do this is at  https://github.com/openmicroscopy/Imperial-
>>>> FLIMfit/blob/master/FLIMfitFrontEnd/Classes/%40flim_data_series/load_
>>>> fli
>>>> m_cube.m.
>>>> (see around line 280)
>>>> 
>>>> This is based on the code form the  Matlab plug-in available for bio-
>> formats.
>>>> 
>>>> Regards
>>>> 
>>>> Ian
>>>> 
>>>> 
>>>> On 6 Feb 2015, at 22:29, Grabmayr, Heinrich
>>>> <Heinrich.Grabmayr at ph.tum.de> wrote:
>>>> 
>>>>> Hi Melissa,
>>>>> 
>>>>>>> I have huge movies (20k to 60k frames) in file formats from
>>>>>>> various camera suppliers that can all be opened using bioformats.
>>>>>>> I would like to access the time series of indivindual pixels. At
>>>>>>> the moment, I do this in matlab by using r = bfGetReader and then
>>>>>>> using the
>>>>>> loci.formats.ChannelSeparator's function to call
>>>>>> r.openBytes<http://downloads.openmicroscopy.org/bio-
>>>>>> 
>>>> 
>> formats/5.0.6/api/loci/formats/ChannelSeparator.html#openBytes%28int,
>>>>>> % 20int,%20int,%20int,%20int%29>(int no, int x, int y, int w, int
>>>>>> h) with w=h=1 and looping through all the planes. This takes ages.
>>>>>> I was wondering whether there might be a smarter way to access the
>>>>>> data I am interested in?
>>>>>> 
>>>>>> I would suggest starting by allocating a single buffer, and then
>>>>>> calling openBytes(int, byte[], int, int, int, int) repeatedly
>>>>>> instead of openBytes(int, int, int, int, int).  The latter will
>>>>>> allocate a new byte array to contain the
>>>>>> pixel(s) each time it is called; I would expect this to have a
>>>>>> noticeable performance impact when called thousands of times.
>>>>> 
>>>>> Thanks for this suggestion. Are you familiar with MATLAB, and how to
>>>> implement this? I have used the approach mentioned because I do not
>>>> know how to pass a reference to an array in matlab.
>>>>> 
>>>>> I investigated the timing just now:
>>>>> Using one call of openBytes(int, int, int, int, int) takes 0.175 ms.
>>>>> This call, and the necessary type casting to be able to store it
>>>>> into a matlab array takes 0.989 ms (although now I come to think
>>>>> about it,
>>>> maybe I should try typecasting the whole array after loading) Opening
>>>> the file using r=bfGetReader(id) takes 40ms And opening the file and
>>>> loading
>>>> 4000 frames take 16s. In this case (.fits file), an acquisition is
>>>> stored in 15 bunches of 2GB-files, so the whole data set is loaded
>>>> after 4 minutes. I do this for several data sets, and that is why I
>>>> say it takes very long. Broken down, these times do not seem to be
>>>> bad to me. Maybe I just have incredibly much data to load.
>>>>> While at the subject, the .cxd files are stored as single 30GB
>>>>> files. When I
>>>> load these, r=bfGetReader takes 5-10 minutes to call. Shouldn't the
>>>> metadata information from one plane be enough, so that the time to
>>>> get the reader wouldn|t  have to depend on the file siye?
>>>>> 
>>>>>> 
>>>>>> If reusing a single buffer doesn't help noticeably, it would be
>>>>>> helpful to know more about exactly which formats you are working
>>>>>> with, as well as roughly how long (in minutes) it takes to open all
>>>>>> of the
>>>> pixels.
>>>>> 
>>>>> I am using .fits files saved by the Andor software Solis, .cxd from
>>>> Hamamatsu LiveImage, and .pcoraw from PCO's CamWare.
>>>>> 
>>>>>> 
>>>>> Thanks,
>>>>>  Heinrich
>>>>> 
>>>>> _______________________________________________
>>>>> ome-devel mailing list
>>>>> ome-devel at lists.openmicroscopy.org.uk
>>>>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>>>> 
>>>> _______________________________________________
>>>> ome-devel mailing list
>>>> ome-devel at lists.openmicroscopy.org.uk
>>>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>>> _______________________________________________
>>> ome-devel mailing list
>>> ome-devel at lists.openmicroscopy.org.uk
>>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>> 
>> _______________________________________________
>> ome-devel mailing list
>> ome-devel at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel



More information about the ome-devel mailing list