jpeg compression hardware

Found the answer:

robert

On a sunny day (Tue, 12 Jun 2007 16:07:20 -0700) it happened "Pete Fraser" wrote in :

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

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.

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

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

On a sunny day (Sat, 16 Jun 2007 03:08:01 GMT) it happened joseph2k wrote in :

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:

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 :-)

On a sunny day (Sat, 16 Jun 2007 03:10:54 GMT) it happened joseph2k wrote in :

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

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.

Me, too. (-:

It contains a couple of assembly optimizations, truely.

For JPEG-1, encoding and decoding are rather symmetric. It shouldn't make much of a difference.

Definitely. It was only a very very rough test to get some numbers, nothing more.

So long, Thomas