tjko / jpegoptim Goto Github PK
View Code? Open in Web Editor NEWjpegoptim - utility to optimize/compress JPEG files
Home Page: http://www.iki.fi/tjko/projects.html
License: GNU General Public License v3.0
jpegoptim - utility to optimize/compress JPEG files
Home Page: http://www.iki.fi/tjko/projects.html
License: GNU General Public License v3.0
Jpegoptim v1.5.5 - Copyright (C) Timo Kokkonen, 1996-2023. All Rights Reserved. REQUIREMENTS Independent JPEG Group's jpeg library (libjpeg) version 6b or later. (Alternatively should also work with libjpeg-turbo or mozjpeg) TESTED PLATFORMS Linux MacOS Windows (setargv.obj "link option" is needed for wildcards expansion to work) INSTALLATION Installation should be very straightforward, just unpack the tar file, make necessary changes to the Makefile, and then compile the program. You may wanna do something like this: tar xzvf jpegoptim-1.5.5.tar.gz cd jpegoptim-1.5.5 ./configure make make strip make install HISTORY v1.5.5 - improved JFIF handling (it should not longer get added in some instances if it was not present in original), new options --keep-jfif and --strip-jfif, other minor fixes v1.5.4 - make sure JPEG mode (progressive vs non-progressive) is preserved by default, fix parallel processing when reading file list (thanks to Cubittus) v1.5.3 - fix potential heap-buffer-overflow (read) when using stdin/stdout and processing corrupt JPEG v1.5.2 - add support for reading list of files to process from a file (--files-from) or from standard input (--files-stdin), improved JPEG marker reporting, fix -d, --dest option (thanks to Almas Kunapyanov), other minor fixes v1.5.1 - fix logging to stdout when --stdout is used *thanks to Eta, improved CMake support (and Github CI stuff) *thanks to Eta, update --treshold option accept decimal numbers as parameter, fix crashes when processing certain broken JPEG images, fix memory leaks, fix (logging) output in parallel processing mode v1.5.0 - add --workers=<max> option to enable parallel processing fix --stdin option, other minor fixes v1.4.7 - experimental support for arithmetic coding (enable with configure option --with-arith), add option --nofix, add support for JFIF Extension (JFXX) markers, support for nanosecond timestamps (thanks to GerbilSoft), optimization now works same with stdin as with standard files, fixed --size (-S) option not working correctly when processing multiple files, new --keep-* options to use with --strip-all (see man page), other minor fixes v1.4.6 - fix double free introduced in previous release v1.4.5 - fix --overwrite option, better error reporting for -d option, fix memcmp() potentially reading past end of buffer, some minor fixes v1.4.4 - more detailed error messages (thanks to Denis Fateyev), CMake support (thanks to Ghostkeeper), other minor fixes v1.4.3 - fix bug that could cause jpegoptim crash when processing certain jpeg files v1.4.2 - add option -P, --preserve-perms, some minor fixes v1.4.1 - fix --stdin option (assume -f when reading from stdin), workaround to bug in libjpeg-turbo (v1.3.1) triggered when option -V or --version was used, other minor fixes v1.4.0 - use memory (instead of temporary files) during optimization, support for reading input from stdin (and sending output to stdout), report also libjpeg version when --version option used, new option --strip-none to preserve "all" markers, other minor fixes & cleanup v1.3.1 - XMP marker support and new --csv option (by Matteo Croce), use DESTDIR instead of INSTALL_ROOT (by Samuli Suominen), changes to make compiling under Win32 and Win64 easier (thanks to Javier Gutiérrez), preserve permissions of files being optimized, skip symlinks (and other special files), other minor fixes v1.3.0 - support for progressive jpegs added (fixes long standing "bug" of progressive jpegs becoming non-progressive during optimization), new options --all-normal & --all-progressive for converting jpegs to non-progressive & progressive, new -S / --size option to set target size for output file (enables lossy optimization), updated GPL/Copyrights language (thanks to Nicolas Vieville) v1.2.5 - safer temp file handling (if mkstemps() available), patch to make "quiet mode" (-q) be quiet by Mathieu Malaterre v1.2.4 - new -T / --threshold option by Matteo Croce, minor fixes (potential memory leaks), merged some patches from Debian jpegoptim package (1.2.3-2) v1.2.3 - IPTC marker support by Dustin Ward, ICC profile support by Dwight Kelly, minor fixes v1.2.2 - Now Exif and COM markers are not discarded (all other markers are discarded as before). New options --strip-all, --strip-exif, and --strip-com added for controlling what markers to strip. v1.2.1 - fixed buggy temp file handling v1.2.0 - Added new options --overwrite and --preserve. GNU autoconf support added, also. v1.1 - new -f option, and other minor changes, improved support for other platforms v1.0a - some changes in docs & makefile v1.0 - first public release LATEST VERSION Latest version is always available from: http://www.iki.fi/tjko/projects.html Sources (GIT) https://github.com/tjko/jpegoptim ACKNOWLEDGEMENT This software is based in part on the work of the Independent JPEG Group. SPONSORS Special thanks for following Github Sponsors that have supported jpegoptim: - midir99 Timo <[email protected]> 09-Aug-2023
Could you please link
http://sourceforge.net/projects/jpegoptim/ ?
jpegoptim ch5_BW_adjustment.jpg -m50 -s
On performing the optimization of the image, the image color modifies as the extra blue screen placed over it. It even happens with more images whose base color is blue (the images mostly contains sky).
I would like to request a recursive (-R) option built into jpegoptim. I believe this would be very beneficial to the usefulness of the application. I do understand that recursive processing can be done using the "find -type f -name "*.jpg" -exec jpegoptim --strip-all {} ;" command. However, this has two issues:
jpegoptim's lossless optimisation is idempotent, which can be extremely helpful under certain circumstances. However, its lossy optimisation (in the same quality settings) is not (always) idempotent, which causes the loss to accumulate after optimising multiple times, therefore it would be very nice if this could be fixed.
According to my personal test on several hundreds of images, after being optimised once in 95 quality, roughly half of the images would readily get optimised the second time in 95 quality; however, none get optimised if the quality is set to 96 the second time. So it seems that idempotency can be achieved by checking the quality of the image in concern, and using loseless optimisation if the quality is already no more than (or less than, if quality is set to 100) the user-defined threshold. I think idempotency could be an optional feature in jpegoptim, and users could enable it via some command line options.
The quality of the image is not written in the header, but could be determined from the quantisation table (cf. the JPEGSetImageQuality
function from ImageMagick). I admit that ImageMagick is a huge dependency if you choose to link to it rather than incorporating the routine in jpegoptim; in that scenario, it might be a good choice to make ImageMagick a (build-time) optional dependency.
d:\TEMP\>jpegoptim.exe *.jpg
jpegoptim: skipping special file: *.jpg
d:\TEMP\>jpegoptim2.exe ./
jpegoptim: skipping directory: ./
In version 1.4.4 it was possible optimize *.jpg with no problem.
http://www.kokkonen.net/tjko/projects.html is unreachable.
on RELEASE.1.4.4
I have found a memory leak vulnerability in jpegoptim.c
https://github.com/tjko/jpegoptim/blob/master/jpegoptim.c#L673
The pointer outbuffer was leaked.
Xubuntu 16.10. Following README, on step ./conifgure
I am getting this:
checking for jpeg_read_header in -ljpeg... no
Cannot find libjpeg or you have too old version (v6 or later required).
and can't follow to make
because it says this:
make: *** No targets specified and no makefile found. Stop.
yet
dpkg -l libjpeg*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===========================-==================-==================-============================================================
ii libjpeg-turbo8:amd64 1.5.0-0ubuntu1 amd64 IJG JPEG compliant runtime library.
ii libjpeg-turbo8:i386 1.5.0-0ubuntu1 i386 IJG JPEG compliant runtime library.
ii libjpeg62:i386 1:6b2-2 i386 Independent JPEG Group's JPEG runtime library (version 6.2)
ii libjpeg8:amd64 8c-2ubuntu8 amd64 Independent JPEG Group's JPEG runtime library (dependency pa
ii libjpeg8:i386 8c-2ubuntu8 i386 Independent JPEG Group's JPEG runtime library (dependency pa
ii libjpeg9:amd64 1:9b-2 amd64 Independent JPEG Group's JPEG runtime library
Is there any reason why this project does not honour the user's umask when creating new files? It seems pretty strange to me :D
I can understand the need for the --preserve-perms
flag (and I think that's a great idea), but the default creation with 600 seems a little odd to me.
With 600 perms it will often mean that a webserver can't read or serve the files, and I imagine web-image optimisation a big proportion of the people using this project.
Currently you support batch image processing nicely by offering destination directory option, however if a user wants to optimize just a single image with a different file name, he can't. I think having 2 parameters one for input and one for output can help in this case and it seems reasonable to have this support in this awesome optimizer.
The package fails to build on arm64 (aarch64-linux-gnu), because the
config.{guess,sub} files are out of date, and are not updated during
the build.
seeing how the arithmetic coding patent has ended and libjpeg-turbo and mozjepeg both support arithmetic coding how about a switch that replaces huffman with arithmetic coding
I just tested a few arithmetic coded jpegs on win7 and while Firefox and IE didn't read them irfanview and xnview both decoded them properly
as both Firefox and Chrome use libjpeg-turbo I expect future versions will support arithmeticly encoded images
also jpegoptim could be a handy tool for lossless conversion of jpeg's from huffman to arithmetic and back
I would like to point out that an identifier like "_JPEGOPTIM_H
" does not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?
@tjko: I've been using my own builds for a long time, see https://github.com/XhmikosR/jpegoptim-windows
How about adding official Windows builds here with AppVeyor/GitHub Actions CI like I've done on my repo?
I have come across a double free in jpegoptim. Please see the ASAN report below.
The crash file test case can be found here.
This was found in commit d23abf2.
The command to compile the binary is as follows:
CC=clang CXX=clang++ CFLAGS='-fsanitize=address,undefined -g -O2' CXXFLAGS=$CFLAGS make
This double-free could be used to assist in exploiting the software via heap manipulation resulting in code execution.
=================================================================
==24775==ERROR: AddressSanitizer: attempting double-free on 0x62d00000a400 in thread T0:
#0 0x4c4780 (/root/jpegoptim/jpegoptim_afl+0x4c4780)
#1 0x4f9c60 (/root/jpegoptim/jpegoptim_afl+0x4f9c60)
#2 0x7f9a700c1f44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#3 0x41a765 (/root/jpegoptim/jpegoptim_afl+0x41a765)
0x62d00000a400 is located 0 bytes inside of 39485-byte region [0x62d00000a400,0x62d000013e3d)
freed by thread T0 here:
#0 0x4c4e6d (/root/jpegoptim/jpegoptim_afl+0x4c4e6d)
#1 0x4faf9b (/root/jpegoptim/jpegoptim_afl+0x4faf9b)
previously allocated by thread T0 here:
#0 0x4c4ac8 (/root/jpegoptim/jpegoptim_afl+0x4c4ac8)
#1 0x4f7078 (/root/jpegoptim/jpegoptim_afl+0x4f7078)
#2 0x7f9a700c1f44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: double-free (/root/jpegoptim/jpegoptim_afl+0x4c4780)
==24775==ABORTING
When having a jpeg file, which seems to be corrupted, e.g. file is missing content due to transfer problems, jpegoptim steps out with an error like this:
test.jpg 960x741 24bit P IPTC ICC JFIF [ERROR]
The similar tool for png files, optipng, offers a -fix switch to repair such problems.
Any possibility to implement such a fix-switch in jpegoptim?
jpegoptim does not compile on hurd kernel:
https://buildd.debian.org/status/fetch.php?pkg=jpegoptim&arch=hurd-i386&ver=1.2.5-1&stamp=1361123428
See:
http://www.gnu.org/software/hurd/hurd/porting/guidelines.html
cat a.jpg | jpegoptim --stdin > b.jpg
Would be great if input file from stdin passed to stdout when result of optimization is larger than original.
At the moment --stdin
option enables --force
option that forces optimized file to stdout, even if it is larger than original.
on RELEASE.1.4.4
heap-buffer-overflow on address 0x60800000bff7 at pc 0x7fb50428558f bp 0x7ffc931d2dc0 sp 0x7ffc931d2570
READ of size 29 at 0x60800000bff7 thread T0
#0 0x7fb50428558e in __interceptor_memcmp ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:414
#1 0x404d73 in main /home/haojun/Downloads/testopensourcecode/jpegoptim-master/jpegoptim.c:579
#2 0x7fb503901b34 in __libc_start_main (/lib64/libc.so.6+0x21b34)
#3 0x4024e8 (/home/haojun/Downloads/testopensourcecode/jpegoptim-master/jpegoptim+0x4024e8)
0x60800000bff7 is located 0 bytes to the right of 87-byte region [0x60800000bfa0,0x60800000bff7)
allocated by thread T0 here:
#0 0x7fb5042b9bb8 in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cc:62
#1 0x7fb503ccdbe3 (/lib64/libjpeg.so.62+0x2cbe3)
#2 0x60f00000ef4f ()
heap-buffer-overflow ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:414 in __interceptor_memcmp
Shadow bytes around the buggy address:
0x0c107fff97a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff97b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff97c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff97d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff97e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c107fff97f0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00[07]fa
0x0c107fff9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff9810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff9820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff9830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c107fff9840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==31389==ABORTING
testcase:
https://github.com/bestshow/p0cs/blob/master/2215-heap-buffer-overflow-jpegoptim
Author: ADLab of Venustech
you can download windows from here
I've built jpegoptim with MINGW32 and MINGW64 against libjpeg-turbo 1.3.1 (also compiled with the respective compilers), and while other applications using said version of libjpeg-turbo appear to work, jpegoptim doesn't with various error messages for images.
These include:
(Premature end of JPEG file) (JPEG datastream contains no image) [ERROR]
(Corrupt JPEG data: 68 extraneous bytes before marker 0xc0) (Invalid JPEG file structure: missing SOS marker) [ERROR]
which error message it outputs is consistent per-image.
As far as I can tell, this affects any image I try to use, but here are two sample images producing the two error messages:
gaben.jpg - (JPEG datastream contains no image)
jpegoptimtest.jpg - (Invalid JPEG file structure: missing SOS marker)
The build recipe for libjpeg-turbo can be found here: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-libjpeg-turbo/PKGBUILD
(Note: The patches don't matter. I've tried without them, and still had the same problem with jpegoptim)
Curiously, the problem is not exhibited on Linux, where jpegoptim works fine with libjpeg-turbo on ArchLinux, leading me to believe that this may be an issue with the various "tweaks" made in win32_compat.h. I also don't think that this problem is exclusively related to the libjpeg-turbo build, as other applications relying on it appear to work as expected.
this utilites not work with file names started from "-"
like -2vfzszxJvBJiPA2djxJKv2ruKBUaehm.jpg
D:\Utils\jpegoptim -f -S70 -m70 --strip-all *.jpg
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- 2
d:\iranpdoc\MyScripts\Utils\jpegoptim: invalid option -- z
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- s
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- z
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- x
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- J
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- B
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- J
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- i
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- P
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- A
d:\anpdoc\MyScripts\Utils\jpegoptim: invalid option -- 2
jpegoptim: invalid argument for option -d, --dest.
How use???
./configure
Error: Cannot find libjpeg or you have too old version (v6 or later required)
I receive 'error creating temp file: mkstemps() failed'
I try last version and the branch master from github.
The certificate expired on 19 September 2018, so https://www.kokkonen.net/tjko/projects.html reports an error
I would like to use jpegoptim with piped data.
Like it is possible with Graphicsmagick or Jpeginfo
gm convert - -resize 400 -
jpeginfo --file -
Is that possible?
For a very few images compressed by jpegoptim, packJPG complains about a non-optimal huffman table, with "reconstruction of inefficient coding not supported". If I get past that warning, compressing with packJPG -p
and then decompress with packJPG, the image is a bit smaller. Compressing that image with jpegoptim --all-progressive --force
would produce the original slightly larger file. This is all a totally lossless operation.
The size difference is tiny. The main issue is that this compression inefficiency also causes jpegoptim to produce an image which another tool refuses to accept. This jpegoptim 1.4.4. is built with mozjpeg 3.1 and I guess it's probably a mozjpeg issue?
Here is an example image. Its SHA1 should be 7fb331d744eb7ce23175184f000f331b637257a6.
Hi Timo,
I know you already state this in the man page but I would like to know if this issue has a chance of being solved or it is really complicated to do it.
Thanks!
./jpegoptim -d ./jpg_out -o ./g8.jpg
==22892==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000380 (pc 0x7fb5811da8be bp 0x0000000000fa sp 0x7ffe3f1ac380 T0)
==22892==The signal is caused by a READ memory access.
==22892==Hint: address points to the zero page.
#0 0x7fb5811da8bd (/lib/x86_64-linux-gnu/libc.so.6+0x7f8bd)
#1 0x49ce56 (/my/jpegoptim/jpegoptim+0x49ce56)
#2 0x51c538 (/my/jpegoptim/jpegoptim+0x51c538)
#3 0x7fb58117cb96 (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#4 0x41ad09 (/my/jpegoptim/jpegoptim+0x41ad09)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x7f8bd)
==22892==ABORTING
file g8.jpg
g8.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 25x25, frames 1
Don't know how to show stack trace, this is the best I could
jpegoptim v1.4.0 x86_64-unknown-linux-gnu
Copyright (c) 1996-2014 Timo Kokkonen.
libjpeg version: 8d 15-Jan-2012
Copyright (C) 1991-2012 Thomas G. Lane, Guido Vollbeding
Copyright (C) 1999-2006 MIYASAKA Masaru
Copyright (C) 2009 Pierre Ossman for Cendio AB
Copyright (C) 2009-2014 D. R. Commander
Copyright (C) 2
*** stack smashing detected ***: jpegoptim terminated
Segmentation fault (core dumped)
ldd /usr/bin/jpegoptim
linux-vdso.so.1 (0x00007fff69ffe000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fb838d46000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007fb838af1000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fb838743000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb83904a000)
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for jpeg_read_header in -ljpeg... yes
checking for round in -lm... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for unistd.h... (cached) yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking for string.h... (cached) yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking jpeglib.h usability... yes
checking jpeglib.h presence... yes
checking for jpeglib.h... yes
checking size of long... 8
checking size of int... 4
checking for getopt_long... yes
checking for mkstemps... yes
checking for broken jmorecfg.h (METHODDEF)... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -c -o jpegoptim.o jpegoptim.c
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -c -o jpegdest.o jpegdest.c
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -c -o misc.o misc.c
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -o jpegoptim jpegoptim.o jpegdest.o misc.o -Wl,-O1,--sort-common,--as-needed,-z,relro -lm -ljpeg
for i in jpegoptim ; do [ -x $i ] && strip $i ; done
core/zlib 1.2.8-3 [installed]
multilib/lib32-zlib 1.2.8-1 [installed]
extra/libjpeg-turbo 1.3.1-1 [installed]
multilib/lib32-libjpeg-turbo 1.3.1-1 [installed]
I just ran jpegoptim compiled with mozjpeg 3.1 on all my photos. 82 out of 15552 (around 0.5%) of files compressed better as baseline using --all-normal.
(I first ran jpegoptim -p --strip-com --strip-xmp --strip-iptc --strip-icc
on all photos putting optimized copies in a new directory tree. Then I added --all-normal to the command line, and ran that on all optimized photos created by the first run and all original photos for which no optimized photos were created by the first run, putting files in a third directory tree. Then I counted the number of files in that third tree.)
I have compressed jpeg image which has 7168 bytes, after compression it will increased upto 7444bytes.
I have few questions (please help to get clear idea about this) :
1.Is compression will be done based on image quality?
2.It is possible to compress smaller images which has below 7kb.?
3.how this library will choose jpegtran or jpegoptim?? based on what???
It seems like -d, --dest
argument not working.
jpegoptim -m60 *.jpg -d 'comp'
Returns
jpegoptim: invalid argument for option -d, --dest
I started using jpegoptim on a set of images I manage, and I noticed that one specific image was constantly throwing a segfault.
I am using v1.4.2, built from the GitHub repo:
jpegoptim v1.4.2 x86_64-unknown-linux-gnu
Copyright (c) 1996-2014 Timo Kokkonen.
libjpeg version: 6b 27-Mar-1998
Copyright (C) 1998, Thomas G. Lane
This is what I was calling:
jpegoptim -m60 --strip-all -Pqf segfault.jpeg
I played around with the params a bit, but nothing changed, so I assumed this was something wrong with this particular image, rebuilt jpegoptim with -ggdb and ran that same command, which resulted in this stack trace:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff763bbfa in fread () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff763bbfa in fread () from /lib/libc.so.6
#1 0x00007ffff7948504 in fill_input_buffer (cinfo=0x7fffffffe150) at jdatasrc.c:95
#2 0x00007ffff794cf53 in next_marker (cinfo=0x7fffffffe150) at jdmarker.c:897
#3 0x00007ffff794dbb8 in read_markers (cinfo=0x7fffffffe150) at jdmarker.c:963
#4 0x00007ffff794b5fa in consume_markers (cinfo=0x608b38) at jdinput.c:296
#5 0x00007ffff7947a95 in jpeg_finish_decompress (cinfo=0x7fffffffe150) at jdapimin.c:387
#6 0x0000000000403cee in ?? ()
#7 0x00007ffff75f6c8d in __libc_start_main () from /lib/libc.so.6
...
So it seems that this is happening when we call jpeg_finish_decompress() from libjpeg. I tried this with libjpeg62 and libjpeg8 on Debian Squeeze, both had the same results.
I'm not sure if this is something that breaks internally in libjpeg or if it is exploding in jpegoptim, but thought it might help catch a bug :)
Below is the image which caused this bug:
Please let me know if you need any more info.
I am not a CLI master, can you please provide me more details about how to compile with MozJPEG support?
I tried:
$ ls /opt/mozjpeg
bin include lib64 share
@ubuntu:~/scripts/jpegoptim$ ./configure CPPFLAGS=-I/opt/mozjpeg/bin/ LDFLAGS=-L/opt/mozjpeg/include/
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for jpeg_read_header in -ljpeg... yes
checking for floor in -lm... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for unistd.h... (cached) yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking for string.h... (cached) yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking jpeglib.h usability... yes
checking jpeglib.h presence... yes
checking for jpeglib.h... yes
checking size of long... 8
checking size of int... 4
checking for getopt_long... yes
checking for mkstemps... yes
checking for labs... yes
checking for broken jmorecfg.h (METHODDEF)... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: config.h is unchanged
$ ./jpegoptim --help
Wrong JPEG library version: library is 80, caller expects 62
I noticed that versin 1.2.3 produces a smaller file than version 1.3.0:
# On Ubuntu 14.04
$ jpegoptim talouspaperia-rintsikansuojana-lowres.jpg
talouspaperia-rintsikansuojana-lowres.jpg 3000x1688 24bit P Exif JFIF [OK] 292347 --> 292347 bytes (0.00%), skipped.
$ jpegoptim --version
jpegoptim v1.3.0 x86_64-pc-linux-gnu
# On Ubuntu 12.04
$ jpegoptim talouspaperia-rintsikansuojana-lowres.jpg
talouspaperia-rintsikansuojana-lowres.jpg 3000x1688 24bit Exif JFIF [OK] 292347 --> 286527 bytes (1.99%), optimized.
$ jpegoptim --version
jpegoptim v1.2.3 x86_64-pc-linux-gnu
File http://www.puutalobaby.fi/wp-content/uploads/2015/09/talouspaperia-rintsikansuojana-lowres.jpg
Is this a regression in something?
I have successfully installed all libraries in linux server. Don't know how to configure with windows server. help me to proceed further.
npm during the installation check that alert
⚠ The
/home/fargustian/node_modules/jpegoptim-bin/vendor/jpegoptim binary doesn't seem to work correctly ⚠ jpegoptim pre-build test failed ℹ compiling from source
After I trying compilation my build, but jpeg image not optimization.
I've tried all that google gave me on this problem.
Help me please :)
jpegoptim
works great for me; in my case I want to use the -S
option to set a target size and downsize my JPEG file as needed. Some of my JPEG images are JPEG-2000 (JP2) files produced by ImageMagick (http://www.imagemagick.org/script/jp2.php ) and jpegoptim
rejects them.
Is there any plan to make jpegoptim
work with JP2 files too, at least for a subset of its functionality?
When running (1.4.2)
find . -type f \( -name '*.jpg' -or -name '*.jpeg' \) -exec jpegoptim -m80 --strip-all "{}" \;
all files permissions are changed from 644 to 600.
I cannot compile latest jpegoptim release within debian build system. It fails with:
gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -c -o jpegoptim.o jpegoptim.c
jpegoptim.c: In function 'main':
jpegoptim.c:579:8: error: format not a string literal and no format arguments [-Werror=format-security]
fprintf(LOG_FH,marker_str);
^
I am getting these errors
I installed libjpeg 9-c
I can see libjpeg.so.62 in the sbin
i have a plesk setup in centos
when i went to install jpegoptim it complained about no libjpeg - so i downloaded and installed it
this allowed jpegoptim to install
ANy idea what i did wrong?
jpegoptim 1.4.2 does not compile on Solaris 9 with the following error:
Undefined first referenced
symbol in file
round jpegoptim.o
See: https://community.oracle.com/thread/1923824
Probably the code below should fix the issue:
Apparently jpegoptim writes its output to a temporary file and uses
rename(2) to move it back to the original. This breaks hard- and
symlinks and changes the permissions of the file.
ref:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708630
Can you make a new git tag as well for the latest edits (mainly the stdio stuff)?
It's a big new feature so it deserves one 😄 and also seems that the Mac OS X homebrew-community creates brew recipes by Github tag release, see e.g. the jpegoptim recipe https://github.com/Homebrew/homebrew/blob/master/Library/Formula/jpegoptim.rb
I'm currently running jpegoptim on a linux box, but it'd be nice if one could install the latest version via brew as well. After there's a new tag I can make a pull request to homebrew with a updated recipe for downloading the latest jpegoptim.
Also: I noticed this repo has a weird "LATEST"-tag which actually seems to point back 11-years, which can be a bit confusing for some people (if they don't notice the date) 😄
Is there a way that jpegoptim could preserve filesystem permissions and (where possible) ownership (user/group)?
eg: I ran it on a bunch of files that were 644, and when I looked at the output they were now 600. Of course, the files also changed to the default user/group instead of the user/group they were.
FWIW: The user/group stuff is not a huge issue, but it's one of those moments after doing it that you go "damn, forgot about that", the permissions issue tends to be the bigger problem if you're running it on a lot of files and they all have odd permissions.
Note: Only way I can see this working is to copy the uncompressed file to a temp file, then overwrite the existing file in place with the compressed version. Doing this "should" preserve any current permissions.
files with extension .tmp instead jpg
When i use --dest=tested2 tested1/Auth.jpg
folder tested2 have filename to - jpegoptim-0-3044.1509186652.tmp
instead Auth.jpg
I use win 8.1 x64
I try win 7 x32
Hello.
I'm having problems in order to set the default output path for assetic to jpegoptim images.
According to the official cookbook documentation, we must use:
filters:
jpegoptim:
bin: usr/bin/jpegoptim
apply_to: "\.jpg$"
strip_all: true
max: 70
twig:
functions:
jpegoptim: { output: myfolder/*.jpg }
And then call the function in a twig template as usual like:
<img class='image' src='{{ jpegoptim('bundles/mybundle/images/myimage.jpg') }}' alt='Image'>
But this doesn't work. The image assets go to my assetic/ folder instead.
However, if I use the alternate single-use with no configutarion tags:
{% image 'bundles/mybundle/images/myimage.jpg'
filter='jpegoptim' output='/myfolder/myimage.jpg' %}
<img src="{{ asset_url }}" alt="Image"/>
{% endimage %}
Then it works perfectly. The bad thing is that I need to specify the output folder in EVERY single image. What's the point of the configuration output tag then? I'm doing it wrong?
Thank you in advance.
When jpegoptim runs in php (shell_exec command) by cron key --preserve-perms not working. If only by php (without cron) all working properly.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.