LPCB is here now: http://qlic.altervista.org/LPCB.html
FLIF was added recently,
next week perhaps BPG and latest WebP,
what else should be tested and added?
LPCB is here now: http://qlic.altervista.org/LPCB.html
FLIF was added recently,
next week perhaps BPG and latest WebP,
what else should be tested and added?
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
JamesWasil (4th January 2018)
* JPEG predictive lossless * JPEG LS * JPEG 2000 lossless
Are already there, since 2011 mostly. More info is welcome.
* JPEG XT part 8
Not 100% sure what this is, but when I tested JPEG XT released on 30/06/2015, it performed exactly as Quo Vadis JPEG, at least with '-c -ls'.
For XT part 8, and JPEG LS part 2, could you please provide links to source code and/or executables?
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
double post, removed.
Last edited by thorfdbg; 12th October 2015 at 12:03.
JPEG XT part 8 is our new JPEG standard. It is implemented by the JPEG XT reference software you find on www.jpeg.org. You run it with the JPEG XT reference software you already have, with the options "-r -q base quality -Q 100 -h". JPEG LS part 2 is JPEG LS with color decorrelation enabled. It is also implemented in the JPEG XT reference software, but *only* in the GPL'd version, so make sure you get the correct one. For that, run it with the command line option "-ls 1 -cls" (or -ls 'something' if you want to try other coding modes than the line-interleaved mode). There is currently no implementation of the MQ-coder enabled JPEG LS part 2, unfortunately, even though it is standardized.
> -r -q base quality -Q 100 -h
Thank you Thomas!
What base quality value works best on photographic images?
Also, which of the following should I try to improve compression ratio and/or speed:
-a
-ra
-rl
-rs
-rv
-other?
Which options are helpful together with '-ls N -cls' ?
Are options printed by jpeg-jpl.exe sorted in chronological order?
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
It is of course image-dependent with complex content requiring lower values for ideal compression, but you do not make much of an error by picking a number like 85 here by default. Arithmetic coding is *outside* of JPEG XT. The code supports it, placeholders for arithmetic coding are in the standard, but it is officially not part of JPEG XT. It is a related codec the source code implements. So, "-a" and "-ar" are something you may want to try, but please do not name it "JPEG XT". "-ar" is something else, for the alpha channel, which we do not have here. "-ra" is arithemtic coding for the residual, yes. Will usually not give you better compression, but your milage may vary. Usually not worth trying. That might be valuable because it puts the residual into progressive mode. -h should be present, unless arithmetic coding is on. There are a couple of options to improve subjective quality, but that's not very useful for lossless. None, that's it. JPEG LS doesn't have anything else but that. I would call that rather "random order", where I tried to sort them approximately by topic.
I think it would be nice to retest Stuffit. Your tests performed with console_stuffEN.exe /c -o which is equal to console_stuffEN.exe /c -o --recompression-level=0
--recompression-level option supports 3 levels. The results on PPM:
Also ZCM general purpose archiver detects graphic data and uses special model for it. Can be downloaded here: http://heartofcomp.altervista.org/zcm093.zipCode:--recompression-level=0 1 079 684 543 --recompression-level=1 1 048 870 928 --recompression-level=2 1 044 760 134
Code:Per-file zcmx64.exe a -m8 -t1 output.zcm input.ppm 1 149 113 836 Solid zcmx64.exe a -s -m8 -t1 archive.zcm C:\data\* 1 148 833 050
Skymmer,
ZCM - okay, thank you,
StuffIt with --recompression-level=1 - is it a lot slower than with 0 ? Is latest StuffIt faster than Deluxe 2010?
Thomas,
With -cls I get errors 1024 and 1038 (with and without -ls 1)
With other variants:
1290129169 - jpeg-gpl.exe -c -ls 0 %1.ppm %1.xt0
1530194360 - jpeg-gpl.exe -l -c -q 100 -a %1.ppm %1.xt_l
1681614121 - jpeg-gpl.exe -r -q 50 -Q 100 -a %1.ppm %1.xt_050
1571180908 - jpeg-gpl.exe -r -q 80 -Q 100 -a %1.ppm %1.xt_080
1541652761 - jpeg-gpl.exe -r -q 90 -Q 100 -a %1.ppm %1.xt_090
1675104211 - jpeg-gpl.exe -r -q 100 -Q 100 -a %1.ppm %1.xt_100
1557989434 - jpeg-gpl.exe -r -q 80 -Q 100 -a -rv %1.ppm %1.xt_080rv
Note in the latter case, with -r ... -rv, it hanged quite often (a couple times on PIA images, also on Sony and two Fuji images), but restarting from the same image always helped.
Last edited by Alexander Rhatushnyak; 12th October 2015 at 20:33.
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
Well, the bad thing about StuffIt is that the latest version for Windows is 14.0.1 while MAC version is already 16.0.4 so I can't test it.
14.0.1 = 14.0.1.27A = 2010SR2
http://my.smithmicro.com/downloads/f...i-language.exe
In console it gives: StuffIt Engine Version: 14.0.0.16
DLL versions:
As for speed:Code:sitx.dll 14.0.2383.921 stuffitengine.dll 14.0.0.16 stuff.exe 14.0.1.16
Code:STA13843.ppm (i7-2700K@4700) ------------------------------ --recompression-level=0 138,851,089 -> 56,034,361: 40.35%. Cpu 4 mb/s (30.716 sec), real 4 mb/s (30.857 sec) = 99%. ram 374 MB, vmem 391 MB --recompression-level=1 138,851,089 -> 52,538,259: 37.83%. Cpu 2 mb/s (62.790 sec), real 2 mb/s (62.930 sec) = 99%. ram 374 MB, vmem 392 MB --recompression-level=2 138,851,089 -> 52,182,019: 37.58%. Cpu 1 mb/s (79.887 sec), real 1 mb/s (80.028 sec) = 99%. ram 375 MB, vmem 393 MB
That's a bug in the earlier version. We need to put on a newer version this meeting. For a fix, please go into the file colortrafo/colortransformerfactory.cpp, in line 287 (or around that), you should have an "if" statement saying: if (ltrafo == MergingSpecBox::JPEG_LS && ocflags == 0) { this should be replaced by: if (ltrafo == MergingSpecBox::JPEG_LS) { and it should work. Sorry for that. It's really not part of XT and hence has not been tested too much for the last version.
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
Yes, residual progressive arithmetic still does not yet define enough contexts to allow encoding or decoding. As said, the standard has nothing there, so the encoding necessarily fails - or rather locks up in this particular case. Yes, I could come up with a encoding scheme here, but it's all outside of XT anyhow.
Fixed software, with a number of additional fixes, is now on www.jpeg.org. Thanks!
Thank you Thomas! Why no Windows Binary this time?
BTW, if someone could build and attach a Win32 exe of BPG 0.9.6, that would be helpful.
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
I had a look at the README in libbpg-0.9.6.tar.gz found here.
There is written the following:
In the same page, there is a binary distribution for Windows 64 bit.Code:2.2) Windows ------------ - Only cross-compilation from Linux is supported. - The following packages need to be installed: mingw64-gcc mingw64-libpng mingw64-libjpeg-turbo mingw64-SDL mingw64-SDL_image yasm. It is recommended to use yasm version >= 1.3.0 to have a faster compilation. - Only a 64 bit target is supported because x265 needs it for bit depths > 8.
EDIT: it seems that for depth = 8 there is no need for 64 bit and it can be compiled for 32 bit, however I don't know how to do it and if it is possible.
Last edited by Mauro Vezzosi; 17th October 2015 at 18:38.
Hello,
BPG tools 0.9.6 binaries (MSYS2/gcc 5.2.0 win32, no 10/12 bit for x265, jctvc encoder included), not (99.99999%) tested, be warned.
bpg-0.9.6-win32.7z
Really, I have only tested on one picture that bpgenc, bpgdec & bpgview were at least running. Use them at your own risk.
AiZ
Alexander Rhatushnyak (17th October 2015)
Hello,
Just for fun, I have updated jctvc encoder in bpgenc to the latest version (HM-16.7). Encoded files size is slightly bigger than with vanilla 0.9.6, which comes with HM-16.2.
bpgenc-0.9.6-win32-HM-16.7.7z
@Alexander, if you prefer single-threaded encoding, jctvc can float your boat. It will take ages to encode your test data but you'll get (much?) better compressed size.
AiZ
Hi,
FYI, with 0.9.6 using jctvc HM-16.7 encoder, total is 1,308,731,065 bytes.
AiZCode:19/10/2015 12,078,319 canon_eos_1100d_01.bpg 19/10/2015 13,400,062 canon_eos_1100d_02.bpg 19/10/2015 11,806,351 canon_eos_1100d_03.bpg 19/10/2015 13,485,763 canon_eos_1100d_04.bpg 19/10/2015 12,240,401 canon_eos_1100d_05.bpg 19/10/2015 12,530,198 canon_eos_1100d_06.bpg 19/10/2015 15,302,535 canon_eos_1100d_11.bpg 19/10/2015 12,745,914 canon_eos_1100d_12.bpg 19/10/2015 14,183,755 canon_eos_1100d_13.bpg 19/10/2015 15,472,011 canon_eos_1100d_14.bpg 19/10/2015 12,163,363 canon_eos_1100d_15.bpg 19/10/2015 12,129,737 fujifilm_finepix_x100_01.bpg 19/10/2015 11,756,740 fujifilm_finepix_x100_02.bpg 19/10/2015 9,785,327 fujifilm_finepix_x100_03.bpg 19/10/2015 11,398,392 fujifilm_finepix_x100_04.bpg 19/10/2015 13,362,759 fujifilm_finepix_x100_05.bpg 19/10/2015 10,344,420 fujifilm_finepix_x100_06.bpg 19/10/2015 9,774,284 fujifilm_finepix_x100_10.bpg 19/10/2015 11,486,791 fujifilm_finepix_x100_11.bpg 19/10/2015 11,675,519 fujifilm_finepix_x100_12.bpg 19/10/2015 12,767,392 fujifilm_finepix_x100_13.bpg 19/10/2015 11,249,448 fujifilm_finepix_x100_14.bpg 19/10/2015 14,128,028 fujifilm_finepix_x100_15.bpg 19/10/2015 10,495,891 olympus_xz1_01.bpg 19/10/2015 10,076,068 olympus_xz1_02.bpg 19/10/2015 11,237,290 olympus_xz1_03.bpg 19/10/2015 11,025,108 olympus_xz1_04.bpg 19/10/2015 10,936,337 olympus_xz1_05.bpg 19/10/2015 11,460,803 olympus_xz1_06.bpg 19/10/2015 11,461,773 olympus_xz1_07.bpg 19/10/2015 10,925,086 olympus_xz1_08.bpg 19/10/2015 12,063,986 olympus_xz1_09.bpg 19/10/2015 10,252,763 olympus_xz1_10.bpg 19/10/2015 11,844,284 olympus_xz1_11.bpg 19/10/2015 12,578,485 olympus_xz1_12.bpg 19/10/2015 12,015,226 olympus_xz1_13.bpg 19/10/2015 14,381,807 olympus_xz1_14.bpg 19/10/2015 14,388,001 olympus_xz1_15.bpg 19/10/2015 9,587,309 olympus_xz1_16.bpg 19/10/2015 13,689,804 olympus_xz1_17.bpg 19/10/2015 11,502,903 olympus_xz1_18.bpg 19/10/2015 11,700,272 olympus_xz1_19.bpg 19/10/2015 19,019,779 olympus_xz1_20.bpg 19/10/2015 19,675,083 olympus_xz1_21.bpg 19/10/2015 18,964,849 olympus_xz1_22.bpg 19/10/2015 10,860,414 olympus_xz1_23.bpg 19/10/2015 14,273,547 olympus_xz1_24.bpg 19/10/2015 14,063,266 olympus_xz1_25.bpg 19/10/2015 14,318,926 olympus_xz1_26.bpg 19/10/2015 15,731,023 olympus_xz1_27.bpg 19/10/2015 286,179 PIA12811.bpg 19/10/2015 546,124 PIA12813.bpg 19/10/2015 11,384,166 PIA13757.bpg 19/10/2015 323,059 PIA13779.bpg 19/10/2015 2,290,074 PIA13785.bpg 19/10/2015 239,835 PIA13799.bpg 19/10/2015 7,198,115 PIA13803.bpg 19/10/2015 7,508,271 PIA13810.bpg 19/10/2015 1,968,928 PIA13812.bpg 19/10/2015 1,971,217 PIA13815.bpg 19/10/2015 1,520,045 PIA13833.bpg 19/10/2015 289,051 PIA13855.bpg 19/10/2015 289,870 PIA13856.bpg 19/10/2015 321,533 PIA13857.bpg 19/10/2015 229,817 PIA13859.bpg 19/10/2015 170,370 PIA13862.bpg 19/10/2015 420,864 PIA13872.bpg 19/10/2015 3,545,314 PIA13882.bpg 19/10/2015 227,749 PIA13891.bpg 19/10/2015 7,359,201 PIA13894.bpg 19/10/2015 34,555,831 PIA13912.bpg 19/10/2015 462,116 PIA13913.bpg 19/10/2015 1,285,399 PIA13914.bpg 19/10/2015 18,355,894 PIA13915.bpg 19/10/2015 517,676 PIA13943.bpg 19/10/2015 15,247,734 sony_a55_01.bpg 19/10/2015 15,712,951 sony_a55_02.bpg 19/10/2015 22,830,657 sony_a55_03.bpg 19/10/2015 22,135,471 sony_a55_04.bpg 19/10/2015 23,276,464 sony_a55_05.bpg 19/10/2015 14,945,046 sony_a55_06.bpg 19/10/2015 14,936,236 sony_a55_07.bpg 19/10/2015 15,702,629 sony_a55_08.bpg 19/10/2015 16,911,012 sony_a55_09.bpg 19/10/2015 20,700,438 sony_a55_10.bpg 19/10/2015 36,402,450 sony_a55_11.bpg 19/10/2015 17,573,106 sony_a55_15.bpg 19/10/2015 18,892,977 STA13452.bpg 19/10/2015 19,320,332 STA13453.bpg 19/10/2015 20,404,639 STA13454.bpg 19/10/2015 10,933,724 STA13455.bpg 19/10/2015 1,269,628 STA13456.bpg 19/10/2015 13,057,952 STA13457.bpg 19/10/2015 3,733,175 STA13458.bpg 19/10/2015 12,216,123 STA13459.bpg 19/10/2015 7,554,120 STA13771.bpg 19/10/2015 713,615 STA13781.bpg 19/10/2015 1,663,624 STA13782.bpg 19/10/2015 3,904,058 STA13789.bpg 19/10/2015 69,403,942 STA13843.bpg 19/10/2015 62,366,745 STA13844.bpg 19/10/2015 64,014,693 STA13845.bpg 19/10/2015 2,311,387 STA13900.bpg 19/10/2015 2,137,407 STA13901.bpg 19/10/2015 12,426,207 STA13904.bpg 19/10/2015 7,517,206 STA13908.bpg 19/10/2015 1,451,027 STA13942.bpg 107 Files(s) 1,308,731,065 bytes
Thanks for the pointer, windows binaries are now again available at www.jpeg.org.
I also updated the github version at https://github.com/thorfdbg/libjpeg. This is the GPL'd version, i.e. with all of JPEG, JPEG LS and hierarchical support, but without profiles A and B.
It is *a tiny little bit* ahead of the official version, though nothing that affects JPEG LS or lossless JPEG.
Did you try flif in default mode (interlaced, without the -n) ?
The version of flif currently on github is probably somewhat worse in terms of compression but also faster...
Jon, yes I tried, and compressed size was not better than with -n.
How much faster?
By the way, LPCB was updated yesterday.
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
WebP 0.4.4 is out.
On LPCB images:
1240350758 --- cwebp -m 0
1231054814 --- cwebp -m 6 (also -m 5 and -preset photo -m 6)
If we losslessly compress the only image in the WebP 0.4.4 package:
49167 test_ref.ppm
23889 test_ref.png
17365 test_ref.flif-i
16435 test_ref.flif-n-a
16435 test_ref.flif-n
15054 test_ref.webp044-m6
14958 test_ref.webp044-m4
14422 test_ref.flif-n-b
12860 test_ref.bmf
12560 test_ref.gralic111d
UPDATE:
1436811364 --- GCIF
Last edited by Alexander Rhatushnyak; 1st November 2015 at 15:42. Reason: gcif
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
Jyrki Alakuijala (3rd May 2016)
Hi Alexander,
What compressor do you use the while creating your LPCB ? Your own compressor ? JPEG -LS ?
King Regards,
The latest version 125 of paq8px compresses LPCB images to 972'632'649 bytes with switch -8,
and the latest version 0.1.25 of EMMA to 973'965'877 bytes with C 7.
Many compressors including paq8px, Emma, FLIF and GraLIC
have switches that improve compressed size in some cases,
but to be eligible for LPCB, a compressor must produce one output file
for each input file, and the switch(es) must be the same for all test images.
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
For WebP 0.6.1 you can use '-q 100 -m 6' to invoke the cruncher more that tries out a few strategies and takes the best. The lossless got about 1.5 % more dense in WebP 0.5 and a further 1-2 % with 0.6.1.
https://github.com/webmproject/libwe...ses/tag/v0.6.1 (cruncher mode)
https://github.com/webmproject/libwe...ses/tag/v0.5.0 (fixes for density related bugs with grayscale lossless compression)
1'194'936'668 bytes -- webp -lossless -q 100 -m 6
1'222'290'070 bytes -- webp -lossless -q 100
1'128'702'803 bytes -- flif -e -N
1'283'324'851 bytes -- flif -e -N --effort=0
1'126'954'659 bytes -- flif -e -N --effort=100
This newsgroup is dedicated to image compression:
http://linkedin.com/groups/Image-Compression-3363256
Jyrki Alakuijala (27th December 2017)