JPEG-LS hardware implementation

Oct 04, 2007 8 Replies

Hi All,



We are an enthusiasts who are written hardware JPEG-LS IP core. Visit project site

formatting link



It's working in the simulator and we are sure about it. Although sufficient effort should be applied to public this project and prove its rights to life :) In case if we decide to do it the big amount of work appears in front of us: we have to write full documentation, assemble set of demo testbenches, fit and verify core with many FPGA chips and make some software utilities.



Therefore I would hear some opinions from the community about such type of projects: is it really interest for somebody or it will be simple junk efforts. What do you think about practical usage hardwared compression? Who can be interested in it?



We haven't careful thought about licensing terms yet, but I expect it will be free core in any way. There are some reasons to don't open sources so we can't apply GNU but GPL looks quite well.



P.S. I know about opencores.org and I've had done two projects there, so I'll probably place jpeg-ls coder too.



Digitally yours, Michael



formatting link



Link doesn't work ?

Regards, Bart

No, it works now. Periodically somebody ddos-attacked hosting and site goes down. But I hope it's temporary problem.

I've tried about 20 times over the last 24 hours (since you first posted on comp.compression).

No luck.

Hi cms, Good work !

If you have your VHDL code open, please give me a copy.

Thank you.

Weng

Thank you for the high asset our efforts.

We haven't made final decision about future of the project yet so I can't open sources now but I think it'll be possible soon.

Digitally yours, Michael

Hi Michael,

  1. What is your chip used? Why is it limited to 75 MHz?

  1. I haven't read the specs of JPEG-98-LS (I will certainly later). What algorithm is used to beat arithmetic encoding? Can you give some tips?

Weng

We use Altera StratixII GX EP2SGX30DF780C3

formatting link
Single-clock per pixel implementation results in a big combinational fragments that impact project speed. According to the base JPEG-LS standart we have to update four variables for each pixel during one clock cycle in the fact. The bad moment is that core speed significally degradates when pixel width ascending.

The JPEG-LS algorithm includes two operation: context modeling and encoding prediction error by the Golomb-Ryce procedure. For natural images prediction error has a geometrical distribution therefore Golomb coding is optimal for. I have an idea about model enhancement and error encoding which makes implementation faster but in this case core will not be compatiable with ITU-T 87 standard. I think finally there are two branches of the core: slow, but fully- compatable with ITU-T 87 one and own high-performance compressor.

Digitally yours, Michael

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required