Results 1 to 17 of 17

Thread: packJPG v2.5 released under GPL v3

  1. #1
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 42 Times in 9 Posts

    Thumbs up packJPG v2.5 released under GPL v3

    Hi everyone,

    The official home of packJPG was updated today. This is a rather big update which includes:
    - packJPG v2.5, source code included
    - packARC, a new archiver with SFX capabilities based on packJPG, source code included
    - packPNM v0.9 and packPNM v1.0e, source code included

    All source code can be used under the terms of the GPL v3.

    Get it here: http://www.elektronik.htw-aalen.de/packjpg/

  2. #2
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    309
    Thanks
    0
    Thanked 1 Time in 1 Post
    Nice! Will check it out

  3. #3
    Tester
    Stephan Busch's Avatar
    Join Date
    May 2008
    Location
    Bremen, Germany
    Posts
    579
    Thanks
    57
    Thanked 44 Times in 28 Posts
    Thanks Matthias. Hopefully this helps the community to integrate this technology in p.ex. 7-Zip and FreeARC;
    in return the community might be inspiring to enhance / improve this codec.

  4. #4
    Member Alexander Rhatushnyak's Avatar
    Join Date
    Oct 2007
    Location
    Canada
    Posts
    147
    Thanks
    0
    Thanked 4 Times in 3 Posts
    Quote Originally Posted by packDEV View Post
    - packPNM v0.9 and packPNM v1.0e, source code included
    What's the difference between v1.0d and v1.0e? Compressed sizes are the same, and speed is rather similar. Were the included executables compiled with MinGW 3.4.5 ?

    "Warning: it may take several hours or days to run."


    This newsgroup is dedicated to image compression:
    http://linkedin.com/groups/Image-Compression-3363256

  5. #5
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,462
    Thanks
    8
    Thanked 37 Times in 27 Posts
    Quote Originally Posted by Stephan Busch View Post
    Thanks Matthias. Hopefully this helps the community to integrate this technology in p.ex. 7-Zip and FreeARC;
    in return the community might be inspiring to enhance / improve this codec.
    License makes it useless for both 7-zip and FreeArc, except for a being a reference implementation.

  6. #6
    Tester
    Stephan Busch's Avatar
    Join Date
    May 2008
    Location
    Bremen, Germany
    Posts
    579
    Thanks
    57
    Thanked 44 Times in 28 Posts
    Maybe the author allows both to use it. A plugin would be nice or the authors get inspired by the given code.

  7. #7
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,462
    Thanks
    8
    Thanked 37 Times in 27 Posts
    Quote Originally Posted by Stephan Busch View Post
    Maybe the author allows both to use it. A plugin would be nice or the authors get inspired by the given code.
    The problem goes the other way, 7-zip theoretically could use it, but it would make itself practically a GPL3 this way. Igor clearly wants a much more permissive scheme.
    FreeArc could use it, but then it would have to drop a couple of existing components, i.e. GRzip, because their licenses don't allow mixing with something as restrictive as GPL3.
    So it's not that Matthias disallows them to use it, yet it won't happen. He could relax the license restrictions to make it work though. For FreeArc, switching the license to GPL2 would be sufficient (or double licensing with GPL2 as option). For 7-zip, he would have to use something permissive and I doubt we'll see it (though no doubt it would be a nice move and accelerate PackJPG adoption).

  8. #8
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 42 Times in 9 Posts
    Quote Originally Posted by Alexander Rhatushnyak View Post
    What's the difference between v1.0d and v1.0e? Compressed sizes are the same, and speed is rather similar. Were the included executables compiled with MinGW 3.4.5 ?
    The only difference between packPNM v1.0d and packPNM v1.0e is a small fix for a bug which was only recently discovered. Other than that, both arefully compatible. All executables were compiled using GCC v4.5.2.

  9. #9
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 42 Times in 9 Posts
    Quote Originally Posted by m^2 View Post
    The problem goes the other way, 7-zip theoretically could use it, but it would make itself practically a GPL3 this way. Igor clearly wants a much more permissive scheme.
    FreeArc could use it, but then it would have to drop a couple of existing components, i.e. GRzip, because their licenses don't allow mixing with something as restrictive as GPL3.
    So it's not that Matthias disallows them to use it, yet it won't happen. He could relax the license restrictions to make it work though. For FreeArc, switching the license to GPL2 would be sufficient (or double licensing with GPL2 as option). For 7-zip, he would have to use something permissive and I doubt we'll see it (though no doubt it would be a nice move and accelerate PackJPG adoption).
    Well, I have long thought about the proper license for the packJPG source code, and it turned out that there is no such thing as a perfect-for-all license. That being said, theres a paragraph in the packJPG readme about special permissions, special permissions being intended for exactly these cases.

    Of course I wouldn't mind packJPG being used in 7-zip or FreeArc at all. Both are great freeware compression suites, and I'd actually be very happy to have the packJPG algorithm included in both of them. Their respective authors, if they are interested, can contact me anytime and we'll work something out together to get this working.

  10. #10
    Tester
    Stephan Busch's Avatar
    Join Date
    May 2008
    Location
    Bremen, Germany
    Posts
    579
    Thanks
    57
    Thanked 44 Times in 28 Posts
    Yeah that's exactly the way I wanted to suggest.

  11. #11
    Member
    Join Date
    May 2010
    Location
    France
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I'd like to know why is it mandatory to use the console commands to use the PackARC ?

  12. #12
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 42 Times in 9 Posts
    Quote Originally Posted by toino2000 View Post
    I'd like to know why is it mandatory to use the console commands to use the PackARC ?
    I guess you'd prefer drag and drop over using the command line, right? Because of the higher number of possibilities, this is a bit more complicated (although not impossible) for packARC than it was for, packJPG or packJPX.

    Two possibilities come to my mind:
    [1] Under Windows, this could be solved using batch files. I don't especially like this solution, but it would be easy to do, and you could have one batch file each for regular archive creation, SFX archive creation, regular archive extraction and SFX archive extraction. With a bit of work you could also have a packARC right-click context menu entry similar to that of 7-zip.
    [2] I could also implement drag and drop support right into packARC, but I'd have to decide what happens if a regular archive or a SFX archive is dropped: extract or store in a new archive? This would also rule out simple drag and drop creation for either regular or SFX archives.

    One solution for [2] would be this:
    If only one file is dropped, and this file is a regular or SFX archive, extract in place. Otherwise, create a new regular archive using all files dropped.

    Which one sounds better?

  13. #13
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    2,610
    Thanks
    126
    Thanked 365 Times in 235 Posts
    I prefer command line programs. For users who don't know how to use a command window, I think compression in general should be totally transparent to the user. For example, it would be built into the application or OS. When you save a file to disk or over the internet, the application compresses it. When you open it, the application decompresses it. The way to distribute such software is as a library that application developers would use.

    Anyway, that is my goal with libzpaq. Each application could customize the algorithm for whatever data type it uses. If a new version saves files in an improved format, old versions of the application could still open them.

  14. #14
    Member packDEV's Avatar
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    37
    Thanks
    10
    Thanked 42 Times in 9 Posts
    Quote Originally Posted by Matt Mahoney View Post
    I prefer command line programs. For users who don't know how to use a command window, I think compression in general should be totally transparent to the user. For example, it would be built into the application or OS. When you save a file to disk or over the internet, the application compresses it. When you open it, the application decompresses it. The way to distribute such software is as a library that application developers would use.
    I haven't specifically mentioned this before, but packJPG can also be compiled as a library. A set of library functions to be called from external applications are already included in the source code for that case. Instructions for compiling the library are found in the docs. It's very simple, there's even a Makefile included for this and no source code changes needed. The compiled library was used in the past f.e. by Christian Schneider in precomp.

    Additional info: I just noticed that I still have a tiny sample application demonstrating the usage of the packJPG library lying around. I may include it in the next version of the package, but in the meantime, if anyone has trouble using the library, you may also contact me. By the way, the packJPG library is also used in packARC .

    As for packARC, the source code is designed so that it should be easy to include its functionality in other projects. All actual archiver functionality (adding, extracting, testing, deleting, ...) is centralized in one file (pja_archiver.cpp). All functionality that has to do with any kind of user interaction (from the command line, in this case) is seperate from that, in another file (frontend.cpp). Making f.e. a graphical GUI or including in an existing GUI shouldn't be too difficult.

    Quote Originally Posted by Matt Mahoney View Post
    Anyway, that is my goal with libzpaq. Each application could customize the algorithm for whatever data type it uses. If a new version saves files in an improved format, old versions of the application could still open them.
    Backwards compatibility has always been a problem for packJPG. packJPG can, since the first public version, recognize if (and which) another version of packJPG is needed to extract a PJG file, but it can't extract these files. Maybe I'll implement a better way of handling this in the future.

    Additional info: I just noticed that I got this wrong at first, libzpaq has downwards and upwards compatibility. Upwards compatibility or algorithm customization, such as implemented in libzpaq, is no simple feat. For packJPG, I don't think this would be possible. The way the packJPG algorithm is implemented now leaves little room for improvement (I do really hope someone proves me wrong) unless bigger changes are implemented, which would in turn break compatibility.
    Last edited by packDEV; 22nd November 2011 at 22:31.

  15. #15
    Member Raymond_NGhM's Avatar
    Join Date
    Oct 2008
    Location
    UK
    Posts
    51
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Newly added (December 22, 2011): V2.5a

    This version 2.5a is compatible with version 2.5.
    The changes between version 2.5 and 2.5a are meant to improve
    the build process in particular using g++ version 4 and under Linux.

  16. #16
    Member
    Join Date
    Feb 2012
    Location
    Sweden
    Posts
    59
    Thanks
    4
    Thanked 5 Times in 5 Posts
    Very nice program, I was impressed with the both the ratio and the compression/decompression speed. Great for archiving my huge amount of images. Will future releases impact compability?

  17. #17
    Member
    Join Date
    Feb 2012
    Location
    Sweden
    Posts
    59
    Thanks
    4
    Thanked 5 Times in 5 Posts
    One question, if I use the sfx stub in Linux, why does it need to have the .exe extension for it to work? As long as the file is set as executable I don't see why it would need to have an ".exe" extension. However if running without ".exe" extension I get "incorrect usage of SFX executable". Anyway the reason I don't want an ".exe" extension because that extension is tied to Wine (windows) executables and by double clicking on it, the system will try to launch it using Wine. Anyway, just wanted to say again thanks for this great lossless jpeg compressor!

Similar Threads

  1. packJPG v2.5C3
    By packDEV in forum Data Compression
    Replies: 3
    Last Post: 22nd October 2011, 16:23
  2. LZC Compressor GPL
    By Nania Francesco in forum Data Compression
    Replies: 1
    Last Post: 15th September 2008, 06:26
  3. PreComp + PackJPG
    By squxe in forum Data Compression
    Replies: 2
    Last Post: 16th May 2008, 20:53
  4. PackJPG v2.2 released!
    By LovePimple in forum Forum Archive
    Replies: 29
    Last Post: 3rd February 2008, 21:42
  5. PackJPG v2.0 released!
    By LovePimple in forum Forum Archive
    Replies: 3
    Last Post: 18th June 2007, 04:57

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
  •