R
RezaRob
- Jan 1, 1970
- 0
We may need to compress in the order of 100 jpegs per second. Any
ideas if there is good hardware for this?
Thanks.
Reza.
ideas if there is good hardware for this?
Thanks.
Reza.
RezaRob said:We may need to compress in the order of 100 jpegs per second. Any
ideas if there is good hardware for this?
We may need to compress in the order of 100 jpegs per second. Any
ideas if there is good hardware for this?
Thomas said:Of which size? If the image sizes are not too large, it doesn't sound
too unrelaistic that you can do that with off-the-shelve PC hardware.
RezaRob said:We may need to compress in the order of 100 jpegs per second. Any
ideas if there is good hardware for this?
RezaRobwrote:
Of which size? If the image sizes are not too large, it doesn't sound
too unrelaistic that you can do that with off-the-shelve PC hardware.
We may need to compress in the order of 100 jpegs per second. Any
ideas if there is good hardware for this?
Thanks.
We may need to compress in the order of 100 jpegs per second. Any
ideas if there is good hardware for this?
RezaRob said:Say, in the 800x800 range. I don't think the PC hardware can easily
handle it, unless we devote a couple boxes to it.
There probably is, seeing that MJPEG (Motion-JPEG, not to be confused with
MPEG) is nothing but a stream of individual JPEGS.
Correct.
This is the format that,
for instance, Mini-DV cameras use
I don't think so.
thor@mersenne:~> time for ((i=0;i<100;i++)); do cjpeg
<~/WWW/imco/Downloads/lena_o.pgm >out.jpg; done
real 0m2.372s
user 0m1.128s
sys 0m0.204s
This is a 512x512 greyscale image, on a off-the-shelve, not new, P4 3.2
Ghz machine using the standard, not-fully-optimized simple IJG code, and
it gets 100 images/sec. Now pick a larger image, color, a more recent
machine and a high-speed code, probably a dual-core CPU from the store
next block and you're there. It's not entirely unrelastic.
Jan said:I get very different results with a real 800x600 X windows grab
import q1.ppm
-rw-r--r-- 1 root root 7928769 2007-06-12 20:14 q1.ppm
import q1.pgm
-rw-r--r-- 1 root root 2675036 2007-06-12 20:16 q1.pgm
((i=0;i<100;i++)); do cjpeg q1.pgm > out.jpg; done
about 40 seconds on 1GHz Duron.
Zoran (NASDAQ:ZRAN) used to make a chipset that did this; it was used
for many MJPEG boards such as the Iomega BUZ and Pinnacle DC30 and
DC50 about 8 years ago. Unfortunately I can't find information on
their corporate website about it, but it's possible they still sell
and support it.
What do you expect from this machine? (-:
Let's get realistic, please. Nothing against this machine, but a
Duron is not a high-end CPU, and 1Ghz is not exactly up-to-date either.
So long,
Thomas
I get very different results with a real 800x600 X windows grab
import q1.ppm
-rw-r--r-- 1 root root 7928769 2007-06-12 20:14 q1.ppm
import q1.pgm
-rw-r--r-- 1 root root 2675036 2007-06-12 20:16 q1.pgm
((i=0;i<100;i++)); do cjpeg q1.pgm > out.jpg; done
about 40 seconds on 1GHz Duron.
Perhaps he could get some IP for FPGA.
There must be chips for 30fps, most DV cameras must have one.
Have you (op) looked at using an FPGA board as a coprocessor (or even
standalone)?
There are many inexpensive boards that could easily do what you need, but
you'd
need to write some VHDL or Verilog code.
There's a lot of code at opencores.org, but I haven't used any of it.
If you consider FPGAs, comp.arch.fpga is a good source of advice.
800 x 600 color image from a camera.
real 0m6.734s
user 0m5.556s
sys 0m3.516s
2.4 GHz Core 2 Duo
How long does this one take (the one I used?):
ftp://panteltje.com/pub/q1.pgm
Pete Fraser said:I'm not sure if I'm interpreting it incorrectly,
but it seems to be a lot of ASCII numbers.
I just read the spec. That's a strange one.
Should I do the timing reading the ASCII?
I'm not even sure if cjpeg can read ASCII images.
Why is it a 16-bit image?
Pete said:Wrong.