Results 1 to 15 of 15

Thread: New fast open-source paq-based jpeg compressor

  1. #1
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,511
    Thanks
    746
    Thanked 668 Times in 361 Posts
    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

  2. #2
    Member
    Join Date
    Sep 2007
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    stuffit jpeg compression is definitely worth to look at.

  3. #3
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,511
    Thanks
    746
    Thanked 668 Times in 361 Posts
    you are gonna to provide us its sources?

  4. #4
    Member
    Join Date
    Sep 2007
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    not exactly. i can only proide you with an idea

    can you recall the history of cabarc' lz matching?

  5. #5
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,511
    Thanks
    746
    Thanked 668 Times in 361 Posts
    Quote Originally Posted by rip
    not exactly. i can only proide you with an idea
    what idea?

  6. #6
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,475
    Thanks
    26
    Thanked 121 Times in 95 Posts
    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

  7. #7
    Member
    Join Date
    Jun 2008
    Location
    G
    Posts
    372
    Thanks
    26
    Thanked 22 Times in 15 Posts
    Quote Originally Posted by donkey7
    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%

  8. #8
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,511
    Thanks
    746
    Thanked 668 Times in 361 Posts
    Quote Originally Posted by donkey7
    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?

    Quote Originally Posted by donkey7
    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

  9. #9
    Member
    Join Date
    Sep 2007
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Bulat Ziganshin
    what idea?
    to take a close look at stuffit.

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

  10. #10
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,475
    Thanks
    26
    Thanked 121 Times in 95 Posts
    Quote Originally Posted by Bulat Ziganshin
    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.

    Quote Originally Posted by Bulat Ziganshin
    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.

  11. #11
    Member
    Join Date
    Dec 2006
    Posts
    611
    Thanks
    0
    Thanked 1 Time in 1 Post
    Quote Originally Posted by Bulat Ziganshin
    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

  12. #12
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,511
    Thanks
    746
    Thanked 668 Times in 361 Posts
    Quote Originally Posted by donkey7
    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

  13. #13
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    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.

  14. #14
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,511
    Thanks
    746
    Thanked 668 Times in 361 Posts
    thank you, Matt

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

  15. #15
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,985
    Thanks
    377
    Thanked 353 Times in 141 Posts
    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...

Similar Threads

  1. Replies: 23
    Last Post: 24th March 2018, 18:57
  2. BALZ - An Open-Source ROLZ-based compressor
    By encode in forum Data Compression
    Replies: 60
    Last Post: 6th March 2015, 17:47
  3. PeaZip - open source archiver
    By squxe in forum Data Compression
    Replies: 1
    Last Post: 3rd December 2009, 22:01
  4. fcm1 - open source order-1 cm encoder
    By encode in forum Data Compression
    Replies: 34
    Last Post: 5th June 2008, 00:16
  5. Replies: 0
    Last Post: 26th July 2007, 19:47

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •