Hi,
NCSA Gelreader (now in rel 2.0.3, versions for both +/-FPU, available
FREE from the NCSA archives at ftp.ncsa.uiuc.edu and others), is a program
for calculating the sizes of electrophoresed bands directly from a
digitized image of the gel. The idea is really quite good and the
execution is aaaaallllllmosst there.
A number of the genome gnomes here at the Salk have been trying to use
it and after a couple of days thrashing about in GelReader wasteland, we've
managed to figure out enough bugs to get it working.
The reason that I post the results of our self-abasement here is that I
gophered a number of back-postings to bionet on the same questions and
decided to spare others the time and frustration.
In the first place, we can get it to work. And when it does work, it
works well, especially when you consider the work involved in determining
the sizes manually for ~1000 gels of 30 lanes of unknowns per, which is the
size of the project that is being considered.....! However, getting it to
work correctly was not particularly straightforward.
The biggest problem was not so much a bug, but the omission in the
otherwise very well-written (as usual for NCSA productions) manual. It
neglected to mention that the gels require at least 2 lanes of markers and
that they must bracket the samples. (This was also the primary
bewilderment of the backpostings to bionet). These standards lanes must
also be assigned in a menu that is quite unconnected with the menu that
allows you to pick the standards (although, they have implemented a
'template' option in which you can specify how a series of gels will look,
sparing you the time of setting up each scan individually, a boon to large
projects such as the one contemplated here).
Additionally, the actual menu selections are a little unstable. For
example, with a click+paint section thru a menu, a few individual
selections (which should all be selected and colored) are left uncolored
although they have still been selected).
The next problem IS a bug, but not an insurmountable one. Although you
can enlarge the image by 2 and 4 times, the tools for adding and deleting
bands did not work on the enlarged images, although the (same) tools worked
on the lanes. Theband tools work fine on the original-sized image but for
reasons discussed later, it is annoying and headache-inducing to have to
work with the original-sized gel.
The graphics are still not optimal, not surprising considering the
complexity of the vector overlays and images involved. Orphaned lines from
lane assignments are left around the screen, strips of garbled bitmaps
appear at random, deleted and added bands sometimes are not updated until a
complete screen re-draw (altho this was supposed to be fixed and in fact
was reduced in 2.0.3), and the tools are not completely intuitive. Also,
when the bands are found (very quickly and with VERY good selectivity!!),
some (apparently the most intense?) are bracketed by small markers which
are not removed after the band indicator is deleted. Complicating the
process is the default color of the band indicator (purple) which I could
not find a way to change. After a few minutes of squinting into the screen
from 5 cm to determine whether a band was marked or not, the ability to
change the color of the indicator rose rapidly to the head of the list of
Please-do-NOW's.
Some hints for digitizing the gels: We used standard agarose gels
stained with ethidiumBr, photographed with Polaroid film and then digitized
with an XRS scanner. They were scanned at 100dpi, in 8bit grey scale into
Adobe Photoshop with the bundled add-in controller software which also
allowed the scan to be inverted black to white (seemed to be easier for GR
to detect bands; was certainly easier on my eyes). Because they were
scanned in at only 100 dpi, the size of the original images were relatively
small, hence the desire to enlarge them on-screen as much as possible.
The contrast and brightness were adjusted to give the 'eyeball best'
image and the image was cropped and saved as a TIFF file. GR also seems to
have problems with large images - we got relatively perky performance with
smaller images (<150KB) and none of the problems experienced with large
images (the first few scans were done at 300 dpi to 'save resolution' - not
particularly desireable actually, and files were an unmanageable 800KB).
As long as the standards were bracketing the samples (in reality or by
introducing a false lane, of course), the program worked more or less as
advertised, and the calculation of the bands sizes was very fast and at
least as accurate as any of the other computerized sizing programs.
In short, if you have a large mapping project, it is a tremendous work
saver, even working around the bugs.
GelReader output can also be fed directly into another NCSA program
called ContigAsm which purports to analyze the digest pattern and report on
the best way to fit them all together into a physical map. I've not tested
it yet, but when I do, you'll read 'bout it here first.
Here's hoping the GelReader group will continue to improve their work
(and add that bit about the bracketing markers to the manual, eh?).
Thomas Redman, head of the group that wrote GR can be reached at:
redman at ncsa.uiuc.edu.
This posting (tightened and spellchecked) will be combined with my
rolling review of software packages for DNA and protein analysis that
sporadically collides with NETspace. If you want to be put on a mailing
list to get it, let me know (prefix the subject line with: "SAP Review!".
Otherwise, follow bio-soft.
Cheers,
Harry
Harry Mangalam Vox:(619) 453-4100, x250
Dept of Biocomputing Fax:(619) 552-1546
The Salk Institute 1' mangalam at salk-sc2.sdsc.edu
10010 N Torrey Pines Rd 2' hjm at salk-sgi.sdsc.edu
La Jolla CA 92037 3' mangalam at salk.bitnet
