Home > Archive > Compression > June 2007 > Re: jpeg compression hardware
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: jpeg compression hardware
|
|
| RezaRob 2007-06-12, 6:56 pm |
| On Jun 12, 12:57 am, Thomas Richter <t...@math.TU-Berlin.DE> wrote:
> 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.
Say, in the 800x800 range. I don't think the PC hardware can easily
handle it, unless we devote a couple boxes to it.
Reza.
>
> So long,
> Thomas
| |
| Thomas Richter 2007-06-12, 6:56 pm |
| RezaRob wrote:
> On Jun 12, 12:57 am, Thomas Richter <t...@math.TU-Berlin.DE> wrote:
>
>
>
> Say, in the 800x800 range. I don't think the PC hardware can easily
> handle it, unless we devote a couple boxes to it.
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.
For a high-speed jpeg, see for example www.jpg.com.
So long,
Thomas
| |
| Jan Panteltje 2007-06-12, 6:56 pm |
| On a sunny day (Tue, 12 Jun 2007 18:28:55 +0200) it happened Thomas Richter
<thor@math.TU-Berlin.DE> wrote in <5d7vu7F32ob62U1@mid.dfncis.de>:
>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.
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.
| |
| Thomas Richter 2007-06-12, 6:56 pm |
| Jan Panteltje wrote:
> 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.
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
| |
| Jan Panteltje 2007-06-12, 6:56 pm |
| On a sunny day (Tue, 12 Jun 2007 22:34:56 +0200) it happened Thomas Richter
<thor@math.tu-berlin.de> wrote in <5d8e83F32lritU1@mid.dfncis.de>:
>Jan Panteltje wrote:
>
>
>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
OK buy a PS3 a and code for the helper cores.
Still his example was wrong, I use a full high res 800x600 color,
if it truely was only 3 mS for that, then it would be 100x3 = 300 ms.
That would mean the Px whatever many cores was 120x faster then my Duron.
No way, at the most 12 x (or 20x if dual core).
So I'd like to see his results for a true 800x600 RGB grab with detail
on that machine.
Would surprize me it it was faster then 2 seconds for 100 conversions.
| |
| Pete Fraser 2007-06-12, 6:56 pm |
| "Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:f4moc3$sf$1@news.datemas.de...
> 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.
800 x 600 color image from a camera.
real 0m6.734s
user 0m5.556s
sys 0m3.516s
2.4 GHz Core 2 Duo
> Perhaps he could get some IP for FPGA.
> There must be chips for 30fps, most DV cameras must have one.
DV cameras don't use motion JPEG.
They both use a block-based DCT intra-coding scheme, but there are major
differences.
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.
| |
| John_H 2007-06-12, 6:56 pm |
| X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Complaints-To: abuse@supernews.com
Lines: 19
Xref: number1.nntp.dca.giganews.com sci.electronics.design:817144 comp.compression:76437
"Pete Fraser" <pfraser@covad.net> wrote in message
news:136u51d535je212@news.supernews.com...
<snip>
>
> 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.
....and we'll point you to IP sources like those at
http://www.xilinx.com/ipcenter/ (search for JPEG) and you'll find cores that
could be purchased and implemented on development kits. Are you ready to
purchase IP? Are your ins/outs in the PC realm or dedicated hardware?
| |
| Jan Panteltje 2007-06-12, 6:56 pm |
| Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Trace: news.datemas.de mjOSMA9HsQeWgqeOd+gFA9mb57OWLLfeum/ y589NBx6TZDbXf1dH488XsA7VpGI3nF7eGKF1Y07
/ySQ/ syt2xvgygIXUych2awtxAqQOchKjHDELkq0puZh8
4k9XpYrBo/gEzG7VYAtW1OqHxrz3kINZWasx/flBkBEA14tOqN4=
X-Complaints-To: abuse@datemas.de
NNTP-Posting-Date: Tue, 12 Jun 2007 22:51:19 +0000 (UTC)
X-Newsreader-location: NewsFleX-1.5.7.2 (c) 'LIGHTSPEED' off line news reader for the Linux platform
NewsFleX homepage: http://panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
User-Agent: NewsFleX-1.5.7.2 (Linux-2.6.21)
Xref: number1.nntp.dca.giganews.com sci.electronics.design:817147 comp.compression:76463
On a sunny day (Tue, 12 Jun 2007 14:46:15 -0700) it happened "Pete Fraser"
<pfraser@covad.net> wrote in <136u51d535je212@news.supernews.com>:
>"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
>news:f4moc3$sf$1@news.datemas.de...
>
>
>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
I ran it again, but there is still an other H264 encode running I
cannot interrupt now:
for ((i=0;i<100;i++)); do cjpeg /root/q1.pgm >out.jpg; done
27.19s user 1.53s system 96% cpu 29.758 total
Yours is only 4.1 x faster :-)
Duron rules :-)
| |
| Pete Fraser 2007-06-12, 6:56 pm |
| "Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:f4n817$q0n$1@news.datemas.de...
>
> How long does this one take (the one I used?):
> ftp://panteltje.com/pub/q1.pgm
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 Fraser 2007-06-12, 6:56 pm |
|
"Pete Fraser" <pfraser@covad.net> wrote in message
news:136u9pe6l8b50ac@news.supernews.com...
> "Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
> news:f4n817$q0n$1@news.datemas.de...
>
>
>
> 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?
I should have tried it first.
real 0m42.325s
user 0m40.105s
sys 0m4.273s
I assume it spends most of the time dealing with a
strange 16-bit ASCII input file.
| |
| Jan Panteltje 2007-06-13, 7:56 am |
| On a sunny day (Tue, 12 Jun 2007 16:07:20 -0700) it happened "Pete Fraser"
<pfraser@covad.net> wrote in <136u9pe6l8b50ac@news.supernews.com>:
>"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
>news:f4n817$q0n$1@news.datemas.de...
>
>
>
>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?
Eh, 'pgm' is a standard like ppm.
On Unix (or Linux) type:
man pgm
man ppm
I only used it because somebody else used it.
ppm (color) is even 3 x bigger).
Maybe it would be a bit faster using a binary format.
I used 'gif' first, but then cjpeg told me it was not an open format....
I think gif patent has expired now:
# cjpeg q1.gif > q1.jpg
GIF input is unsupported for legal reasons. Sorry.
:-)
LOL
| |
| Pete Fraser 2007-06-13, 6:56 pm |
| "Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:f4oh3n$kdh$1@news.datemas.de...
> Eh, 'pgm' is a standard like ppm.
> On Unix (or Linux) type:
> man pgm
> man ppm
> I only used it because somebody else used it.
> ppm (color) is even 3 x bigger).
> Maybe it would be a bit faster using a binary format.
I think a binary format would be much faster.
I think most of thee time is taken in reading
the ASCII image file.
| |
| Steven Pigeon 2007-06-14, 7:56 am |
| Pete Fraser wrote:
> "Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
> news:f4oh3n$kdh$1@news.datemas.de...
>
>
> I think a binary format would be much faster.
> I think most of thee time is taken in reading
> the ASCII image file.
>
>
PPM/PGM support both ascii and binary formats.
The major advantage of ppm/pgm is the very simple
parsing. If you write a minimalist implementation,
reading the header ask for little more than scanf.
As temporary or interchange file format, it's
fine.
Best,
S.
| |
|
|
| joseph2k 2007-06-16, 3:56 am |
| Jan Panteltje wrote:
> On a sunny day (Tue, 12 Jun 2007 18:28:55 +0200) it happened Thomas
> Richter <thor@math.TU-Berlin.DE> wrote in <5d7vu7F32ob62U1@mid.dfncis.de>:
>
>
>
> 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.
How very bizarre. I suppose that some implementations the algorithms for
jpeg may be encode / decode asymmetric (they should not be). My digital
camera uses jpeg encoding in many modes, on a very ordinary computer not
using Manufacturer specific software, the pictures appear immediately. My
camera does not seem to spend much time encoding the pictures either, it
has modes to take 5 frame groups varied by f-stop, and it is always ready
as soon as i press the shutter button again. I really doubt that even with
a custom jpeg IP FFT component that the algorithm takes all that much time.
As for the very, very poor performance of that particular PC program, i will
never use that program. thanks for the review. How about you write a
better program, i am sure that you can. (yes i have been through your web
site, seen years of your posts, etc.,)
--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.Â_Â_
--Schiller
| |
| joseph2k 2007-06-16, 3:56 am |
| Thomas Richter wrote:
> Jan Panteltje wrote:
>
>
> 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 don't know about you but at 800 X 600 i expect it to perform at 30 FPS or
more encode or decode.
--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.Â_Â_
--Schiller
| |
| Jan Panteltje 2007-06-16, 6:55 pm |
| On a sunny day (Sat, 16 Jun 2007 03:08:01 GMT) it happened joseph2k
<quiettechblue@yahoo.com> wrote in
<luIci.14641$RX.132@newssvr11.news.prodigy.net>:
>How very bizarre. I suppose that some implementations the algorithms for
>jpeg may be encode / decode asymmetric (they should not be). My digital
>camera uses jpeg encoding in many modes, on a very ordinary computer not
>using Manufacturer specific software, the pictures appear immediately. My
>camera does not seem to spend much time encoding the pictures either, it
>has modes to take 5 frame groups varied by f-stop, and it is always ready
>as soon as i press the shutter button again. I really doubt that even with
>a custom jpeg IP FFT component that the algorithm takes all that much time.
>
>As for the very, very poor performance of that particular PC program, i will
>never use that program. thanks for the review. How about you write a
>better program, i am sure that you can. (yes i have been through your web
>site, seen years of your posts, etc.,)
Hi, thank you for the compliment.
I am writing some other program atm..
Just after I wrote that thing about the FPGA, I got an Altera email pointing to this:
http://www.altera.com/products/ip/d...g/ipm-index.jsp
I dunno about pricing, but it has free trial.
Depending on what the OP wants, he could use a standalone or PCI[e] card with FPGA.
I myself have a small digital video camera that directly encodes to mpeg4.... 640x480@30fps,
on SDcard, so there are chips for that too it seems.
The other way is buying a Sony PS3, it has a Cell processor, runs Linux, and there are
I think 6 peripheral processors available, but programming those is not easy.
PS3 is expected to fall in price by about 100$ (or Euro) before the end of the year....
This may be cheaper then FPGA.... gives you some good games too :-)
| |
| Jan Panteltje 2007-06-16, 6:55 pm |
| On a sunny day (Sat, 16 Jun 2007 03:10:54 GMT) it happened joseph2k
<quiettechblue@yahoo.com> wrote in
<2xIci.14642$RX.2144@newssvr11.news.prodigy.net>:
>Thomas Richter wrote:
>
>I don't know about you but at 800 X 600 i expect it to perform at 30 FPS or
>more encode or decode.
If you think 'mplayer' or 'xine' yes, it does many more fps then 30 in mpeg2
and Divx etc. on my box.
Only H264 is slower.
But I think this is highly optimized code written in asm.
There is a difference between 'encoding' and 'decoding' it seems.
mcamip http://panteltje.com/panteltje/mcamip/ uses libjpeg, and decodes
about 25fps on a Duron 1GHz last time I looked (tha tcamera supplies
a chain of jpeg pictures).
I wrote that :-)
libjpeg all by itself should do more.
Different from previous shell shown scripts though.
| |
| Thomas Richter 2007-06-18, 3:55 am |
| Jan Panteltje wrote:
Me, too. (-:
[color=darkred]
> If you think 'mplayer' or 'xine' yes, it does many more fps then 30 in mpeg2
> and Divx etc. on my box.
> Only H264 is slower.
> But I think this is highly optimized code written in asm.
It contains a couple of assembly optimizations, truely.
> There is a difference between 'encoding' and 'decoding' it seems.
For JPEG-1, encoding and decoding are rather symmetric. It shouldn't
make much of a difference.
> mcamip http://panteltje.com/panteltje/mcamip/ uses libjpeg, and decodes
> about 25fps on a Duron 1GHz last time I looked (tha tcamera supplies
> a chain of jpeg pictures).
> I wrote that :-)
> libjpeg all by itself should do more.
> Different from previous shell shown scripts though.
Definitely. It was only a very very rough test to get some numbers,
nothing more.
So long,
Thomas
|
|
|
|
|