[ome-users] Flex File Format
Jason Swedlow
jason at lifesci.dundee.ac.uk
Tue May 5 15:28:58 BST 2009
Hi Ghislain and John-
On 3 May 2009, at 16:04, Ghislain Bonamy wrote:
> Hi Jason,
>
> Thanks for the feedback! Let me try to clarify a few points:
>
>
>>> Unfortunately the flex file format is not up to date in the
>>> bioformats, although some of the new metadata is handled. In
>>> particular, bioformats is unable to retrieve the number of fields/
>>> z-section/channels/time point, which is critical point.
>>>
>>
>>
>> Thanks for this feedback. This is news to us, as we correctly
>> report this metadata from the test files we have. If you have had
>> problems using Bio-Formats, the best thing to do is to send us
>> details, and if possible, the offending files, and we'll certainly
>> work to we fix any problems we find.
>>
>
>
> GB: What I meant here is that many new tags are supported; however
> some of the critical one are not correctly handled. I do not believe
> that that I am using any special files, but rather that the way to
> extract the number of z-sections, fields etc. has not been
> implemented. I talked about his with Melissa a few months ago, and
> perhaps we can take this discussion off-line with users interested
> in FLEX file reader improvements in bioformats.
>
Great-- we can discuss getting data and specs of what you need off-list.
>
>>> I was hoping to work on this and add this capacity to the format
>>> but have not had a chance to it. I have contacted P&E about maybe
>>> helping out since they are using Omro a base for their Columbus
>>> platform, but I don't think, oddly enough, that they are
>>> interested to help.
>>>
>>>
>>
>> On the contrary, PerkinElmer (I assume that is who you are
>> referring to) have been very helpful supplying test files. Again,
>> if you have files that might expose something we don't know about,
>> sending us specific details and the data is the best thing to do.
>>
>
>
> GB: Yes I was referring to PerkinElmer. I am glad to hear that they
> provided file examples, although I still hope that perhaps they will
> provide some actual coding/testing support to allow full handling of
> their FLEX file format. As mentioned above, I do not think that the
> flex files that I am using differ from the one they have provided. I
> believe it is more a matter of parsing out the full information
> contained in their metadata.
>
>
That's fine. PerkinElmer have been a great partner and provided lots
of feedback and advice. Off-list, we can discuss this. However, in
general, specifics are most handy-- version of software, file formats,
etc.
>
>>> Perhaps if enough customer request that they help improving
>>> bioformats they might do it.
As I said, they have already been quite helpful
>>> I will try to work on it soon and will keep the Opera users
>>> posted. Furthermore, a nice feature would be to be able to keep
>>> the metadata from the flex file in addition to the metadata from
>>> OME, so that the flex file remains backward compatible with the
>>> Epochal (becomes both an ome.tiff and remains a flex file). This
>>> feature which could be extended to all TIFF derivative format, may
>>> require some serious modifications of bioformats, but I will let
>>> the expert (i.e.. Jason) see what they can do about t.
>>>
>>
>>
>>
>> Can you explain why we should do this? Why doesn't the metadata in
>> OME-TIFF satisfy your needs? Note that we NEVER directly write
>> proprietary formats-- we have enough problems supporting reads of
>> all the variants. Writing as well would be a minefield, and more
>> importantly, breaks the whole concept of supporting interoperability.
>>
>
>
> GB: I am not suggesting writing a proprietary file format, although
> I see why it may sound like it. One of the limitations with using
> the OME-TIFF model is that the file becomes incompatible with the
> vendors tools. It seems that the format selected by P&E is very good
> in the sense that it builds on a format logic closely related to OME-
> TIFF. Thus, I though enabling creation of chimeric files could be
> useful for formats in which it can be implemented (manly with Tiff
> derivative formats). I wrote this in relation to importing files
> into OMERO, which was the purpose of the original thread. If Flex
> flex files can be converted as OME.TIFF, but retain the flex file
> characteristics (ie. flex extension + correct IFID), this would make
> it very convenient. I suppose that an easier (and perhaps better)
> alternative would be to generate an OME-TIFF file were the pixel
> data points to the flex file? Could this work and allow users to
> import there flex files into OMERO?
I can see the rationale for this-- from a user's standpoint. In my
own lab, we would use this with the proprietary files we use in our
own work. However, this approach is quite frankly, the opposite of
what we want to achieve in the long run. It does provide short-term
gain, but is sort of an interoperability hack. Inevitably, any
software package that wanted to update metadata would have to do it
twice, for both files, and read both files to ensure that it had up-to-
date metadata. That just seems messy.
However, your critical point-- the OME-TIFF file is incompatible with
vendors' tools. Above you mention repeatedly pressuring the vendors
to support a standardised library. Why not do the same with the file
format? In the 'conventional' microscopy community a number of
vendors support OME-TIFF read and write. Why not in HCAs?
Unfortunately, in OME, we have to take the long view. We have been
unremitting in pushing for true software interoperability. Part of
our strategy is try as hard as possible to provide data formats and
interfaces that are useful, as complete, functional, and well-
documented as possible, so that noone, vendors in particular, can
claim that there are parts missing that make our tools unusable. As
always, if such a blocker exists, we very much appreciate the
feedback-- we'll work hard to correct it.
Specifically, we can talk off-list about flex, and get that sorted
out. Once we establish what's missing and get it fixed, we can
announce to the list. In general, the major hurdle is getting the data.
>
>
>>> On another note bioformats does support the luraware compression,
>>> granted hat you provide a license code for it. Logic would suggest
>>> that a key would be required to compress with luraware but not to
>>> decompress to make the forma at least partially open. This however
>>> is not the case. Perhaps P&E should in my opinion provide such
>>> license code since the capacity of a user to read an image is
>>> obviously a inherent part of their system. However, this may not
>>> be part of the agreement they reach with Luraware. In the mean
>>> time, saving as uncompressed tiff is the better solution.
>>>
>>
>>
>> We can't comment on PerkinElmer's plans for file formats; we have
>> no knowledge of their plans and agreements and any discussions of
>> this with the community and users is up to them. We do however
>> agree that saving data in uncompressed form often leaves the user
>> with many more options for data handling and analysis.
>>
>
>
> GB: Agreed, just brought it up for users employing Luraware
> compression and hoping to get a response from people at P&E, to see
> if it would be feasible within their licensing agreement with
> Luraware to provide a license key to their Opera users. In
> particular for working with OMERO with compressed FLEX files.
>
> Let me know if my points remain unclear.
We very much appreciate your comments and feedback.
Cheers,
Jason
> _____________________________
>
> From: ome-users-bounces at lists.openmicroscopy.org.uk on behalf of
> John Moffat
> Sent: Fri 5/1/2009 11:40 PM
> To: ome-users at lists.openmicroscopy.org.uk
> Subject: [ome-users] Flex File Format
>
>
>
> Hi,
> I was just about to ask the exact same question as the previous
> poster. Since I'm not using the Lurawave compression (not worth the
> hassle, in my opinion), is there a way we can activate the
> PerkinElmer .flex format in the bioformats library?
>
> Does anyone know if the flex file bioformat is up to date with the
> newer (Acapella 2) version of the format? Either way, I'd like to test
> it.
>
> Thanks
> John
>
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>
>
>
>
>
> **************************
>
> Wellcome Trust Centre for Gene Regulation & Expression
>
> College of Life Sciences
>
> MSI/WTB/JBC Complex
>
> University of Dundee
>
> Dow Street
>
> Dundee DD1 5EH
>
> United Kingdom
>
>
>
> phone (01382) 385819
>
> Intl phone: 44 1382 385819
>
> FAX (01382) 388072
>
> email: jason at lifesci.dundee.ac.uk <mailto:jason at lifesci.dundee.ac.uk>
>
>
>
> Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/ <http://www.dundee.ac.uk/lifesciences/swedlow/
> >
>
> Open Microscopy Environment: http://openmicroscopy.org <http://openmicroscopy.org/
> >
>
> **************************
>
>
>
> The University of Dundee is a Scottish Registered Charity, No.
> SC015096.
>
>
>
>
>
>
>
>
>
**************************
Wellcome Trust Centre for Gene Regulation & Expression
College of Life Sciences
MSI/WTB/JBC Complex
University of Dundee
Dow Street
Dundee DD1 5EH
United Kingdom
phone (01382) 385819
Intl phone: 44 1382 385819
FAX (01382) 388072
email: jason at lifesci.dundee.ac.uk
Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
Open Microscopy Environment: http://openmicroscopy.org
**************************
The University of Dundee is a Scottish Registered Charity, No. SC015096.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20090505/dc489303/attachment.html>
More information about the ome-users
mailing list