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

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?

When jpegoptim runs in php (shell_exec command) by cron key --preserve-perms not working. If only by php (without cron) all working properly.

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

mozilla/mozjpeg#232 (comment)

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

http://www.kokkonen.net/tjko/projects.html is unreachable.

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

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.

./jpegoptim -d ./jpg_out -o ./g8.jpg

g8.jpg 25x25 8bit N JFIF [OK] 436 --> 250 bytes (42.66%), optimized.
AddressSanitizer:DEADLYSIGNAL

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

g8.zip

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

ORIGINAL:

AFTER OPTIMIZATION:

Command Used:

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

Image is downloaded from http://www.creativedigitaldarkroom.com/Downloads.html

I have successfully installed all libraries in linux server. Don't know how to configure with windows server. help me to proceed further.

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.

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

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

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?

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.

I receive 'error creating temp file: mkstemps() failed'
I try last version and the branch master from github.

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.

on RELEASE.1.4.4

#jpegoptim --dest=tempoutdir $FILE

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

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

you can download windows from here

Could you please link
http://sourceforge.net/projects/jpegoptim/ ?

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]

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.

The certificate expired on 19 September 2018, so https://www.kokkonen.net/tjko/projects.html reports an error

./configure
Error： Cannot find libjpeg or you have too old version (v6 or later required)

How use???

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

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.

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:

ifndef HAVE_LIBM

define round(x) floor(0.5+x)

endif

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:

1. Requires advanced Linux terminal knowledge or using Google to find the command
2. Does not work with the --totals option, since essentially it's running jpegoptim separately for each file

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.

It seems like -d, --dest argument not working.

jpegoptim -m60 *.jpg -d 'comp'

Returns

jpegoptim: invalid argument for option -d, --dest

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?

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

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.

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

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?

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

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.

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

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.

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.

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.

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?

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