New fast open-source paq-based jpeg compressor

[Bulat Ziganshin]

no, i don't wrote that, but one of fa users give me an idea - if we borrow jpeg model from paq and make it alone program - how fast it will be? can we keep the same compression level as paq now does? ghow much memory it should require?

hope that Matt can answer this question. if this is possible, we can expect such impelemntation in ccm, lprepaq and freearc next versions

[rip]

stuffit jpeg compression is definitely worth to look at.

[Bulat Ziganshin]

you are gonna to provide us its sources?

[rip]

not exactly. i can only proide you with an idea

can you recall the history of cabarc' lz matching?

[Bulat Ziganshin]

not exactly. i can only proide you with an idea

what idea?

[Piotr Tarsa]

i doubt it will be much faster. maybe two or three times faster (max). memory requirements should be much lower - i guess jpeg model uses only few megabytes.

better encourage packjpg author to open sources of his program. people like christian (author of ccm) can improve performance, other people can develop new useful features (like progressive jpeg handling + non- jfif headers handling) or integrate packjpg with libjpeg for widespread use.

if yaakov gringeler alone made superb entropy coder for jpeg, we all can make better one.

integrating packjpg with libjpeg will make packjpg most popular entropy coder for jpegs and will make stuffit an exotic commercial experiment

[thometal]

i doubt it will be much faster. maybe two or three times faster (max). memory requirements should be much lower - i guess jpeg model uses only few megabytes.

better encourage packjpg author to open sources of his program. people like christian (author of ccm) can improve performance, other people can develop new useful features (like progressive jpeg handling + non- jfif headers handling) or integrate packjpg with libjpeg for widespread use.

if yaakov gringeler alone made superb entropy coder for jpeg, we all can make better one.

integrating packjpg with libjpeg will make packjpg most popular entropy coder for jpegs and will make stuffit an exotic commercial experiment

jeap I agree 100%

[Bulat Ziganshin]

if yaakov gringeler alone made superb entropy coder for jpeg, we all can make better one

of course, we can. this just need time. are you have one?

i doubt it will be much faster. maybe two or three times faster (max).

why? afaik, paq8 contains >50 models, and jpeg model is only one of them

[rip]

what idea?

to take a close look at stuffit.

however, i agreed with donkey7, it would be much better to take packjpg instead.

[Piotr Tarsa]

why? afaik, paq8 contains >50 models, and jpeg model is only one of them

look at http://cs.fit.edu/~mmahoney/compression/#jpeg and compare paq8f and paq8fthis3. they both have identical number of models, but later one has more complex jpeg model. improvement in jpeg compression caused 35 % longer encoding. so this suggests that jpeg model has a very heavy impact on overall speed.

of course, we can. this just need time. are you have one?

i didnt mean creating one from scratch, but for example improving packjpg. it needs some time for ideas to come - if more people will think about jpeg compression algorithm then ideas will come faster (brainstorm ) and main developer can test them.

[Black_Fox1]

if we borrow jpeg model from paq and make it alone program - how fast it will be?

All other models are switched off when JPEG stream is found, arent they?
So it shouldnt boost speed much when used alone IMHO

[Bulat Ziganshin]

i didnt mean creating one from scratch, but for example improving packjpg

i should remind you that we dont have stuffit or packjpg sources

when they will be avalilable, i will just add them to freearc. i dont have time to develop my own jpeg compressor

[Matt Mahoney]

The JPEG model in PAQ turns off all the other models, so taking them out would not help much. However, the regular PAQ model is used to compress the headers, so you would lose a small amount of compression.

[Bulat Ziganshin]

thank you, Matt

so we don't yet have open-source jpeg compressor with acceptable performance

[encode]

Lets wait for PackJPG...

PackJPG should be carefully tested by the author and standardized in favor to keep full backwards compatibility. These days, PackJPG staying as a draft and experimental...