packJPG v2.5 released under GPL v3

[packDEV]

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/

[Intrinsic]

Nice! Will check it out

[Stephan Busch]

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.

[Alexander Rhatushnyak]

- 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 ?

[m^2]

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.

[Stephan Busch]

Maybe the author allows both to use it. A plugin would be nice or the authors get inspired by the given code.

[m^2]

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).

[packDEV]

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.

[packDEV]

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.

[Stephan Busch]

Yeah that's exactly the way I wanted to suggest.

[toino2000]

I'd like to know why is it mandatory to use the console commands to use the PackARC ?

[packDEV]

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?

[Matt Mahoney]

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.

[packDEV]

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.

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.

[Raymond_NGhM]

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.

[binarysoup]

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?

[binarysoup]

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!