Giter Club home page Giter Club logo

guetzli's Introduction

Guetzli

Introduction

Guetzli is a JPEG encoder that aims for excellent compression density at high visual quality. Guetzli-generated images are typically 20-30% smaller than images of equivalent quality generated by libjpeg. Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.

Build Status

Building

On POSIX systems

  1. Get a copy of the source code, either by cloning this repository, or by downloading an archive and unpacking it.
  2. Install libpng. If using your operating system package manager, install development versions of the packages if the distinction exists.
    • On Ubuntu, do apt-get install libpng-dev.
    • On Fedora, do dnf install libpng-devel.
    • On Arch Linux, do pacman -S libpng.
    • On Alpine Linux, do apk add libpng-dev.
  3. Run make and expect the binary to be created in bin/Release/guetzli.

On Windows

  1. Get a copy of the source code, either by cloning this repository, or by downloading an archive and unpacking it.
  2. Install Visual Studio 2015 and vcpkg
  3. Install libpng using vcpkg: .\vcpkg install libpng.
  4. Cause the installed packages to be available system-wide: .\vcpkg integrate install. If you prefer not to do this, refer to vcpkg's documentation.
  5. Open the Visual Studio project enclosed in the repository and build it.

On macOS

To install using Homebrew:

  1. Install Homebrew
  2. brew install guetzli

To install using the repository:

  1. Get a copy of the source code, either by cloning this repository, or by downloading an archive and unpacking it.
  2. Install Homebrew or MacPorts
  3. Install libpng
    • Using Homebrew: brew install libpng.
    • Using MacPorts: port install libpng (You may need to use sudo).
  4. Run the following command to build the binary in bin/Release/guetzli.
    • If you installed using Homebrew simply use make
    • If you installed using MacPorts use CFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib' make

With Bazel

There's also a Bazel build configuration provided. If you have Bazel installed, you can also compile Guetzli by running bazel build -c opt //:guetzli.

Using

Note: Guetzli uses a large amount of memory. You should provide 300MB of memory per 1MPix of the input image.

Note: Guetzli uses a significant amount of CPU time. You should count on using about 1 minute of CPU per 1 MPix of input image.

Note: Guetzli assumes that input is in sRGB profile with a gamma of 2.2. Guetzli will ignore any color-profile metadata in the image.

To try out Guetzli you need to build or download the Guetzli binary. The binary reads a PNG or JPEG image and creates an optimized JPEG image:

guetzli [--quality Q] [--verbose] original.png output.jpg
guetzli [--quality Q] [--verbose] original.jpg output.jpg

Note that Guetzli is designed to work on high quality images. You should always prefer providing uncompressed input images (e.g. that haven't been already compressed with any JPEG encoders, including Guetzli). While it will work on other images too, results will be poorer. You can try compressing an enclosed sample high quality image.

You can pass a --quality Q parameter to set quality in units equivalent to libjpeg quality. You can also pass a --verbose flag to see a trace of encoding attempts made.

Please note that JPEG images do not support alpha channel (transparency). If the input is a PNG with an alpha channel, it will be overlaid on black background before encoding.

guetzli's People

Contributors

andymanitara avatar da2x avatar eustas avatar fkistner avatar gaod avatar hughbe avatar jan-wassenberg avatar jyrkialakuijala avatar khavishbhundoo avatar lvandeve avatar msbit avatar pborreli avatar pjkui avatar robryk avatar ruuda avatar sbussard avatar szabadka avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

guetzli's Issues

Ubuntu 16.04 compilation error due to gflags was not found in the pkg-config search path.

After installing the needed packages as described in the README.MD using apt-get in Ubuntu 16.04 there's this error after running make:
==== Building guetzli (release) ==== Linking guetzli Package gflags was not found in the pkg-config search path. Perhaps you should add the directory containing 'gflags.pc' to the PKG_CONFIG_PATH environment variable No package 'gflags' found
The gflags.pc file simply doesn't exist on the whole system.

Undefined reference to pthread_rwlock_init

Hey guys,

in my system (Ubuntu Ubuntu 16.04.2 LTS 4.4.0-66-generic), I've gotten "Undefined reference to pthread_rwlock_init" in my build.

In the file guetzli.make I've had to add -lpthread to LINKCMD variable. I don't if it was necessary in your build (maybe not), but I thought it would be interesting if you could add it in your source files.

Best regards,

Rodrigo Gonçalves de Branco

7MB png resulted in 20MB jpg

I am curious if this is expected. After running a 7MB png (5120x2880 resolution) in guetzli darwin and waiting over 45 minutes for it to process, the file grew by 13MB.

Using a tool like Pixelmator took 5 seconds to convert the same png to a jpg at 84 quality, which resulted in a 4.9MB file.

./guetzli ./in.png ./out.jpg -verbose should result in quality 84, correct?

Why not progressive?

Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.

I thought that image-heavy websites prefer progressive mode than sequential mode (facebook, instagram), etc). I haven't done bench marking myself, but how much faster is sequential mode in terms of decompression speed?

PNG output support?

I'd like to create optimized PNG image.

Any plan to support PNG output? Or any recommended alternatives for PNG image?

solved: build failure on Ubuntu/Kubuntu 16.10

Per here: jart/hiptext#38

...libgflags.pc is missing on Ubuntu (I'm on Kubuntu 16.10), which causes build errors:

Package libgflags was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgflags.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgflags' found

As root I made /usr/lib/x86_64-linux-gnu/pkgconfig/libgflags.pc per the instructions in the above link, and it built fine.

I understand the bug is fixed in later versions of libgflags-dev? Anyway, wanted to post so that others might find it, and perhaps you could update the README, etc.

Ubuntu build instructions fail

On Ubuntu 16.10 with libgflags-dev and libpng-dev installed ...

Build following supplied 'On POSIX systems' instructions fails as neither gflags.pc nor libgflags.pc not on system (... Package libgflags was not found in the pkg-config search path....)

Backing out recent changes that use pkgconfig allow build to work again
(HEAD is now at 95ba421... Work around mysterious Mac build error.)

“No package 'gflags' found” and “guetzli.make:103: recipe for target 'bin/Release/guetzli' failed”

On Ubuntu 16.04
the permission is root

lyl@lyl:~/program/guetzli$ ls
bin    CONTRIBUTING.md  guetzli.make  guetzli.vcxproj          LICENSE   obj        premake5.lua  snapcraft.yaml  tools      zlib.BUILD
BUILD  guetzli          guetzli.sln   guetzli.vcxproj.filters  Makefile  png.BUILD  README.md     third_party     WORKSPACE

and,

lyl@lyl:~/program/guetzli$ make
==== Building guetzli (release) ====
jpeg_data_encoder.cc
Package gflags was not found in the pkg-config search path.
Perhaps you should add the directory containing `gflags.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gflags' found
.....
.....
.....
collect2: error: ld returned 1 exit status
guetzli.make:103: recipe for target 'bin/Release/guetzli' failed
make[1]: *** [bin/Release/guetzli] Error 1
Makefile:26: recipe for target 'guetzli' failed
make: *** [guetzli] Error 2

What Problem???

Segfault on malformed input

/p/t/guetzli (master) $ ./bin/Release/guetzli crasher-min-36.jpg /dev/null
fish: './bin/Release/guetzli crasher-m…' terminated by signal SIGSEGV (Address boundary error)
/p/t/guetzli (master) $ xxd crasher-min-36.jpg
00000000: ffd8 ffdb 0043 0030 3030 3030 3030 3030  .....C.000000000
00000010: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000020: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000030: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000040: 3030 3030 3030 30ff db00 4301 3030 3030  0000000...C.0000
00000050: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000060: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000070: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000080: 3030 3030 3030 3030 3030 3030 ffc0 0011  000000000000....
00000090: 0800 0830 3003 3022 0002 1101 0311 01ff  ...00.0"........
000000a0: c400 1a11 0100 0203 0100 0000 0000 0000  ................
000000b0: 0000 0000 00fb 99ac 30e7 97ff d9         ........0....

(Discovered using afl-fuzz)

Fails to link with libgflags_nothreads.so: undefined reference to `pthread_rwlock_unlock'

Building with gcc 6, make fails with:

Linking guetzli
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libgflags_nothreads.so: undefined reference to `pthread_rwlock_unlock'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libgflags_nothreads.so: undefined reference to `pthread_rwlock_init'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libgflags_nothreads.so: undefined reference to `pthread_rwlock_destroy'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libgflags_nothreads.so: undefined reference to `pthread_rwlock_wrlock'
collect2: error: ld returned 1 exit status
guetzli.make:103: recipe for target 'bin/Release/guetzli' failed
make[1]: *** [bin/Release/guetzli] Error 1
Makefile:28: recipe for target 'guetzli' failed
make: *** [guetzli] Error 2

CUDA and/or OpenCL usage for DCT and other functions?

Current execution time is horrible for any practical use case. I was wondering why don't we simply plug-in available functions from NVIDIA's NPP library? It wouldn't mean porting anything to CUDA simply plugging in available functions. Anyone working on GPU port?

Photoshop cannot open files

Photoshop under OS X cannot open many files produced by guetzli. It returns with error "Could not complete your request because an invalid non-baseline JPEG table number >= 2 is found." I am also told that they don't work under OS X Preview for some people. I can run them through jpegtran to get them to work everywhere.

Not using subsampling

I've used gimp with subsampling 4:2:0 and get better compression than guetzli. Is it possible to have that option?

Comparison with mozjpeg?

README says:

Guetzli-generated images are typically 20-30% smaller than images of equivalent quality generated by libjpeg

But what about mozjpeg? It existed long before this project, by the way — 1.0 release was in Mar 5, 2014, and it does similar job.

Fails to build with error: ‘memcpy’ was not declared in this scope

Building with gcc 6, make fails with:

guetzli.cc
guetzli/guetzli.cc: In function ‘bool {anonymous}::ReadPNG(FILE*, int*, int*, std::vector<unsigned char>*)’:
guetzli/guetzli.cc:119:45: error: ‘memcpy’ was not declared in this scope
         memcpy(row_out, row_in, 3 * (*xsize));
                                             ^
guetzli/guetzli.cc: In function ‘int main(int, char**)’:
guetzli/guetzli.cc:221:68: error: ‘memcmp’ was not declared in this scope
       memcmp(in_data.data(), kPNGMagicBytes, sizeof(kPNGMagicBytes)) == 0) {
                                                                    ^
guetzli.make:165: recipe for target 'obj/Release/guetzli.o' failed
make[1]: *** [obj/Release/guetzli.o] Error 1
Makefile:28: recipe for target 'guetzli' failed
make: *** [guetzli] Error 2

Arithmetic coded JPEG support

Arithmetic coding is a part of the JPEG standard. Initially, it wasn't implemented by encoders and decoders due patents. But now there is no such limitation, all patents are expired several years ago. libjpeg supports arithmetic coding since version 7.x (2009), libjpeg-turbo and mozjpeg also support arithmetic coding. It significantly improves compression ratio.

Currently, Chromium doesn't support it. There is a ticket about it, so it may be changed in the future. You can star the ticket to support it if you think that arithmetic coded JPEG support is a good idea.

LD Flag `-s` Obselete

Building guetzli via make on Mac OS X 10.11.3 results in this error for me:

ld: warning: option -s is obsolete and being ignored
ld: internal error: atom not found in symbolIndex(__ZN7guetzli21ButteraugliComparatorD2Ev) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [bin/Release/guetzli] Error 1
make: *** [guetzli] Error 2

To fix this error I edited guetzli.make and made these changes:

- ALL_LDFLAGS += $(LDFLAGS) -s
+ ALL_LDFLAGS += $(LDFLAGS) #-s

This successfully linked the build and generated the guetzli executable in bin/Release.
I don't know anything about make, but if someone could point me in the proper direction for detecting OS X in a make file I would be willing to open a PR to fix this issue.

Cheers!

Unbelievably good encoding performance?

It seems unrealistic, but testing on 128px square images at 90 quality, I'm getting roughly 10x smaller files than PS saving the same images at 9 quality. Visual quality is comparable.

I've written a blog post showing the results and will attach a zip of the results later.
http://uxgroup.com.au/using-googles-guetzli-jpeg-encoder

This isn't a bug, but I want to know what factor is resulting in this performance, as it doesn't seem to be normal.

CentOS `make` Compile error

Installed dependency package libpng libpng-devel gflags gflags-devel.

yum install -y libpng libpng-devel gflags gflags-devel

make //The error is as follows

==== Building guetzli (release) ====
butteraugli_comparator.cc
Package gflags was not found in the pkg-config search path.
Perhaps you should add the directory containing `gflags.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gflags' found
cc1plus: error: unrecognized command line option "-std=c++11"
make[1]: *** [obj/Release/butteraugli_comparator.o] Error 1
make: *** [guetzli] Error 2

Is it really necessary to rewrite the source code to support quality lower than 84?

I just wanted to play around with guetzli and when I tried to compress some images it told me that in order to go lower than --quality 84 I need to rewrite the source code.

Guetzli should be called with quality >= 84, otherwise the
output will have noticeable artifacts. If you want to
proceed anyway, please edit the source code.

Wouldn't be a short yes-or-no-prompt and a flag that suppresses said warning be much better?

Something along the lines of:

Guetzli should be called with quality >= 84, otherwise the
output will have noticeable artifacts. Do you want to
proceed anyway? [yes / no]

and some flag, probably -f, to skip the prompt.

What do you think?

Build errors/warnings.

In file included from /usr/local/include/gflags/gflags.h:84:
/usr/local/include/gflags/gflags_declare.h:43:9: warning: 'GFLAGS_NAMESPACE' macro redefined [-Wmacro-redefined]
#define GFLAGS_NAMESPACE gflags
        ^
<command line>:1:9: note: previous definition is here
#define GFLAGS_NAMESPACE google
        ^
output_image.cc
guetzli/output_image.cc:206:5: error: use of undeclared identifier 'exit'
    exit(1);
    ^

On FreeBSD 11.

Building on OS X

$ ~ brew list
... gflags libpng ... 
$ ~/git/guetzli make
==== Building guetzli (release) ====
guetzli.cc
guetzli/guetzli.cc:24:10: fatal error: 'gflags/gflags.h' file not found
#include "gflags/gflags.h"
         ^
1 error generated.
make[1]: *** [obj/Release/guetzli.o] Error 1
make: *** [guetzli] Error 2 

Anyone gotten this to work?

Guetzli doesn't seem to respect PNG color profiles

I don't know whether this is a problem with Guetzli, but I thought I'd report it.
The attached PNG looks very different when its embedded color profile is respected, but Guetzli doesn't seem to respect it or include it (or any metadata) in the JPEG produced.

jf7_031849

The resulting JPEG looks dark and drab... the color has shifted because the color data was assumed to be something (sRGB?) instead of being treated as the ProPhotoRBG that it is.

One could just copy the color profile over to the resulting JPEG, but since Guetzli takes into account human perception, one would assume that it should analyze the proper colors to begin with, so it should apply the color profile before actually inspecting the colors as data.....

Support YUV422 input

This is the image:
image

./guetzli_linux_x86-64 image.jpg output.jpg gives the error:

Invalid input JPEG file
Guetzli processing failed

Is the JPEG file really invalid? What qualifies as invalid or valid? The image above came directly from a an android phone's camera.

Why limit quality 84 by default?

Please open it to any quality level. Just warn user is enough instead of redirect user to change the code in a manner of just to do testing. Since I do not has VS Studio Environment setup well yet, cannot compile the code. So far, the compression at 84 compare to libjpeg is versy imperssive. guetzli is much smaller and better quality. I just want to go lower and see the result.

How to do batch compress images?

Imagemagick is a good tool that can support batch compress images like:

mogrify -verbose -format jpg -quality "85%" **/*.png

But how to do this by using guetzli?

Feature request: memory limit

I've tried Guetzli on a large batch of images, and my macOS machine ended locking up hard. I presume it's because macOS doesn't fail malloc, but instead switches to using a combination of compressed RAM and swap, which on such a large memory demand bring performance to a halt.

I'm interested in limiting Guetzli's memory use to a percentage of machine's RAM size (e.g. no more than half of all RAM).

Will it be reliable enough if it's done heuristically based on number of pixels in the image?

Is CacheAligned::Allocate used for the majority of allocations? Would it be better to put a limit there?

Can't read jpg data from input file

I'm trying to do something simple like this guetzli-master/bin/Release/guetzli --quality 84 /home/user/Desktop/logo.jpg /home/user/Desktop/logo.jpg

but I get this error

Can't read jpg data from input file
Guetzli processing failed

there are no problems with png to jpg , am I doing something wrong?

PHP shared hosting

Is there any way to use that in PHP project on shared hosting (Apache)?

Null pointer dereference in ProcessJpegData (processor.cc:790)

Compiled with afl-g++ and ASan.

./guetzli id:000000,sig:06,src:000000,op:flip2,pos:164.min /dev/null

(linked file is a zip file...unzip first before running above command)

ASAN:DEADLYSIGNAL
=================================================================
==25977==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55a45ae98e29 bp 0x7ffd18ad4a90 sp 0x7ffd18ad4540 T0)
    #0 0x55a45ae98e28 in ProcessJpegData guetzli/processor.cc:790
    #1 0x55a45aeaecda in guetzli::ProcessJpegData(guetzli::Params const&, guetzli::JPEGData const&, guetzli::Comparator*, guetzli::GuetzliOutput*, guetzli::ProcessStats*) guetzli/processor.cc:836
    #2 0x55a45aeaecda in guetzli::Process(guetzli::Params const&, guetzli::ProcessStats*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) guetzli/processor.cc:863
    #3 0x55a45adb2dcf in main guetzli/guetzli.cc:237
    #4 0x7fe6dc95d2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
    #5 0x55a45adb3b69 in _start (/home/joseph/fuzz/guetzli/guetzli-afl-debug/bin/Debug/guetzli+0xab69)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV guetzli/processor.cc:790 in ProcessJpegData
==25977==ABORTING

Windows support

The only binaries are for Linux and Mac. Do you plan to support Windows? If so, when do you expect Windows binaries to be available?

centos 7.3 build errors

Using CentOS 7.3 64bit

yum list libpng gflags libpng-devel gflags-devel -q | tr -s ' '
Installed Packages
gflags.x86_64 2.1.1-6.el7 @epel 
gflags-devel.x86_64 2.1.1-6.el7 @epel 
libpng.x86_64 2:1.5.13-7.el7_2 @updates
libpng-devel.x86_64 2:1.5.13-7.el7_2 @updates
make
==== Building guetzli (release) ====
guetzli.cc
<command-line>:0:18: error: ‘google’ is not a namespace-name
guetzli/guetzli.cc:33:17: note: in expansion of macro ‘GFLAGS_NAMESPACE’
 using namespace GFLAGS_NAMESPACE;
                 ^
guetzli/guetzli.cc:33:33: error: expected namespace-name before ‘;’ token
 using namespace GFLAGS_NAMESPACE;
                                 ^
guetzli/guetzli.cc: In function ‘int main(int, char**)’:
guetzli/guetzli.cc:194:55: error: ‘SetUsageMessage’ was not declared in this scope
       "guetzli [flags] input_filename output_filename");
                                                       ^
guetzli/guetzli.cc:194:55: note: suggested alternative:
In file included from guetzli/guetzli.cc:24:0:
/usr/include/gflags/gflags.h:331:29: note:   ‘gflags::SetUsageMessage’
 extern GFLAGS_DLL_DECL void SetUsageMessage(const std::string& usage);
                             ^
guetzli/guetzli.cc:195:43: error: ‘ParseCommandLineFlags’ was not declared in this scope
   ParseCommandLineFlags(&argc, &argv, true);
                                           ^
guetzli/guetzli.cc:195:43: note: suggested alternative:
In file included from guetzli/guetzli.cc:24:0:
/usr/include/gflags/gflags.h:346:31: note:   ‘gflags::ParseCommandLineFlags’
 extern GFLAGS_DLL_DECL uint32 ParseCommandLineFlags(int *argc, char*** argv, bool remove_flags);
                               ^
guetzli/guetzli.cc:198:31: error: ‘ShowUsageWithFlags’ was not declared in this scope
     ShowUsageWithFlags(argv[0]);
                               ^
guetzli/guetzli.cc:198:31: note: suggested alternative:
In file included from guetzli/guetzli.cc:24:0:
/usr/include/gflags/gflags.h:175:29: note:   ‘gflags::ShowUsageWithFlags’
 extern GFLAGS_DLL_DECL void ShowUsageWithFlags(const char *argv0);  // what --help does
                             ^
make[1]: *** [obj/Release/guetzli.o] Error 1
make: *** [guetzli] Error 2

Memory usage

The official 1.0 release binary crashes on Windows encoding a 24 MP photo.
It seems like this is a RAM issues, since it quickly eats gigabytes of RAM before crashing.
Is there a 64bit version? And is the RAM usage expected?

problems compiling on osx with bazel

I ran into some errors compiling guetzli with bazel on osx 10.11.
These changes to WORKSPACE fixed it for me:

  1. change http://github.com/glennrp/libpng/archive/v1.2.57.zip to https://github.com/glennrp/libpng/archive/v1.2.57.zip
  2. change third_party/butteraugli/ to the absolute path e.g. /Users/chris/guetzli/third_party/butteraugli/

null pointer dereference in LinearRgb (butteraugli_comparator.cc:43)

Compiled with afl-clang-fast.

./guetzli --quality 78 test000 /dev/null

ASAN:DEADLYSIGNAL
=================================================================
==21996==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000004fa40d bp 0x62300000e140 sp 0x7fffb7d6b530 T0)
    #0 0x4fa40c in LinearRgb /root/guetzli/guetzli/butteraugli_comparator.cc:43
    #1 0x4fa40c in guetzli::ButteraugliComparator::ButteraugliComparator(int, int, std::vector<unsigned char, std::allocator<unsigned char> > const&, float, guetzli::ProcessStats*) /root/guetzli/guetzli/butteraugli_comparator.cc:63
    #2 0x5e414d in guetzli::Process(guetzli::Params const&, guetzli::ProcessStats*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /root/guetzli/guetzli/processor.cc:854
    #3 0x41a99c in main /root/guetzli/guetzli/guetzli.cc:228
    #4 0x7fbef01432b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
    #5 0x41b819 in _start (/root/guetzli/bin/Debug/guetzli+0x41b819)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /root/guetzli/guetzli/butteraugli_comparator.cc:43 in LinearRgb
==21996==ABORTING

Supported Colorspace

I got an error "Only YUV color space input jpeg is supported, Guetzli processing failed". Where can I find the supported colorspace list?

Extremely slow performance

How long does it take for you to compress a couple of images?

I tried compressing a 7,8MB JPG with --quality 84 and it took nearly 20 minutes.

I also tried a 1,4MB JPG with --quality 85 and it took nearly 10 minutes.

I must assume that this is not normal - is something wrong with my binary?

I am on Ubuntu 16.04 LTS, intel core i7-4790K CPU @ 4.00GHz
I installed gflag via sudo apt-get install libgflags-dev and got libpng via sudo apt-get install libpng16-dev. After that I make with no errors.

convert -quality 85 src.jpg dst.jpg runs in under 1 second, if that is any help.

Anyone else experience this?

Support resizing and/or thumbnail workflow

Web authors or content-management systems often need to export multiple sizes of an image for different UI or devices.

Based on the documentation and some quick tests I did, it seems like the ideal workflow that involves Guetzli would be:

  1. Have a huge source PNG
  2. Resize that source PNG into multiple smaller PNGs of the dimensions you need.
  3. Use Guetzli to convert those PNGs to hyper-optimized JPEGs.

Images made in that middle step are essentially discarded/overhead. You also need to use another library to do it, and try to preserve PNG quality as you go.

Is a feature that would resize the source image while processing in scope for this CLI?

$ guetzli --quality 85 --resize 720x480 in.png out.jpg

An big potential reason to avoid this is that people start asking for even more this-could-be-ImageMagick features.

Homebrew gflags has no `libgflags.pc`

Building from master (c78689c5e020c0cd3580783213798b6323eaa454) on macOS gives me the following error:

==== Building guetzli (release) ====
Creating obj/Release
butteraugli_comparator.cc
Package libgflags was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgflags.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgflags' found

...snip...

butteraugli.cc
Package libgflags was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgflags.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgflags' found
Linking guetzli
Package libgflags was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgflags.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgflags' found
Undefined symbols for architecture x86_64:
  "google::FlagRegisterer::FlagRegisterer<bool>(char const*, char const*, char const*, bool*, bool*)", referenced from:
      __GLOBAL__sub_I_guetzli.cc in guetzli.o
  "google::FlagRegisterer::FlagRegisterer<double>(char const*, char const*, char const*, double*, double*)", referenced from:
      __GLOBAL__sub_I_guetzli.cc in guetzli.o
  "google::SetUsageMessage(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in guetzli.o
  "google::ShowUsageWithFlags(char const*)", referenced from:
      _main in guetzli.o
  "google::ParseCommandLineFlags(int*, char***, bool)", referenced from:
      _main in guetzli.o
  "_png_create_info_struct", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_create_read_struct", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_destroy_read_struct", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_get_channels", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_get_image_height", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_get_image_width", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_get_rows", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_init_io", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_read_png", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
  "_png_set_longjmp_fn", referenced from:
      (anonymous namespace)::ReadPNG(__sFILE*, int*, int*, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >*) in guetzli.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [bin/Release/guetzli] Error 1
make: *** [guetzli] Error 2

As part of the Homebrew gflags package, the pkg-config file is gflags.pc, not libgflags.pc so the build process can't set up the build flags properly.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.