ETA on packjpeg 2.4 ?

[SvenBent]

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)

[Simon Berger]

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

[PiPPoNe92]

Is there a mod-improved version of packjpeg?

[SvenBent]

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

[Matthias Stirner]

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.

[Simon Berger]

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

[Bulat Ziganshin]

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

[Intrinsic]

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/

[SvenBent]

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

[m^2]

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?

[SvenBent]

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

[Skymmer]

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.

[m^2]

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.

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.

[m^2]

I just received:

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.

[Intrinsic]

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.

[m^2]

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.

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.

[Skymmer]

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:

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

[m^2]

Are you sure? It works for me with 2.3c version:

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

[Skymmer]

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 !

[Intrinsic]

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.

[Raymond_NGhM]

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)

[Skymmer]

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.

[m^2]

Idea:
Stronger modes that try different c/s parameters and take the smallest result. About what suggested here, but done internally.

[Fallon]

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

[Shelwien]

Note also http://www.elektronik.htw-aalen.de/p...ge%20v1.0d.zip

[Intrinsic]

Superb, can't wait to test it out and see if it matches StuffIT.

[m^2]

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?

[Raymond_NGhM]

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.

[maadjordan]

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

[thometal]

and its 100% looseless with metadata right?