Activity for Bob Friesenhahn
-
Bob Friesenhahn modified ticket #29
use pkg-config to look up freetype info
-
use pkg-config to look up freetype info
-
This is finally addressed in development GraphicsMagick and will appear in the next release.
-
Are you able to attach the involved files in the form of a tarball or zip file? That would help debug this issue. The -size option does not support '>' syntax. This syntax can only be used for geometries where there is an image already read so the size can be known. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
-
Segmentation Fault when comparing images
-
Problem seems to be fixed already and fix will be in next release.
-
Segmentation Fault when comparing images
-
I am able to reproduce this problem on a Ubuntu Linux system using the 1.3.30 release but the problem does not occur with the development version. While there have been some PNG fixes and (many other fixes), I am not quite sure which fix might have solved the issue. I am suspecting that the issue is due to a double-free of heap memory. Are you able to build with the development source code and see if the problem still occurs for you?
-
number_colors sanity check
-
Due to existing checks/constaints, the severity of this issue is within reasonable bounds in GraphicsMagick and not a denial of service opportunity. There is no need for any code changes at this time.
-
I checked bmp.c and dib.c and see that they are already adding additional checks/constraints on the number of colors prior to attempting to allocate the colormap. I do not see the same in pict.c. It seems unlikely that PICT actually supports more than 256 colors.
-
On Mon, 10 Sep 2018, Petr Gajdos wrote: Indeed, I had not noticed there is a check against MaxColormapSize in AllocateImageColormap(). Thanks for your explanation, feel free to close. Individual checks to verify that the requested number of colors do not exceed the amount allowed by the file format are definitely still useful (e.g. 256 entries is still a lot less memory than 64k entries) since it is good to reject corrupt files. Some file formats are sloppy and provide a larger storage unit than...
-
I don't see a need for any of these changes. There is a significant cost to setting the seekable_stream option because it prohibits reading directly from a file descriptor and requires copying all the input to a temporary file (or would requiring buffering all input to allocated memory). The AllocateImageColormap() function will not allocate more than 64k colormap entries in any build configuration (a 524k byte allocation in total) so this is not much of a DOS opportunity.
-
On Sat, 25 Aug 2018, Friedrich Thun wrote: Hi, so far i used Image Magick to convert all pages of pdf files into single images, but it works very slow. i compared the speed of graphicsmagick commands and imagemagick command and gm works mucth fast, so i decided to "convert" my im command to an gm command. with IM i use this options: -units pixelsperinch -alpha background -alpha off but i couldn't find something similar at graphicsmagick. i don't know what this options do, this was an advice in the...
-
On Mon, 30 Jul 2018, Don Perrin wrote: Hi! I run this batch file every night to create a montage PDF of the images in all my folders on an FTP site. I'd like to add a file extension to the label on each file (is this possible?) Also, I take it PSD file additon to the montage is no longer possible. Is this accurate? Thanks everyone in advance for any help provided! From the documentation for the -format option, it looks like you want to replace the %t with %f. The %t is documented to report "top of...
-
This issue is fixed by Mercurial Changeset 15744:4a8fc48e6aed. Thank you very much for bringing this issue to our attention.
-
Unexpected hang on a crafted Cineon image
-
Using geometry to concat huge sizes of images (4000+) bugs out of order.
-
Reporter has admitted to cockpit error.
-
Unexpected hang on a crafted Cineon image
-
The reason for the hang is that the file claims to have dimensions of 16768256x17279, which results in the creation of a 2.2TB temporary file to read the pixels into. Adding the option '-limit pixels 10mp' avoids the hang. It is obvious that code should be added to reject the irrational request based on input image size.
-
On Wed, 18 Jul 2018, Hahah Really wrote: P.s. I tested gm montage -geometry 256x256 -tile 64x64 "*.jpg" "map.jpg" now and it still doesn't work. Exactly the same result. Try doing gm identify "*.jpg" and see what the order of the files it displays is. Is it similar to montage, or different? The large image sometimes painted in the montage sounds like somehow the resize (due to -geometry) is failing to reduce the image dimensions. For the special case of JPEG input files you may see much better performance...
-
On Mon, 16 Jul 2018, Hahah Really wrote: I have 4000+ images in one folder which, if placed in a 64x64 grid, result in a map image. Attached (unknown.png) is an image of how it looks after using: gm montage -geometry 256x -tile x64 *.jpg map.jpg All images are 256x256px in size and the grid is, as I said, 64x64 big. The other attached image (explorer.png) is a screenshot of the Windows Explorer with the folder I mentioned. Can't attach the whole image folder though. I am confused by the two images...
-
On Wed, 11 Jul 2018, freshlydog wrote: I not talking about choosing format, i asking quality images by default (4:4:4, default quality 75 is ok) - to see less shitty images in the internet. IM starting from around 6.9.1 by default makes picture with quality 92 and no subsampling. GraphicsMagick has a commitment to stability across each major release cycle. This one (1.3.x) started almost 11 years ago. A commitment to stability is a major feature of GraphicsMagick vs ImageMagick. It should not be...
-
On Tue, 10 Jul 2018, freshlydog wrote: Please make -sampling-factor 4:4:4 by default to make quality images. The normal primary tunable is quality factor (-quality), which defaults to 75 (as IJG JPEG does). At high levels, I think that this disables sampling. If we default to no sampling and/or an exceptionally high quality factor, then output JPEG image sizes would become much larger by default. A radical change like this would make many users mad. JPEG is intended for use with natural images such...
-
On Tue, 10 Jul 2018, freshlydog wrote: I thought GM uses only fonts so i just installed old distributive. I copied GS_LIB from "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GPL Ghostscript\8.61" to "HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\8.61" - that worked. GM uses Ghostscript for Postscript and PDF rendering if it finds it. Under Windows, it loads Ghostscript as a loadable DLL module so the Ghostscript it finds needs to be binary compatible. Bob
-
On Tue, 10 Jul 2018, freshlydog wrote: 64-bit GM can't find 32-bit GS path in registry because it's inside Wow6432Node: "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GPL Ghostscript\8.61". I tried set evironment variable GHOSTSCRIPT_FONT_DIR (googled it), but GM ignores it. I think that this is because you are using a 32-bit application on a 64-bit Windows. Even if the fonts were found, the Ghostscript installed there would not be usable if it is not the same bits (32/64) as GraphicsMagick. If you install...
-
On Thu, 28 Jun 2018, kirotawa wrote: Hi Bob, what is commit that fix this issue? That is a good question since it was already fixed by the time the problem was reported and so there is no specific change entry for this POC. If you really need to know, then I suggest studying the Mercurial commits to coders/tiff.c and read the entries in the ChangeLog files. Bob
-
GraphicsMagick 1.3.30 is now available
-
PSD file can not be completely converted to jpg file
-
I followed up with Mercurial changeset 15719:7f9f260096b0 since it seemed like there were more issues than just a memory leak.
-
small memory leak in rgb.c, gray.c and cmyk.c
-
This problem is fixed by Mercurial changeset 15718:af80f48585b2. Thanks for the report!
-
Thanks for the reports about PSD but PSD is officially not supported since the 1.3.24 release of May 30, 2016. You forgot to mention what version you are using but probably it is an antique version prior to 1.3.24, or you made some effort to still use PSD. A dedicated volunteer with a lot of time would be required to make PSD better. We did not delete the code but were already aware that it was inadequate so it is disabled by default. Bob
-
On Wed, 13 Jun 2018, Yog Chan wrote: Hi Bob, This is terrific. Thank you very much. So I can just set the shell's environment variables and it should be fine. Yes. The command line utilities also support a -limit option (e.g. -limit Pixels 10mp) which allows setting the same things as the environment variables on a case-by-case basis. Likewise, the C and C++ APIs provide access to setting the limits. Follow up question (I've not actually tried this yet): suppose I set the memory limit, and an image...
-
On Tue, 12 Jun 2018, Yog Chan wrote: Some of the vulnerabilities with ImageMagick are addressed by use of the policy.xml file. I would like to know if I can do the same thing with GraphicsMagick. In particular, consider the pixel flood attack exploit. This exploit involves specifying an extremely large pixel value in the encoding of the (small/regular sized) image itself, so that when the decoder tries to allocate memory for the entire image, it takes up all the memory and results in a dos attack....
-
I will follow up by repeating the recommendation to always use the latest GraphicsMagick release (or even latest Mercurial or development snapshot) if you are processing files that you don't trust. GraphicsMagick has been participating in Google's oss-fuzz project (and previously has undergone considerable fuzzing by volunteers as well as Coverity static analysis) and although there are some resource limits applied during the oss-fuzz fuzzing, excessive resource requests (including those which overflow...
-
ImageMagick CVE-2017-18272 applies to GraphicsMagick
-
This fix is applied as Mercurial changeset 15701:23f53da8b9d3. Thanks for the report!
-
WIN64 has incorrect type sizes
-
GraphicsMagick has used project-generated defines since the VisualStudio project was developed. There are other defines used as well to indicate if code is being built for a DLL library or DLL module.
-
Parsing of SVG images fail with "Non-conforming drawing primitive definition (push)"
-
The reporter is now happy!
-
On Mon, 21 May 2018, Egor Pugin wrote: magick/magick_types.h.in lines 54,77 ~~~ if defined(WIN64) ~~~ is wrong. Also WIN32 is wrong (but defined in windows.h). ~~~ WIN64 must be _WIN64 and WIN32 must be _WIN32 ~~~ Please see the comment at the top of magick/api.h. These defines come from the VisualStudio project file (are produced by the configure program) and are not the same as the internal Windows defines. Is there some problem you are trying to solve? Bob
-
Inconsistent results from qsort callback
-
Sending to Gregory Wolfe since this is a render.c issue.
-
tile:<image> appears to blow image up by 100% before applying tiling
-
This problem is fixed by Mercurial changeset 15657:f298a4c346e5. Thank you for the bug report.
-
This is a very interesting finding. The problem is specific to the JPEG file format (and the few other formats responding to -size) since -size influences the image size that libjpeg returns. If you use an input format which does not respond to -size, then the issue will not occur. Bob
-
I don't know if the nested_clippaths.svg test case for #517 is supposed to work. The main concern was to avoid a heap overwrite with this test case.
-
Please try again with Mercurial changeset 15653:432696c6a3f9. This one avoids the heap overflow encountered in issue 517 and appears to accept your input without an error.
-
On Sat, 19 May 2018, Hsiu Vardaman wrote: Thanks for the quick response and fix! I can confirm that 15651:4897d905117d fixes the issue for me. Thanks again. Unfortunately, going back to the original bug which resulted in the fixes shows that these latest changes cause that bug to re-appear. Bob
-
GraphicsMagic can't convert a http url in linux os
-
No response from reporter. Comma is not valid in the host part of a domain name.
-
Parsing of SVG images fail with "Non-conforming drawing primitive definition (push)"
-
I broke it so I should fix it. Changeset 785758bbbfcc "DrawImage(): Fix pointer computation which leads to large strncpy size request and bad array index." introduced wrong tests for arithmetic overflow. The remedy for this problem is provided by Mercurial changeset 15651:4897d905117d. Thanks for the bug report.
-
Parsing of SVG images fail with "Non-conforming drawing primitive definition (push)"
-
GraphicsMagick 1.3.29 build fails at linking time with many "undefined reference" errors
-
Build was using older GraphicsMagick library from system.
-
On Mon, 14 May 2018, Giovanni Mariani wrote: You are right: removing the previous libraries from my build system fixed the issue... I guess this ticked can be closed: sorry for the noise. It does indicate that there is a weakness in the build system. Hopefully it is not induced by libtool as delivered with GraphicsMagick (you are using a modified libtool). Bob
-
On Mon, 14 May 2018, Giovanni Mariani wrote: Trying to build GraphicsMagick 1.3.29 for Rosa Linux Fresh R10 (a Mandriva derivative) x86_64. Our build process always passes the --no-undefined option to the linker, but this with 1.3.29 causes the build to fail at linking time with many "undefined references". The DrawInfoGetClipPath() function is a new function added to libGraphicsMagick for this release. The most likely cause of the problem is that there is a previously existing libGraphicsMagick.so...
-
Use a few delegate libraries in fuzzing
-
assertion failure in WriteBlob
-
This is in response to "Trace Probe"'s glomming onto this report. While I did not reproduce the assertion, I did notice an excessively large memory allocation and added extra validations. The changes are included in 15623:d97a40634bef In the future, please open new problem reports for new problematic input files.
-
On Tue, 1 May 2018, Valentine Rozental wrote: What version of the GraphicsMagick library will contain the solution? The 1.3.29 release (made on April 29) contains the solution. Bob
-
GraphicsMagick 1.3.29 is now available
-
Global lock in png.c downgrade multithreads performance
-
This issue was fixed in the 1.3.27 release: JPEG/PNG: The SETJMP_IS_THREAD_SAFE definition is used to determine if setjmp/longjmp are thread safe. If these interfaces are thread safe, then concurrent reads/writes are possible. This definition is false for Solaris but true for Linux. JPEG and PNG will be fully concurrent if this definition is enabled.
-
ErrorCorruptImage: Magick: Unexpected end-of-file () for some ico images
-
While is perhaps not the best solution, Mercurial changeset 15606:6b2168007560 eliminates the error report. The problem is that it was expected that there be a mask image following the DIB data but there was nothing after the DIB data. Improvements to this is a task for the future.
-
heap-buffer-overflow in AcquireCacheNexus when processing jng file
-
This issue is fixed by Mercurial changeset 15604:8b649b561a43. Thank you for the report.
-
Converting SVG to PNG/JPG: Not handling 'defs', 'use' correctly
-
SVG: Dash-Array has no effect on Stroke with Gradient
-
Annotate Stretch doesn't work
-
Annotate Stroke doesn't work well
-
Annotate weight doesn't work
-
incorrectly renders SVG
-
gm convert svg: Non-conforming drawing primitive definition (image).
-
SVG to JPEG conversion does not render Google fonts
-
Debian Bug #802872 "SVG to PNG conversion omits circles"
-
strokeLineCap not work with strokePattern
-
SVG to PNG fails with Non-conforming drawing primitive definition (path).
-
Valid SVGfile not accepted by gm validate
-
Ugly stroke anti-alias
-
On Wed, 18 Apr 2018, bglyne wrote: When the stroke anti-alias is on and the background is 100% transparent, the border of the stroke is obviously supposed to be the gradient from the stroke color to transparency, but it is not in reality. The border is actually the gradient from stroke color to the (solid) background color as if the alpha channel was not there. On the other hand, if the background is not 100% transparent, say 99% transparent, the anti-alias gradient is correctly from the stroke color...
-
On Mon, 16 Apr 2018, valentine wrote: Please let me know if you need more examples of ICO files that cause to the problem. Thank you! Examples are always welcome. It is wise to bundle up files into a zip file and upload the zip file because SourceForge will re-write formats that it recognizes, losing the original issue. Bob
-
Improper call to JPEG library in state 201
-
This issue is fixed in the development sources and will appear in the next release.
-
graphicsmagick cannot find decode delegates for any image format
-
This was found to be an issue with Solus Linux packaging. The packaging was stripping the .la files which are still needed to load modules using libltdl.
-
On Mon, 16 Apr 2018, valentine wrote: Has anyone run into the same problem? I have not had time yet to investigate this further. Due to ongoing "security" updates, readers are on a "hair trigger" such that any error detected while reading the image data (even just one byte) will result in an error report rather than returning a partially corrupt image. If the file is even one byte short (according to the decoder) there will be an error report. Bob
-
On Thu, 12 Apr 2018, shoeb wrote: Hi Bob, Thanks for your quick response. I used "gm convert infile.jpg -profile SRGBSPAC.ICM outfile.jpg" command and result is below. https://cdnintegrationdesignerimages.azureedge.net/UserPhoto/08dc2937-40e6-4a55-9377-16d11c19755c/Photos/original/90265754987bf-be00-4eab-96bd-7c0d5c00392d.jpg I have attached source file name "input.jpg". Used profile is "sRGBProfile.icm" If the file does not already contain an embedded CMYK profile, then you will need to find one...
-
On Tue, 10 Apr 2018, shoeb wrote: Is there any command in GM which can convert CMYK image to RGB image? Yes. At the most simple/crude level, you can do gm convert infile.jpg -colorspace rgb outfile.jpg but since there is no one definition of CMYK, it is best to use a CMS color profile which accurately describes the origin CMYK space and a CMS color profile which describes the target RGB space. If the origin color profile is already embedded in the image you can just provide the RGB profile for the...
-
Horizontal lines artefacts when converting eps to jpg
Oh no! Some styles failed to load. 😵
Please try reloading this page