RE: Phoenix software for Coulter analyser
From: Dan Smith (DJS@[EMAIL PROTECTED]
)
Date: Thu Jan 30 1997 - 16:48:00 EST
=95 Next message: Pizzo,Eugene: "FACSCalibur 4-color option"
=95 Previous message: Pete Macardle: "(no subject)"
=95 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Phoenix Flow's multiplus has worked very well in analyzing Profile II
data
for us.
Dan Smith
San Diego
----------
{From: owner-cyto-sendout
{To: Cytometry Mailing List
{Subject: Phoenix sofware for Coulter analyser
{Date: Thursday, January 30, 1997 4:28PM
{
{
{We are looking into software for good display and analysis of data.
{We use a coulter profile 2 analyser. Does anyone have experience with
{Phoenix MultiPlus analysis software, or could recommend any other
{software package for consideration?
{
{I would appreciate any advice.
{
{Stan.Stan Ress
{Clinical Immunology laboratory
{Dept of Medicine
{H47 Old main BLG,
{Groote Schuur Hospital,
{Observatory,
{Cape Town, South Africa
{7925
{
{e-mail: sress@[EMAIL PROTECTED]
Intern + 2721-4066201
{FAX : Intern + 2721-4486815
{
________________________________________
=95 Next message: Pizzo,Eugene: "FACSCalibur 4-color option"
=95 Previous message: Pete Macardle: "(no subject)"
=95 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:51 EST
From: Robert C. Leif, Ph.D. (rl...@[EMAIL PROTECTED]
)
Date: Tue Jul 29 1997 - 20:25:22 EST
* Next message: Vincent Falco: "Salary Survey Responses"
* Previous message: Maryalice Stetler-Stevenson: "Re: CD20
Gating"
* Maybe in reply to: Jim Houston: "Re: Re[2]: Leave FCS3.0
alone."
* Next in thread: Dave Coder: "Re: Re[2]: Is FCS3.0 obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ]
[ author ]
[ attachment ]
________________________________________
To: cyto-inbox
From: Bob Leif
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?
---------------------------------------------------------------------------=
=AD-
---------------------------------
At 03:35 PM 7/28/97 +0100, you wrote:
- Hide quoted text -
- Show quoted text -
>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 <rh...@[EMAIL PROTECTED]
> |
>|Hills Road Cambridge |Web http://facsmac.med.cam.ac.uk
|
>|CB2 |ftp server ftp://131.111.80.78 |
>|UK | |
>|_________________________________|_____________________________________|
________________________________________
* Next message: Vincent Falco: "Salary Survey Responses"
|
