Page 1 of 2 12 LastLast
Results 1 to 30 of 41

Thread: ETA on packjpeg 2.4 ?

  1. #1
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts

    ETA on packjpeg 2.4 ?

    Does anybody know when packjpeg 2.4 will get released. and why its taking so long time.

    its rellaly seem to be much better then the old 2.3 version (tested by using precomp)

  2. #2
    Member
    Join Date
    Oct 2007
    Location
    Germany, Hamburg
    Posts
    408
    Thanks
    0
    Thanked 5 Times in 5 Posts
    You really think it is still in development?
    Sorry, but it is obvious that he stopped active working on it. If it is only temporarily or if it was the last version only he knows it...

  3. #3
    Member
    Join Date
    Aug 2009
    Location
    Bari
    Posts
    74
    Thanks
    1
    Thanked 1 Time in 1 Post
    Is there a mod-improved version of packjpeg?

  4. #4
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts
    Precomp has the packjpeg 2.4 beta implantend inside it.

    it give smaller files and sofar less troubles then pack jpeg 2.3

    woudl wish someone would make a qucik rapper for the packjpg dll. as precompts si much slower than just using packjpg

  5. #5
    Member
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Can't tell yet, but soon... :-)

    Hey, thanks for your interest in my work. Actually, I'm still working on packJPG. Real life(tm) slowed down development over the last few (actually: many) months, but I'm back on track and the v2.4 is planned for a release real soon. Can't tell a exact date yet, though. If everything goes as planned, it's before christmas, if not it's January or February.

    The version incorporated in precomp was a beta version. I made some more improvements on compression and speed in the meantime. You can also look forward to a special packJPG SFX format and a third-party-made GUI with this release.

  6. #6
    Member
    Join Date
    Oct 2007
    Location
    Germany, Hamburg
    Posts
    408
    Thanks
    0
    Thanked 5 Times in 5 Posts
    Good to read I was wrong even if it seemed so for followers.
    I am excited to get a better and hopefully more robust version

  7. #7
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    Matthias, are you fixed those crashes on unusual data? people often use packjpg as a part of precomp (and then as part of FreeArc -max, for example) and these crashes somewhere inside complex compression task makes them angry

  8. #8
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    325
    Thanks
    18
    Thanked 6 Times in 5 Posts
    New Version of packJPG released! V2.3c is now available

    - crash issue with certain images fixed
    - compatibility with packJPG v2.3 maintained

    http://www.elektronik.htw-aalen.de/packjpg/

  9. #9
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts
    Does this 2.3c version have the same compressions as te 2.4alpha in precomp ?


    i use precomp instead of packjpeg because it makes smaller files

  10. #10
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by Intrinsic View Post
    New Version of packJPG released! V2.3c is now available

    - crash issue with certain images fixed
    - compatibility with packJPG v2.3 maintained

    http://www.elektronik.htw-aalen.de/packjpg/
    How about making a library that would let image viewers display .pjg files?

  11. #11
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts
    Quote Originally Posted by m^2 View Post
    How about making a library that would let image viewers display .pjg files?
    its a great idea. but i think pjg format need to stabilize first

  12. #12
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    Yes, idea is great but implementation will be quite problematic due the symmetric nature of PackJPG. For example on my system an 4,6 MB high quality camera shot is compressed\decompressed in about 8 seconds. So realize how annoying it will be to wait before appearing of new picture in your viewer.

  13. #13
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by Skymmer View Post
    Yes, idea is great but implementation will be quite problematic due the symmetric nature of PackJPG. For example on my system an 4,6 MB high quality camera shot is compressed\decompressed in about 8 seconds. So realize how annoying it will be to wait before appearing of new picture in your viewer.
    I agree this is a major issue, but IMO not a show-stopper.
    -It's still perfectly fine for smaller files. On Core2@1.8 that I'm using now, unpacking a 300 KB pjg takes less than starting an image viewer.
    -If you need to view a pjg, it's much faster to do it directly than to start a command line, decompress, view, delete the .jpg.
    -It makes it much more newbie friendly

    I guess that it could be made faster at the expense of having files bigger, but I think that being just 5-10% smaller than jpg, won't win PackJPG any popularity.

    Quote Originally Posted by SvenBent View Post
    its a great idea. but i think pjg format need to stabilize first
    It's great that you like it.
    I want to write a Total Commander plugin and start to actually use it.
    Last edited by m^2; 13th December 2009 at 22:23.

  14. #14
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    I just received:
    Code:
    Decompressing JPEG image data -> warning (skipped file):
     reconstruction of non optimal coding not supported
    Could you please tell what's up? I got it during compression.

    Also, I have a feature request:
    could you make a bit-lossy, but pixel-lossless mode? I see that the files optimized with jpegtran are bigger after packjpg compression. And many has the issue mentioned above.
    Last edited by m^2; 14th December 2009 at 17:57.

  15. #15
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    325
    Thanks
    18
    Thanked 6 Times in 5 Posts
    PackJPEG performs best on plain JPEG files, ie no Huffman table optimisation or progressive encoding.

    StuffIT performs best on JPEGs which have had their Huffman tables optimised.

    Both dislike progressive encoding, so while progressive JPEGs will the majority of the time be smaller on disk, you'll get less benefit from compression with PackJPEG and StuffIT.

    Here is an example of a bunch of files i was testing on yesterday:



    I basically grab a bunch of files from various test sets and zap them with one of my scripts(through Directory Opus of course) like this:

    md JSpaz
    jpegtran.exe -copy none -outfile .\JSpaz\{file} {file}
    md JSpazOpt
    jpegtran.exe -copy none -optimize -outfile .\JSpazOpt\{file} {file}
    md JSpazProgOpt
    jpegtran.exe -copy none -optimize -progressive -outfile .\JSpazProgOpt\{file} {file}

    I then process each of the directories with a command like this:

    arc create -mprecomp+rep:128mb:24 ..\{file}-131209-prec-r24-128 *.* > ..\{file}-131209-prec-r24-128.log

    (that line should help you understand the format i use for tests, ie 131209 is the date format(dd/mm/yy), prec = precomp, r24-128 = rep:128mb:24

    And as you can see in the above image PackJPEG(through precomp) gives it's best results on plain ol JPEGs.

    And like you by the sounds i go for pixel-exact compression for picture formats, and for that i have another script which converts a JPEG into both a Huffman table optimised version but no progressive encoding and also one with both, then it compares the sizes and gives me back the smallest file. The majority of the time a file is smaller with both Huffman + Progressive, but sometimes(esp on smaller pictures) progressive hurts the filesize. For those who twitch at the sound of this jpegtran does this completely pixel-lossless ;p

    As for your picture problem i could take a look at the offending image for you if you want, or you could check it out with JPEGSnoop

    jpegtran can also fix some jpeg errors if you use -progressive on it.

  16. #16
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by Intrinsic View Post
    And like you by the sounds i go for pixel-exact compression for picture formats, and for that i have another script which converts a JPEG into both a Huffman table optimised version but no progressive encoding and also one with both, then it compares the sizes and gives me back the smallest file. The majority of the time a file is smaller with both Huffman + Progressive, but sometimes(esp on smaller pictures) progressive hurts the filesize.
    Yes, I also have such script. And it optimizes pngs and gifs too.

    Quote Originally Posted by Intrinsic View Post
    As for your picture problem i could take a look at the offending image for you if you want, or you could check it out with JPEGSnoop

    jpegtran can also fix some jpeg errors if you use -progressive on it.
    I downloaded the program, but don't understand the output, so I uploaded a sample:
    http://i46.tinypic.com/6ynync.jpg

    I think the jpg is valid, just for some reason unsupported by PackJPG.

  17. #17
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    Quote Originally Posted by m^2 View Post
    I downloaded the program, but don't understand the output, so I uploaded a sample:
    http://i46.tinypic.com/6ynync.jpg

    I think the jpg is valid, just for some reason unsupported by PackJPG.
    Are you sure? It works for me with 2.3c version:
    Code:
    --> packJPG v2.3c (11/28/2009) by Matthias Stirner <--
    Copyright 2006-2009 HTW Aalen University & Matthias Stirner
    All rights reserved
    
    
    Processing file 1 of 1 "6ynync.jpg" ->
    ----------------------------------------
    Determining filetype                 0ms
    Reading header & image data         46ms
    Decompressing JPEG image data       47ms
    Checking values range                0ms
    Applying prefilter to DC             0ms
    Calculating scanorder                0ms
    Calculating zero dist lists         15ms
    Compressing data to PJG            594ms
    ----------------------------------------
    -> Compressing OK
     time taken  :     734 msec
     byte per ms :     474 byte
     comp. ratio :   80.80 %
    
    
    
    -> 1 file(s) processed, 0 error(s), 0 warning(s)
     ---------------------------------
     time taken        :      750 msec
     avrg. byte per ms :      463 byte
     avrg. comp. ratio :    80.80 %
     ---------------------------------
    Decompression works too.

    P.S. Please, no LOSSY modes or at least optionally.

  18. #18
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by Skymmer View Post
    Are you sure? It works for me with 2.3c version:
    Code:
    --> packJPG v2.3c (11/28/2009) by Matthias Stirner <--
    Copyright 2006-2009 HTW Aalen University & Matthias Stirner
    All rights reserved
    
    
    Processing file 1 of 1 "6ynync.jpg" ->
    ----------------------------------------
    Determining filetype                 0ms
    Reading header & image data         46ms
    Decompressing JPEG image data       47ms
    Checking values range                0ms
    Applying prefilter to DC             0ms
    Calculating scanorder                0ms
    Calculating zero dist lists         15ms
    Compressing data to PJG            594ms
    ----------------------------------------
    -> Compressing OK
     time taken  :     734 msec
     byte per ms :     474 byte
     comp. ratio :   80.80 %
    
    
    
    -> 1 file(s) processed, 0 error(s), 0 warning(s)
     ---------------------------------
     time taken        :      750 msec
     avrg. byte per ms :      463 byte
     avrg. comp. ratio :    80.80 %
     ---------------------------------
    Decompression works too.

    P.S. Please, no LOSSY modes or at least optionally.
    Tinypic recompressed it.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	jpg.jpg 
Views:	417 
Size:	632.7 KB 
ID:	1168  

  19. #19
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    Yes, now it works... Brrrrr... Doesn't work By the way, very nice example. Not only it refused by PackJPG but it also makes JPEGsnoop to choke a little bit. More exactly speaking JPEGsnoop's preview is not shown for this file, although it should. PreComp's PackJPG also out of luck. PAQ8px_67 doesn't recognise this file as JPEG. WinZIP 14 says that "Note: this file is not supported by JPEG compression. Using Enhanced Deflate instead". Only tool which done it was StuffIT. I'll put this file in my collection. Thanks m^2 !

  20. #20
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    325
    Thanks
    18
    Thanked 6 Times in 5 Posts
    I found the problem, it has some non-transformable edge-blocks, and when encoded as a progressive jpeg packjpeg doesn't like it. It fails if the image dimensions are not a multiple of the iMCU size (usually 8 or 16 pixels), because they can only transform complete blocks of DCT coefficient data.
    You can see what happens in tools that don't follow -perfect(in jpegtran) like IrfanView when you try todo a lossless jpeg transform it starts dropping those edge blocks it can't transform perfectly.

    You can see the error occur using this line:
    jpegtran.exe -copy all -optimize -progressive -rotate 90 -perfect -outfile jpg-jt.jpg jpg.jpg

    If only the Huffman tables are optimised(or not) then it works without a problem.

    StuffIT(v9) accepts this file regardless.

  21. #21
    Member Raymond_NGhM's Avatar
    Join Date
    Oct 2008
    Location
    UK
    Posts
    51
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Post

    Quote Originally Posted by Intrinsic View Post
    I found the problem, it has some non-transformable edge-blocks, and when encoded as a progressive jpeg packjpeg doesn't like it. It fails if the image dimensions are not a multiple of the iMCU size (usually 8 or 16 pixels), because they can only transform complete blocks of DCT coefficient data.
    You can see what happens in tools that don't follow -perfect(in jpegtran) like IrfanView when you try todo a lossless jpeg transform it starts dropping those edge blocks it can't transform perfectly.

    You can see the error occur using this line:
    jpegtran.exe -copy all -optimize -progressive -rotate 90 -perfect -outfile jpg-jt.jpg jpg.jpg

    If only the Huffman tables are optimised(or not) then it works without a problem.

    StuffIT(v9) accepts this file regardless.
    1st. don't miss, be careful, you need to see packjpg's "readme.txt"

    Because packjpg, that can autofix (built in) some progressive or non progressive JPEGs
    problems (with -p switch), during on compression as well as than other fixer tools.

    packjpg -p jpg.jpg

    --> packJPG v2.3c (11/28/2009) by Matthias Stirner <--
    Copyright 2006-2009 HTW Aalen University & Matthias Stirner
    All rights reserved

    Processing file 1 of 1 "jpg.jpg" -> Compressing -> 74.17% (hummm good compression...)

    -> 1 file(s) processed, 0 error(s), 1 warning(s)


    Well...then decompress in new file & compare it with original JPG
    & you can see from offset=0x8e263 & later modified with packjpg... nice...
    & without any problem.

    (647,851 bytes) Original
    (647,707 bytes) Fixed
    (480,479 bytes) Packed


    2nd. WinZIP v12/v13/v14 DO NOT support PROGRESSIVE JPEGs yet,
    however winzip in some cases a little bit better than packjpg.
    StuffIT: a big package/commercial, it's no likely compression tool.
    PAQ8xxx, is slower & time waster...

    Result: Packjpg smaller/optimal tool for JPEGs
    Next in new features, i want to see for complete to arena of the pleasure...
    GUI version/compression+generation in archive (.PJA & make SFX)

  22. #22
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    Quote Originally Posted by Raymond_NGhM View Post
    WinZIP v12/v13/v14 DO NOT support PROGRESSIVE JPEGs yet,
    however winzip in some cases a little bit better than packjpg.
    Well, yes, the lack of support for Progressive JPEGs is drawback but wait for results of my JPEG test which I started a couple of days ago. I just need to wait until PAQ8px will end its job but I'm already can say that WinZIP noticeably packs better then PackJPG and much faster.

  23. #23
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Idea:
    Stronger modes that try different c/s parameters and take the smallest result. About what suggested here, but done internally.

  24. #24
    Member Fallon's Avatar
    Join Date
    May 2008
    Location
    Europe - The Netherlands
    Posts
    154
    Thanks
    14
    Thanked 10 Times in 5 Posts

    Post

    Releases of packJPG: V2.4
    http://www.elektronik.htw-aalen.de/packJPG/index.htm

    List of improvements over v2.3c:

    - improved compression: typical file size reduction is now 23%...24%
    - around 10% faster compression & decompression
    - major improvements to JPG compatibility
    - UPX compression removed due to false alerts in virus scanners
    - new switch: [-ver] (verify file after processing)
    - new switch: [-np] (no pause after processing)
    - new progress bar output mode
    - arithmetic coding routines rewritten from scratch
    - various smaller improvements to numerous to list here
    - new SFX (self extracting) archive format

  25. #25
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts

  26. #26
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    325
    Thanks
    18
    Thanked 6 Times in 5 Posts
    Superb, can't wait to test it out and see if it matches StuffIT.

  27. #27
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by SvenBent View Post
    Quote Originally Posted by m^2 View Post
    How about making a library that would let image viewers display .pjg files?
    its a great idea. but i think pjg format need to stabilize first
    Any news?

  28. #28
    Member Raymond_NGhM's Avatar
    Join Date
    Oct 2008
    Location
    UK
    Posts
    51
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Thumbs up

    I glad to say...
    Now PackJPG 2.4 "absolutely" better than WinZip & take 3rd rank after PAQ & Stuffit,

    Well,
    The one of best feature key in v2.4, it make Solid (PJA --> SFX) archive in
    during compress multiple JPG files to achieve better compression ratio
    than multi single .PGJ
    however we can't see this key in WinZip.

  29. #29
    Member
    Join Date
    May 2008
    Location
    Kuwait
    Posts
    301
    Thanks
    26
    Thanked 22 Times in 15 Posts
    i can confirm what Raymond_NGhM found .. at last as i requested before but i don't know how. I think its combined dictionary

    i shall compare with stuffit 14 soon on my private collection ..

    SCHINDER ..KINDLY UPDATE PRECOMP
    Last edited by maadjordan; 24th April 2010 at 19:49.

  30. #30
    Member
    Join Date
    Jun 2008
    Location
    G
    Posts
    372
    Thanks
    26
    Thanked 22 Times in 15 Posts
    and its 100% looseless with metadata right?

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

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