Activity for Bob Friesenhahn
-
Bob Friesenhahn posted a comment on discussion Help
On Sun, 17 Nov 2019, Budge wrote: Hi Bob, Have taken your advice and downloaded and installed libfpx from the ImageMagick site as you suggested but have run into difficulties with ImageMagick itself. I think I may be OT continuing this correspondence with you so please forgive but my experience so far may be of assistance. ImageMagick is a competing project, which I used to work on long ago, but I don't do much with it anymore. ImageMagick has many more features than GraphicsMagick, but as you found...
-
On Sat, 16 Nov 2019, Budge wrote: I find all my oldest CD storage of pictures are in Kodak .fpx format. I wish to convert them to .jpg before putting them on the cloud. I use openSUSE Tumbleweed and have installed GM version 1.3.33-1.2. I tried the simplest of commands gm convert Iris_Home.fpx Iris_Home.jpg and this gave me the result ~~~ No decode delegate for this image format (Iris_Home.fpx). ~~~ I am lost here and would appreciate some help please. I did play with a windoze program which seemed...
-
Mercurial change set 16129:e1d5936f7cdd updates TclMagick/pkgIndex.tcl as advised (third issue).
-
Mercurial change set 16129:e1d5936f7cdd updates TclMagick/pkgIndex.tcl as advised.
-
Mercurial change set 16127:8d98ab60025d addresses the install-sh path issue (first issue). Mercurial change set 16128:cc4441e4b662 clears the exception from the wand after it has been reported, plus fixes a memory leak (fourth issue).
-
I am thinking that changing the configure.ac script from AC_CONFIG_AUX_DIR([unix/config]) to AC_CONFIG_AUX_DIR([unix/tclconfig]) would likely "solve" the problem.
-
TclMagick issues and patch
-
I have a volunteer who is willing to work on this. He tells me that the standard Ghostscript installation package insists on installing as Administrator so he is unable to produce a standard installation to test with. By what means may he achieve a standard (easily replicated by other users) installation using the Ghostscript installation package so he can develop and test code to solve this issue? Given that I have been bitten by problems after installing Ghostscript system-wide as Administrator,...
-
On Fri, 8 Nov 2019, Marc wrote: Hello Everybody, I am running gm, Version 1.3.33-q8 on an Intel I7, 16 GB RAM, Windows 7 Pro x64, I have set the limits in the environment-vars: Resource Limits (Q8, 32 bits/pixel, 64bit address) Disk: Unlimited (MAGICK_LIMIT_DISK) Files: 1.5Ki (MAGICK_LIMIT_FILES) Map: 2.0GiB (MAGICK_LIMIT_MAP) Memory: 5.0GiB (MAGICK_LIMIT_MEMORY) Pixels: Unlimited (MAGICK_LIMIT_PIXELS) Threads: 1 (OMP_NUM_THREADS) Width: 512.0MiP (MAGICK_LIMIT_WIDTH) Height: 512.0MiP (MAGICK_LIMIT_HEIGHT)...
-
Using ssh protocol avoids timeouts but it takes several minutes for the server to do anything at all.
-
Mercurial access to GraphicsMagick repository is slow or times out
-
Now that I look at the related code in Magick++/lib/Options.cpp I see that it does this: Magick::ImageType Magick::Options::type ( void ) const { return _imageInfo->type; } The ImageInfo structure is used for input options rather than for output. The related code in Magick++/lib/Image.cpp forwards the request like: // Image representation type Magick::ImageType Magick::Image::type ( void ) const { ExceptionInfo exceptionInfo; GetExceptionInfo( &exceptionInfo ); ImageType image_type = constOptions()->type();...
-
What does command-line gm identify file.jpg report for your file? Does the report differ from what gm identify +ping file.jpg reports? In theory, the default ping mode is supposed to try not to read image data or do other expensive processing. There was a release or two where the JPEG reader was not fully parsing the JPEG header. The current release should be fully parsing the JPEG header. The ImageInfo structure has a 'ping' option (not exposed in Magick++ as far as I can see) which requests that...
-
On Thu, 19 Sep 2019, xm wrote: That was fast, thanks! Now it is ok, I tested current snapshot. Sorry for not fixing this issue correctly the first time. It must be a classic case of haste makes waste. :-) 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
-
static module loader is still case-sensitive
-
This should be fixed by changeset 16111:45d2f234c8a1. Thank you for the report!
-
On Wed, 18 Sep 2019, xm wrote: I should add that this is the 1st memcmp in the / Assign module name from alias. / for-cycle. If the OpenModule() input parameter module is e.g. "jpg", the module alias "JPEG" will not be copied into module_name and then the 2nd for-cycle cannot find the relevant static module... I think that this is fixed now in GraphicsMagick Mercurial. Please double-check my work. Thanks, Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Wed, 11 Sep 2019, Dan wrote: Thank you for your time Bob, I really appreciate that! No problem. I have little free time but the free time I do give is given for free. :-) I am concerned that we don't appear to have solved the problem yet. The mystery is why it appears that your log.mgk file was found, but that there was not observed change in behavior due to it. I did notice that you ran 'gm' subordinate to a 'find' command and am unsure what effect that might have vs running it directly as I...
-
On Thu, 5 Sep 2019, Dan wrote: Ah. Thanks. I'm attaching system calls in a text file. The ltrace text file is a product of this script: ~~~ MAGICK_CONFIGURE_PATH=$HOME/.magick MAGICK_DEBUG=configure ltrace -S -o /mnt/c/Users/dan/desktop/ltrace_gm_sample.txt find . -name '*.tif' -type f -exec bash -c 'gm convert -monitor "$0" "${0%.tif}.pdf"' {} \; What I see in your trace looks like it is tracing the bash shell implementation and I see nothing in it from GraphicsMagick. It would help to reduce it...
-
On Wed, 4 Sep 2019, Dan wrote: When I try to invoke the environmental variables with gm, ltrace encounters them as something that is not a program, so the ltrace output is empty. Instead, I'm pasting ltrace system calls demangled when running a simple gm conversion script, with -debug "all" enabled. Hopefully this can help? You would need to list the environment variables before ltrace. vars ltrace gm ... You can also export environment variables using export syntax. For example: export MAGICK_DEBUG=configure...
-
On Wed, 4 Sep 2019, Dan wrote: Hi Bob Thank you for your assistance. I've duplicated your work exactly- up to the point of generating log output. For some reason I still cannot produce a log file. Perhaps a sample of the terminal output can help: ~~~ 12:22:14 0:01 0.000u 16270 log.c/SetLogEventMask/1173/Configure: Set log event mask: configure 12:22:14 0:01 0.000u 16270 blob.c/GetConfigureBlob/2086/Configure: Searching for file "log.mgk" in path "/home/dan/.magick/:/usr/share/GraphicsMagick-1.4/config/:/usr/lib/GraphicsMagick-1.4/config/"...
-
On Fri, 23 Aug 2019, Dan wrote: Very basic questions here but I have to admit I'm stumped: <magicklog> <log events="error,warning"> <log output="txtfile"> <log filename="Magick-%d.log"> <log generations="3"> <log limit="2000"> <log format="%t %r %u %p %m/%f/%l/%d:\\n %e"> </log></log></log></log></log></log></magicklog> How in the world do I direct the output of the txt log to a location of my choosing? I've tried <log output="/home/myname/error.txt"> and that doesn't work. I've tried <log filename="/home/myname/Magick-%d.log">...
-
It is not uncommon that the shared libraries are re-linked upon installation. Perl's Make::Maker (and Perl itself) has a mind of its own and arbitrarily resists/discards configuration directives. It does not want to obey requests and instead prefers to use settings used when Perl itself was built, and may ignore LD_LIBRARY_PATH. While it is useful to perform in-tree testing, unfortunately, there is no 100% reliable substitute for 'make check' of PerlMagick after GraphicsMagick has been formally installed....
-
GraphicsMagick 1.3.32 gives SIGABRT with compare module
-
The problem with initializing the PNG module is fixed as of the 1.3.33 release made this past weekend.
-
GraphicsMagick 1.3.33 is now available
-
On Thu, 18 Jul 2019, Mattias Wadman wrote: See the same issue with 1.3.32 built on alpine linux 3.10 but on linux it seems to crash with illegal instruction. Applied https://sourceforge.net/p/graphicsmagick/code/ci/f30492f40f78d867b43422215057dd21de4ba447/ to 1.3.32 and it works fine again. Thanks for fast fix Bob. It is good that the fix also fixes Alpine Linux (with musl C library). I will produce a new release before long (perhaps this weekend) to fix the couple of known regressions and fix additional...
-
WriteOnePNGImage(): Fix saving to palette when image has an alpha channel but no color is marked as transparent
-
Your patch (plus some white-space fixes) is applied as Mercurial changeset 16074:f8cf2a56e123. Thank you very much for the patch.
-
Fix documentation typo
-
Your fix is submitted to GraphicsMagick Mercurial as changeset 16073:0872570056c9. Thank you for the patch.
-
On Mon, 1 Jul 2019, Paul Wessel wrote: The specific message is: gm compare: abort due to signal 6 (SIGABRT) "Abort"... Abort trap: 6 I am away on a vacation trip at the moment. Please check if the latest development snapshot has the problem, or try the latest from Mercurial. This already existing changeset fixed a SIGABRT during initialization under OS X and will likely fix the problem: changeset: 16063:f30492f40f78 user: Bob Friesenhahn bfriesen@GraphicsMagick.org date: Mon Jun 17 18:54:43 2019...
-
`gm identify foo.png` crashes on macOS (v 1.3.32)
-
This problem is fixed by Mercurial changeset 16063:f30492f40f78. Thank you very much for bringing this to my attention.
-
On Mon, 17 Jun 2019, chdiza wrote: Making the tiny suggested patch seems to have fixed the problem. You also requested some more output: ``` gm convert -list formats | fgrep PNG PNG P rw- Portable Network Graphics (libpng 1.6.37, zlib 1.2.11) It looks like the string takes 26 characters and 32 were provided so it should not have crashed. It may be that Apple's strlcat() is testing the actual size of the buffer against the MaxTextExtent argument which was improperly provided and this is why it is...
-
On Mon, 17 Jun 2019, Bob Friesenhahn wrote: I am thinking that the problem may go away if you change coders/png.c at line 32 from version[32]; Sorry, I should have said line 6405. This is at the top of RegisterPNGImage(). 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
-
If my suggested change eliminates the crash, then the output of gm convert -list formats | fgrep PNG from the fixed version would still be very helpful in order to know what was put in the version string and how long the string allocation should have been. 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, 17 Jun 2019, chdiza wrote: macOS doesn't have gdb, so I used lldb and reproduced your instructions. I hope that is enough. Here is what I see: The debugger output is very useful. Are you able to provide the output of gm convert -list formats | fgrep PNG from the previous gm which worked? This would be very useful. I am thinking that the problem may go away if you change coders/png.c at line 32 from version[32]; to version[MaxTextExtent]; The problem must be that one of the components producing...
-
On Mon, 17 Jun 2019, chdiza wrote: I just built 1.3.32 on macOS 10.14.5. The build succeeds, but gm identify crashes when applied to (AFAICT) any png file. I get: gm identify: abort due to signal 6 (SIGABRT) "Abort"... Abort trap: 6 Are you able to provide a debugger backtrace so we can see where this problem is occuring? One way to get this (assuming that debug symbols are still enabled) is to do: gdb /path/to/gm gdb> r identify file.png [ should crash here] gdb> bt Usually SIGABRT is related to...
-
GraphicsMagick 1.3.32 is now available
-
On Wed, 12 Jun 2019, Aaron Martinez wrote: That is the current version that we are running in our production environment, but I also ran the same command using 1.3.31 w/ a different error message: ~~~ /usr/local/Cellar/graphicsmagick/1.3.31/bin/gm identify: No decode delegate for this image format (13860517.tif). /usr/local/Cellar/graphicsmagick/1.3.31/bin/gm identify: Request did not return an image. Sometimes this might mean that your GraphicsMagick does not support TIFF at all, but in this case...
-
On Wed, 12 Jun 2019, Aaron Martinez wrote: When running a basic gm identify -verbose command on a tif image, I get the following errors: ~~~ /usr/local/Cellar/GraphicsMagick-1.3.18/utilities/gm identify: Memory allocation failed (13860516.tif). /usr/local/Cellar/GraphicsMagick-1.3.18/utilities/gm identify: Request did not return an image. ~~~ This is not specific to the image format as I was able to run the command for other tif images. Would anyone be able to help explain why this may be happening?...
-
On Tue, 4 Jun 2019, Bob Friesenhahn wrote: On Tue, 4 Jun 2019, John Mikhael wrote: Hello, A public ssh key is fine as long as it is on a user account that does not have any project permissions (just used for checking out). However a better alternative is to use rsync like: rsync -a hg.code.sf.net::p/graphicsmagick/code graphicsmagick-rsync hg clone graphicsmagick-rsync/code graphicsmagick In my test here, your example took 19 minutes to perform the rsync given 50Mbit dedicated-fiber connectivity....
-
On Tue, 4 Jun 2019, John Mikhael wrote: Hello, A public ssh key is fine as long as it is on a user account that does not have any project permissions (just used for checking out). However a better alternative is to use rsync like: rsync -a hg.code.sf.net::p/graphicsmagick/code graphicsmagick-rsync hg clone graphicsmagick-rsync/code graphicsmagick In my test here, your example took 19 minutes to perform the rsync given 50Mbit dedicated-fiber connectivity. It still seems very slow when I added the...
-
I am told that some sites competing with SourceForge use the Mercurial ClonebundlesExtension to improve the performance (and lessen the server load) of cloning a Mercurial repository: https://www.mercurial-scm.org/wiki/ClonebundlesExtension 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 Fri, 31 May 2019, Bob Friesenhahn wrote: On Thu, 30 May 2019, John Mikhael wrote: Hello, We are looking into this issue. In the meantime can you try to check out with ssh:// instead of https://? It should be more reliable. An ssh checkout requires user authentication, but the user doesn't need to be part of the project. So you could set up a separate account with an ssh key for this purpose. I will see if it is possible to do this for oss-fuzz. With oss-fuzz everything is encapsulated in a script...
-
On Thu, 30 May 2019, John Mikhael wrote: Hello, We are looking into this issue. In the meantime can you try to check out with ssh:// instead of https://? It should be more reliable. An ssh checkout requires user authentication, but the user doesn't need to be part of the project. So you could set up a separate account with an ssh key for this purpose. I will see if it is possible to do this for oss-fuzz. With oss-fuzz everything is encapsulated in a script and starts from absolute scratch. Bob Bob...
-
On Fri, 31 May 2019, Harald Hanche-Olsen wrote: I hit this old bug today. Here is a simple way to reproduce it: ~~~ gm convert -size 100x100 xc:white -draw 'circle 50 50 60 60' test.pdf ~~~ The resulting pdf file is indeed malformed. The reason this does not cause a problem for most (all?) pdf previewers, is that the offending object (#11 in this example) is never referenced by any other object, so pdf viewers are unlikely to try to parse it. However, any program that parses entire pdf files, such...
-
Can not clone GraphicsMagick Mercurial repository
-
Add braille image format support
-
Your patch is now in the GraphicsMagick respository as changeset 16018:f3e7ae399ec1. Thank you very much for your contribution. Any information you can provide regarding the Braille image format is appreciated so that we can update the formats documentation. In case you would like to provide your own format documentation, the source file which provides information on the formats is www/formats.rst. This text becomes the web page available at http://www.graphicsmagick.org/formats.html
-
This line would need to be removed: +% Copyright (C) 1999-2019 ImageMagick Studio I did find your submission as it originally appeared in ImageMagick 6.3.9 so there is some basis for comparison.
-
I see that you are the original author of this module. That is a good thing since then there is hope that we can use a version of this code since you are the legal author of the original and are able to offer the original code under any license. Are you able to produce a version of this code which safely removes the "Copyright (C) 1999-2019 ImageMagick Studio" declaration? We can not mix ImageMagick Apache-licenced code into GraphicsMagick because GraphicsMagick is pure MIT-licensed and the ImageMagick...
-
heap-use-after-free in function ThrowLoggedException of magick/error.c
-
This problem is fixed by Mercurial changeset 15992:44ab7f6c20b4. Thank you very much for the report!
-
heap-buffer-overflow in ImportRLEPixels of coders/miff.c
-
This problem is fixed by changeset 15991:bc99af93614d, which addresses the typo which resulted in this heap overflow as well as undefined behavior caused by large shifts. Thank you very much for this report.
-
Identify not returning data from animated WebP
-
heap-buffer-overflow in ImportRLEPixels of coders/miff.c
-
How to get unique colors from an image using Graphicsmagick?
-
Closing stale support issue which has been partially answered. There is still no -unique-colors option in GraphicsMagick.
-
Need ability to suppress/ignore warning messages
-
Closing support issue which was opened as a bug (and is still open).
-
Install problem on Ubuntu
-
I am assuming that this issue is no longer relevant so I am closing it. GraphicsMagick no longer offers source RPM packages since distributions do a much better job of supporting GraphicsMagick for their distribution.
-
Graphicsmagick configuration
-
I am not sure what additional "checks" could be reasonably added to "validate" HPGL input files prior to handing responsiblity for software which does have intimate knowledge of HPGL parsing. The actual problem here appears to be with hp2xx. Unfortunately, hp2xx is unmaintained since 2003 and so it is unlikely to fare well in today's world of software fuzzing. Are there any fuzzing efforts for hp2xx and a set of effective patches for the problems found? We currently request EPS output from hp2xx....
-
I should mention that the 'hg clone' and 'hg update' problems have been observed on multiple client systems.
-
GraphicsMagick Mercurial repository not working correctly
-
heap-buffer-overflow in function WriteMATLABImage of coders/mat.c
-
This problem is fixed by Mercurial changeset 15961:57ac0ae85e2a. Thank you for the report.
-
heap-buffer-overflow in function WritePDBImage of coders/pdb.c
-
This problem is fixed by changeset 15960:85f5bdcd246a. Thank you for the report.
-
Division by Zero in coders/wmf.c
-
This problem is fixed by Mercurial changeset 15957:72b0bcf425b6. It seems like libwmf should have reported an error from wmf_scan() if the bounding box is zero.
-
heap-buffer-overflow in function WritePDBImage of coders/pdb.c
-
heap-buffer-overflow in function WriteMATLABImage of coders/mat.c
-
heap-use-after-free in function ThrowLoggedException of magick/error.c
-
heap_buffer_overflow_WRITE in function WriteXWDImage of coders/xwd.c
-
This problem (and more) is fixed by Mercurial changeset 15953:d823d23a474b. Thanks for the report.
-
stack-buffer-overflow in function SVGStartElement of coders/svg.c
-
This bug is fixed by Mercurial changeset 15952:b6fb77d7d54d. Thank you for the report.
-
heap-buffer-overflow in function ReadMIFFImage of coders/miff.c
-
This problem is fixed via Mercurial changeset 15951:f7610c1281c1. Thank very much for reporting the issue.
-
heap-buffer-overflow in function ReadXWDImage of coders/xwd.c
-
This problem is fixed by Mercurial changeset 15950:7cff2b1792de. Thanks for the report.
-
heap-buffer-overflow in function CloneImage of magick/image.c
-
This problem is fixed by changesets 15948:40fc71472b98 and 15949:86a9295e7c83. Thank you very much for the report!
-
memory leak in function ReadMPCImage of coders/mpc.c
-
This problem is fixed by Mercurial changeset 15945:a348d9661019. Thanks for the report! Note that the problem text described this issue as a buffer overflow, but the subject was correct that there was only a memory leak.
-
use allocate memory before null check
-
I have implemented a fix for pdb.c. The source code in magick/render.c line 2506 is specifically to deal with memory allocation failure so I wonder what you mean by "latest version of GraphicsMagick". I have impemented a fix for segment.c I have implemented a fix for xwindow.c The fixes are implemented in changeset 15944:4188ef30df01. Thanks for inspecting the code and reporting these issues.
-
memory leak in function lite_font_map of coders/wmf.c
-
With testing here (on a Ubuntu 18.04 Linux system with 48GB of RAM) using a self-compiled libwmf 0.2.8.4 I am not seeing the memory leaks and GraphicsMagick quits in an orderly way. I tested using both ASAN and Valgrind. The program did use a huge amount of memory, with a heap peak size of 3,134,112,719 bytes.
-
I am pretty sure that this issue is due to libwmf simply causing the program to exit rather than returning an error code to GraphicsMagick so that it can do things like free memory.
-
memory leak in function lite_font_map of coders/wmf.c
-
memory leak in function ReadMPCImage of coders/mpc.c
-
stack-buffer-overflow in function SVGStartElement of coders/svg.c
-
heap_buffer_overflow_WRITE in function WriteXWDImage of coders/xwd.c
-
heap-buffer-overflow in function ReadMIFFImage of coders/miff.c
Oh no! Some styles failed to load. 😵