Activity for Bob Friesenhahn
-
Bob Friesenhahn posted a comment on ticket #38
On Wed, 15 Apr 2020, dancx wrote: edit: so with With "-density 50" it is showing 210x297mm,however the jpg is cut and not show entirely. And then I have read this article: https://stackoverflow.com/questions/46663640/itext-pdf-fails-with-message-dictionary-key-endstream-is-not-a-name The pdf has not a closed endstream... Thanks for this link. One time someone reported that there was a syntax problem but they did not provide any information as to what the problem is. It would be really useful if someone...
-
On Wed, 15 Apr 2020, dancx wrote: Hello , I mean -page option : gm convert -page A4 C:\img\A.jpg C:\img\A.pdf gm convert -page 210x297 C:\img\A.jpg C:\img\A.pdf gm convert -page A4 C:\img\A.jpg -format A4 C:\img\A.pdf This is not working Please keep in mind that there is no warranty. A better order of operations is gm convert C:\img\A.jpg -density 75 -page A4 C:\img\A.pdf The JPEG file itself may specify its own resolution so it should be listed first. Then you can specify the pixel density of the...
-
On Wed, 15 Apr 2020, dancx wrote: I would like to convert a ".jpg" file with dimension 1080x1920 to format a4 .pdf (210x297 mm ). However when I use those commands I do not receive my result,the format will not show 210x297mm (for example in Adobe reader) gm convert -format A4 C:\img\A.jpg C:\img\A.pdf gm convert -format 210x297 C:\img\A.jpg C:\img\A.pdf gm convert -format A4 C:\img\A.jpg -format A4 C:\img\A.pdf I am missing something? As described in the documentation, the -page option is supposed...
-
On Tue, 14 Apr 2020, Daniel Coelho wrote: Hello, I would like to convert a ".jpg" file with dimension 1080x1920 to format a4 (210x297 mm ). However when I use those commands I do not receive my result,the format will not show 210x297mm (for example in Adobe reader) gm convert -format A4 C:\img\A.jpg C:\img\A.pdf gm convert -format 210x297 C:\img\A.jpg C:\img\A.pdf gm convert -format A4 C:\img\A.jpg -format A4 C:\img\A.pdf I am missing something? The documentation says to use the -page option: -page...
-
On Thu, 2 Apr 2020, Rava wrote: Hi, on https://sourceforge.net/projects/graphicsmagick/files/graphicsmagick-binaries/1.3.35/ I only find binaries for Windows. Are Linux binaries not to be found in https://sourceforge.net/projects/graphicsmagick/files/graphicsmagick-binaries/ even though the URL says "/graphicsmagick-binaries/" and not "/graphicsmagick-windows-binaries/" ? I looked into the readme at https://sourceforge.net/projects/graphicsmagick/files/ and the first mention of Linux was about a...
-
On Sun, 22 Mar 2020, Galenmacil wrote: Hello, I started using GM about 3 years ago. For batch processing, it is the best solution for me. Thanks for that amazing utility. Now, as you probably know already, the new HEIC format is getting more and more attention, some even suggest it will eventually replace JPEG. The fact that you get about twice as much compression for similar degradation as in JPEG format cannot be ignored. So, my question is, is there any discussion or plans about integrating it...
-
On Fri, 13 Mar 2020, Ben Nadel wrote: That's so interesting that my version is so old. I literally just installed using apt-get: RUN apt-get update && apt-get install -y \ graphicsmagick \ && apt-get clean .... like 2-weeks ago. I guess the apt-get package version is behind. I'm not really a "platform guy", so I don't even fully understand how apt-get works or how often those packages are updated. I'm use to npm in the Node.js world, which is basically always up-to-date for fresh installs. I'll have...
-
On Thu, 12 Mar 2020, Kevin Dente wrote: Any other suggestions on things I can try? Or am I just hitting a limitation of GM? I am thinking that this is a current limitation of GM. Glenn told me a few times that PNG needed special palette generation support for this case but it was not clear to me what was needed and he is no longer available to answer questions. It appears that the PNG8 encoder (PNG8:filename) is totally broken when writing PNG output with transparency. The broken PNG crashes the...
-
On Wed, 11 Mar 2020, Kevin Dente wrote: gm identify -verbose shows 256 colors Yes, I noticed that. I also noticed that specifying the output like 'png8:file.png' results in a corrupt file. Interestingly, trying with the version of ImageMagick which came on my Ubuntu system resulted in a sort of bi-level PNG which does not even use a colormap. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public...
-
On Wed, 11 Mar 2020, Kevin Dente wrote: That results in "8-bit Gray 256c" - better but not 2c. BTW I'm using ImageMagick identify because gm's version doesn't seem to show this info. Try 'gm identify -verbose file.png' and see if its output agrees. The colormap should be included in the output. It will be obvious if there are 256 colors in the colormap. I have no idea if the summary info ImageMagick produces is correct. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Wed, 11 Mar 2020, Kevin Dente wrote: I'd like to generate a two-color grayscale PNG (one that shows up in identify as 8-bit gray 2c) by drawing black text onto a transparent background. I haven't been able to figure out a command to do it. No matter what I do, it generates a 16-bit grayscale gray image. Is there someway to force it to output a 2-color image? Add the option -depth 8 so it thinks the image should be 8-bit. For example notice the difference between these two commands: % gm convert...
-
On Wed, 11 Mar 2020, Ben Nadel wrote: I'll take a look at ping, I wasn't aware of that modification. As far as waiting for 10-seconds, the command on the command-line completes instanteously. So, I don't think it's a timeout issue. I think I'm just not understanding something about Java's ProcessBuilder. This is much more low-level than my typical day-to-day work. Make sure that Java is only attempting to read from the output. The underlying call is likely popen() or an equivalent. That said, I did...
-
On Wed, 11 Mar 2020, Hakan wrote: can you suggest a command line(s) to create a grayscale image that can seperate 'perceived gray' from 'perceived color' based on a threshold on intensity and how to compose it back into the RGB original , if you think this can be done without modifications to GM ? I am not clear how that could be done. Obviously your technical knowledge in this field is far more than mine and I cannot comment if your generic suggesting will work, or how well it works without testing...
-
On Wed, 11 Mar 2020, Hakan wrote: Yes, it is a single pass algorithm. It is 1 read operation (from input) and 1 write (to output bitmap) to the same pixel location with no dependency on other pixels. I experimented with -operator channel operator rvalue[%] and was hoping it could be implemented with that structure -operator all neutralize-gray rvalue[%] there are very similar other commands but nothing that does a decision based on max(RGB)-min(RGB) For someone familiar with the C/C++ interface it...
-
On Wed, 11 Mar 2020, Hakan wrote: I would like to execute a 'neutralize gray' effect at the pixel level. Is the following pseude function possible with GM command line ? It seems like your algorithm is a single-pass algorithm where each pixel is analyzed/accessed just once. Is my interpretation correct? If so, this is easily implemented in C/C++ using the GraphicsMagick library, and could be implemented (albeit much more slowly) using PerlMagick or another interpreted extension which allows updating...
-
On Tue, 10 Mar 2020, Ben Nadel wrote: process = processBuilder.start(); waitValue = process.waitFor( 10, timeUnit.SECONDS ); exitValue = process.exitValue(); ``` Here, I'm trying to redirect the standard-output to a log-file. However, when this finishes, the log-file is empty. It looks like this implementation is waiting for 10 seconds and then just quitting. Perhaps the command is taking more than 10 seconds to run? If all you needed to do is obtain 'identify' style output, then it appears that...
-
On Tue, 10 Mar 2020, Ben Nadel wrote: This is a bit of strange question, and I'm not really great a command-line stuff, so sorry if this doesn't make any sense. I am having trouble capturing output when I use info:- in conjunction with gm convert. If I run something like this, programmatically: gm identify -format %w jpg:image.jpg ... I can captature the standard-output no problem. However, if I try to do something like this, programmatically: gm convert jpg:image.jpg -format %w info:- ... I cannot...
-
On Sat, 7 Mar 2020, Ben Nadel wrote: I see from the Security page that I am supposed to explicitly specify a reader such as jpg: or png: when reading in a file so that we don't rely on automated detection. I've been able to do this for input file operations. However, I cannot figure out how to do it for the -draw operation. Something like: -draw 'image 0,0 300,300 jpg:/path/to/overlay.jpg' When I try to include teh jpg: reader specification in this location, I get a "unable to open file - no such...
-
On Fri, 6 Mar 2020, Ben Nadel wrote: I'm just running into this myself. I'm attempting to create intermediary images that contain some "annotations". Then, I was planning to create a composite image of all the "annotation images" on top of the target image. Only, the annotation images all end up with that halo effect on the edges. This problem has not been studied or worked on yet. Similar issues have been solved in other areas such as when resizing an image, which also produced fringing. I am not...
-
On Thu, 5 Mar 2020, Andrew Lay wrote: Here is the updated code. Does that look good to you? Still a bit slow and memory hungry. I will try and find the memory leak, which will probably means I can use MPC and speed it up. Right? Also in your opinion have a chosen a good library? Is GraphicsMagick built for game frames or should I try something else? Your image size is very small. With this image size, the overheads from things other than the actual pixels are likely to dominate the time if the pixels...
-
On Wed, 4 Mar 2020, Andrew Lay wrote: define DISPLAY_DEFAULT_WIDTH 320 define DISPLAY_DEFAULT_HEIGHT 200 Thanks for you help. I will give a better reply soon :) That is very small so it does not explain large memory usage. A memory leak in your program would explain large memory usage. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/publ...
-
On Wed, 4 Mar 2020, Andrew Lay wrote: I am using Magick+ to produce frames for a game engine. I invested time in switching from GDI for a performance increase but I ended up getting the opposite; not only is it much slower but it chews up more ten times the memory (60 mb vs 800mb). What are the dimensions (rows and columns) of the image you are creating? I figured that the culprit was probably the way in which I used the library, not the library. It is possible. GraphicsMagick is more memory hungry...
-
On Tue, 3 Mar 2020, Ben Nadel wrote: Ah, very interesting. I had tried also doing something like providing a -size XxY prior to the input to read "up to" the highest row, as you described. But, that didn't seem to be doing what I thought it might. For the formats which require -size, it specifies the size (rows and columns) of the raster image. For the JPEG or JBIG formats, if specified prior to the file name, it will cause a subresolution of the image to be returned from libjpeg/libjbig, which can...
-
On Mon, 2 Mar 2020, Ben Nadel wrote: I see from this other post on ImageMagick, that they have a syntax for reading-in only part of an image: https://www.imagemagick.org/discourse-server/viewtopic.php?t=13694 GraphicsMagick currently only partially supports this feature. Efficient support for it requires support for it in the image readers since different file formats have different capabilities. Some file formats (e.g. tiled TIFF) could provide optimized support for it. Some uncompressed formats...
-
GraphicsMagick 1.3.35 is now available
-
GM Causes JVM Instability
-
Resolved by providing new initailization interface which provides more control.
-
As of Mercurial changeset 16251:f86618d5e836 there is now an InitializeMagickEx() function: MagickPassFail InitializeMagickEx(const char path, unsigned int options, ExceptionInfo exception); as well as this definition define MAGICK_OPT_NO_SIGNAL_HANDER 0x0001 You can call the function like: ExceptionInfo exception; GetExceptionInfo(&exception); (void) InitializeMagickEx(path,MAGICK_OPT_NO_SIGNAL_HANDER,&exception); if (exception.severity != UndefinedException) CatchException(&exception); DestroyExceptionInfo(&exception);...
-
On Thu, 20 Feb 2020, Don Chaney wrote: Sorry if this has already been discussed. I'm converting a CMYK TIFF to PNG and the resulting image appears to be negated. CMD: gm convert -trim -resize 1000x1000 "in\%%~nF.tif" -mattecolor "#FFFFFF" -frame 60x60 -quality 100 "out\%%~nF.png" Now that I have a copy of your file and a chance to experiment with your command, I see that the command line ordering is not good If I change the order to gm convert 557835_image1.tif -colorspace rgb -trim -resize 1000x1000...
-
On Thu, 20 Feb 2020, Don Chaney wrote: Thanks! I've attached the problem .tif file. Please send to to my own email address (see below) rather than to the mailing list. The mailing list discards such attachments. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
-
On Thu, 20 Feb 2020, Don Chaney wrote: Thanks, Bob. I tried the -colorspace option and it did not fix the problem. Is there a list of acceptable .icc files to download? I tried one and gm said it was invalid. The problem is that when you use CMYK you are supposed to know the CMYK you are using. :-) There are some standard ones used for pre-press work but CMYK is usually device-specific (e.g. for a printer) and thus it varies. Provided that your GraphicsMagick has LCMS (LittleCMS) support, then it...
-
On Thu, 20 Feb 2020, Don Chaney wrote: Sorry if this has already been discussed. I'm converting a CMYK TIFF to PNG and the resulting image appears to be negated. There are many flavors of CMYK, and CMYK is like the inverse of RGB. To solve this, you will need to find an ICC profile which best describes the CMYK colorspace of your input file, and an ICC profile matching the RGB (e.g. sRGB) that you want to produce. It does not appear that your TIFF file has an ICC profile embedded in it so it would...
-
On Thu, 20 Feb 2020, Don Chaney wrote: Sorry if this has already been discussed. I'm converting a CMYK TIFF to PNG and the resulting image appears to be negated. Looking at the PNG writer, it looks like it should have changed the "CMYK" to RGB. I suggest adding the options -debug transform,coder to your command line so you will be informed as to the steps taken. What viewer are you using to look at the PNG image? Is it possible that the viewer is using the XMP metadata and using its advisement for...
-
On Thu, 20 Feb 2020, gudenau wrote: You could create a stuct that has a version member in it and when you check for a flag you could check against it's version. If it's too low you know to use the default value. The problem with a struct is that it establishes a binary interface, which must then be preserved. Since this is C rather than C++, there is no way to automatically initialize a version member. A simple integer flags value seems better. Functions would be provided that external code could...
-
I see that DestroyMagick() and PanicDestroyMagick() are already publically exposed for use. The DestroyMagick() function should be used for a normal clean-up of GraphicsMagick such as for an orderly shutdown which releases all acquired resources. The PanicDestroyMagick() function should be used for the case where something has gone severely wrong but there is a desire to clean up things which don't go away when the program goes away such as temporary files. The new InitializeMagickEx() function could...
-
On Wed, 19 Feb 2020, gudenau wrote: That change does seem to make this work. Why does GM use signal handlers? Signals are how the operating system tells the program to quit, whether it be due to CONTROL-C at the keyboard, or that the program did something wrong. Depending on the signal, GraphicsMagick will attempt to do things like remove temporary files so that the disk does not fill up. I suppose making some sort of InitializeMagickEx(InitInfo* initInfo) might be in order? Maybe, if the option...
-
On Tue, 18 Feb 2020, gudenau wrote: I've manually compiled GM from the source archive and it's still doing the same thing, but gm version is reporting GraphicsMagick 1.3.34 2019-12-24 Q8 http://www.GraphicsMagick.org/ now. That seems a bit better. I would try steps like disabling OpenMP support to see if that helps. Unless things have changed, my memory of Java JNI was that it can only support single-threaded invocation. This means there would be a problem if more than one Java thread called through...
-
To be clear, the 'gm' utility contains practically no code. Everything pertaining to GraphicsMagick (including the reported version) is in the library so if the gm utility does not report the expected version, then it seems like there must be a problem. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
-
On Tue, 18 Feb 2020, gudenau wrote: The header in /usr/lib/GraphicsMagick/magick/version.h seems to say 1.3.34. ```C define MagickPackageName "GraphicsMagick" define MagickCopyright "Copyright (C) 2002-2019 GraphicsMagick Group.\nAdditional copyrights and licenses apply to this software.\nSee http://www.GraphicsMagick.org/www/Copyright.html for> define MagickLibVersion 0x232002 define MagickLibVersionText "1.3.34" define MagickLibVersionNumber 23,20,2 define MagickChangeDate "20191224" define MagickReleaseDate...
-
On Tue, 18 Feb 2020, gudenau wrote: Well, I ran gm version. There is always a chance that IM might be doing something screwy. Is there any way to check what signal handlers are in use? It sounds like you are using the library rather than the gm utility. Are you sure that you are using the GraphicsMagick library rather than ImageMagick? When calling InitializeMagick inside a JVM via JNI it causes the JVM to become unstable and crash shorly after or spin and pin a CPU thread to 100%. I have had the...
-
On Tue, 18 Feb 2020, gudenau wrote: I am using OpenJDK 13.0.1 on Arch Linux with Graphics Magick 7.0.9-22. Are you sure that you are using GraphicsMagick? 7.0.9-22 sounds like an ImageMagick release number. The most recent GraphicsMagick release is 1.3.34. In GraphicsMagick, the InitializeMagick function does set up signal handlers. This might conflict with Java, which likely sets up its own signal handlers. I am not really sure what to do about this other than introduce a new form of InitializeMagick()...
-
Unexpected dots appears on png converted by bmp.
-
I am unable to reproduce this issue. The person who reported the issue is unable to provide any assistance from their end. Closing this issue until it can be reproduced.
-
We are all a little busy these days. Since I am not able to reproduce the problem, this issue will be closed in a couple of weeks unless I am too busy to remember. Otherwise, if you can provide some assistance from your end, maybe the underlying cause can be discovered.
-
Pixel cache dimensions incompatible with image dimensions
-
This problem is fixed now. The fix is provided by Mercurial changeset 16208:873fe3a5a171. Thanks for the report!
-
Histogram produces incorrect color table attribute
-
This problem is fixed by Mercurial changeset 16209:558eac3f8fbb. Thanks for the report!
-
Histogram produces incorrect color table attribute
-
Assertion in WriteBlob at magick/blob.c:4937
-
This problem is fixed by Mercurial changeset 16203:085f95f92eae. Thanks for the report!
-
heap-buffer-overflow in EncodeImage at coders/pict.c:1114
-
This problem is elminated by Mercurial changeset 16202:8273307fa414. Thanks for the report!
-
heap-buffer-overflow in EncodeImage at coders/pict.c:1114
-
Assertion in WriteBlob at magick/blob.c:4937
-
On Fri, 3 Jan 2020, Arjen de Korte wrote: Currently, there are build failures with php7-gmagick in PHP 7.4 when multi threading is enabled (the default). See https://bugs.php.net/bug.php?id=78465 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91256 The extension calls DestroyMagick() just before closing. If running in single thread, all is well, but if running in multi thread the extension segfaults. Adding a 10 ms delay between calling DestroyMagick() and closing the extension works around this,...
-
On Fri, 3 Jan 2020, Arjen de Korte wrote: If we can't call omp_pause_resource_all(omp_pause_hard) in the library (I have to admit, that I didn't consider the possibility that this library might be called by a caller that uses OpenMP too), it might be useful to have a function in the library that would explicitly release whatever OpenMP is using and wait until it is released. So basically a wrapper around this function. I'm not sure about the garbage collection in PHP. It seems that there have been...
-
Is php7-gmagick built as a loadable module (a shared library loaded via dlopen())? I have encountered issues before with some Linux versions where it seemed that OpenMP did not play well with loadable module initialization/destruction. Due to this, some GraphicsMagick coder modules which might benefit from threading do not use OpenMP by default. Loadable modules are actually quite tricky since OpenMP (GOMP, in this case) might have already been spun up when the module is loaded, or it might not have...
-
On Fri, 3 Jan 2020, Arjen de Korte wrote: The extension calls DestroyMagick() just before closing. If running in single thread, all is well, but if running in multi thread the extension segfaults. Adding a 10 ms delay between calling DestroyMagick() and closing the extension works around this, so this appears to be a race condition - the threads opened by OpenMP don't close quickly enough and are still active when DestroyMagick() returns. Since OpenMP 5 one can call omp_pause_resource_all(omp_pause_hard)...
-
I compiled GraphicsMagick using GCC 4.4.6, but unfortunately, I am not able to reproduce the problem. My testing is done under Solaris rather than Linux since that is where I built this old compiler. Unfortunately, the issue can easily be system-specific since OpenMP behavior is influenced by the hardware and OS. How many CPU cores do you have? One way to find out is by doing gm convert -list resources and see what number is reported for 'Threads'. In my case I only have 4 real cores on the system...
-
heap-buffer-overflow in WritePCXImage
-
This problem is fixed by Mercurial changeset 16181:bd13b1d335f3. Thank you for the report!
-
heap-buffer-overflow in WritePCXImage
-
On Fri, 27 Dec 2019, shirley Wang wrote: The gcc -version I'm using is gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23) , surely it's earlier than the 4.7.1 version :( I'll try to remove sub-commands later, thx. It looks like I have gcc 4.4.6 available to me. Maybe it still works. If so, I will test with it. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/u...
-
On Wed, 25 Dec 2019, shirley Wang wrote: Hello Bob, Adding "-limit threads 1" does solve the problem. And I notice that the problem only occurs when I deal with bmp. Dealing jpg with same command just work properly. That is unfortunate. It is fortunate that there is a solution (disable OpenMP threading) but unfortunate that unless I can reproduce the problem it will be difficult to solve. The next thing to do is to take your original command and remove the -auto-orient, -scale, and -crop sub-commands...
-
GraphicsMagick 1.3.34 is now available
-
The 1.3.34 release will include support for WebP compression in TIFF. Zstd will not be supported yet since we have not yet integrated Zstd into the Visual Studio build.
-
I have tested this command on two different computers with different build options and am not seeing any misbehavior at all. I do not have OS X to test with. As previously requested, please add '-limit threads 1' immediately after 'convert' and see if the problem goes away. Also, please include the complete output of 'gm -version' and 'gm convert -list formats' into this bug report. What is the origin of the GraphicsMagick you are using? Thanks, Bob
-
On Thu, 19 Dec 2019, Bob Friesenhahn wrote: bug report at SourceForge. Make sure to bundle the original PNG in a zip file before uploading it since SourceForge usually re-writes files it recognizes. If the original file can not be publically shared, I should have said BMP apparently. :-) Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/pu...
-
On Thu, 19 Dec 2019, shirley Wang wrote: hi, I'm using gm 1.3.33 to do some image convert. The system I use is 64bit linux. When I execute following command to a bmp, I got some strange result: convert -auto-orient -scale 200x -gravity Center -crop 200x130+0+0 -quality 75 -strip test.bmp png:dest.png The result size I expected is 44456B, but the result became 44806B sometimes and when I check the result png, I found some unexpected dots on the image (I put the abnormal png in attachment). It does...
-
GhostScript installation check
-
GraphicsMagick now also checks HKEY_CURRENT_USER as described.
-
On Sun, 15 Dec 2019, Giovanni Remigi wrote: You are welcome, thank you for taking care of this. MSYS2 is very easy to install and maintain. The only issue I have with it and MinGW 64 is that it compiles 10 times slower than on Linux. My software compiles in 3 minutes on Linux and 30 minutes on Windows. I think one reason for the slowness is that someone decided that make should be case insensitive when compiling under Windows. Windows is case insentive, but value preserving. My prior MinGW had a...
-
On Wed, 11 Dec 2019, Giovanni Remigi wrote: I have been using Graphics Magick API for at least four years together with my C++ application running on Windows, Linux and Mac. On Windows I compile Graphics Magick using MSYS2 anb MinGW64 using the following command: sh configure --prefix=/mingw64/local/dst/graphicsmagick --with-quantum-depth=16 --enable-shared --disable-static --disable-openmp --disable-installed --without-perl --without-webp --without-wmf make -j8 make install This command generates...
-
heap-buffer-overflow in function EncodeImage of coders/pict.c
-
This problem is fixed by changeset 16153:28f8bacd4bbf. Thank you for the report!
-
traps: gm[24562] trap invalid opcode ip:7fa6c4553048 sp:7ffe4b7b46c8 error:0 [2934835.125412] in png.so[7fa6c4553000+1000]
-
This appears to be a build/platform specific issue. Even a corrupted byte in a file could cause this issue.
-
heap-buffer-overflow in function EncodeImage of coders/pict.c
-
A 32-byte WebP file which produces a 16384x13316 image is pretty amazing.
-
On Thu, 12 Dec 2019, Giovanni Remigi wrote: What about adding something similar to the configure script, would it bee too trivial? msys_build='no' if [[ $(gcc --version | grep ^gcc) == *"MSYS2"* ]]; then msys_build='yes' fi MSYS/MSYS2 are primarily a shell environment derived from Cygwin which allows the GCC compiler and Unix style build scripts to be able to target native Windows APIs. I don't have a desire to target using the MSYS Unix emulation APIs. Except for the special case where a program...
-
On Wed, 11 Dec 2019, Giovanni Remigi wrote: The library libltdl-7.dll is installed in MSYS2 but it seems it is not detected by the configure script. To double check, I tried to use a pragma message in the code to check if HasLTDL is defined or not and as expected it is not. Additionally I tried to build Graphics Magick with the option "--with-modules" which creates all coders "dll" and the related "la" files. In this case it works fine at run-time but I wanted to make it works on Linux, Windows and...
-
On Wed, 11 Dec 2019, Giovanni Remigi wrote: On WIndows Graphics Magick has been compiling and working nicely up to version 1.3.28. When I compiled version 1.3.29 and higher, with the same command above, everything works fine. Unfortunately, at run-time, when trying to read or write an image format e.g. PNG I get the following exception: Tried: IM_MOD_RL_PNG_.dll [No such file or directory] Coder not found (PNG) reported by Magick++/lib/Exception.cpp:435 In order to get the first line I had to set...
-
Alternative patch
-
A one-byte length does not seem very useful. A variable size length indication (e.g. based on the top bit being set) seems more useful. It seems that we need to learn more about this. Regardless, I am attaching an alternate patch. Please take a look at it and see if it works for you. I don't plan on committing any fix until I have a test case and have had the time to fully analyze the issue.
-
On Tue, 26 Nov 2019, Bob Friesenhahn wrote: Are you able to provide a sample file that I can use for testing? If you do provide a sample file, make sure to wrap it in a zip file or some other archive format which will prevent SourceForge from re-writing it. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
-
On Mon, 25 Nov 2019, Phillip Seaver wrote: The name in the Image Resource Block is a Pascal string, so it's limited to 255. The beginning of the query string is 15 characters. Add a trailing null and 271 is the max. (I made it larger than I needed to in case I needed to add more to the beginning, if I recall correctly. Just being a little paranoid) Here's the Adobe specification about Image Resource Blocks: https://www.adobe.com/content/dam/acom/en/devnet/photoshop/psir/ps_image_resources.pdf I did...
-
On Mon, 25 Nov 2019, EmlynB wrote: If there's known issues between some of the flags used for specific parts of the PNG library on different CPUs, do you have a list? There are multiple ways to build libpng. It is also possible that libpng source code has been patched. A compiler bug could easily cause this sort of problem. Libpng is considered performance-sensitive so there may have been use of maximum optimizations. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Mon, 25 Nov 2019, EmlynB wrote: Using Alpine linux docker image (node:12-alpine) apk install graphicsmagick Use the library to resize an image and it fails: traps: gm[24562] trap invalid opcode ip:7fa6c4553048 sp:7ffe4b7b46c8 error:0 [2934835.125412] in png.so[7fa6c4553000+1000] The host machine is ECS t3a: We don't provide any pre-built binaries for Alpine Linux. This issue should be reported to whoever is producing the binaries you are using for Alpine Linux (in particular libpng). It seems...
-
On Mon, 25 Nov 2019, Phillip Seaver wrote: The name in the Image Resource Block is a Pascal string, so it's limited to 255. The beginning of the query string is 15 characters. Add a trailing null and 271 is the max. (I made it larger than I needed to in case I needed to add more to the beginning, if I recall correctly. Just being a little paranoid) As a reminder, a corrupted or non-conforming file could produce any input. The input could be too short or too long. Null termination may be missing....
-
How was the allocation size of attr_name selected? Is there a specification which provides the maximum length of a clipping path name (the value part)? As written, the patch is a recipie for a stack overwrite or reading outside the bounds of a heap allocation if the input is intentionally corrupted. I am able to make it robust but am curious about the clipping path name length.
-
Fix for GetImageClippingPathAttribute
-
GhostScript installation check
-
Needed information was provided, re-opening this bug.
-
On Wed, 20 Nov 2019, Budge wrote: Hi Bob, Many thanks for the advice and link to documentation. This program is awesome and has saved me all that grief with scripts. I am making good progress, although my syntax is rubbish so I ended up creating the wrong subdirectory but in the right place. The program converted about 150 files from 10 subdirectories until it crashed with the message copied below. I am including the whole cli text output so if you can please correct my syntax that would be great....
-
On Tue, 19 Nov 2019, Budge wrote: Running GM to convert my .fpx files to jpg gave me good quality images but much smaller files. For example a .fpx image which was shown as being 549.0 KiB converted to a file of 130.7 KiB. I assume this is an artefact from the multiple content of the .fpx format and will need to follow this up to understand more. GraphicsMagick uses a default quality level of 75. Since these are important images, you should use an argument like '-quality 85' or '-quality 90', which...
-
GhostScript installation check
-
There was no response from the person who opened this report as to how we can reproduce the described installation using an existing Ghostscript installer. Due to the inability to reproduce the scenario, this report is closed until an adequate definition is available.
-
On Mon, 18 Nov 2019, Budge wrote: Hi Bob, Many thanks. I am not sure of correct etiquette for my replies as I feel I am so far below the user knowledge base. Please tell me to whom I should reply and to which address. You are doing good! There is no established user knowledge base. Please reply the way you have been so that others can learn from your experience. I have downloaded the GraphicsMagick-LATEST archive file and found that running ./compile with no additional parameters seems to work just...
Oh no! Some styles failed to load. 😵
Please try reloading this page