libgd/libgd

GD Graphics Library

GD Graphics (Draw) Library

GD is an open source code library for the dynamic creation of images by programmers.

GD is written in C, and "wrappers" are available for Perl, PHP and other languages. GD can read and write many different image formats. GD is commonly used to generate charts, graphics, thumbnails, and most anything else, on the fly.

The most common applications of GD involve website development, although it can be used with any standalone application!

The library was originally developed by Thomas Boutell and is now maintained by many contributors (see the CONTRIBUTORS file) under the umbrella of PHP.net.

If you like to contribute, report bugs, see how to contribute document

For security related issues, please contact us at [email protected]

Support available in or using issues.

We also have a mailing list. To subscribe to any mailing list, send an email to [email protected]. Then emails can be sent to [email protected].

Downloads/etc...

Please visit our homepage for more details.

Supported Image Formats

GD has support for:

• WebP via libwebp
• JPEG via IJG/libjpeg or libjpeg-turbo
  • Does not include JPEG 2000
• PNG via libpng
• AVIF via libavif
  • This includes AVIF read support if your system's libheif has AV1 decoding.
• HEIF via libheif
• TIFF via libtiff
• BMP (builtin)
• GIF (builtin)
• TGA (builtin)
• WBMP (builtin)
• XPM via libXpm

Besides that, GD depends on some external libraries, which are all optional and disabled by default:

• FreeType for rendering fonts
• Fontconfig for configuring and customizing font access
• libraqm for complex text layout
• libimagequant for conversion of RGBA images to 8-bit indexed-color images
  • NOTE libimagequant is dual-licensed: GPLv3 and commercial license

Platforms supported

CI means whether we have an automatic CI for this platform. If someone has CI for these platforms or any other platforms not listed here and would like to add them to our automatic CI, please get in touch with us, it will much appreciated!

Platform	Support	CI
Linux x64	✓	✓
Linux x86	✓	✓
Linux ARM64	✓	✓
Windows x86	✓	✓
Windows x64	✓	✓
Windows arm64	✓	x
macOS x64	✓	✓
macOS M1	✓	x
S390	✓	x

It is also known to work on almost all variations of *BSD, Solaris, etc. We don't have CI nor environment to test them. However many progamming languages binding do test libgd on these platforms.

Compilers

It should compile with all C99 and C++ compliant compilers, either using CMake or the configure script.

We do have CI using:

• GCC
• CLang
• Visual Studio
• Xcode
• MingW

Supported Versions

• GD 2.3 (Branch GD-2.3) serie is in active support for bug fixes. No new additions will be added.
• GD 2.4 (master) is the active development branch. No release date yet.
• GD 3.0 has been started, focusing on high quality 2D Vector drawing APIs and full support of actual ARGB 32 bits/8bits or float. It is not production ready yet

libgd's Issues

Suspicious code in /gd-libgd/src/gd_crop.c

Hello,

i have found a supspicious piece of code in file /gd-libgd/src/gd_crop.c at line 215. Consider following line:

#!C
} else if (tr == bl || tr == bl) {

Either it can be reduced to

#!C
} else if (tr == bl) {

or this is a copy&paste error!

Best regards

Martin Ettl

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/20
• Originally reported by: ettlmartin (Martin Ettl)
• Originally created on: Aug 06 2012

gdlib-config is no longer maintained?

Hello,

After installing gdlib from mercurial repository, I noticed that it now uses cmake, and that the gdlib-config script is no longer interpolated and installed. I would like to know if it will no longer be maintained, or if you can re-add it again. It is used by the GD perl module, and if it will no longer be maintained, I must warn the author :)

Thank you

Alberto Simões

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/4
• Originally reported by: Anonymous
• Originally created on: Jul 14 2011

Missing includes in archive

The following files are in src folder, but not in the archive from download (2.1.0-preview.tar.xz)

• gd_color.h
• gd_nnquant.h
• gd_intern.h

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/44
• Originally reported by: remicollet (Remi Collet)
• Originally created on: Apr 21 2013

imagecopyresampled() produces rounding errors

imagecopyresampled() produces rounding errors.

A simple example is trying to resample a fully transparent 560x349 image down to 100x62.

The resulting image will have transparency 2/255, not 0 as it was in the original image.

This is caused by a conversion to int without rounding - alpha/spixels is often something like 126.999999999, that is floored down to int 126, and then 126 is transformed into opacity=2.

The fix would be to change

#!c
red /= spixels;
green /= spixels;
blue /= spixels;
alpha /= spixels;

to

#!c
red = red/spixels+0.5;
green = green/spixels+0.5;
blue = blue/spixels+0.5;
alpha = alpha/spixels+0.5;

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/26
• Originally reported by: vitalif (vitalif)
• Originally created on: Oct 15 2012

how to install??

Hi, I'm having the same issue as others here where I've downloaded the library to my Mac 10.6 OSX snow leopard and there's no configure file, install-sh is asking for a file to be passed to it and there's no instructions....

Any help on this?

Best,

K

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/22
• Originally reported by: Anonymous
• Originally created on: Aug 28 2012

fix configure.ac and Makefile.am's to top dir and subdirs

Current autoconf scripts are only in /src. configure.ac needs to be moved to topdir and the various makefile.am needs to be udpated accordingly.

Last stoping point for 2.1 1st beta release.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/41
• Originally reported by: pierrejoye (Pierre Joye)
• Originally created on: Apr 06 2013

DEFAULT_FONTPATH in gd.h and gdft.c

If DEFAULT_FONTPATH is not set when building (and it's not from CMakeLists.txt) it is set in the code in two places, in gd.h and gdft.c (actually the latter is never used, because gd.h already has set it.). I'd like to add a reasonable default value for Windows, but it would be good to first move everything to one place. Any thoughts?

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/40
• Originally reported by: wojdyr (Marcin Wojdyr)
• Originally created on: Apr 05 2013

cmake scripts enhancements

I'd like to propose two changes to cmake script, but before making PR I'd like to ask what you think about it.

• FindFreetype.cmake - the version of this file distributed with cmake does more robust search for headers and library. It'd be easy to replace or remove this script from libgd unless there are some essential customizations. I think there are none, but I may be wrong.
• more control what is built: options BUILD_SHARED_LIBRARY, BUILD_STATIC_LIBRARY, BUILD_PROGRAMS

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/43
• Originally reported by: wojdyr (Marcin Wojdyr)
• Originally created on: Apr 17 2013

Error imagefilledellipse with radius more than 2070 dots .

Sorri for my english...
Try to use:
imagefilledellipse($i, 1505, 1505, 3000, 3000, $any_color);
There is trubble instead any filledellipse...
This error is begining sinse ~2070 dots.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/11
• Originally reported by: Anonymous
• Originally created on: Dec 05 2011

Anti-aliased line doesn't honor thickness

When drawing an anti-aliased line, a static function gdImageAALine is used instead original gdImageLine. But gdImageAALine's line is always a (perceptually) 1-pixel thick line, regardless of what value was
called with gdImageSetThickness.

How to reproduce:
Set thickness to n > 1. Draw a line with the antialased color.

Actual results:
A 1-pixel wide AA line is drawn.

Expected results:
An n-pixel wide AA line is drawn.

Additional info:
https://bugzilla.redhat.com/show_bug.cgi?id=198042
(but the patch attached by the bug report above is buggy, I'll attach a fixed one)

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/16
• Originally reported by: hhorak (hhorak)
• Originally created on: Feb 28 2012

Output of gdlib-config --libs is wrong

$ gdlib-config --libs

gives

-ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm

Why is

-lgd

missing in this list?

I tried generating the shell script gdlib-config from config/ but failed.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/17
• Originally reported by: Anonymous
• Originally created on: Apr 17 2012

tests/jpeg/jpeg_read.c fails with libjpeg8/9 due different subsampling method

On Debian Wheezy amd64 the jpeg_read.c test fails with:

jpeg/jpeg_read.c:28: Total pixels changed: 18218 with a maximum channel difference of 0.
jpeg/jpeg_read.c:29: gdAssertImageEqualsToFile failed.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/50
• Originally reported by: oerdnj (Ondřej Surý)
• Originally created on: Apr 22 2013

Cannot build php 5.3.18 with ilbgd on CentOS 6.3

Hello everybody,
I tried to build php 5.3.18 with libgd using commands:

./configure --prefix=/usr/php --enable-exif --with-gd=/usr/local --with-png-dir=/usr/local --with-jpeg-dir=/usr/local

make -j4

And I got errors during second command:

In file included from /root/php-5.3.18/ext/gd/gd.c:58:
/root/php-5.3.18/ext/gd/libgd/gd_compat.h:43: error: nested redefinition of ‘enum gdPixelateMode’
/root/php-5.3.18/ext/gd/libgd/gd_compat.h:43: error: redeclaration of ‘enum gdPixelateMode’
/root/php-5.3.18/ext/gd/libgd/gd_compat.h:44: error: redeclaration of enumerator ‘GD_PIXELATE_UPPERLEFT’
/usr/local/gd.h:781: note: previous definition of ‘GD_PIXELATE_UPPERLEFT’ was here
/root/php-5.3.18/ext/gd/libgd/gd_compat.h:46: error: redeclaration of enumerator ‘GD_PIXELATE_AVERAGE’
/usr/local/gd.h:783: note: previous definition of ‘GD_PIXELATE_AVERAGE’ was here
/bin/sh /root/php-5.3.18/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/local/ -Iext/gd/ -I/root/php-5.3.18/ext/gd/ -DPHP_ATOM_INC -I/root/php-5.3.18/include -I/root/php-5.3.18/main -I/root/php-5.3.18 -I/root/php-5.3.18/ext/date/lib -I/root/php-5.3.18/ext/ereg/regex -I/usr/include/libxml2 -I/usr/local/include -I/usr/include/freetype2 -I/usr/local/ -I/root/php-5.3.18/ext/mbstring/oniguruma -I/root/php-5.3.18/ext/mbstring/libmbfl -I/root/php-5.3.18/ext/mbstring/libmbfl/mbfl -I/root/php-5.3.18/TSRM -I/root/php-5.3.18/Zend -I/usr/local/include -g -O2 -fvisibility=hidden -c /root/php-5.3.18/ext/gd/libgd/gd_compat.c -o ext/gd/libgd/gd_compat.lo
make: *** [ext/gd/gd.lo] Error 1

GD was installed with libjpeg and libpng:

libjpeg

wget http://www.ijg.org/files/jpegsrc.v8d.tar.gz

tar -xzf jpegsrc.v8d.tar.gz

cd jpeg-8d

./configure --prefix=/usr/local

make -j4

make install

libpng

wget http://downloads.sourceforge.net/project/libpng/libpng15/1.5.13/libpng-1.5.13.tar.gz?r=http%3A%2F%2Fwww.libpng.org%2Fpub%2Fpng%2Flibpng.html&ts=1351421424&use_mirror=citylan

tar -xzf libpng-1.5.13.tar.gz

cd libpng-1.5.13

./configure --prefix=/usr/local

make -j4

make install

GD

hg clone https://bitbucket.org/pierrejoye/gd-libgd

cd gd-libgd/

mkdir build

cd build

echo "cmake_policy(SET CMP0002 OLD)" >> ../CMakeLists.txt

cmake ..

make -j4

make install

Does anybody know how to fix this?
Thanks in advance

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/30
• Originally reported by: ssemashko (Siarhei Semashko)
• Originally created on: Mar 01 2013

MyGDLib

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/33
• Originally reported by: Anonymous
• Originally created on: Mar 08 2013

Use libimagequant for palette generation

I've developed a library for high-quality quantization that IMHO is a big quality improvement over an old algorithm currently used by libgd (you can try it at http://tinypng.org ).

http://pngquant.org/lib/

I've managed to integrate the library with libgd at code level, but I'm not submitting a patch yet, as I haven't figured out how to link with it properly.

I'm not sure what's your approach to handling external dependencies like this. I don't have OS-level package for the library, and I'm not familiar with cmake enough to figure out how to best integrate it.

The library is BSD-licensed and could be statically linked.

What would be your approach to integrating such library? Should I create a dynamically linked library as a package? Would you just copy the code to libgd or hook it as a submodule/subrepository? Or maybe cmake could download and build static version of the library?

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/34
• Originally reported by: pornel (pornel)
• Originally created on: Mar 14 2013

bug with imagecopyresampled

Hello
appears strange bug with gd
version - 2.0.33
php - 5.2.10
After imagecopyresampled on the new image appear gray line like in attached image, but original image was clear without any gray pieces

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/23
• Originally reported by: madman25 (Vlad Vlad)
• Originally created on: Sep 13 2012

Problems found by Coverity static analysis tool

A static analysis using Coverity has been performed on libgd source.
List of defects is attached. Some of the problems have straight fix so I'll attach several patches, that can be applied for gd-2.0.35 source.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/28
• Originally reported by: hhorak (hhorak)
• Originally created on: Dec 10 2012

gdImageLine may misbehave or enter infinite loop if anti-aliasing is used and image size > 32768

Please look at the following piece of code:

#include<stdio.h>
#include "gd.h"

int main() {
  /* Declare the image */
  gdImagePtr im;
  /* Declare output files */
  FILE *pngout;
  int black, white;

  im = gdImageCreateTrueColor(63318, 771);

  /* Allocate the color white (red, green and blue all maximum). */
  white = gdImageColorAllocate(im, 255, 255, 255);  
  /* Allocate the color white (red, green and blue all maximum). */
  black = gdImageColorAllocate(im, 0, 0, 0);  

  /* white background */
  gdImageFill(im, 1, 1, white);

  gdImageSetAntiAliased(im, black);

  /* This line fails! */
  gdImageLine(im, 28562, 631, 34266, 750, gdAntiAliased);  

  /* Open a file for writing. "wb" means "write binary", important
    under MSDOS, harmless under Unix. */
  pngout = fopen("test.png", "wb");

 /* Output the image to the disk file in PNG format. */
  gdImagePng(im, pngout);

  /* Close the files. */
  fclose(pngout);

  /* Destroy the image in memory. */
  gdImageDestroy(im);
}

The function gdImageLine seems to never return, if at least one of the coordinates is over 32768 and anti-aliasing is used.

With coordinates different from the above example, the function may return, but the line drawn is still incorrect.

This problem was originally reported to gnuplot (bug no. 3377536), but I was able to isolate it.

gd version: 2.0.36
system: Ubuntu linux 10.04.2 32-bit

Péter Juhász

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/5
• Originally reported by: Anonymous
• Originally created on: Jul 26 2011

Building for mingw with configure script

Hi, I downloaded the 2.0.33 hg tag as a tar.bz2 and tried to ./configure and make the library:

../libgd-2.0.33/configure --host=x86_64-w64-mingw32 --with-jpeg=/jpeg --with-zlib=/zlib

The configuring went fine, but suring the make step, a DLL related error pops up:

#!sh


x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../libgd-2.0.33/src -I. -I/gnuplotinstall/include/freetype2 -I/gnuplotinstall/include -I/gnuplotinstall/include -I/jpeg/include -g -O2 -MT gdfontg.lo -MD -MP -MF .deps/gdfontg.Tpo -c ../libgd-2.0.33/src/gdfontg.c  -DDLL_EXPORT -DPIC -o gdfontg.lo
../libgd-2.0.33/src/gdfontg.c:4380:32: error: variable 'gdFontGiant' definition is marked dllimport
../libgd-2.0.33/src/gdfontg.c:4380:32: warning: 'gdFontGiant' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
make[2]: *** [gdfontg.lo] Error 1
make[2]: Leaving directory `/home/Ruben/libgd'

This may have to do with the libtool deciding on -DDLL_EXPORT and you using NONDLL and the nonstandard WIN32 (should be _WIN32) and BGDWIN32 macros to decide on __declspec things. I tried configuring with --disable-shared and --disable-static, but both (!) popped up the same error. Perhaps the ifdefs need to be modified to also cater for libtool's DLL_EXPORT?

Thanks!

I have attached config.log

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/1
• Originally reported by: rubenvb (rubenvb)
• Originally created on: May 18 2011

Poor maximum JPEG quality.

The maximum JPEG quality is poor comparing to other tools, like ImageMagick or Photoshop.

The colors are lost even at quality=100.

See http://oserv.org/bugs/gd/ for original (.png) / GD(.gd.jpg) / ImageMagick (*.im.jpg) comparison.

Everything was done using maximum quality settings.

Was tested using php and perl, the results are the same.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/18
• Originally reported by: Anonymous
• Originally created on: Apr 19 2012

contributing to libgd

Is there any areas where I can work on to contribute something as a developer to libgd?

Please let me know

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/29
• Originally reported by: Anonymous
• Originally created on: Feb 12 2013

Please include bootstrap.sh in archive

This file seems useful for downstream

• allow to regenerate configure if needed (if patch applied to *.m4 files)
• use recent auto* stuff
• honored --disable-rpath (not working with current version)
• allow aarch64 build (need autoconf 2.69, iirc)

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/48
• Originally reported by: remicollet (Remi Collet)
• Originally created on: Apr 22 2013

Failed to compile for MinGW64 (cross compilation)

Below is the output from the ./configure stage. The compilation fails, as seen at the bottom, with the message: "error: variable 'GD_COLOR_MAP_X11' definition is marked dllimport"

checking build system type... i386-pc-mingw32
checking host system type... i386-pc-mingw32
checking target system type... i386-pc-mingw32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking if we are building a Cygwin target... no
checking for gcc... x86_64-w64-mingw32-gcc.exe
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
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 x86_64-w64-mingw32-gcc.exe accepts -g... yes
checking for x86_64-w64-mingw32-gcc.exe option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of x86_64-w64-mingw32-gcc.exe... gcc3
checking for gcc... (cached) x86_64-w64-mingw32-gcc.exe
checking whether we are using the GNU C compiler... (cached) yes
checking whether x86_64-w64-mingw32-gcc.exe accepts -g... (cached) yes
checking for x86_64-w64-mingw32-gcc.exe option to accept ISO C89... (cached) none needed
checking dependency style of x86_64-w64-mingw32-gcc.exe... (cached) gcc3
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc.exe... /usr/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (/usr/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i386-pc-mingw32 file names to i386-pc-mingw32 format... func_convert_file_msys_to_w32
checking how to convert i386-pc-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking for /usr/x86_64-w64-mingw32/bin/ld.exe option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for archiver @FILE support... @
checking for strip... /usr/x86_64-w64-mingw32/bin/strip.exe
checking for ranlib... /usr/x86_64-w64-mingw32/bin/ranlib.exe
checking command to parse /usr/bin/nm -B output from x86_64-w64-mingw32-gcc.exe object... failed
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc.exe -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 dlfcn.h... no
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc.exe supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc.exe option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc.exe PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc.exe static flag -static works... yes
checking if x86_64-w64-mingw32-gcc.exe supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc.exe supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc.exe linker (/usr/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for X... libraries /usr/lib, headers
checking for ANSI C header files... (cached) yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for ld used by GCC... /usr/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (/usr/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... no, consider installing GNU libiconv
checking iconv.h usability... no
checking iconv.h presence... no
checking for iconv.h... no
checking for sin... yes
checking for deflate in -lz... yes
checking png.h usability... no
checking png.h presence... no
checking for png.h... no
checking libpng/png.h usability... no
checking libpng/png.h presence... no
checking for libpng/png.h... no
checking for png_create_read_struct in -lpng... yes
checking for freetype-config... /usr/bin/freetype-config
checking for FT_Init_FreeType in -lfreetype... no
configure: WARNING: not found - disabling freetype support
checking ft2build.h usability... no
checking ft2build.h presence... no
checking for ft2build.h... no
no
checking for FcInit in -lfontconfig... no
checking for jpeg_set_defaults in -ljpeg... no
checking for XpmReadFileToXpmImage in -lXpm... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... no
checking whether pthreads work with -pthreads... no
checking whether pthreads work with -mthreads... no
checking for the pthreads library -lpthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no

** Configuration summary for gd 2.1.0:

   Support for PNG library:          yes
   Support for JPEG library:         no
   Support for Freetype 2.x library: no
   Support for Fontconfig library:   no
   Support for Xpm library:          no
   Support for pthreads:             yes

checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config/Makefile
config.status: creating config/gdlib-config
config.status: creating test/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
make -C ../src/libgd/src CPPFLAGS="-I/home/J/svn/mingw64/src/zlib-1.2.7" LDFLAGS="-L/home/J/svn/mingw64/install/win32-g++/bin/cygwin"
make[1]: Entering directory `/home/J/svn/mingw64/src/libgd/src'
make  all-am
make[2]: Entering directory `/home/J/svn/mingw64/src/libgd/src'
/bin/sh ./libtool --tag=CC    --mode=compile x86_64-w64-mingw32-gcc.exe -DHAVE_CONFIG_H -I.    -I/home/J/svn/mingw64/src/zlib-1.2.7  -fPIC -MT gd.lo -MD -MP -MF .deps/gd.Tpo -c -o gd.lo gd.c
libtool: compile:  x86_64-w64-mingw32-gcc.exe -DHAVE_CONFIG_H -I. -I/home/J/svn/mingw64/src/zlib-1.2.7 -fPIC -MT gd.lo -MD -MP -MF .deps/gd.Tpo -c gd.c -o gd.o
gd.c:1:0: warning: -fPIC ignored for target (all code is position independent)
mv -f .deps/gd.Tpo .deps/gd.Plo
/bin/sh ./libtool --tag=CC    --mode=compile x86_64-w64-mingw32-gcc.exe -DHAVE_CONFIG_H -I.    -I/home/J/svn/mingw64/src/zlib-1.2.7  -fPIC -MT gd_color.lo -MD -MP -MF .deps/gd_color.Tpo -c -o gd_color.lo gd_color.c
libtool: compile:  x86_64-w64-mingw32-gcc.exe -DHAVE_CONFIG_H -I. -I/home/J/svn/mingw64/src/zlib-1.2.7 -fPIC -MT gd_color.lo -MD -MP -MF .deps/gd_color.Tpo -c gd_color.c -o gd_color.o
gd_color.c:1:0: warning: -fPIC ignored for target (all code is position independent)
mv -f .deps/gd_color.Tpo .deps/gd_color.Plo
/bin/sh ./libtool --tag=CC    --mode=compile x86_64-w64-mingw32-gcc.exe -DHAVE_CONFIG_H -I.    -I/home/J/svn/mingw64/src/zlib-1.2.7  -fPIC -MT gd_color_map.lo -MD -MP -MF .deps/gd_color_map.Tpo -c -o gd_color_map.lo gd_color_map.c
libtool: compile:  x86_64-w64-mingw32-gcc.exe -DHAVE_CONFIG_H -I. -I/home/J/svn/mingw64/src/zlib-1.2.7 -fPIC -MT gd_color_map.lo -MD -MP -MF .deps/gd_color_map.Tpo -c gd_color_map.c -o gd_color_map.o
gd_color_map.c:1:0: warning: -fPIC ignored for target (all code is position independent)
gd_color_map.c:761:33: error: variable 'GD_COLOR_MAP_X11' definition is marked dllimport
gd_color_map.c:761:33: warning: 'GD_COLOR_MAP_X11' redeclared without dllimport attribute: previous dllimport ignored
Makefile:745: recipe for target `gd_color_map.lo' failed
make[2]: *** [gd_color_map.lo] Error 1
make[2]: Leaving directory `/home/J/svn/mingw64/src/libgd/src'
Makefile:418: recipe for target `all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/J/svn/mingw64/src/libgd/src'
../Makefiles/Makefile.libs:79: recipe for target `../install/win32-g++/bin/cygwin/libgd.a' failed
make: *** [../install/win32-g++/bin/cygwin/libgd.a] Error 2

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/27
• Originally reported by: Anonymous
• Originally created on: Oct 19 2012

Newbie install issues OSX

I have downloaded the file and through terminal have tried to install but am having issues. My overall aim is to install gnuplot and I think I need this for that so I have put this into terminal:

sudo ln -s /usr/X11R6/include/fontconfig /usr/local/include ln -s 'which glibtool' ./libtool ./configure --with-png=usr/X11 --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib

and have the message back: ln: --x-libraries=/usr/X11/lib: No such file or directory

I have no idea how to fix this issue and just need a little help doing so. I have seen comments to other issues but find them hard to follow as I am following a tutorial on how to install gnuplot of which this is part of and so have very experience in actually using terminal and knowing its commands.

Basically baby steps would be nice if possible...

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/25
• Originally reported by: Anonymous
• Originally created on: Oct 13 2012

WebP support?

I see that the GD library in PHP has WebP support. What about the standalone GD here?

And libwebp-0.1.2 was released in Apr 1, 2011, will WebP support depends on it?

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/3
• Originally reported by: Anonymous
• Originally created on: Jun 20 2011

Migration to git?

This is not an issue, but just an idea.

I wonder if it would be nice to migrate the gd repository to git, because mercurial lacks some useful features git has, e.g. http://www.emilsit.net/blog/archives/git-is-more-usable-than-mercurial/.
And I think GD developers are all familiar with git :)

For instruction to convert hg repositories to git on bitbucket, you may find http://blog.bitbucket.org/2011/10/05/converting-hg-repositories-to-git/.

But hg-fast-export is an easier alternative to do that: http://hedonismbot.wordpress.com/2008/10/16/hg-fast-export-convert-mercurial-repositories-to-git-repositories/ It can maintain all logs as well as tags in the original repository.

Thank you for your consideration.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/31
• Originally reported by: tabe (Takeshi Abe)
• Originally created on: Mar 02 2013

./configure

I went through all the documentations and it says that I need to run ./configure but I can't seem to locate one. I saw another posting on that with the resolved status but no explanation how it was resolved.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/14
• Originally reported by: Anonymous
• Originally created on: Jan 24 2012

how to build on systems without cmake ?

I'm trying to build libgd on an AIX 6.1 platform, with no cmake or
autoconf / automake or hg installed .
Where is a Makefile.in script for the package ? none of your source
tar files contain one nor can I find one under the hg HTTP source
pages . I tried running 'automake' and 'autoconf'', which produces a
src/configure, but no Makefile.in file.
libgd used to need only GNU make - why has it moved to using a less
powerful, flexible and available make program ?
In my corporate environment a very old version of libgd that used gmake was "approved", meaning that we can build and use it, but cmake is not. Now we want to start using the newer libgd, we cannot
build it . Has anyone built libgd without cmake on an AIX platform ?
Please restore the ability of libgd to compile on SVR4 UNIX - thanks!

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/15
• Originally reported by: Anonymous
• Originally created on: Feb 09 2012

gd_filter.c(71) : error C2440 (MSVC 9 SP1)

gd_filter.c(71) : error C2440: '=' : cannot convert from 'int (__stdcall *)(gdImagePtr,int,int)' to 'int (__cdecl *)(gdImagePtr,int,int)'

Unless I'm missing something, this is a serious bug for the DLL build.

I think line 11 should be like:

#ifdef NONDLL
#define BGD_CALLTYPE
#else
#ifdef WIN32
#define BGD_CALLTYPE __stdcall
#else
#define BGD_CALLTYPE _stdcall
#endif /* WIN32 */
#endif /* NONDLL */

#define PIXEL_FUNCTION_DECLARE(f) int (BGD_CALLTYPE *f)(gdImagePtr, int, int)

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/10
• Originally reported by: Anonymous
• Originally created on: Nov 14 2011

Some symbols are not public despite BGD_DECLARE

Ondrej, something goes wrong with BGD_DECLARE, for some reasons not all symbols are not public T but local t, like gdImageStringFT. Can you take a look please?

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/45
• Originally reported by: pierrejoye (Pierre Joye)
• Originally created on: Apr 21 2013

gdImageCopyResampled broken when built with Visual C++ 2010 32-bit due to floor2() "smart" cast

The gdImageCopyResampled() function is broken when built with Visual C++ 2010 32-bit (with full optimization, -O2) due to floor2() "smart" cast. The result is generally a white image with colored artifacts, rather than the re-sampled image.

This is most probably a compiler optimization bug, so this is not directly a GD bug. But I open the ticket for people who might get similar troubles :)

The bug is triggered by the following line in gd.c:
sx = floor2 (sx);

Possible fix is to do the following in gd.c:

#if (defined(_WIN32) && defined(_M_IX86) && defined(_MSC_VER) && _MSC_VER == 1600)
/* Do not use optimized version due to possible compiler bug with VC++2010/ix86. */
#define floor2(exp) floor(exp)
#else
#define floor2(exp) ((long) (exp))
#endif

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/12
• Originally reported by: xroche (Xavier Roche)
• Originally created on: Dec 12 2011

Downloads available?

Hello,

currently the Site http://www.libgd.org/ is down. Does anyone know when it will be aavailable?
Best reagrds,
Andreas

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/35
• Originally reported by: Anonymous
• Originally created on: Mar 21 2013

MyGDLib

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/32
• Originally reported by: Anonymous
• Originally created on: Mar 08 2013

Support reading 16-bit grayscale PNGs with full fidelity

The documentation below indicates that libgd does not support 16-bit grayscale or 48-bit colored PNGs. We would like to use 16-bit PNGs on our website, and we would like to draw colored overlays on top of the 16-bit PNGs, probably making them 48-bit PNGs. Will libgd ever support this? Can you offer an alternative solution? Thanks!

gdImageCreateFromPng(FILE *in)
(FUNCTION)
gdImageCreateFromPngPtr(int size, void *data)
(FUNCTION)
gdImageCreateFromPngCtx(
gdIOCtx *in) (FUNCTION)
gdImageCreateFromPng is called to load images from PNG format files. Invoke gdImageCreateFromPng with an already opened pointer to a file containing the desired image. gdImageCreateFromPng returns a gdImagePtr to the new image, or NULL if unable to load the image (most often because the file is corrupt or does not contain a PNG image). gdImageCreateFromPng does not close the file. You can inspect the sx and sy members of the image to determine its size. The image must eventually be destroyed using gdImageDestroy().
If you already have the image file in memory, pass the size of the file and a pointer to the file's data to gdImageCreateFromPngPtr, which is otherwise identical to gdImageCreateFromPng.
If the PNG image being loaded is a truecolor image, the resulting gdImagePtr will refer to a truecolor image. If the PNG image being loaded is a palette or grayscale image, the resulting gdImagePtr will refer to a palette image. gd retains only 8 bits of resolution for each of the red, green and blue channels, and only 7 bits of resolution for the alpha channel. The former restriction affects only a handful of very rare 48-bit color and 16-bit grayscale PNG images. The second restriction affects all semitransparent PNG images, but the difference is essentially invisible to the eye. 7 bits of alpha channel resolution is, in practice, quite a lot.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/7
• Originally reported by: Anonymous
• Originally created on: Oct 12 2011

RGB to Lab colorspace conversion

I am working on an image resizing and cropping script that attempts to detect which areas of an image are more important when making cropping decisions--essentially asking the computer to determine perceptual color differences. To accomplish this, I convert pixels from the RGB colorspace into Lab colorspace and compare the differences. (http://en.wikipedia.org/wiki/Lab_color_space#Advantages_of_Lab). While I can make this happen in PHP, it is slow and uses too much memory. I would love to see functions to facilitate this conversion and comparison directly in GD.

To convert from RGB to Lab, you first need to convert from RGB to XYZ colorspace and then from XYZ to Lab colorspace. Here are the functions that I use for conversion in PHP (which have been derived from the formulas on the EasyRGB website http://www.easyrgb.com/index.php?X=MATH):

GD color index to RGB:
http://code.google.com/p/smart-lencioni-image-resizer/source/browse/croppers/smart.class.php?spec=svn396646277d47c1571ff1dae31a6a5c5fed459bda&r=abd3273a317de1f9807541685f50f4e234be0561#450

RGB to XYZ:
http://code.google.com/p/smart-lencioni-image-resizer/source/browse/croppers/smart.class.php?spec=svn396646277d47c1571ff1dae31a6a5c5fed459bda&r=abd3273a317de1f9807541685f50f4e234be0561#469

XYZ to CIE-L_a_b* (more complex):
http://code.google.com/p/smart-lencioni-image-resizer/source/browse/croppers/smart.class.php?spec=svn396646277d47c1571ff1dae31a6a5c5fed459bda&r=abd3273a317de1f9807541685f50f4e234be0561#531

or

XYZ to Hunter-Lab (less complex):
http://code.google.com/p/smart-lencioni-image-resizer/source/browse/croppers/smart.class.php?spec=svn396646277d47c1571ff1dae31a6a5c5fed459bda&r=abd3273a317de1f9807541685f50f4e234be0561#511

And comparing the colors (more info at http://en.wikipedia.org/wiki/Color_difference):

deltaE 2000 (complex):
http://code.google.com/p/smart-lencioni-image-resizer/source/browse/croppers/smart.class.php?spec=svn396646277d47c1571ff1dae31a6a5c5fed459bda&r=abd3273a317de1f9807541685f50f4e234be0561#588

or

deltaE 76 (simple):
http://code.google.com/p/smart-lencioni-image-resizer/source/browse/croppers/smart.class.php?spec=svn396646277d47c1571ff1dae31a6a5c5fed459bda&r=abd3273a317de1f9807541685f50f4e234be0561#573

or

deltaE CMC:
http://code.google.com/p/smart-lencioni-image-resizer/source/browse/croppers/smart.class.php?spec=svn396646277d47c1571ff1dae31a6a5c5fed459bda&r=abd3273a317de1f9807541685f50f4e234be0561#672

For accuracy purposes, I would prefer to be able to use the more complex equations. However, if they prove to be too slow, it would be nice to fall back on the simpler versions.

So my question is this: does this kind of functionality make sense to include in GD (I hope so)? If so, will you add it? I am unfamiliar with C, otherwise I would submit the code, but hopefully it won't be too much work to convert the PHP functions I have provided here.

When you port this code, you might want to change some of the variables I set into parameters. For example, in deltaCMC(), I set $weightL and $weightC at the beginning to suit my needs. In GD, these would be better off as parameters.

Also, these are just the conversions that I needed. There are more conversions that people might find useful. For these, the EasyRGB website is a great starting point.

The links to the functions that I sent were all written by me, based off of the math on the Wikipedia articles:

• http://en.wikipedia.org/wiki/Lab_color_space
• http://en.wikipedia.org/wiki/Color_difference

and the EasyRGB website

• http://www.easyrgb.com/index.php?X=MATH
• http://www.easyrgb.com/index.php?X=DELT

And, although I have released my code under GPL, I am more than happy to give you permission to release it under a different license, such as BSD.

Thanks!

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/6
• Originally reported by: lencioni (Joe Lencioni)
• Originally created on: Sep 03 2011

add make tests

make tests must be added so tests can be automated.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/46
• Originally reported by: pierrejoye (Pierre Joye)
• Originally created on: Apr 21 2013

Latest version has no configure file...

I'm probably just too inexperienced to understand what is going on and how to compile without a ./configure file, but it appears that the latest release of the library has no configure file. How do I compile?

Never mind -- I needed to install cmake!

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/13
• Originally reported by: vvanhee (vvanhee)
• Originally created on: Dec 21 2011

How to install?

Hi,
I don't see any build tool or a relevant README in the source.
Alternatively, can you add a wiki page describing how to install this from source?

Thanks.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/9
• Originally reported by: burak (Burak Gürsoy)
• Originally created on: Nov 11 2011

gdImageFilledRectangle can take very long time with rects outside of image

There is an (arguable) bug in gdImageFilledRectangle:

If you call it with a rect outside of the image bounds it may take surprisingly long depending on the position. The user would expect that the performance does not depent on the position of the rect.

Consider the arguments: x1=-2147483648, y1=57, x2=-2147483644, y2=65
The function clips x1 and y2 to the image, but not x2 and y2. This sets the parameters to
x1=0, y1=57, x2=-2147483644, y2=65
Then it swaps x1/x2 if needed, setting to parameters to
x1=-2147483644, y1=57, x2=0, y2=65
This leads to an iteration from -2147483644 to 0.

Clipping needs to be done on x2 and y2 also in "gd.c" line 2400ff.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/21
• Originally reported by: GabrielSchreiber (Gabriel Schreiber)
• Originally created on: Aug 21 2012

Cant install on windows

everything goes good untill i get here

C:\Program Files\CMake 2.8\bin\cmake.exe ..

then it says that c:\program not recognized as an internal or external command
not sure what to do any help would be helpful

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/24
• Originally reported by: Anonymous
• Originally created on: Sep 27 2012

Can we assume CMake 2.8?

Dear Pierre, Kornel,

I found CMake's "ExternalProject" feature rocks as it is used for building libimagequant in FindLIQ.cmake.
One thing I wonder is the feature is available as of 2.8. So, can we assume CMake 2.8 for future development?

Thank you for your consideration.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/37
• Originally reported by: tabe (Takeshi Abe)
• Originally created on: Mar 27 2013

Bad rendering of PNG image

if you take the image attached and run it through this code you will get the 2nd attachment. Note the blue background which should not be there.

Code:

#!php

<?php
    $image_url= image_URL.png';
    $data=  file_get_contents( $image_url, false, null, -1, 500000); 

    $image= imagecreatefromstring  ($data);
    header("Content-type: image/png");
    imagepng($image,null,4);
    imagedestroy($image);
?>  

Gd version tested:

GD Support enabled
GD Version 2.0
FreeType Support enabled
FreeType Linkage with freetype
FreeType Version 2.4.8
T1Lib Support enabled
GIF Read Support enabled
GIF Create Support enabled
JPEG Support enabled
libJPEG Version unknown
PNG Support enabled
libPNG Version 1.2.46
WBMP Support enabled

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/39
• Originally reported by: Anonymous
• Originally created on: Apr 02 2013

Update LICENSE

LICENSE file should be updated to match some of the code recently added. Mainly PHP License should be added as far as I can tell

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/47
• Originally reported by: pierrejoye (Pierre Joye)
• Originally created on: Apr 22 2013

bogus "not a valid gif" errors

Starting from recently, imagecreatefromgif() SYSTEMATICALLY fails to open EVERY gif I get from Google Maps static image api, with the bogus error message:
"[filename here] is not a valid GIF file"

I don't know whether the gifs from google are 100% standard compliant, but they are ok enough to be viewed in the browser and in any image viewer, and hence imagecreatefromgif must be able to open them (whether or not it wants to emit a warning).

I'll attach three example gif images that trigger the issue.

Tested it on two different versions:
Newer server:

#!python

GD Support  enabled
GD Version  bundled (2.0.34 compatible)
FreeType Support    enabled
FreeType Linkage    with freetype
FreeType Version    2.1.7
GIF Read Support    enabled
GIF Create Support  enabled
JPEG Support    enabled
libJPEG Version 6b
PNG Support enabled
libPNG Version  1.2.12
WBMP Support    enabled
XBM Support enabled

Older server:

#!python

GD Support  enabled
GD Version  bundled (2.0.28 compatible)
FreeType Support    enabled
FreeType Linkage    with freetype
FreeType Version    2.2.1
GIF Read Support    enabled
GIF Create Support  enabled
JPG Support enabled
PNG Support enabled
WBMP Support    enabled
XBM Support enabled

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/42
• Originally reported by: matteosistisette (matteosistisette)
• Originally created on: Apr 07 2013

Migrate to autoconf 2.69 for arm 64 support

I've got a bug report [1], that gd contains config.guess and config.sub, which don't support arm 64 (aarch64). The support was added in autoconf 2.69.

I'm unfortunately not able to confirm this bug, because I don't have an access to ARM 64 machine currently.

Would it be possible to migrate these scripts to newer version to be able to build gd on arm 64 smoothly?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=925393

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/36
• Originally reported by: hhorak (hhorak)
• Originally created on: Mar 25 2013

macrosis

HI

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/19
• Originally reported by: Anonymous
• Originally created on: Apr 24 2012

build fails on fedora-16 due to missing -lm

Linking C executable copyrotated
/usr/bin/ld: CMakeFiles/copyrotated.dir/copyrotated.o: undefined reference to symbol 'sin@@GLIBC_2.2.5'
/usr/bin/ld: note: 'sin@@GLIBC_2.2.5' is defined in DSO /lib64/libm.so.6 so try adding it to the linker command line
/lib64/libm.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [examples/copyrotated] Error 1
make[1]: *** [examples/CMakeFiles/copyrotated.dir/all] Error 2
make: *** [all] Error 2

configure.ac has tests for -lm - I guess copyrotated isn't using that?

Not sure thus is the right fix, but I was able to workaround with:

diff -r 733361a31aab examples/CMakeLists.txt
--- a/examples/CMakeLists.txt Fri Jun 17 16:09:25 2011 +0900
+++ b/examples/CMakeLists.txt Fri Nov 04 15:25:20 2011 -0400
@@ -32,7 +32,7 @@

FOREACH(test_name ${TESTS_FILES})
add_executable(${test_name} "${test_name}.c")

• target_link_libraries (${test_name} ${GD_LIB})
• target_link_libraries (${test_name} ${GD_LIB} -lm)
  ENDFOREACH(test_name)

if (WIN32 AND NOT MINGW AND NOT MSYS)

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/8
• Originally reported by: ellson (John Ellson)
• Originally created on: Nov 04 2011

broken

This distro is broken. Docs say there is a configure file in the package. There is not. Therefore, the instructions cannot be followed; i.e. "type ./configure". I'll call this major as it is broken right out of the box and could be easily fixed by either adding a configure file or changing the instructions to something sensical.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/38
• Originally reported by: Anonymous
• Originally created on: Mar 28 2013

fix tip mingw build

diff -ru8i src/gd_filter.c src.new/gd_filter.c
--- src/gd_filter.c 2011-05-14 13:38:26 +0800
+++ src.new/gd_filter.c 2011-06-17 10:25:10 +0800
@@ -13,28 +13,28 @@
 #define GET_PIXEL_FUNCTION(src)(src->trueColor ? gdImageGetTrueColorPixel : gdImageGetPixel)

 #ifdef WIN32
 # define GD_SCATTER_SEED() (unsigned int)(time(0) * GetCurrentProcessId())
 #else
 # define GD_SCATTER_SEED() (unsigned int)(time(0) * getpid())
 #endif

-int gdImageScatter(gdImagePtr im, int sub, int plus)
+BGD_DECLARE(int) gdImageScatter(gdImagePtr im, int sub, int plus)
 {
    gdScatter s;

    s.sub  = sub;
    s.plus = plus;
    s.num_colors = 0;
    s.seed = GD_SCATTER_SEED();
    return gdImageScatterEx(im, &s);
 }

-int gdImageScatterColor(gdImagePtr im, int sub, int plus, int colors[], unsigned int num_colors)
+BGD_DECLARE(int) gdImageScatterColor(gdImagePtr im, int sub, int plus, int colors[], unsigned int num_colors)
 {
    gdScatter s;

    s.sub  = sub;
    s.plus = plus;
    s.colors = colors;
    s.num_colors = num_colors;
    s.seed = GD_SCATTER_SEED();
@@ -48,17 +48,17 @@
        if (!gdImageBoundsSafe(im, dest_x, dest_y)) {           \
            continue;                                           \
        }                                                       \
                                                                \
        pxl = f(im, x, y);                                      \
        new_pxl = f(im, dest_x, dest_y);                        \
    } while (0)

-int gdImageScatterEx(gdImagePtr im, gdScatterPtr scatter)
+BGD_DECLARE(int) gdImageScatterEx(gdImagePtr im, gdScatterPtr scatter)
 {
    register int x, y;
    int dest_x, dest_y;
    int pxl, new_pxl;
    unsigned int n;
    int sub = scatter->sub, plus = scatter->plus;
    PIXEL_FUNCTION_DECLARE(f);

diff -ru8i src/gd_pixelate.c src.new/gd_pixelate.c
--- src/gd_pixelate.c   2011-05-14 13:38:26 +0800
+++ src.new/gd_pixelate.c   2011-06-17 10:25:34 +0800
@@ -1,11 +1,11 @@
 #include "gd.h"

-int gdImagePixelate(gdImagePtr im, int block_size, const unsigned int mode)
+BGD_DECLARE(int) gdImagePixelate(gdImagePtr im, int block_size, const unsigned int mode)
 {
    int x, y;

    if (block_size <= 0) {
        return 0;
    } else if (block_size == 1) {
        return 1;
    }

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/2
• Originally reported by: Anonymous
• Originally created on: Jun 17 2011

bmp_im2im failed test

./bmp/bmp_im2im
pixels changed: 9766

From code.background should be red.
bmp_im2im_src.bmp background color Red
bmp_im2im_dstc.bmp background color Blue

Everywhere, color order is Blue, Green, Red, except in load_palette.

Proposal

#!c

--- src/gd_bmp.c    2013-04-21 19:12:29.361789089 +0200
+++ /dev/shm/BUILD/gd-2.1.0/src/gd_bmp.c    2013-04-22 13:59:01.008208467 +0200
@@ -749,9 +749,9 @@ static int bmp_read_palette(gdImagePtr i

    for (i = 0; i < count; i++) {
        if (
-           !gdGetByte(&r, infile) ||
-           !gdGetByte(&g, infile) ||
            !gdGetByte(&b, infile) ||
+           !gdGetByte(&g, infile) ||
+           !gdGetByte(&r, infile) ||
            (read_four && !gdGetByte(&z, infile))
        ) {
            return 1;

This make test ok, and ..;dst.bmp background is also Red.

---

• Bitbucket: https://bitbucket.org/libgd/gd-libgd/issue/49
• Originally reported by: remicollet (Remi Collet)
• Originally created on: Apr 22 2013