[ome-devel] Storage format for 'fitted' parameter (FLIM) images?

[Munro, Ian]

Thanks Melissa 

I'd somehow got hold of the wrong idea.
How about floating-point .tif if I can work out how to write them?

Ian


On 13 Mar 2012, at 15:05, Melissa Linkert wrote:

> Hi Ian,
> 
>> I've finally managed to get back to looking at this  problem & in the absence of any feedback on here,
>> I've started looking at openEXR as an open floating-point  image format for holding processed parameter images.
>> 
>> As far as I can tell this is already compatible with bio-formats.
> 
> I can't speak to the suitability of OpenEXR for storing FLIM data, but
> do note that OpenEXR files are not currently supported in
> OMERO/Bio-Formats.  There are plans to support these files, as noted here:
> 
> http://trac.openmicroscopy.org.uk/ome/ticket/4125
> 
> ...but the work has not been done yet, and realistically will not be
> done until after the 4.4 release of OMERO/Bio-Formats.
> 
> Regards,
> -Melissa
> 
> On Tue, Mar 13, 2012 at 02:20:18PM +0000, Munro, Ian wrote:
>> Hi Again.
>> 
>> I've finally managed to get back to looking at this  problem & in the absence of any feedback on here,
>> I've started looking at openEXR as an open floating-point  image format for holding processed parameter images.
>> 
>> As far as I can tell this is already compatible with bio-formats.
>> 
>> Does anyone have any thoughts or objections?
>> 
>> Regards
>> 
>> 
>> Ian
>> 
>> 
>> On 22 Feb 2012, at 12:16,  wrote:
>> 
>>> HI all
>>> 
>>> At the recent Dundee meeting I described 3 categories of data required to make OMERO compatible with 
>>> fluorescence lifetime imaging  (FLIM).
>>> 
>>> 1) 'raw'  time-resolved intensity data		 (as acquired by the microscope)
>>> 2) fitted (floating point) parameter 'images'	(generated by fitting software)
>>> 3) merged RGB maps.					(for inclusion in papers etc)
>>> 
>>> Currently the 2nd type is stored as a .csv image by the fitting code that Donald has already included in OMERO.
>>> There is concern here over this for two reasons:
>>> 
>>> 1) iIt is inefficient  in terms of storage.
>>> 2) There will inevitably be a loss of precision.
>>> 
>>> Could we change to another format for this (assuming it isn't too late) ?
>>> If so what format?
>>> 
>>> Any thoughts welcome.
>>> 
>>> Regards
>>> 
>>> Ian
>> 
>> _______________________________________________
>> ome-devel mailing list
>> ome-devel at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel