Please see Suzanne Leif's and my posting on the ISAC web site and
R. C. Leif and S. B. Leif, "Evolution of Flow Cytometry Standard, FCS3.0,
into a DICOM-Compatible Format". Optical Diagnostics of Biological Fluids
and Advanced Techniques in Analytical Cytology, Ed. A. V. Priezzhev , T.
Asakura, and R. C. Leif. A. Katzir Series Editor, Progress Biomedical
Optics Series , SPIE Proceedings Series,Vol. 2982, pp 354-366 (1997).
Many of your very good suggestions were separately arrived at by us.
However, there are two separate subjects: 1) What should be included in a
Flow Cytometry File for Data Transfer and 2) The actual format for the Flow
Cytometry File for Data Transfer. We suggested switching to the Digital
Imaging and Communications in Medicine, DICOM, format after the year 2000.
My client Phoenix Flow has a product, QC-Tracker, which can be transformed
into a generic FCS reader, data storage system, and user programmable data
analysis system. Would you or others be interested in this type of product?
----------------------------------------------------------------------------
---------------------------------
At 03:35 PM 7/28/97 +0100, you wrote:
>
>As one of Jim Houston's "backyard" flow people (I actually do have a
>FACStar plus in my backyard- see advert in another message) who dabbles
>with programming, I would like to see a little less flexibility, and more
>standardisation in the standard. I believe that integer-based data files
>are the way to go, losing the ascii and floating point options (which I
>haven't seen implemented). I would also lose the multiple data-set file
>option, since this could be better handled by a separate database manager,
>or even by putting a group of files in a separate directory. I would
>implement a record/structure -based text section with only the mandatory
>keywords and their values (this could be made backwards-compatible by
>including the old delimiters) to overcome misinterpretation of the text
>section format by those implementing FCS software, and allowing readers to
>parse through errors (such as empty value fields) more readily; at the very
>least I'd make a standard delimiter. It would also speed things up parsing
>wise if there were three file types, one for each data mode with file type
>flagged in the header: eg FCS3.U, FCS3.C, FCS3.L for histogram, contour,
>and list data respectively, notice that this alternative naming wouldn't
>change the string length for the file type information, and if there is
>ever a revision of FCS 3, the fifth character could be used to denote it.
>Since the data are organised so differently in each of these types, and
>they are handled so differently, I think it's reasonable that these
>differences are flagged early in the parsing.
>
>I would put user-specified keywords in a section separate from the (now)
>structured text section, the analysis section would be ideal.
>
>The advantages of the above changes are that they are compatible with the
>proposed standard, but speed up and ease parsing (and writing) of the
>information that are needed to properly analyse the file. Using a
>structured text section removes ambiguity caused by a commentable delimiter
>(eg cytomation's empty values, BD's LYSYS allowing you type the delimiter
>into text fields). User-specific data would be written to a different
>section (the analysis part), where it can be found by those in the know.
>
>To avoid Swiftian confusion over byte order it may be worthwhile explicitly
>writing an integer constant (eg 1) into the text part, this would allow
>automatic detection of byte order, since if byte swapped it would be read
>incorrectly (eg as 256), an integer based on printable character values
>might be preffered.
>
>Mario roederer's wish list hasn't hit the forum yet, so it looks like this
>list may be the the easiest place for these discussions, that's why I've
>sent my message here, and it's where I'd prefer to see the discussion held.
>
>Ray
>
>(ME!ME!ME!- sorry about the egocentric nature of this letter)
>
>At 12:24 pm -0500 18/7/97, Jim Houston wrote:
>>I would like to see FCS3.0 left alone. There are many users in Flow who
>>have no idea what the capablilities of the FCS standard are or what it
>>does for them.
>>
>>I have seen the world of flow data stored differently by each vendor. Let
>>us not go back to that. FCS has served the flow world well.
>>
>>Let us also not forget the backyard flow persons who dabble at programming
>>on their spare time to make FCS work for them. Who share code and ideas.
>>Reformating FCS to meet specific clincal needs is a bit self centered for
>>those requesting that this be done. Those who have full time programmers
>>or those that sell products for data analysis are needed to help users,
>>not to dictate what they need.
>>
>>
>>Jim Houston
>
>
> Ray Hicks
>________________________________________________________________________
>|University of Cambridge |Tel 01223 330149 |
>|Department of Medicine |Fax 01223 336846 |
>|Level 5, Addenbrookes Hospital |e-mail <rh208@cus.cam.ac.uk> |
>|Hills Road Cambridge |Web http://facsmac.med.cam.ac.uk |
>|CB2 |ftp server ftp://131.111.80.78 |
>|UK | |
>|_________________________________|_____________________________________|
>
>
>
>