Jpeg routines out there ?

pjr

I need a routine to decode and render a jpeg file. Did a search on obex and found nothing.
Can anyone help ?

Duane Degn

I don't know of any code to decode a jpeg with a Propeller.

I'd also like to be able to decode a jpeg. I have one of these LinkSprite cameras I'd like to be able to use with a Prop.

Even with the ablity to decode a jpeg, a Prop is going to have a hard time displaying anything except very small images because of the memory limitations of the Propeller.

Rayman

I have a few types of Solomon graphics chips lying around waiting for me to get busy...

One of them can decode and encode jpg files either from memory or an attached SD card.
Still dreaming of getting that working with the Prop one day...

But, Prop2 might come sooner and then you can uses existing C code to do it...

Rayman

Actually, you might be able to do it with Catalina or GCC and external memory on Prop 1. But, I think it would be very, very slow...

ericball

I suspect libjpeg (http://www.ijg.org/ ) could be compiled with Catalina or GCC and given sufficient external memory an image could be decoded. Slow is a relative term, but given the Prop 1 doesn't have a hardware multiply that's going to mean the multiply intensive DCT is going to take a lot of cycles.

However, the bigger question is what are you going to do with the bitmap once it's decoded. About the only external memory video driver I know of is Dr.Acula's http://forums.parallax.com/showthread.php?134209-256x224-video-driver

Dave Hein

I was able to port the IJG code to a C3 board using PropGCC. I used the XMM mode to execute code from flash. The IJG code uses malloc to allocate memory buffers. I wrote a malloc interface routine to allocate small buffers from hub RAM and large buffers from external RAM. The program was able to encode and decode the sample image that was provided with the source code. It took around a minute to 1.5 minutes do encode/decode the image, which is around 200x150 in size.

The IJG code is a good starting point, but it will require a lot of optimization to make it work well on the Prop. The DCT/.IDCT can be made much faster by running it in a cog and using a fast butterfly algorithm. Other areas that would need optimizing are the variable length encoder/decoder and the quantizer. The memory usage needs to be made more efficient. You will need a 16-line buffer for each component that is the full width of the image. For an image that is 256 pixels wide, you would need 256x16x3 = 12K of memory to buffer 16 lines.

Rayman

Nice work Dave. I'm impressed.

Ale

Nice,

I am sure a handful of COGs can be dedicated to the encode/decode. I remember that my 286 @ 16 MHz was able to decode a 256x256 pixel JPG in a few minutes.... minutes!! , and it had multiplier !

pedward

I would have to think that if a 386DX-40 could be workable at the beginning of the WWW era, a Prop 1 has the horsepower to decode JPEG in a reasonable time. The 386 had a lot of variable length instructions, and corresponding variable cycle times.

BTW, I ran a 386DX-40 with windows using Winsock and Netscape 0.9, by the power of grayskull it can be done!

Ale

I had a 486 in the internet era of '96... plenty of those jpgs were 10kbytes or less in size, and plenty of those graphics were actually gifs ... win 3.11 and the win32s extensions... that thing was slow!... I friend of mine got win95 on a 386... that is patience! ;-).. I thought win95 required a 486... it doesn't matter anymore, I think...

Dave Hein

The attached zip files contains the port I did for PropGCC. You have to download the JPEG source from the IJG site and copy the files from the zip file into the source directory. The instructions are in the readme.txt file in the zip file.

pedward

To get reasonable JPEG support, one will have to write it in PASM. I've written a lot of C code, and I haven't seen anything but the simplest of code, turned into ASM that would do as well as a human. Face it, C just ain't gonna cut it for breakneck speed and it never has, ASM has always ruled.

If I could find time, I *WOULD* write a JPEG decoder and perhaps encoder in PASM, since I see this as one of the hurdles that should be jumped to extend the Prop further into other areas. There are a lot of $10 CMOS cameras that spit out JPEG directly, and for machine vision I think this will be necessary, not to mention the fact that JPEG can store an image in much smaller space, so it's memory efficient for OSD graphics.