Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal

We have been buying generic dual-CPU computers from Microway. These are based on AMD's 64-bit OPteron CPU rather than Intel's. We have been generally happy with them. I think the Dell Precision series is also very attractive.


Badri Roysam
Professor, Department of Electrical, Computer and Systems Engineering
Associate Director, NSF Center for Subsurface Sensing & Imaging Systems (CenSSIS ERC)
Rensselaer Polytechnic Institute
110 8th Street, Troy, New York 12180-3590.
Office(JEC 7010): 518-276-8067, Lab(JEC 6308): 518-276-8207, Fax: 518-276-8715
Email: [log in to unmask], Web: http://www.ecse.rpi.edu/~roysam



----- Original Message -----
From: Bill Oliver [mailto:[log in to unmask]]
To: [log in to unmask]
Subject: **SPAM** Re: Which computer for image processing ?


> Search the CONFOCAL archive at
> http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
> 
> On Thu, 19 Oct 2006, Christophe Leterrier wrote:
> 
> > Search the CONFOCAL archive at
> > http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
> >
> > Hi all,
> >
> > I would like to get answers to the following question : what would be the 
> > best choice for a post-aquisition, image processing computer ? It will run
> 
> > ImageJ and possibly other image processing and visualization software 
> > (depending on the OS). I want to be able to cope with big volumes of data,
> 
> > image enhancement, deconvolution, 3-4-5D vizalisation.
> 
> My personal opinion is that this isn't as big a deal as it was
> a few years ago.  I used to do my image processing on an 8-processor
> SGI Infinite Reality Engine a few years ago, and now do most of 
> it on a tiny cluster of $800 laptops.
> 
> For me, the first thing you need to decide on is what
> software you want to run, and then buy the box to fit
> the software.  If you want to run an app that only
> works on Windows, then you will run Windows.  If it
> requires 6G RAM, then get 6G RAM.
> 
> Here are a few things to think about, though:
> 
> 1) Make sure to buy plenty of RAM.  Most people think that
> it's the cpu that dictates the speed of processing.  In cases
> of large datasets, it's often paging to/from virtual memory
> that is the bottleneck.  If you have a choice of buying
> a cpu that's 20% faster versus having double the RAM for
> the same euros, do the RAM.
> 
> 2) High end graphics cards only add speed to interactive
> 3D graphics -- not to image processing, deconvolution, etc.
> The only exception I've seen to this is some video
> software that does some processing in the graphics
> card.  Those kinds of packages tell you what cards
> they will and will not work with.
> 
> If you expect to be doing virtual reality and plan to
> have complex 3D scenes with fancy shading, lighting, 
> texturing, etc. then you may need a hard core graphics
> card.  Otherwise, spend your money on processing and
> a better monitor.
> 
> 3) Don't scrimp on the monitor.  If you are going to
> be doing diagnostic or other decisionmaking work based
> on the images you produce and look at on the monitor,
> then sticking a crappy monitor on a great box wastes the 
> box.  That's particularly true if you are going with an 
> lcd monitor -- make sure its dynamic range, gamut, etc. 
> will do the job.
> 
> Obviously, if your output is really hard copy, then 
> spend your money on the printer instead. But I've seen
> people spend $20,000 on a box and $120 on a monitor.
> 
> 4) Think about clustering -- whether you do it formally
> or informally.  I do a lot of animations for my private
> consult work, and use a render farm for that.  For that
> kind of thing, two cheap medium-fast machines are much 
> better than one expensive really fast machine.
> 
> In fact, that's the graveyard for my old boxes. I still 
> have an old Pentium III box churning out frames -- slowly,
> but every little bit helps.
> 
> With a real linux-based grid and the right code, you can 
> make use of multiple cheap boxes efficiently.  Some code,
> such as ITK, supports chunking in images nicely, so you
> can throw bits of large datasets all over the place when
> doing processing.
> 
> 5) Go dual-core or dual processor on your base machine.
> Even if you can't make use of multiprocessor/parallelized
> code, two processors will really speed things up, particularly
> with memory/cpu-hogging OS's like Windoze.  That way, 
> Microsoft can eat up one processor calling home to Redmond, leaving
> one cpu for real work.
> 
> Thus, you get a performance increase on a dual processor/dual
> core box even in you don't have parallelized code.  If you
> move to a 4/8/16/32/etc processor box, then you have to
> worry about being able to use all the processors efficiently,
> which is very software dependent.
> 
> >
> > - PC or Mac ? Are the new Mac Pro an option ? What are the options for 
> > high-end PCs ?
> 
> I'm a linux/unix kind of guy, so of the two, I'd go with the Mac.
> The overhead and intrusiveness of the OS is lower, it's BSD at
> the core which means that you can tune it with abandon, and
> you don't have to worry with the proprietary/antipiracy stuff 
> in Windows (that will become a much greater hassle in Vista).
> Also, of course, you don't have the issues that Windows has 
> with viruses, etc.  There are always security issues, regardless
> of the OS, but security failure is not part of the design of
> linux/BSD/MacOS X/Solaris.
> 
> 
> Since you are from France, look at Mandriva Linux.  That's
> what I use on most of my machines, and I love it.
> 
> 
> billo
> http://www.billoblog.com/billoblog
>