0
\$\begingroup\$

Physicist here, so please be gentle ;-) I am designing a device to acquire in a few seconds a large amounts of images (a few terabytes), that then need to be analysed, possibly on the fly. Is there a way to screen the images and filter them before saving them, so to store in memory only those with the desired features? Thanks!


The setup I'm describing already exists (http://www.pnas.org/content/109/29/11630.full) and I am looking for ideas to improve it (the quantity of generated data is enormous, and improving the pre-screening would help to make the cells detection faster).

Regarding the accepted answer, the process could be

Data → SDRAM storage → GPU/FPGA prescreening → storage of the selected images → CPU processing

right? Please correct me if I got it wrong.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ You'll have to be a lot more specific about what the screening algorithm is. In general, you'll store all the images temporarily in SDRAM, and then transfer the ones you want to keep from there to permanent storage. But any system that can handle 1 TB/sec (or more) probably involves a lot of FPGAs operating in parallel. \$\endgroup\$
    – Dave Tweed
    Mar 30, 2016 at 14:45
  • \$\begingroup\$ Regarding the algorithm: I am still designing it, but it will probably consist of a few basic image manipulation tasks - thresholding, binarization, area measurement, ... \$\endgroup\$
    – user105233
    Mar 30, 2016 at 14:51
  • 1
    \$\begingroup\$ "A few terabytes" - ! This is going to be quite the system. \$\endgroup\$
    – pjc50
    Mar 30, 2016 at 14:58
  • \$\begingroup\$ @pjc50: Yes. I work in high-definition realtime video imaging processing, and I wouldn't try to process more than about 1 GB/sec in a single FPGA, so I'm envisioning something on the order of 1000 FPGAs, each with several GB of DDR SDRAM attached. I'd love to design such a system -- it would be quite a challenge! \$\endgroup\$
    – Dave Tweed
    Mar 30, 2016 at 15:05
  • 2
    \$\begingroup\$ I've added key information from one of your comments to the question. You should have done this up front. It turns out that the "images" are 1-D, and the existing architecture already has the image sensor feeding an FPGA, which puts relevant data into SDRAM, from where it is further screened by a CPU. So, are you looking for improvements in the FPGA design, or in the CPU throughput? \$\endgroup\$
    – Dave Tweed
    Mar 30, 2016 at 15:58

1 Answer 1

1
\$\begingroup\$

The answer is trivially 'yes there is'. However, can you afford it?

If the save/dump criterion is as simple as 'average of all pixel values' > 128, then you may well be able to build it straight into the raft of buffers you will need to accept the image data from the sensors and handle the storage. If the save/dump criterion is 'does Google's online image recogniser see a dog?' then I doubt Google will let you have the bandwidth, and you will have to build an equivalent.

I suggest you code up your save/dump criterion in C, and see how fast it runs on a commercial PC. There's not the remotest possibility it will run fast enough, but it will let you see how many orders of magnitude you are short, and let you develop some benchmarks, and perhaps simplify the algorithm.

Then port it to a massively multicore GPU, you might find you don't need too many. A few PC's, each containing a number of GPUs is going to be cheaper and easier to develop with than any bespoke FPGA based system. Once you've demonstrated a few GPUs won't cut it, then you go to a raft of FPGAs, or ask Alphabet nicely.

\$\endgroup\$
7
  • \$\begingroup\$ What are you assuming is handling the 1 TB/sec I/O bandwidth? A GPU has a lot of compute power, but relatively little memory, and the I/O bandwidth is limited to a few video channels and a PCIe memory channel -- a few GB/sec at most. \$\endgroup\$
    – Dave Tweed
    Mar 30, 2016 at 15:07
  • \$\begingroup\$ He's designing a device to do it, that's not part of the question. It would have to provide a wide enough, fast enough interface, a few PXIe lanes perhaps. \$\endgroup\$
    – Neil_UK
    Mar 30, 2016 at 15:11
  • \$\begingroup\$ @Neil_UK: thanks for the info. In terms of speed, would you expect the GPUs-based solution to be faster than the FPGA-based one? \$\endgroup\$
    – user105233
    Mar 30, 2016 at 15:12
  • \$\begingroup\$ @albus_c - No, read my answer, it would be cheaper and easier to develop, there are all sorts of tools available now to port both image processing functions and general purpose parallel code onto GPUs. I would expect FPGAs to be smaller and use less power though, so if you'd got to several MOBOs of several GPUs and were still an order of magnitude or two adrift, then you may find it better to switch to an FPGA solution. \$\endgroup\$
    – Neil_UK
    Mar 30, 2016 at 15:16
  • 1
    \$\begingroup\$ You are right about the algorithm development. I'm focusing on the I/O requirements, but maybe I'm misunderstanding what the OP actually means by "memory". I suppose it's possible that the image acquisition system is already buffering the data in SDRAM, and that the screening can occur at a much lower rate. But even at 1 GB/s, we're talking about something on the order of a hour to screen "a few terabytes" of data. \$\endgroup\$
    – Dave Tweed
    Mar 30, 2016 at 15:29