Ex****ting figures from cell quest: how?
From: Murali Ramanathan (mur...@[EMAIL PROTECTED]
)
Date: Tue Mar 25 1997 - 21:25:07 EST
* Next message: Calin Tatu: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: Gregor Rothe: "Re: CD14 negative monocytes"
* Next in thread: Woo, Gary: "RE: Ex****ting figures from cell
quest:
how?"
* Maybe reply: Woo, Gary: "RE: Ex****ting figures from cell
quest:
how?"
* Maybe reply: Tom Frey: "Re: Ex****ting figures from cell quest:
how?"
* Maybe reply: Tom Frey: "Re[2]: Ex****ting figures from cell
quest:
how?"
* Maybe reply: vanburen
%flovax.dnet.wayne....@[EMAIL PROTECTED]
"Re: Ex****ting figures from cell quest: how?"
* Maybe reply: Todd A. Johnson: "Re: Ex****ting figures from cell
quest: how?"
* Maybe reply: Calman Prussin: "RE: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Hello everybody
I have had the same problem. If you want classy
graphics you have several options and none of
them are simple.
There are several freeware/shareware programs
that can read files created by Cell Quest.
FCS Assistant ($25 shareware for the Macintosh) can
read these files and convert them to ASCII.
You can then plot the data in the graphing program of
choice. I am not sure whether FCS assistant allows
you to save gated files. I havent used it much.
If you have a Windows machine, get WinMDI which
lets you save histograms in ASCII. It also can save
gated histograms and dot plots.
Both FCS Assistant and WinMDI can be accessed from
the U Mass flow cytometry software page.
http://www.bio.umass.edu/mcbfacs/flowcat.html
Another approach is to scan the plots
of interest and then use DataThief (Available from the
NIH Image site, I dont know the URL) to "steal" the
x-y coordinates. This is really useful if you dont
have acess to the original files and are stuck with
a lousy print out. Data Thief creates a text file that
can be read in any graphing program. This does not
work for dot plots.
Hope that helps
Regards
Murali Ramanathan
________________________________________
* Next message: Calin Tatu: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: Gregor Rothe: "Re: CD14 negative monocytes"
* Next in thread: Woo, Gary: "RE: Ex****ting figures from cell
quest:
how?"
* Maybe reply: Woo, Gary: "RE: Ex****ting figures from cell
quest:
how?"
* Maybe reply: Tom Frey: "Re: Ex****ting figures from cell quest:
how?"
* Maybe reply: Tom Frey: "Re[2]: Ex****ting figures from cell
quest:
how?"
* Maybe reply: vanburen
%flovax.dnet.wayne....@[EMAIL PROTECTED]
"Re: Ex****ting figures from cell quest: how?"
* Maybe reply: Todd A. Johnson: "Re: Ex****ting figures from cell
quest: how?"
* Maybe reply: Calman Prussin: "RE: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
RE: Ex****ting figures from cell quest: how?
From: Woo, Gary (g...@[EMAIL PROTECTED]
)
Date: Tue Mar 25 1997 - 16:42:06 EST
* Next message: Derek Davies: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: RICHARD L. DARLEY: "CD14 negative monocytes"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Tom Frey: "Re: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
hey al
we use power macs with system 7.5.1. pressing ****ft + apple key + 3
takes a picture of entire screen. file is saved on hard drive as
"picture 1". can view picture using simple text or ex****t to word
file
using "insert picture" command. hope this helps.
Gary Woo,
Amgen QC/AR flow lab
>----------
>From: Al Sabirsh
>Sent: Tuesday, March 25, 1997 13:25
>To: Cytometry Mailing List
>Subject: Ex****ting figures from cell quest: how?
>Hello to all,
>We would like to publish some figures/diagrams/pictures produced by Cell
>Quest on a power Mac. I tried printing them to a file (which
>subsequently prints out just fine) but nothing I have that can normally
>open postscript files (Photoshop, Canvas, Word etc.) will read them.
>Copying everything to the clipboard works, but there is a loss of
>resolution, particularly in the fonts, that requires lots of fiddly
>correction. So.....
>How is everybody else doing this? It seems ridiculous to have to
>reconstruct the figures manually. What am I missing? The list archive
>doesn't seem to contain any info on this.
>Al Sabirsh
________________________________________
* Next message: Derek Davies: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: RICHARD L. DARLEY: "CD14 negative monocytes"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Tom Frey: "Re: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Ex****ting figures from cell quest: how?
From: Tom Frey (Tom_F...@[EMAIL PROTECTED]
)
Date: Tue Mar 25 1997 - 20:23:37 EST
* Next message: Chris Worth: "Is there a source?"
* Previous message: Calin Tatu: "Re: Ex****ting figures from cell
quest: how?"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Tom Frey: "Re[2]: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Alan,
What you can do is the following: just type command-****ft-3 and you
will
here the sound of a snap shot of your desktop. An image of your
destop
will be saved probably as a file called picture in your hard drive.
You can open this file with SimpleText and use regular cut and paste
part
of this picture to any software, or you open it with any
graphic/multimedia software where you can invert the black background
of
your plots to white and do any other modification.
Good Luck,
Christian
On Tue, 25 Mar 1997, Al Sabirsh wrote:
> Hello to all,
> We would like to publish some figures/diagrams/pictures produced by Cell
> Quest on a power Mac. I tried printing them to a file (which
> subsequently prints out just fine) but nothing I have that can normally
> open postscript files (Photoshop, Canvas, Word etc.) will read them.
> Copying everything to the clipboard works, but there is a loss of
> resolution, particularly in the fonts, that requires lots of fiddly
> correction. So.....
> How is everybody else doing this? It seems ridiculous to have to
> reconstruct the figures manually. What am I missing? The list archive
> doesn't seem to contain any info on this.
> Al Sabirsh
A method that I have found useful for high quality graphics from
CellQuest is to
generate a figure that is two-fold or more larger (in all dimensions)
than the
final output that I intend. (Remember to increase the point size for
the text
of the plots and any free text.) You can then print at 50% or cut and
paste and
then either adjust the size or print at 50% in the new application.
This has the effect of smoothing text and of decreasing the size of
the dots in
dot plots. Note that sufficiently smoother text can sometimes be
obtained
merely by changing point size or selecting bold.
One other warning about this trick - the finer dots don't project very
well and
I therefore don't recommend it for slides!
Tom_F...@[EMAIL PROTECTED]
Next message: Chris Worth: "Is there a source?"
* Previous message: Calin Tatu: "Re: Ex****ting figures from cell
quest: how?"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Tom Frey: "Re[2]: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re[2]: Ex****ting figures from cell quest: how?
From: Tom Frey (Tom_F...@[EMAIL PROTECTED]
)
Date: Wed Mar 26 1997 - 17:04:24 EST
* Next message: Christine OConnell: "job posting"
* Previous message: Chris Worth: "Is there a source?"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: vanburen
%flovax.dnet.wayne....@[EMAIL PROTECTED]
"Re: Ex****ting figures from cell quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Something peculiar happened to my previous post, and I am not sure
whether the
following was actually received by other readers. What I had intended
to say
was:
A method that I have found useful for high quality graphics from
CellQuest is to
generate a figure that is two-fold or more larger (in all dimensions)
than the
final output that I intend. (Remember to increase the point size for
the text
of the plots and any free text.) You can then print at 50% or cut and
paste and
then either adjust the size or print at 50% in the new application.
This has the effect of smoothing text and of decreasing the size of
the dots in
dot plots. Note that sufficiently smoother text can sometimes be
obtained
merely by changing point size or selecting bold.
One other warning about this trick - the finer dots don't project very
well and
I therefore don't recommend it for slides!
Apologies for any repetition.
Tom_F...@[EMAIL PROTECTED]
Next message: Christine OConnell: "job posting"
* Previous message: Chris Worth: "Is there a source?"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: vanburen
%flovax.dnet.wayne....@[EMAIL PROTECTED]
"Re: Ex****ting figures from cell quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Ex****ting figures from cell quest: how?
From: vanburen%flovax.dnet.wayne....@[EMAIL PROTECTED]
Wed Mar 26 1997 - 19:12:40 EST
* Next message: Todd A. Johnson: "Re: Ex****ting figures from
cell
quest: how?"
* Previous message: Tom Mc Closkey: "summary-best long term data
storage"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Todd A. Johnson: "Re: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
With regards to the several layers of PICTs (bitmaps) used to
represent a
dot plot from CellQUEST, I believe that each PICT represents a
different
percentage of cells. This would allow CellQUEST to quickly display,
for
example, 10% of cells, and then switch to 50% of cells, without re-
reading
the FCS file.
With Canvas 3.5, you can combine these layers into a single PICT,
saving
disk space and redraw time. I think you select all the layers, then
select
Object Specs and check Convert to Paint Object. Use 1-bit for black-
and-
white plots, and 8-bit for color plots.
Also with Canvas 3.5, you can improve the PICT resolution, from the
standard 72dpi to at least 300dpi (the resolution of most contem****ary
printers). For the PICTs, select Object Specs, then select (for
example)
300 from the pop-up menu next to DPI. Answer the "maintain size"
dialog
by clicking on No.
The PICT will be approximately 4-times smaller, so make sure to start
with a bigger PICT in CellQUEST. There is no advantage to changing the
resolution if you click Yes to maintain size; in fact, you will just
be
using more disk/RAM space.
Personally, I edit each plot separately. Most investigators don't
request
that many plots for presentation/publication, so I don't feel it is
all
that time consuming. I too use CellQUEST to draw one plot at a time
for
this purpose, the same as Roger mentioned. After all, CellQUEST is NOT
a graphics manipulation program, it is a flow cytometry analysis
program,
and lacks certain things I find im****tant, such as rulers and
positioning
options. CellQUEST is fine for analysis, but I prefer Canvas for
graphics.
/\/\/\_ Eric Van Buren, vanburen%flovax.d...@[EMAIL PROTECTED]
\ \ Karmanos Cancer Institute and Immunology & Microbiology
\_^_/ Wayne State University, Detroit, Michigan
________________________________________
* Next message: Todd A. Johnson: "Re: Ex****ting figures from
cell
quest: how?"
* Previous message: Tom Mc Closkey: "summary-best long term data
storage"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Todd A. Johnson: "Re: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Ex****ting figures from cell quest: how?
From: Todd A. Johnson (tajohn...@[EMAIL PROTECTED]
)
Date: Wed Mar 26 1997 - 19:59:17 EST
* Next message: Adrian Smith: "Re: Ex****ting figures from cell
quest"
* Previous message: vanburen
%flovax.dnet.wayne....@[EMAIL PROTECTED]
"Re: Ex****ting figures
from cell quest: how?"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Calman Prussin: "RE: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
In response to Al's query:
I've used the routine of copying and pasting dot plots and contour
plots
into graphics programs like Photoshop, but I've developed a different
technique for getting histograms into publishable quality.
There's a shareware program from Sumex-AIM (a share/freeware MAC site)
called DataThief. The latest version is 2.0, although I seem to have
better luck with version 1.0.8. The purpose of this program is to
take a
PICT file of a graph and convert the line graph into X,Y coordinates
that
are then saved into a tab-delimited file format. Once you have each
of
your single color histograms in this format, it's easy enough to use
Excel
or CricketGraphIII to make nice, publication quality plots. Your
plots can
be overlayed, as in the case of negative and positive populations, and
now
that your plot's in a graphing program, you can do anything you want
with
the axis labels, titles, legends, etc.
Some Tips:
1) Make your plot in CellQuest as large as possible. I think
histograms
come out better with a little smoothing (about 5). The larger it is,
the
more points there will be to ex****t (this is also true when copying
dot and
contour plots into your graphics programs). Generally I make the
do***ent
size 2 pages wide and use the whole area for the plot. I use the Cell
Quest zoom feature to make the actual histogram take up as much of the
plot
as possible.
2) Copy the plot and paste into PhotoShop. Where the graph line
intersects the axis, you will probably have to erase the x-axis on the
right side. The auto-trace feature in Datathief will follow the
lowest
path, so if your line hits the axis, your data from there on out will
be
just that, zero...
3) Select AutoTrace from the righthand DT menu. In file options
deselect
"Include Headers." (if its on it puts some notations on the top of the
ex****ted data that you don't really need.) In Trace options, make the
trace height around 50. If you're histogram has very steep and long
****tions, you might have to increase this number. Select for a
logarithmic
X-axis after you've entered X-min,X-max, Y-min,Y-max.
4) When making your graph in your graphing program, choose the x-axis
to
be logarithmic, or else it will look strange.
If you play around with all of this, you should come out with some
excellent looking graphs. The one last difficult step is if you want
one
histogram, say a negative sample, to be a grey shade, and the other
one
shaded white. There must be a graphing program that does this,
perhaps
DeltaGraph or SigmaPlot, but I'm so familiar with CricketGraphIII,
that I
use that program preferentially. If I want shading, I copy the plot
that
I've made in CGIII and paste it into Canvas. The ungrouped plot in
canvas
consists of 1)blocks of text, 2) the axes and tick marks, and 3) the
plot
line - as a series of short, connected lines (essentially a
multifacetted
polygon.) To shade an area in Canvas, that area has to be completely
enclosed by a line, so you have to edit one of the end points and
connect
it with the other (since the axis is ex****ted separately.) A little
time
consuming, but the final product comes out very nice.
I hope this helps. I wish it didn't consume so much time but when we
used
the HP with Lysis and the paintjet printer, I used to scan in the
printed
histogram, so at least I've eliminated a step.
Todd A. Johnson
UC San Diego, School of Medicine
tajohn...@[EMAIL PROTECTED]
>I have used the same technique that Derek describes, of copying the plot
to
>the clipboard and pasting into a drawing program. I totally agree that BD
>needs to add an ex****t function to CQ, one that allows ex****t as PICT,
>TIFF, or other formats.
>When the plot is pasted into another program, it is a bit-mapped image,
>with several layers grouped. One consequence of bit-mapping is all text
>prints poorly, like using a dot-matrix printer. For publications and
>slides, I have edited those out and added my own labels to the axes.
>To do that, one must first ungroup the figure (I use programs like Canvas
>and ClarisDraw, but others are likely to work, as well). I was
immediately
>surprised to learn that the axes and labels are in one layer and the data
>(dots or contours) are in several other layers, apparently corresponding
to
>"cuts" in the data. So, for a contour plot, there is one layer that
>includes all contours, another that includes all but the inner contours,
>another that includes all but the inner 2 contours, ad nauseum. One way
to
>speed up printing, is to send the top layer, that includes all data
>(contours or dots), to the back, then delete all other layers. (As I
>recall, the axes and labels are the top layer, so that must also be sent
to
>the back, even to be able to select the various layers of dots or
contours.)
>I echo Derek's recommendation of "getting the plots into as near the
>finished article as possible before ex****ting." Because the pasted figure
>is bit-mapped, any resizing will increase the size of dots or thickness
of
>lines. It will look ugly. When I want to group several histograms for
>ex****t, I use a single plot in CQ, that I have adjusted to the final size
>that I want. Then I load the data for each sample into the same plot, to
>assure that all plots will be the same size in the finished version.
>Also, I would note a common error the I make is to select the plot
>incorrectly when copying. If you click on the plot, not on the border
>around the plot, the copy command is not active. I have been surprised at
>times, when I thought I copied a plot, then pasted something altogether
>different into my drawing program.
>Hopefully, BD will implement a better way in a future release.
>Roger
>>Hello there,
>>I have had a lot of trouble with this very problem. It does seem
>>ridiculous that there isnt the facility for ex****ting CQ do***ents as a
>>graphical format.
>>Using the clipboard is fine as long as the program you want is on the
same
>>computer and you have time to play with it etc. The approach I am using
is
>>to use an intermediary program to dump the CQ graphics in and then save
as
>>a PICT file.
>>I am using a shareware program called Graphic Converter which is
>>obtainable from the Info-Mac archives at Sumex. The location (off the
top
>>of my head) is:
>>gst/grf/graphic-converter-25.hqx
>>This enables one to paste the dot-plots, histograms or WHY into a
do***ent
>>which can then be saved in any number of commonly used graphical formats
>>eg BMP, GIF, JPG, PICT and TIFF. As far as Im aware, most common
programs
>>used to generate slides such as Photoshop, PowerPoint, Claris and Word
can
>>read PICT files so that is what I normally recommend (I believe filesize
>>is smaller as well).
>>Even so, I would still recommend getting the plots into as near the
>>finished article as possible before ex****ting.
>>Hope this is of some help, but if anyone is using a different approach
I'm
>>sure we'd all be happy to hear about it.
>>Derek
________________________________________
* Next message: Adrian Smith: "Re: Ex****ting figures from cell
quest"
* Previous message: vanburen
%flovax.dnet.wayne....@[EMAIL PROTECTED]
"Re: Ex****ting figures
from cell quest: how?"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Next in thread: Calman Prussin: "RE: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
RE: Ex****ting figures from cell quest: how?
From: Calman Prussin (CPRUS...@[EMAIL PROTECTED]
)
Date: Wed Mar 26 1997 - 12:43:52 EST
* Next message: Calman Prussin: "RE: Ex****ting figures from cell
quest"
* Previous message: Neal Benson: "Re: HP 340 Networks"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
I'm not sure what the resolution of a screen dump (command-****ft-3),
but I suspect it could be a problem in some situations. I simply copy
(command-C) from CellQuest and paste (command-V) into Canvas. I have
not noticed a problem with the label fonts, but I replace them with
more publication appropriate axis labels anyhow.
Below are the Cellquest 3 to Canvas 5 tips I keep to remind myself.
CANVAS 5, RULES OF ENGAGEMENT
1. Allot as much RAM as possible to both Canvas and Cellquest (>12 MB
each)
2. Breath slowly and repeat "This is only a program, it is not
my enemy".
3. Select a dotplot in CellQuest.
4. Copy in CellQuest,
Paste into Canvas.
5. Ungroup dotplot and using the eraser, remove any
axis markers you wish.
6. Dot Plots consist of a number of grouped
components (dots, plot frame, markers).
One of those is a white rectangle. Ungroup the dotplot and remove the
white rectangle, as it often interferes. Regroup.
7. Any color
changes (i.e. red subpopulation) need to done in CellQuest.
8. Don't
rescale dot plots after pasting in from CellQuest.
9. Expect color to
take more time and frustration than B/W.
Good luck,
Calman
----------
From: Al Sabirsh
Sent: Tuesday, March 25, 1997 8:25 AM
To: cyto-inbox
Subject: Ex****ting figures from cell quest: how?
Hello to all,
We would like to publish some figures/diagrams/pictures produced by
Cell
Quest on a power Mac. I tried printing them to a file (which
subsequently prints out just fine) but nothing I have that can
normally
open postscript files (Photoshop, Canvas, Word etc.) will read them.
Copying everything to the clipboard works, but there is a loss of
resolution, particularly in the fonts, that requires lots of fiddly
correction. So.....
How is everybody else doing this? It seems ridiculous to have to
reconstruct the figures manually. What am I missing? The list
archive
doesn't seem to contain any info on this.
Al Sabirsh
________________________________________
* Next message: Calman Prussin: "RE: Ex****ting figures from cell
quest"
* Previous message: Neal Benson: "Re: HP 340 Networks"
* Maybe in reply to: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Ex****ting figures from cell quest: how?
From: Derek Davies (dav...@[EMAIL PROTECTED]
)
Date: Tue Mar 25 1997 - 13:03:39 EST
* Next message: Deborah Berglund: "Anti-FAK and Anti-VIN"
* Previous message: Woo, Gary: "RE: Ex****ting figures from cell
quest:
how?"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Next in thread: Roger Smith: "Re: Ex****ting figures from cell
quest:
how?"
* Reply: Roger Smith: "Re: Ex****ting figures from cell quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Hello there,
I have had a lot of trouble with this very problem. It does seem
ridiculous that there isnt the facility for ex****ting CQ do***ents as
a
graphical format.
Using the clipboard is fine as long as the program you want is on the
same
computer and you have time to play with it etc. The approach I am
using is
to use an intermediary program to dump the CQ graphics in and then
save as
a PICT file.
I am using a shareware program called Graphic Converter which is
obtainable from the Info-Mac archives at Sumex. The location (off the
top
of my head) is:
gst/grf/graphic-converter-25.hqx
This enables one to paste the dot-plots, histograms or WHY into a
do***ent
which can then be saved in any number of commonly used graphical
formats
eg BMP, GIF, JPG, PICT and TIFF. As far as Im aware, most common
programs
used to generate slides such as Photoshop, PowerPoint, Claris and Word
can
read PICT files so that is what I normally recommend (I believe
filesize
is smaller as well).
Even so, I would still recommend getting the plots into as near the
finished article as possible before ex****ting.
Hope this is of some help, but if anyone is using a different approach
I'm
sure we'd all be happy to hear about it.
Derek
****************************************************************************
* Derek Davies Voice: (44) 0171 269
3394 *
* FACS Laboratory, FAX: (44) 0171 269
3100 *
* Imperial Cancer Research Fund, e_mail:
derek.dav...@[EMAIL PROTECTED]
*
* London,
UK *
*
*
* Web Page: http://www.icnet.uk/axp/facs/davies/index.html
*
****************************************************************************
On Tue, 25 Mar 1997, Al Sabirsh wrote:
> Hello to all,
> We would like to publish some figures/diagrams/pictures produced by Cell
> Quest on a power Mac. I tried printing them to a file (which
> subsequently prints out just fine) but nothing I have that can normally
> open postscript files (Photoshop, Canvas, Word etc.) will read them.
> Copying everything to the clipboard works, but there is a loss of
> resolution, particularly in the fonts, that requires lots of fiddly
> correction. So.....
> How is everybody else doing this? It seems ridiculous to have to
> reconstruct the figures manually. What am I missing? The list archive
> doesn't seem to contain any info on this.
> Al Sabirsh
________________________________________
* Next message: Deborah Berglund: "Anti-FAK and Anti-VIN"
* Previous message: Woo, Gary: "RE: Ex****ting figures from cell
quest:
how?"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Next in thread: Roger Smith: "Re: Ex****ting figures from cell
quest:
how?"
* Reply: Roger Smith: "Re: Ex****ting figures from cell quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Ex****ting figures from cell quest: how?
From: Roger Smith (rosm...@[EMAIL PROTECTED]
)
Date: Wed Mar 26 1997 - 08:19:37 EST
* Next message: Jorge Neumann: "Re: normal CD4 counts -Reply"
* Previous message: Matthias Haury: "Re: Ex****ting figures from
cell
quest: how?"
* In reply to: Derek Davies: "Re: Ex****ting figures from cell
quest:
how?"
* Next in thread: Christian Awaraji: "Re: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
I have used the same technique that Derek describes, of copying the
plot to
the clipboard and pasting into a drawing program. I totally agree that
BD
needs to add an ex****t function to CQ, one that allows ex****t as PICT,
TIFF, or other formats.
When the plot is pasted into another program, it is a bit-mapped
image,
with several layers grouped. One consequence of bit-mapping is all
text
prints poorly, like using a dot-matrix printer. For publications and
slides, I have edited those out and added my own labels to the axes.
To do that, one must first ungroup the figure (I use programs like
Canvas
and ClarisDraw, but others are likely to work, as well). I was
immediately
surprised to learn that the axes and labels are in one layer and the
data
(dots or contours) are in several other layers, apparently
corresponding to
"cuts" in the data. So, for a contour plot, there is one layer that
includes all contours, another that includes all but the inner
contours,
another that includes all but the inner 2 contours, ad nauseum. One
way to
speed up printing, is to send the top layer, that includes all data
(contours or dots), to the back, then delete all other layers. (As I
recall, the axes and labels are the top layer, so that must also be
sent to
the back, even to be able to select the various layers of dots or
contours.)
I echo Derek's recommendation of "getting the plots into as near the
finished article as possible before ex****ting." Because the pasted
figure
is bit-mapped, any resizing will increase the size of dots or
thickness of
lines. It will look ugly. When I want to group several histograms for
ex****t, I use a single plot in CQ, that I have adjusted to the final
size
that I want. Then I load the data for each sample into the same plot,
to
assure that all plots will be the same size in the finished version.
Also, I would note a common error the I make is to select the plot
incorrectly when copying. If you click on the plot, not on the border
around the plot, the copy command is not active. I have been surprised
at
times, when I thought I copied a plot, then pasted something
altogether
different into my drawing program.
Hopefully, BD will implement a better way in a future release.
Roger
>Hello there,
>I have had a lot of trouble with this very problem. It does seem
>ridiculous that there isnt the facility for ex****ting CQ do***ents as a
>graphical format.
>Using the clipboard is fine as long as the program you want is on the
same
>computer and you have time to play with it etc. The approach I am using
is
>to use an intermediary program to dump the CQ graphics in and then save
as
>a PICT file.
>I am using a shareware program called Graphic Converter which is
>obtainable from the Info-Mac archives at Sumex. The location (off the top
>of my head) is:
>gst/grf/graphic-converter-25.hqx
>This enables one to paste the dot-plots, histograms or WHY into a
do***ent
>which can then be saved in any number of commonly used graphical formats
>eg BMP, GIF, JPG, PICT and TIFF. As far as Im aware, most common programs
>used to generate slides such as Photoshop, PowerPoint, Claris and Word
can
>read PICT files so that is what I normally recommend (I believe filesize
>is smaller as well).
>Even so, I would still recommend getting the plots into as near the
>finished article as possible before ex****ting.
>Hope this is of some help, but if anyone is using a different approach
I'm
>sure we'd all be happy to hear about it.
>Derek
________________________________________
* Next message: Jorge Neumann: "Re: normal CD4 counts -Reply"
* Previous message: Matthias Haury: "Re: Ex****ting figures from
cell
quest: how?"
* In reply to: Derek Davies: "Re: Ex****ting figures from cell
quest:
how?"
* Next in thread: Christian Awaraji: "Re: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Ex****ting figures from cell quest: how?
From: Christian Awaraji (c...@[EMAIL PROTECTED]
)
Date: Tue Mar 25 1997 - 11:10:32 EST
* Next message: Ronald L. Rabin, M.D.: "CD14 neg monocytes"
* Previous message: Sue DeMaggio: "Putting a message on the
listserv"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Next in thread: Matthias Haury: "Re: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Alan,
What you can do is the following: just type command-****ft-3 and you
will
here the sound of a snap shot of your desktop. An image of your
destop
will be saved probably as a file called picture in your hard drive.
You can open this file with SimpleText and use regular cut and paste
part
of this picture to any software, or you open it with any
graphic/multimedia software where you can invert the black background
of
your plots to white and do any other modification.
Good Luck,
Christian
On Tue, 25 Mar 1997, Al Sabirsh wrote:
> Hello to all,
> We would like to publish some figures/diagrams/pictures produced by Cell
> Quest on a power Mac. I tried printing them to a file (which
> subsequently prints out just fine) but nothing I have that can normally
> open postscript files (Photoshop, Canvas, Word etc.) will read them.
> Copying everything to the clipboard works, but there is a loss of
> resolution, particularly in the fonts, that requires lots of fiddly
> correction. So.....
> How is everybody else doing this? It seems ridiculous to have to
> reconstruct the figures manually. What am I missing? The list archive
> doesn't seem to contain any info on this.
> Al Sabirsh
________________________________________
* Next message: Ronald L. Rabin, M.D.: "CD14 neg monocytes"
* Previous message: Sue DeMaggio: "Putting a message on the
listserv"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Next in thread: Matthias Haury: "Re: Ex****ting figures from
cell
quest: how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Ex****ting figures from cell quest: how?
From: Matthias Haury (mha...@[EMAIL PROTECTED]
)
Date: Wed Mar 26 1997 - 04:04:06 EST
* Next message: Roger Smith: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: Ayala Sharp: "Double staining-
Intracellular"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Next in thread: Calin Tatu: "Re: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Al,
Talking about Cellquest 3.xx. you don't need to make screen shots of
your
graphs, you can just copy-paste them in any PICT format accepting
program
(Canvas, Claris Draw etc), the only thing you have to do, is put the
plots
to the right size in Cellquest first. You only loose resolution if you
start changing the size of your plots in the drawing program (the
plots are
copied as bitmaps).
I agree (and have told this already several times to BDIS) however,
that
it's ridiculus that they don't ex****t the textparts in editable format
(so
you can just change the labels etc in the drawing program), also if
you
ungroup the plot in Canvas you get several layers of dots... which is
very
bizarre.
But you don't need to make screenshots, as they don't give you any
higher
resolution either (72 dpi max and you can't change the size
afterwards
either).
Hope that clarifies things a bit.
Cheers,
Matthias
_____________________________________________________________________________
Matthias Haury Flowcytometry Dept Immunology Institut
Pasteur
mha...@[EMAIL PROTECTED]
Tel: 33 (01) 40 61 31 29 Fax: 33 (01) 45
68 86 39
_____________________________________________________________________________
>Hello to all,
>We would like to publish some figures/diagrams/pictures produced by Cell
>Quest on a power Mac. I tried printing them to a file (which
>subsequently prints out just fine) but nothing I have that can normally
>open postscript files (Photoshop, Canvas, Word etc.) will read them.
>Copying everything to the clipboard works, but there is a loss of
>resolution, particularly in the fonts, that requires lots of fiddly
>correction. So.....
>How is everybody else doing this? It seems ridiculous to have to
>reconstruct the figures manually. What am I missing? The list archive
>doesn't seem to contain any info on this.
>Al Sabirsh
________________________________________
* Next message: Roger Smith: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: Ayala Sharp: "Double staining-
Intracellular"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Next in thread: Calin Tatu: "Re: Ex****ting figures from cell
quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
\Re: Ex****ting figures from cell quest: how?
From: Calin Tatu (c...@[EMAIL PROTECTED]
)
Date: Tue Mar 25 1997 - 20:16:07 EST
* Next message: Tom Frey: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Maybe you should try to download the GhostScript viewer and
interpreter for Mac, which is freely available at:
ftp://ftp.cs.wisc.edu/pub/ghost/aladdin/mac
At least on PCs, GhostScript deals just fine with images,
calin
Calin Tatu
Dept. of Microbiology & Immunology
University of North Carolina
CB#7290 602 FLOB
Chapel Hill, NC 27599-7290
Phone: 919-966-3131
FAX: 919-962-8103
c...@[EMAIL PROTECTED]
Next message: Tom Frey: "Re: Ex****ting figures from cell
quest:
how?"
* Previous message: Murali Ramanathan: "Ex****ting figures from
cell
quest: how?"
* In reply to: Al Sabirsh: "Ex****ting figures from cell quest:
how?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Why WinList?
From: Abby Allen (al...@[EMAIL PROTECTED]
)
Date: Tue Mar 18 1997 - 15:25:02 EST
* Next message: Vadim Chromiak: "B.D.I.S. Home Page"
* Previous message: Maryalice Stetler-Stevenson: "(no subject)"
* Next in thread: Larry Seamer (CYTOM): "Re: Why WinList?"
* Reply: Larry Seamer (CYTOM): "Re: Why WinList?"
* Maybe reply: Tom Mc Closkey: "RE: Why WinList?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Hello everyone!
My boss just returned from a cytometry meeting where she was
sufficiently impressed with Verity Software's WinList software.
Currently, I am using Cellquest and Elite software. What is it about
WinList that would impress my boss over Cellquest and the Elite
software. What special features does it have and do I need it?
Once again, I appreciate your insight, information, etc.
Thankyou!
Abby
--
**********************************************************************
Abby Allen
Center for Blood Research
800 Huntington Ave.
Boston, MA 02115
al...@[EMAIL PROTECTED]
Next message: Vadim Chromiak: "B.D.I.S. Home Page"
* Previous message: Maryalice Stetler-Stevenson: "(no subject)"
* Next in thread: Larry Seamer (CYTOM): "Re: Why WinList?"
* Reply: Larry Seamer (CYTOM): "Re: Why WinList?"
* Maybe reply: Tom Mc Closkey: "RE: Why WinList?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Re: Why WinList?
From: Larry Seamer (CYTOM) (LSEA...@[EMAIL PROTECTED]
)
Date: Wed Mar 19 1997 - 03:31:22 EST
* Next message: Laborator Citometrie: "RE: FTP "reget" option"
* Previous message: Mario Roederer: "Re: viral inactivation"
* In reply to: Abby Allen: "Why WinList?"
* Next in thread: Tom Mc Closkey: "RE: Why WinList?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
In reply to your question:
I have no experience CellQuest. But I do have experience with ELITE
software and WinList. My experience with the ELITE software is with
the
standard DOS version. With the caveat that 3rd party ELITE
for Windows software exists. And, I understand, Coulter is readying
their
own version of the software for Windows 3.1 or '95, I will share my
views.
In general there are 3 major reasons to choose WinList over Elite
software (DOS version). First is versatility. WinList allows the user
to create any number of 1,2, or 3 parameter displays of any size
anywhere
on the screen. They can be shaded, line-drawings, big dots, little
dots, etc. WinList allows complex gating logic and complex calculated
parameters. The user can change the names of the parameters, the
channel
resolution of the histograms, can create color eventing on single
parameter histograms as well as dot-plots. The second major reason is
that Winlist runs under Windows (either 3.1 or '95). This allows the
user
to cut and paste with other Windows programs to create presentation
graphics and link calculations with spreadsheets such as Excel. And
third, WinList will analyze data from virtually any instrument. So
those
of us that have both BD and Coulter cytometers can use one analysis
package for both.
Larry Seamer
Technical Director, Flow Cytometry Core
University of New Mexico, CRTC
On Tue, 18 Mar 1997, Abby Allen wrote:
> Hello everyone!
> My boss just returned from a cytometry meeting where she was
> sufficiently impressed with Verity Software's WinList software.
> Currently, I am using Cellquest and Elite software. What is it about
> WinList that would impress my boss over Cellquest and the Elite
> software. What special features does it have and do I need it?
> Once again, I appreciate your insight, information, etc.
> Thankyou!
> Abby
> --
> **********************************************************************
> Abby Allen
> Center for Blood Research
> 800 Huntington Ave.
> Boston, MA 02115
> al...@[EMAIL PROTECTED]
> **********************************************************************
________________________________________
* Next message: Laborator Citometrie: "RE: FTP "reget" option"
* Previous message: Mario Roederer: "Re: viral inactivation"
* In reply to: Abby Allen: "Why WinList?"
* Next in thread: Tom Mc Closkey: "RE: Why WinList?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
RE: Why WinList?
From: Tom Mc Closkey (thom...@[EMAIL PROTECTED]
)
Date: Thu Mar 20 1997 - 13:19:25 EST
* Next message: Richard Moldwin: "HP to Windows NT reader"
* Previous message: Julie Pribyl: "GPA Assay"
* Maybe in reply to: Abby Allen: "Why WinList?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
--- On Tue, 18 Mar 1997 15:25:02 -0500 Abby Allen
<al...@[EMAIL PROTECTED]
> wrote:
What is it about
>WinList that would impress my boss over Cellquest and the Elite
>software. What special features does it have and do I need it?
One feature of Winlist is the ability to perform n-color post
acquisition
compensation, which cir***vents the limitations of instrument
subtraction
circuitry, which is often quite limited.
Tom
--------------------------------------------------------
Thomas W. Mc Closkey, Ph. D.
Director, Flow Cytometry
North Shore University Hospital
Biomedical Research Center
350 Community Drive
Manhasset, Long Island, New York 11030
ph: 516-562-4844 [office]; 516-562-1135/4641 [lab]
3/20/97 10:22:07 AM
E-mail: thom...@[EMAIL PROTECTED]
Next message: Richard Moldwin: "HP to Windows NT reader"
* Previous message: Julie Pribyl: "GPA Assay"
* Maybe in reply to: Abby Allen: "Why WinList?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:33:55 EST
Last words from Mario (we hope) on data display
From: Mario Roederer (Roede...@[EMAIL PROTECTED]
)
Date: Wed Oct 01 1997 - 07:48:40 EST
* Next message: Michel Canton: "Cell surface receptor - Part B"
* Previous message: Frank Buehling: "anti-CCR-3"
* In reply to: Calman Prussin: "RE: data display"
* Next in thread: Rafael Nunez: "Re: Last words from Mario (we
hope)
on data display"
* Reply: Rafael Nunez: "Re: Last words from Mario (we hope) on
data
display"
* Reply: Ray Hicks: "Re: Last words from Mario (we hope) on data
display"
* Maybe reply: Howard Shapiro: "Re: Last words from Mario (we
hope) on
data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Alice laid the gauntlet at my feet, and now I will return the favor to
all of
those involved in this debate (or who wanted to be involved!). I will
propose
to Cytometry to write a perspective on the topic of FACS data
display. Everyone
now knows my bias against dot plots: I challenge any of those of you
who
champion dot plots (or even color dot plots) to join my effort and
write a
"counterpoint" analysis to provide a balancing viewpoint.
This ongoing discussion has been most spirited and, I think, very
informative.
I think that we are winding down to repeating ourselves, so I will try
to make
this my last words to the mailing list, at least for now!
Calman writes about dot plots:
> Furthermore it stresses the single cell nature of the
> data- each dot is a cell.
No, no, no, no, no, no, no! This is precisely the problem! In dot
plots, each
dot can be one cell, two cells, three cells, or a thousand cells. You
can never
know which. This is the fundamental error of dot plots. Once again,
the number
of events you display in a dot plot can totally change how it
appears--
you are
thereby inadvertently massaging the data.
I agree with Alice that the precise way of contouring can affect how
the more
frequent populations appear. This is why the choice of contouring
algorithms is
so im****tant! One of the most robust (in that it is objective, not
allowing
"user-defined" contouring levels, etc.) is probability contouring.
This method
of contouring has been adopted by SAS Institute for use in their
bivariate
displays--in addition, it is offered by several FACS data analysis
packages.
This method of contouring generates displays that are indepedent of
the number
of events collected -- something that no other display can do. Thus,
using Dot
plots or color dot plots or user-defined thresholding, I can make a
variety of
conclusions about the same sample depending solely on how many events
I choose
to collect (or display)!
Jim Houston is 100% correct that the precise method of data display is
critical.
I urge reviewers and editors to demand that this information be
included in all
FACS data displays.
Finally, one last word about "raw data." Let us not delude ourselves
into
thinking that dot plots or unsmoothed plots are "raw"--these
themselves are
presentations of highly processed data. Much more raw is the listmode
data--why
not publish tables of the basic values, then? (e.g., "Note how
frequent are the
events which have parameter 2 values between 1200 and 1240, and
parameter 3
values between 800 and 950. This suggests...")
Of course, this is nonsense: but I bring it up to drive home the
point that
these displays are only called "raw" in order to subtly convey the
mistaken
impression that the original measurements haven't been tampered with.
Of
course, even the listmode data is only as raw as a well-done steak.
There has
been a lot of signal processing that converts the original
photoelectron counts
of the PMT into a computer stored value--there is averaging,
smoothing,
background correction, etc., etc.
Once again, this brings us to the fundamental point of data display:
to convey
information accurately to the reader. I highly recommend a book by
Edward
Tufte, "The Visual Display of Quantitative Information," about this
topic
(especially to programmers developing analysis packages). This
fabulous book
shows how misleading different styles of graphs can be, and discusses
some of
the underlying principles of data display--principles largely ignored
by
developers of FACS data analysis programs.
There was some discussion about art vs. science. Do not mistake
artistry for
disinformation! Of course there is art in science, and in the
presentation of
scientific data. If not, we would only see tables of numbers that
would be
incomprehensible--we are, after all, only human.
mr
________________________________________
* Next message: Michel Canton: "Cell surface receptor - Part B"
* Previous message: Frank Buehling: "anti-CCR-3"
* In reply to: Calman Prussin: "RE: data display"
* Next in thread: Rafael Nunez: "Re: Last words from Mario (we
hope)
on data display"
* Reply: Rafael Nunez: "Re: Last words from Mario (we hope) on
data
display"
* Reply: Ray Hicks: "Re: Last words from Mario (we hope) on data
display"
* Maybe reply: Howard Shapiro: "Re: Last words from Mario (we
hope) on
data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:04 EST
Re: Last words from Mario (we hope) on data display
From: Rafael Nunez (rafa...@[EMAIL PROTECTED]
)
Date: Fri Oct 03 1997 - 07:53:07 EST
* Next message: Dennis Broud 301-827-5246 FAX 301-594-6289: "Re:
data
display"
* Previous message: Patrick Gerin: "Virus quantitation in
culture
supernatants ?"
* In reply to: Mario Roederer: "Last words from Mario (we hope)
on
data display"
* Next in thread: Ray Hicks: "Re: Last words from Mario (we
hope) on
data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Dear Mario
When you point out that dot plots is a poor choice for presenting data
(single color dot plot), I was very surprised for that sentence. Then
you
bring up that even color dot plots are not good, but contours are ok.
However, if you have a small population against a big one, when you
use
contours you almost take out the small one and then your
representation of
the small one will be at the best: one single contour. What about,
when you
are using three or four colors and you will be interest in detection
of
markers on this small population?
I put my point here, because I use to analyze Dendritic cells/
Langerhans
cells that represent less than 1% of the PBMC and less than 1% of the
skin
cells and may be 10 % of the cells in the lymph, with this little
fraction
I should measured CD1a vs HLA-DR, and then selected and check for two
other
markers. Then, my contour plot only shown an awfull spot that said
nothing
to me and less to others that are not familiar with FACS. Actually,
still
they do not buy that this spot were truly DC/LC.
Another point that I want to bring home is that if you put colors in
your
graphics (dots, contours and histograms) in order to made them more
reader
friendly, you should also be prepared to paid for that artistic
feature and
in some journals it run as high as 1600 US dollars. I still have the
letter
from some obscure middle man. Editors never get dirty on money. Even
for
Swiss standards is very high. Therefore, I also propose, that if the
figure
requires the color for better understanding, it should be always free.
What
about open this can of worms, I guess we can propose this to the
journals
that are publi****ng papers on cytometry
Rafael
>Alice laid the gauntlet at my feet, and now I will return the favor to
all of
>those involved in this debate (or who wanted to be involved!). I will
propose
>to Cytometry to write a perspective on the topic of FACS data display.
>Everyone
>now knows my bias against dot plots: I challenge any of those of you who
>champion dot plots (or even color dot plots) to join my effort and write
a
>"counterpoint" analysis to provide a balancing viewpoint.
>This ongoing discussion has been most spirited and, I think, very
informative.
>I think that we are winding down to repeating ourselves, so I will try to
make
>this my last words to the mailing list, at least for now!
>Calman writes about dot plots:
>> Furthermore it stresses the single cell nature of the
>> data- each dot is a cell.
>No, no, no, no, no, no, no! This is precisely the problem! In dot
plots,
>each
>dot can be one cell, two cells, three cells, or a thousand cells. You
can
>never
>know which. This is the fundamental error of dot plots. Once again, the
>number
>of events you display in a dot plot can totally change how it
appears--you are
>thereby inadvertently massaging the data.
>I agree with Alice that the precise way of contouring can affect how the
more
>frequent populations appear. This is why the choice of contouring
>algorithms is
>so im****tant! One of the most robust (in that it is objective, not
allowing
>"user-defined" contouring levels, etc.) is probability contouring. This
>method
>of contouring has been adopted by SAS Institute for use in their
bivariate
>displays--in addition, it is offered by several FACS data analysis
packages.
>This method of contouring generates displays that are indepedent of the
number
>of events collected -- something that no other display can do. Thus,
>using Dot
>plots or color dot plots or user-defined thresholding, I can make a
variety of
>conclusions about the same sample depending solely on how many events I
choose
>to collect (or display)!
>Jim Houston is 100% correct that the precise method of data display is
>critical.
>I urge reviewers and editors to demand that this information be included
>in all
>FACS data displays.
>Finally, one last word about "raw data." Let us not delude ourselves
into
>thinking that dot plots or unsmoothed plots are "raw"--these themselves
are
>presentations of highly processed data. Much more raw is the listmode
>data--why
>not publish tables of the basic values, then? (e.g., "Note how frequent
>are the
>events which have parameter 2 values between 1200 and 1240, and parameter
3
>values between 800 and 950. This suggests...")
>Of course, this is nonsense: but I bring it up to drive home the point
that
>these displays are only called "raw" in order to subtly convey the
mistaken
>impression that the original measurements haven't been tampered with. Of
>course, even the listmode data is only as raw as a well-done steak.
There has
>been a lot of signal processing that converts the original photoelectron
>counts
>of the PMT into a computer stored value--there is averaging, smoothing,
>background correction, etc., etc.
>Once again, this brings us to the fundamental point of data display: to
>convey
>information accurately to the reader. I highly recommend a book by
Edward
>Tufte, "The Visual Display of Quantitative Information," about this topic
>(especially to programmers developing analysis packages). This fabulous
book
>shows how misleading different styles of graphs can be, and discusses
some of
>the underlying principles of data display--principles largely ignored by
>developers of FACS data analysis programs.
>There was some discussion about art vs. science. Do not mistake artistry
for
>disinformation! Of course there is art in science, and in the
presentation of
>scientific data. If not, we would only see tables of numbers that would
be
>incomprehensible--we are, after all, only human.
>mr
\|/
(o o)
________________________________oOo__(_)__oOo_________________________________
___/\_ | Rafael Nunez
mailto:rafa...@[EMAIL PROTECTED]
/ o \/| | University Inst.for Virology http://www.unizh.ch/vetvir
/ _| | Winterthurerstr. 266a Telephone: (+41) 1
6358710
/_/\__/-\/ | 8057 Zurich SWITZERLAND Faximile : (+41) 1
6358911
______________________________________________________________________________
________________________________________
* Next message: Dennis Broud 301-827-5246 FAX 301-594-6289: "Re:
data
display"
* Previous message: Patrick Gerin: "Virus quantitation in
culture
supernatants ?"
* In reply to: Mario Roederer: "Last words from Mario (we hope)
on
data display"
* Next in thread: Ray Hicks: "Re: Last words from Mario (we
hope) on
data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:04 EST
Re: Last words from Mario (we hope) on data display
From: Ray Hicks (rh...@[EMAIL PROTECTED]
)
Date: Sat Oct 04 1997 - 10:06:00 EST
* Next message: Nicholson, Janet: "gp41 and gp120 antibodies"
* Previous message: Donnenberg, Albert: "RE: data display"
* In reply to: Mario Roederer: "Last words from Mario (we hope)
on
data display"
* Next in thread: Howard Shapiro: "Re: Last words from Mario (we
hope)
on data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Hi,
I use dotplots to give me an idea of where populations lie, and I get
the
computer to count events in the regions that I set. I don't feel that
I
need to act as a densitometer, so I don't fiddle around getting the
"correct" contour set-up. Nonetheless I find that I'm not more than
5-10%
(of estimated percentage) out on most estimates that I'm asked to make
at
run time for populations in the range of 5% to 50% of total. The
proximity
of similar dots gives an impression of increasing density, that works
not
unlike halftoning used in the print industry for representing grey
scales.
As for low frequency populations: I had no problem seeing a cluster
of 31
transfectants in 2 million cells yesterday using an ac***ulating dot
plot
(whether I managed to sort any of them is a separate issue). It
didn't
matter that the negatives appeared as a solid blob, I could still
count 28
positive dots on the screen (presumably one or two of the dots
represented
more than one event - the computer counted them for me as well so who
cares?). How would you go about choosing contour levels to best
represent
this population? Could you really choose levels that would allow you
to say
that there is a 0.005% population, or even to visualise it, in less
time
than it takes to count the dots and divide by the total?
Ray
ps I realise that the sample size isn't really large enough for
statistical
significance, so let's not open that can of worms, but here's an
interesting quote from the Feedback section of New Scientist magazine
on
the Issue:
"The following is a recent conversation Feedback held with a
representative
of the Office for National Statistics(ONS), after being referred there
for
a concise definition of the term 'statistical significance'.
Feedback: "Could you tell me the definition of statistical
significance?"
ONS: "What do you mean?"
Feedback: "You know, if you sample a population, when does that
sample
become statistically significant? When is it taken
into
account?"
ONS: "Well, we sample the population every other year, we
collect the
data, print it...and then it becomes significant""
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: Nicholson, Janet: "gp41 and gp120 antibodies"
* Previous message: Donnenberg, Albert: "RE: data display"
* In reply to: Mario Roederer: "Last words from Mario (we hope)
on
data display"
* Next in thread: Howard Shapiro: "Re: Last words from Mario (we
hope)
on data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:04 EST
Re: Last words from Mario (we hope) on data display
From: Howard Shapiro (h...@[EMAIL PROTECTED]
)
Date: Sat Oct 04 1997 - 22:16:13 EST
* Next message: BI...@[EMAIL PROTECTED]
"Re: data display
(contours,etc)"
* Previous message: PLM: "Thanks for "minimum mouse cells
needed"
information!"
* Maybe in reply to: Mario Roederer: "Last words from Mario (we
hope)
on data display"
* Next in thread: David L. Haviland, Ph.D.: "RE: data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
>I will propose
>to Cytometry to write a perspective on the topic of FACS data display.
>I challenge any of those of you who
>champion dot plots (or even color dot plots) to join my effort and write
a
>"counterpoint" analysis to provide a balancing viewpoint.
A forum with various viewpoints, well do***ented and illustrated,
would
probably be very helpful to the reader****p.
>Calman writes about dot plots:
>> Furthermore it stresses the single cell nature of the
>> data- each dot is a cell.
>No, no, no, no, no, no, no! This is precisely the problem! In dot
plots, each
>dot can be one cell, two cells, three cells, or a thousand cells. You
can
never
>know which.
I think what he probably meant was that a dot plot does allow you to
spot
numbers of occurrences below your lowest threshold value for
contouring,
including single occurrences; it is true that if there isn't a dot at
a
point on a dot plot there weren't any cells observed with the
corresponding
data values.
>I agree with Alice that the precise way of contouring can affect how the
more
>frequent populations appear. This is why the choice of contouring
algorithms is
>so im****tant! One of the most robust (in that it is objective, not
allowing
>"user-defined" contouring levels, etc.) is probability contouring. This
method
>of contouring has been adopted by SAS Institute for use in their
bivariate
>displays--in addition, it is offered by several FACS data analysis
packages.
>This method of contouring generates displays that are indepedent of the
number
>of events collected -- something that no other display can do.
By "probability contouring" do you mean normalization, so the contour
lines
represent percentile values rather than absolute numbers of cells?
This is
a very sensible method of displaying things, and facilitates
comparison of
samples of unequal sizes. In order to deal with rare events, however,
you
still have to have dots or their equivalent added to the contour plot.
Thus, using Dot
>plots or color dot plots or user-defined thresholding, I can make a
variety of
>conclusions about the same sample depending solely on how many events I
choose
>to collect (or display)!
>Jim Houston is 100% correct that the precise method of data display is
critical.
>I urge reviewers and editors to demand that this information be included
in all
>FACS data displays.
Note, for example, that bivariate chromosome contour plots are
generally
made with higher thresholds than plots of immunofluorescence...and it
wouldn't be a bad idea to include a scale or to indicate which contour
lines
represent which percentiles.
>Once again, this brings us to the fundamental point of data display: to
convey
>information accurately to the reader. I highly recommend a book by
Edward
>Tufte, "The Visual Display of Quantitative Information," about this topic
>(especially to programmers developing analysis packages). This fabulous
book
>shows how misleading different styles of graphs can be, and discusses
some of
>the underlying principles of data display--principles largely ignored by
>developers of FACS data analysis programs.
>There was some discussion about art vs. science. Do not mistake artistry
for
>disinformation! Of course there is art in science, and in the
presentation of
>scientific data. If not, we would only see tables of numbers that would
be
>incomprehensible--we are, after all, only human.
Tufte actually has three books out; each is a work of art as well as a
work
of science. In the Chapter on Data Analysis in the 3rd Edition of
Practical
Flow Cytometry, I suggest that single parameter distributions be
represented
using Tufte's minimalist version of the "Box and Whiskers" plot, which
shows
the position of the median, 25th and 75th, and 5th and 95th percentile
values (or, alternatively, the full range of the data instead of 5th
and
95th %). This could readly be extended to a two-dimensional version,
but
might be better represented by different colored (or differently
shaded)
areas than by contour lines.
-Howard
________________________________________
* Next message: BI...@[EMAIL PROTECTED]
"Re: data display
(contours,etc)"
* Previous message: PLM: "Thanks for "minimum mouse cells
needed"
information!"
* Maybe in reply to: Mario Roederer: "Last words from Mario (we
hope)
on data display"
* Next in thread: David L. Haviland, Ph.D.: "RE: data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:04 EST
RE: data display
From: David L. Haviland, Ph.D. (dhavi...@[EMAIL PROTECTED]
)
Date: Fri Oct 03 1997 - 15:31:37 EST
* Next message: P. VAIGOT: "cytoplasmic staining"
* Previous message: LAAD...@[EMAIL PROTECTED]
"Enhanced Annexin V"
* Maybe in reply to: Houston, Jim : "RE: data display"
* Next in thread: Donnenberg, Albert: "RE: data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Greetings all:
I have learned a great deal and have enjoyed the discussion concerning
data
display, dot vs contour, etc. To settle a curiosity that I had, I
privately asked M_Roederer
this question.
"We know each plot (contour/dot/density) has its benefits and
pitfalls.
However, does anyone know of an instance where a conclusion or part
thereof
has been in serious doubt because a conclusion was drawn off a dot
plot,
when a contour plot would have suggested a different conclusion?"
Frankly, I expected "no" as the respone but was suprised when Mario
stated
there had been a few instances. So my question to the group is does
anyone
have such a reference(s) of a flow cytometric "opps"? Were manuscript
retractions involved?
Many thanks in advance,
David
________________________________________
* Next message: P. VAIGOT: "cytoplasmic staining"
* Previous message: LAAD...@[EMAIL PROTECTED]
"Enhanced Annexin V"
* Maybe in reply to: Houston, Jim : "RE: data display"
* Next in thread: Donnenberg, Albert: "RE: data display"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:04 EST
Re: Graphics Resolution
From: Joseph Trotter (trot...@[EMAIL PROTECTED]
)
Date: Wed Sep 24 1997 - 19:17:57 EST
* Next message: Bela Mehta: "Simultaneous detection of BrdU and
cytokines"
* Previous message: Kenneth A Schafer: "Re: Contour plots &
smoothing:
rights and wrongs"
* In reply to: Howard Shapiro: "Graphics Resolution"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Howard,
Of course - we've discussed that before. Most "Flow images"
contain text in addition to rasterized lines. Most Fonts at 72dpi are
relatively crude when compared to say, PostScript output at 300dpi.
So,
I believe it totally justified to enable high resolution output of
flow data, even if the ratio of "pixels" to "data points" does wander
to where the resolution is greater than that of the displayed data.
In addition, with a panel of plots at 300dpi, you can reduce
the
size for publication without losing data due to bitmap image hacking.
This
is where scalable image files come in handy. Nobody wants a bitmap
shrinking algorithm "drawing" their data.
The sobriety of the investigator in performing these tasks, however,
is obviously beyond our control....
Regards,
Joe
________________________________________
* Next message: Bela Mehta: "Simultaneous detection of BrdU and
cytokines"
* Previous message: Kenneth A Schafer: "Re: Contour plots &
smoothing:
rights and wrongs"
* In reply to: Howard Shapiro: "Graphics Resolution"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:03 EST
Re: Re[2]: Leave FCS3.0 alone.
From: Jim Houston (jim.hous...@[EMAIL PROTECTED]
)
Date: Fri Jul 18 1997 - 12:24:25 EST
* Next message: J.Paul Robinson: "Re: FCS discussion"
* Previous message: Kong: "Fixation of cells"
* In reply to: Larry_Sea...@[EMAIL PROTECTED]
"Re[2]: Is FCS3.0
obsolete?"
* Next in thread: Ray Hicks: "Re: Re[2]: Leave FCS3.0 alone."
* Reply: Ray Hicks: "Re: Re[2]: Leave FCS3.0 alone."
* Maybe reply: Robert C. Leif, Ph.D.: "Re: Re[2]: Leave FCS3.0
alone."
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
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
________________________________________
* Next message: J.Paul Robinson: "Re: FCS discussion"
* Previous message: Kong: "Fixation of cells"
* In reply to: Larry_Sea...@[EMAIL PROTECTED]
"Re[2]: Is FCS3.0
obsolete?"
* Next in thread: Ray Hicks: "Re: Re[2]: Leave FCS3.0 alone."
* Reply: Ray Hicks: "Re: Re[2]: Leave FCS3.0 alone."
* Maybe reply: Robert C. Leif, Ph.D.: "Re: Re[2]: Leave FCS3.0
alone."
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:00 ES
Re: Re[2]: Leave FCS3.0 alone.
From: Ray Hicks (rh...@[EMAIL PROTECTED]
)
Date: Mon Jul 28 1997 - 09:35:28 EST
* Next message: Jan Keij: "first use of PI for viability"
* Previous message: Lucia Mariano da Rocha Silla: "CD34 cells
separation"
* In reply to: Jim Houston: "Re: Re[2]: Leave FCS3.0 alone."
* Next in thread: Robert C. Leif, Ph.D.: "Re: Re[2]: Leave
FCS3.0
alone."
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
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: Jan Keij: "first use of PI for viability"
* Previous message: Lucia Mariano da Rocha Silla: "CD34 cells
separation"
* In reply to: Jim Houston: "Re: Re[2]: Leave FCS3.0 alone."
* Next in thread: Robert C. Leif, Ph.D.: "Re: Re[2]: Leave
FCS3.0
alone."
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:01 EST
Re: Re[2]: Leave FCS3.0 alone.
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?
----------------------------------------------------------------------------
---------------------------------
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 <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"
* 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 ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:01 EST
Re: Re[2]: Is FCS3.0 obsolete?
From: Dave Coder (dco...@[EMAIL PROTECTED]
)
Date: Fri Jul 25 1997 - 13:42:39 EST
* Next message: James Weaver 301-594-5879 FAX 301-594-3037:
"Application of Flow Cytometry to Immunotoxicity Testing Workshop"
* Previous message: Echeagaray, Patricia L.: "Minimum number of
mouse
cells for Flow"
* Maybe in reply to: Larry_Sea...@[EMAIL PROTECTED]
"Re[2]: Is FCS3.0
obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Data File Standards and Related Issues
As a follow-up to the discussion about the strengths and weaknesses of
the
Data File Standard for Flow Cytometry, Version FCS3.0, there has been
a
section of the ISAC Web Page devoted to this topic for almost a year.
In addition to a hypertext version of the complete FCS3.0
specification,
you can find the names, addresses, and phone numbers of all the
members of
the ISAC Data File Standards Committee. This committee is charged
with
formulating the standard, and is interested in receiving comments from
those it serves. There is also an on-line forum discussing various
aspects
of FCS3.0 that was started by Larry Seamer, the Committee Chair, when
the
file specification was released last year. With the permission of
those who
have recently submitted extended comments to the Cytometry Mailing
List, I
have copied that discussion to the forum to provide a complete listing
of
current commentary. Guenter Valet has started a follow-up forum that
is
also liked to the same page.
The ISAC Web Page also has many links to other sites throughout the
world
that deal with data file standards and their implementation in science
and
medicine. Extended alternative opinions that have been submitted by
ISAC
members are published there as well.
Your on-going remarks on the topic are solicited. In addition to
formatted
text, you may also submit figures and other illustrations to accompany
your
text comments. If you wish to submit figures, please send email to me
for
details.
The Data Files Standards Page can be reached at:
http://nucleus.immunol.wa****ngton.edu/ISAC/data_standards.html
Dave Coder
Editor, ISAC WWW Home Page
http://nucleus.immunol.wa****ngton.edu/ISAC.html
dco...@[EMAIL PROTECTED]
Next message: James Weaver 301-594-5879 FAX 301-594-3037:
"Application of Flow Cytometry to Immunotoxicity Testing Workshop"
* Previous message: Echeagaray, Patricia L.: "Minimum number of
mouse
cells for Flow"
* Maybe in reply to: Larry_Sea...@[EMAIL PROTECTED]
"Re[2]: Is FCS3.0
obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:00 ES
RE:FCS3.0 etc
From: Randy T. Fischer (fisch...@[EMAIL PROTECTED]
)
Date: Thu Jul 17 1997 - 03:25:15 EST
* Next message: kc...@[EMAIL PROTECTED]
"LDL Receptor Assay for FH"
* Previous message: Bob Ashcroft: "RE: Cell Culture after DNA
Ploidy
Staining"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
I agree with both Marty and Gunter in the very im****tant issue
of
standardizing data formatting. I would point out that lobbying ISAC is
only, however, part of the answer. Regardless of what ISAC may choose
to
recommend, it is still up to the manufacturers to implement what they
want
to do, and if they do not agree with ISAC, then too bad for ISAC and
the
flow community. A potentially more powerful force for change might be
the
FDA, which regulates machines used in CLINICAL settings. If the FDA
could
be persuaded to require all CLINICAL data be universally both
accessible
and readable, then the manufacurers would be forced to upgrade
machines and
software or lose theLUCRATIVE CLINICAL market. This would make
analyzing
data from different sources easier, and could facilitate the exchange
of
crucial clinical results from various trials where multiple sites and
machines are in use.
So how does this get done? Gunter (and Paul's agreeing
response)
are correct this needs to be revisited at Asilomar, with perhaps an
additional idea. Any concrete standardization protocol, FCS3.0 or
whatever
it ends up being designated, should be then presented to any and all
regulatory agencies by ISAC to ensure no individual manufacturer
decides
FCS3.0 in their format is acceptable, even if it is not universally
readable.
Randy T. Fischer
NIA/NIH
GRC
Baltimore, MD 21224
fisch...@[EMAIL PROTECTED]
Next message: kc...@[EMAIL PROTECTED]
"LDL Receptor Assay for FH"
* Previous message: Bob Ashcroft: "RE: Cell Culture after DNA
Ploidy
Staining"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:00 EST
Re: Is FCS3.0 obsolete ?
From: G.K.Valet (va...@[EMAIL PROTECTED]
)
Date: Thu Jul 17 1997 - 04:53:04 EST
* Next message: Steven Merlin: "Re: Sample Injection Module"
* Previous message: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Dear colleagues,
thank you for the immediate response which
demonstrates the high general concern about this
im****tant issue.
Re*****sment of the FCS3.0 format should primarily
focus on:
1. facilitation of contacts with the *external* world
(e.g. conformity to regulatory issues, unambiguous
interface for sample information, parameters
designations, scales and data, international character
coding, contact with data management systems etc)
2. de-complication of the *internal* world of this file standard
to make it as robust as e.g. GIF, JPEG or MPEG image
file standards.
The definition of the "external world" requirement
may need a consensus prior to the technical implementation
phase. The *electronic* development of such a consensus
could be a nice task for the ISAC on-line discussion forum !
Best regards
G.Valet
E-mail: va...@[EMAIL PROTECTED]
http://www.biochem.mpg.de/valet/cellbio.html
________________________________________
* Next message: Steven Merlin: "Re: Sample Injection Module"
* Previous message: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:00 EST
Re: Is FCS3.0 obsolete?
From: G.K.Valet (va...@[EMAIL PROTECTED]
)
Date: Wed Jul 16 1997 - 01:43:52 EST
* Next message: gema...@[EMAIL PROTECTED]
"email address"
* Previous message: Leonie Gaudry: "Cell Culture after DNA
Ploidy
Staining"
* Next in thread: BI...@[EMAIL PROTECTED]
"Re: Is FCS3.0
obsolete?"
* Maybe reply: BI...@[EMAIL PROTECTED]
"Re: Is FCS3.0
obsolete?"
* Maybe reply: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
To: cyto-inbox
flow cytometry file and software standardization and clinical
cytometry
One of the primary goals of a file standard in flow cytometry
should be to provide:
1.) general interchange of list mode files amongst different software
platforms.
2.) standardized interfaces for the im****t and ex****t of sample
(patient)
and result information e.g. from general information management
systems into list mode files or from list mode files into such
data management systems.
To achieve these goals, rigorous simplicity and conformity with
existing regulations in the biomedical health and research areas
are mandatory.
FCS1.0 and FCS2.0 standards have been *very helpful* for many
purposes and it was an *excellent* idea in retrospect to have
introduced
a file standard relatively early in the history of ISAC. Both
standards
have clearly favoured the interchange of list mode files and thus
e.g.
greatly facilitated the efforts for standardized multiparameter data
classification
(http://www.biochem.mpg.de/valet/cellclas.html)
in medicine.
On the other hands *both* standards have been in practice *quite
difficult*
for the *automated* evaluation of even very *simple* things in files
from
different flow cytometers and cell sorters like:
- which fluorescence or light scatter is associated with which
photomultiplier,
- where is the patient identification located,
- where is the assay information
- which parameter is linear and which logarithmically measured,
- how can the computer clock time scale be converted into an obvious
time scale in sec
With FCS2.0 but even more with FCS3.0 we are thrown into the orcus
of bit compressed and multiexperiment information within single list
mode files,
furthermore into non standardized areas for gate and result storage.
This development is *clearly* the *wrong* direction to go. Already
FCS1.0
and FCS2.0 were only *frame standards* i.e. they left a much *too
high* degree
of freedom for coding the *generally relevant information*. Since flow
cytometry
has a strong biomedical bias and is used for diagnostic purposes in
medicine,
it seems mandatory that file standards are produced which conform to
the required clarity for medical but also for research purposes. There
is no
objection that there are reserved areas for the storage of proprietory
information
for certain algorithms of manufacturer software but the *generally*
used
information must be *rigorously* standardized in future FCS
standards !
It seems therefore im****tant to reconsider the FCS3.0 standard. We
all
apreciate the excellent work of the FCS3.0 standardization committee
in
addressing the many relevant issues. The practical implementation of
the
FCS3.0 file standard will, however, atomize and explode the efforts to
process
each others files totally because these files will have in a *general
sense* the
tendency to become *illegible* to third party software.
I believe that both Mario's and Bob's comments are *very relevant*
and all
those involved in flow cytometric software should make efforts and
reconsider
the FCS3.0 issue very seriously in the near future.
It *cannot* be the goal of all of us to favor *complications* in
this
fundamentally
essential area of file formats and software standardization especially
in times were im****tant developments from the side of ISAC/CCD/CCS as
well as from the European Working Group for Clinical Cell Analysis
(EWGCCA,
http://www.biochem.mpg.de/valet/eurocel1.html)
are under way. They
promote
international harmonization e.g. of flow cytometric immunophenotyping
and
cell function assays. By this, fascinating new developments in the
area of
individualized patient therapy and Cellular Medicine
(http://www.biochem.mpg.de/valet/keyvirt1.html)
will be greatly favored. They will substantially enhance the use and
im****tance
of flow cytometry in the clinical laboratory and in medicine in
general.
My *suggestion* is that the FCS3.0 issue be officially readdressed
at
Phil Dean's upcoming workshop in Asilomar.
Best regards
G.Valet
E-mail: va...@[EMAIL PROTECTED]
http://www.biochem.mpg.de/valet/cellbio.html
________________________________________
* Next message: gema...@[EMAIL PROTECTED]
"email address"
* Previous message: Leonie Gaudry: "Cell Culture after DNA
Ploidy
Staining"
* Next in thread: BI...@[EMAIL PROTECTED]
"Re: Is FCS3.0
obsolete?"
* Maybe reply: BI...@[EMAIL PROTECTED]
"Re: Is FCS3.0
obsolete?"
* Maybe reply: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:00 EST
Re: Is FCS3.0 obsolete?
From: BI...@[EMAIL PROTECTED]
Wed Jul 16 1997 - 07:46:59 EST
* Next message: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Previous message: Josi Antonio Cancelas: "Question on fast
cell
sorting"
* Maybe in reply to: G.K.Valet: "Re: Is FCS3.0 obsolete?"
* Next in thread: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
Gunter has raised some very relevant issues with regard to data
storage and
management in flow cytometry.
FCS 3.0 does an adequate, if ***bersome job, of providing a data
interchange
format. However, most instrumentation manufacturers developed software
that
would read FCS files that their instruments generated, and didn't put
in much
effort to covering other cases (one manufacturer, in particular,
actively made
it's software refuse to read FCS files from other sources, a stroke
of "marketing brilliance"). This was facilitated by the design of FCS
- the
free form text header (keyword-values) contribute to the difficulty of
developing a general library to parse these values into usable form.
However, I don't believe that FCS per se is the cause of the
difficulty Gunter
expresses for his second criteria - interfacing with databases for
patient or
experiment management. A very im****tant aspect has been consistently
overlooked by commercial software - a method for users to easily fill
in the
necessary attributes for the FCS keywords. Much development has been
spent on
generating flashy graphics whose axis are "intelligently" labeled FL1
and FL2 (or
P1 and P2). The combination of instrument configuration which would
specify
measurement parameter color, (FITC, TexRed, etc.), parameter scaling
(log,
lin), and other instrument conditions with sample attributes (source,
cell
type, stains, etc.) could currently all be stored in FCS keywords and
read into
various databases from them, satisfying mcuh of Gunter's second
criteria. However
without the development of appropriate software for users to generate
this
information, this won't happen. Moreover, I would think it appropriate
for ISAC
to generate some standards on what these attribute values should be.
It would
be very obnoxious to search your database for e.g. cd4 OR CD4 OR cd-4
OR CD-4
OR...
As a "proof of principle" let me summerize what we have done here.
Since 1983
we have provided a klunky (compared to GUIs) "protocol editor" which
allowed
users to generate a matrix of cell types and reagents. Our collection
software
associated each element of this matrix with one or more collected
samples. This
was combined, as indicated above, with instrument configuration
parameters (from
our standardization program). Data collected during one FACS run is
accessed
together as an "experiment" with an instrument, date, and user stamp.
People
could browse an archive of old experiments and bring up data with
graphs whose
axes were properly labeled and had reagent and cell type descriptions.
Despite
its unfriendliness, most Facility users found that the benefits
outweighed the
disadvantages and annotated their data. I think the lesson to be
learned is that
if the capacity to annotate exists and is relatively easy to use, most
of the
time it will be because the benefits are great.
-Marty Bigos
Stanford Shared FACS Facility
________________________________________
* Next message: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Previous message: Josi Antonio Cancelas: "Question on fast
cell
sorting"
* Maybe in reply to: G.K.Valet: "Re: Is FCS3.0 obsolete?"
* Next in thread: J.Paul Robinson: "Re: Is FCS3.0 obsolete?"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ attachment ]
________________________________________
This archive was generated by hypermail 2.1.6 : Thu Jan 01 2004 -
17:34:00 EST
Re: Is FCS3.0 obsolete?
From: J.Paul Robinson (robin...@[EMAIL PROTECTED]
)
Date: Wed Jul 16 1997 - 17:04:28 EST
* Next message: G.K.Valet: "Re: Is FCS3.0 obsolete ?"
* Previous message: BI...@[EMAIL PROTECTED]
"Re: Is FCS3.0
obsolete?"
|
