Activity for Bob Friesenhahn
-
Bob Friesenhahn modified ticket #766
CVE-2026-33535
-
Record that this issue is fixed.
-
A fix for the buffer overflow issue is submitted by Mercurial changeset 18020:df03dfbf4d4b. Only up to 10 digits are collected at a time, and any failure to convert the digits to an integer resets back to the default state.
-
It seems that the ImageMagick6 patch referred to is incomplete. The problem is not that 'delta' is too short, rather, the problem seems to be that a nul byte may be written beyond the boundary of 'delta', which is statically allocated. The current code has much more implementation such as to ignore requests which would overflow the boundary of 'delta'. This existing line of GraphicsMagick code is humorous: delta[strlen(delta)+1]='\0'; Ultimately, the goal is that the 'delta' string is turned into...
-
CVE-2026-28690
-
Change set 18010:967c71e2b740 provides necessary error handling for ImageToBlob(), as well as to assure that no more than 256 colors will be supplied to the MNG PLTE chunk.
-
If CVEs provided adequate and complete descriptions of an issue, then the information could be used to immediately attack existing code. So they use vague obtuse descriptions which mean almost nothing. Based on the last part of the ImageMagick edits, there may have been an overflow of the image colormap.
-
I did a search and see that CVE-2026-28690 is about a MNG encoder stack buffer overflow rather than a use of a null pointer in the JNG encoder. The ImageMagick project may have made other fixes while claiming to address CVE-2026-28690. It would be useful to know the details about where this stack buffer overflow happens. Are you able to determine this? I do recall solving several MNG stack overflow issues in the past.
-
Petr, much thanks for bringing ImageMagick CVE issues which also apply to GraphicsMagick to my attention.
-
CVE-2026-30883
-
Mercurial changeset 18009:a0855348fb11 "coders/png.c (png_write_raw_profile): Detect and report an excessively large profile, and other unexpected conditions.", should address this issue, and a few others.
-
CVE-2026-30883
-
This seems to be in png_write_raw_profile(). I wish my attention was not drawn to this function since it appears that at least 50% of the lines of code in its implementation introduce their own bug. The description of the CVE says that it is provoked by an "extremely large profile", which suggests that operations based on 'length' may over/underflow. It seems difficult for an attacker to provide an "extremely large profile" unless it is from a file format where the profile may be stored compressed,...
-
CVE-2026-28690
-
The JNG writer code does look pretty bad. It seems to be a prototype.
-
CVE-2026-25799
-
This issue is addressed by Mercurial changeset 18005:85f3971e259d, which is included in the latest (1.4.020260306) source development snapshot. Much thanks to Petr, who tried extra hard to communicate about this issue with me.
-
If you are able to select the default branch, that would be fantastic.
-
I asked Google this question: "mercurial how to assure that files are treated as binary" and it says that mercurial stores all files as binary. It also says: The distinction between text and binary is primarily for user-facing tools (like hg diff), which try to show human-readable changes, but will show "binary files differ" if NUL bytes are present That is the message I saw. It suggests adding a "[merge-patterns]" section to .hgrc and therefore I added this to my .hgrc: [merge-patterns] **.fpx =...
-
Please make sure that you use a very descriptive branch name, especially since Mercurial does not allow changing history. The generic branch name you used for libtiff can only be used the one time. It would have been much better if it had included the libtiff version.
-
Yes, just provide proposed ChangeLog text, and I will take care of that part of the update. This is helpful since I update ChangeLog often, and many times, there will be a change of the date at the top of the ChangeLog and thus an automatic re-generation of some dependent files. It would be perhaps better if most generated files were removed from the Mercurial repository (they would still be in distribution archives) but I am not sure what the scope of the impact would be. For example, web sites...
-
Update libtiff
-
I merged your your branch into main (after fixing a Magick++ compilation bug that I had created) and closed the branch so it does not show up in the branches listing. Unlike git, Mercurial history is totally immutable. This means that the branch which was created will always be present, even though the branch has been "closed". I had to do this in order to push changes: % hg push pushing to GM searching for changes abort: push creates new remote branches: Update libtiff (1 closed) (use 'hg push --new-branch'...
-
In the future, please avoid updating the top-level ChangeLog given that this is assured to cause a large merge conflict. There are many generated files which depend on ChangeLog. The HTML files are generated based on ChangeLog, and the date at the top of the ChangeLog file is used as the release date for the whole package. For unknown reasons, all of the binary PerlMagick/t/fpx/input files were modified. Maybe Microsoft Windows did that. I will revert this change. I see that tiff-4.7.1/cmake/Findliblzma.cmake...
-
Kevin, FYI, development GraphicsMagick has advanced quite a lot when it comes to reading HEIF and even HEIF sequences. While HEIF sequences can be read, there is surely more to do in order to play them like a video. Libheif itself is still not entirely evolved when it comes to sequences. Please take a look and provide feedback.
-
The reason why I mention the Garamond font issue, is that failing to find it causes test.wmf to fail.
-
It seems that the libwmf project has removed some files. That does not hide a problem. Due to the process of continual improvement, it seems that some Widows fonts have gone missing in my Ubuntu Linux 24.04 LTS system. The Garamond family of fonts, and some others are not where they used to be.
-
The redeclipse.ico file is no longer available via the provided link, but it is likely the same as this one.
-
WMF files - extremely long loading
-
Magick::Image::attribute(string, string) bug
-
As mentioned by Juraj Komacka, the Magick++ API was previously fixed to allow passing a NULL pointer to remove any existing attribute data under the same name. Furthermore, as of September 7, 2023 this change was made: changeset: 17203:bc0e3fe2eb00 user: Bob Friesenhahn bfriesen@GraphicsMagick.org date: Thu Sep 07 18:27:44 2023 -0500 files: ChangeLog VisualMagick/installer/inc/version.isx magick/attribute.c magick/version.h www/Changelog.html description: SetImageAttribute(): Remove SetImageAttribute()...
-
GIF thumbnail generation bug
-
I see that the images were stored on some other website and are no longer available. Re-doing the tests here based on the built-in logo image and latest (2026) ImageMagick code: gm convert logo: -resize '604x451!' /tmp/logo.jpg gm identify /tmp/logo.jpg /tmp/logo.jpg JPEG 604x451+0+0 DirectClass 8-bit 30.7Ki 0.000u 0m:0.000001s magick identify /tmp/logo.jpg /tmp/logo.jpg JPEG 604x451 604x451+0+0 8-bit sRGB 31483B 0.000u 0:00.000 gm convert /tmp/logo.jpg -quality 50 -resize x48 -gravity center -crop...
-
Looking at this issue again, I see that the geometry (-resize option) does not include the exclamation mark (!) that is documented to be required in order for -resize to change the image aspect ratio. This means that the command line usage was incorrect.
-
resize method is off by a few pixels
-
Looking at this issue again, I see that the geometry (-resize option) does not include the exclamation mark (!) that is documented to be requierd in order for -resize to change the image aspect ratio. This means that the command line usage was incorrect.
-
DIB: Unable to write a monochrome DIB as 8bit depth.
-
Mercurial changeset 17909:88ac0115762a modifies the image monochrome method to set the Image is_monochrome flag to false if it is already set. This may allow this re-arranging of your settings to provide the desired result: image.type( PaletteType ); image.classType( PseudoClass ); image.monochrome( false ); I will mark this issue closed. Please let me know if it does not help.
-
It is quite common to convert an image from one format/type to another. Due to this, the image_info depth value may be a value in the range of 1 to 64 obtained from some other file format, or it may be specified by the user (using -depth parameter) and may be a value in the range of 0 to 18446744073709551615. Currently there is no "memory" of the format that the image came from (if it came from a format). In the normal case, it is reasonable to write the output file in as compact a sub-format as...
-
Ticket moved from /p/graphicsmagick/bugs/247/ Can't be converted: _milestone: v1.0_(example)
-
PSD is currently not really supported and is not enabled in the build.
-
direct call to "xml2-config" make cross-builds fail
-
GraphicsMagick configure no longer uses xml2-config. It uses pkg-config data. Fully-static builds are supported (other than perhaps the OS core libraries) based on data from pkg-config. Marking this issue as fixed until recent evidence is provided to prove that there is still an issue.
-
can not open *.wbm
-
I did some research and found that "WBM" is sometimes used, and was not able to find mention of "WBP" being used. However, I am not qualified to argue about the past! This issue is addressed by Mercurial changeset 17906:535ba4e5fe55.
-
Ticket moved from /p/graphicsmagick/bugs/219/ Can't be converted: _milestone:
-
TclMagick requires tk even when configure --without-tk
-
TclMagick does not use the MagickWand library. Regardless, as of October, 2024 the build relationship between TkMagick and TclMagick has been completely re-imagined. This issue is declared fixed (unless proven otherwise).
-
Compile and link failures on a Redhat 5.4 64-bit system
-
The TclMagick build has been completely redone (in 2024) such that there is no longer a direct library dependency from one shared library to another. The GraphicsMagick build is updated to detect and apply the necessary dependency libraries as reported by pkgconfig. This issue is believed to be fixed.
-
ping(blob) reports JPG and JNX files as monochrome BilevelType
-
This issue is solved by Mercurial changeset 17905:6e5569db2deb. Thank you for your extreme patience!
-
Wrong conversion of omega character
-
Defect in WMF conversion - parser failure
-
Another WMF conversion flaw
-
gm cannot read a standard WMF test file "WmfTest.wmf "
-
gm cannot read a standard WMF test file "SPBANNER.WMF "
-
Wrong conversion of wmf image
-
Please do not think that VisualBasic6 runtime will be supported forever - msvbvm60.dll
-
Ubuntu Linux 24.04LTS no longer even provides symbols.ttf. Other Windows fonts appear to be there and the package which used to install it (ttf-mscorefonts-installer) is installed, but the file is not present.
-
Support JBIG gray level images via multiple planes
-
Support of JBIG gray level images
-
Changed this to a feature request given that multi-level JBIG does not appear to be in actual use (although documented) and it is less efficient than more modern algorithms for lossless compression.
-
Ticket moved from /p/graphicsmagick/bugs/762/ Can't be converted: _milestone: v1.0_(example)
-
I agree that many of the 3rd party libraries are out of date, and/or contain reported vulnerabilities. A summary of the 3rd party libraries and their current versions is available at Windows Distribution 3rd Party Source Code. The build procedure is documented at Windows Distribution Build Procedure. Windows project files are created using a configure program with source code under VisualMagick/configure/. A pre-compiled configure.exe program is provided. The configure program writes Visual Studio...
-
If I convert your lena.pcx to lossless JP2 it requires 159,285 bytes. Your JBIG file required 184,620 bytes.
-
If I convert your lena.jbg to lossless JP2 it requires 159,285 bytes. Your JBIG file required 184,620 bytes.
-
Wrong support of JBIG gray level images
-
JP2 supports lossless. Unfortunately, it was not working in GM due to a tiny bug (fixed in Mercurial). gm convert lena.pcx -define jp2:rate=1.0 lena.jp2 WEBP supports lossless. gm convert lena.pcx -define webp:lossless=TRUE lena.webp JXL is supposed to support lossless, but for some reason requesting it is throwing an error in my build. Here are some sizes I obtain in various lossless formats. My Lena image is 256x256 whereas yours is 512x512: File Size lenaI16-lzma.tiff 42608 lenaI16.pnm 196623...
-
There is no support for JBIG2 in the Windows build, or in libtiff either. If JBIG2 is accepted, it is being mapped to uncompressed. Compare with an ordinary JPEG or JP2 file instead.
-
It is my understanding that there was an attempt in the standards organizations to use JBIG for more than bi-level images, but the effort failed. Are you aware of any implementations besides your own? Is the compression level very good as compared with modern compression algorithms? JBIG1 has been replaced by JBIG2.
-
This work is merged as Mercurial changeset 17876:7de523023b85 by using the patch. I did not merge with Hg directly since sometimes this has caused unwanted branches in the repository.
-
Options Documentation: add jxl coder specific options
-
Please verify that you are pleased with the result.
-
Reading multiple GIFs doesn't read the comments correctly.
-
This issue should be addressed by Mercurial changeset 17869:67f0e477d45e. Thanks for reporting this issue and providing an example.
-
I have now followed up by adding MagickSetBackgroundColor() to the Wand API.
-
I have submitted a source code change so that the drawing canvas will be initialized with the user-provided background color (including transparency). Previously, the background color would be used, but the opacity was always reset to opaque. The source code change is as simple as editing magick/mvg.c and changing "(void) SetImage(image,OpaqueOpacity);" to "SetImageColor(image,&image->background_color);". I know that this does not yet address your concern with the missing Wand API.
-
GraphicsMagick attempts to implement SVG 1.1 (first released in January 2003). It appears that there is no external way (e.g. -background) to force the background to be transparent. Using Google Search, I entered the query "using SVG 1.1, how to set the background of the image to transparent" and it produces a useful "AI" response. It suggests this (and a few other approaches): To make an SVG background transparent, either set the |fill| and |stroke| of a background |<rect>| element to |none| or...
-
Thank you for the useful feedback. I never saw this message, and likely because I did not test at the command line, or otherwise use a way where I would have seen the message. I think I see the origin of the problem and I will submit installer edits, and leave myself a note to test it later. The problem is likely that the function 'VCRedistNeedsInstall' is defaulting to Visual C from 2008. I have made edits to the installer source code but still need to verify that they work. Thus far, no one has...
-
Note that this is not a bug. The PGM specification says: There is a newline character at the end of each of these lines. Programs that read this format should be as lenient as possible, accepting anything that looks remotely like a PGM. This means that a PGM file is supposed to have a newline character after the last line as well. Regardless, I did think (for a long time) that it was wrong to report an error if the reader knows that it has decoded all required samples. Recently, I have been looking...
-
pbm p2 format reader error
-
Note that this is not a bug. The PGM specification says: There is a newline character at the end of each of these lines. Programs that read this format should be as lenient as possible, accepting anything that looks remotely like a PGM. This means that a PGM file is supposed to have a newline character after the last line as well. Regardless, I did think (for a long time) that it was wrong to report an error if the reader knows that it has decoded all required samples. Recently, I have been looking...
-
Please do not think that VisualBasic6 runtime will be supported forever - msvbvm60.dll
-
Please do not think that VisualBasic6 runtime will be supported forever - msvbvm60.dll
-
I used CMake (Thank You!) to build a new VisualMagick configure.exe. It now depends on the new common runtime. I see that PathTool was downloaded from https://www.digievo.co.uk/downloads/legacy/legacy.aspx, but the PathTool.zip file only contains a binary dated from 2002, so there is no source code for it. Inno Setup supports what is needed. There is no more need to update MS-DOS autoexec.bat. Thanks for the reminder about this problem.
-
Optimize HEIC identify performance by deferring libheif initialization
-
I have submitted this change: (ReadHEIFImage): Invert the sense of ignore_transformations. Default 'ignore_transformations' to true since otherwise 'identify' can be very slow due to doing much of the work involved with reading the file. The user should pass '-define heif:ignore-transformations=false' if a fully accurate report of image dimensions (and some other information) is required. This is to address the concern raised in issue #75 "Optimize HEIC identify performance by deferring libheif initialization"....
-
The problem is that 'ignore_transformations' is false by default and so it does some file decoding to find the real image dimensions and some other info. Adding this to the identify request makes it go fast: -define heif:ignore-transformations=true If the default condition is changed, then it will be fast by default, but then the user must specify -define heif:ignore-transformations=false In order to assure accurate dimensions (e.g. in case the image is rotated). Bob
-
Thanks for bringing the strange pause to my attention. The problem is not with library initialization. The problem is that the default identify 'ping' mode is not being respected. I am investigating.
-
If I first do gm convert 2009-000000416500023801240010285726_stamped.tif converted.tif Then pages extract as expected from converted.tif. This means that the issue has something to do with the way the TIFF was written.
-
In the future, the situation with HEIC may improve. For example, the OS vendor (e.g. Microsoft, Ubuntu, ...) may pay for licensing, and GraphicsMagick can use an already licensed library on the computer. The libheif library which provides access to HEIC and a number of other formats is very complicated since it depends on several other libraries. It is easy to take care of this under Linux but not so easy (at least for me) under Windows at the moment.
-
And I see this behavior: % gm identify -format "%p\n" 2009-000000416500023801240010285726_stamped.tif 1 2 3 4 5 6 7 8 9 10 11 % gm identify -format "%s\n" 2009-000000416500023801240010285726_stamped.tif 0 1 2 3 4 5 6 7 8 9 10 Yes, the above does stop at 10. Regardless, it does appear that there is still an issue (in 1.3.46).
-
"Subimage specification returns no images" converting 1 page of multipage tiff to png
-
I do see this behavior: % for n in 0 1 2 3 4 5 6 7 8 9 10 ; do for> printf "n=%d\n" n for> gm convert 2009-000000416500023801240010285726_stamped.tif'['$n']' crap.tiff for> done n=0 n=1 n=2 n=3 n=4 n=5 n=6 gm convert: Subimage specification returns no images (2009-000000416500023801240010285726_stamped.tif). n=7 gm convert: Subimage specification returns no images (2009-000000416500023801240010285726_stamped.tif). n=8 gm convert: Subimage specification returns no images (2009-000000416500023801240010285726_stamped.tif)....
-
convert +dither does not work as expected
-
As described previously, the command line is parsed from left to right. This means that the -colors request needs to come after +dither. This is a usage error.
-
The current Visual Studio build (which has produced releases up to 1.3.46) strategy is clearly at a dead end because it is too difficult to integrate additional/updated 3rd-party software. It is much better to offload the work to others. The Unixish configure build works fine for Cygwin , MINGW64, and MSYS2 and it already offloads the work to others. It is clear that CMake is the best way to offload work to others for Visual Studio builds, so I plan to put work into building using CMake, and not...
-
"make check" fails on all perl tests
-
In a static (--disable-shared --enable-static --with-perl) GraphicsMagick build, with building PerlMagick enabled, I can run the PerlMagick test suite by doing 'make check-perl'. I am not sure how to make things better for a dynamic PerlMagick given that the PERL build process, test framework, and run-time logic changes with PERL releases, and also depends on operating system specific behavior. Being able to test an uninstalled static build seems to be the best that I can do. Due to uncontrollable...
1 >
