Activity for Bob Friesenhahn
-
Bob Friesenhahn modified ticket #654
Check on number colors
-
The BMP number_colors parameter is not always relevant since using it while decoding depends on the BMP version and the number of bits per pixel. There is a check for number_of colors at line 951 of bmp.c: if (bmp_info.bits_per_pixel < 16) { if (bmp_info.number_colors > (1UL << bmp_info.bits_per_pixel)) ThrowBMPReaderException(CorruptImageError,UnrecognizedNumberOfColors,image); } It would be bad to reject otherwise valid files since then users would be blocked from reading their files. I don't think...
-
BMP parser: Check on file size
-
We have found that there are many slightly defective BMP files that users still want to be able to read. The file size parameter is sometimes slightly wrong because of bugs in the writing software. A decision was made to not reject files based on this file size parameter, which is not needed in order to successfully decode a BMP file. From a security standpoint, GraphicsMagick does check important things which might cause harm while reading (and writing). GraphicsMagick's BMP reader is continually...
-
I only have one Windows system to test on. A system that has Visual Studio installed on it (what I have) already has everything needed to run the program which is built, so it is useless for testing. It would be IMMENSELY useful if someone can provide sha1 checksums (or similar) for the Visual Studio SP1 manifest and DLL files needed in order to run GraphicsMagick. We are only talking about a total of four files. Microsoft is spectacularly unhelpful in that they only provide an installer exe package...
-
Changeset 16586:e10a315d4eb4 has been added to the GraphicsMagick-1_3 for anyone using the branch.
-
Convert test fails in 1.3.37
-
I am assuming that the sed approach will work for FreeBSD since FreeBSD's sed supports the -n option. It does also work using Solaris/Illumos native sed. Please make me aware of if it does not work. In the mean-time, changeset 16585:0ae6efa44c38 should solve the problem.
-
On Tue, 14 Dec 2021, Daniel E wrote: Running the test suite there's one test failing, ~~~ ... PASS: utilities/tests/convert.tap 146 - -white-threshold 80% ERROR: utilities/tests/convert.tap - missing test plan ... ~~~ OS: FreeBSD 13, amd64 If there's any other information you need just ask :-) Since you allow asking, then I will. :-) On my system, this returns the value 146 (in the source tree): cd utilities/tests wc -l convert-cmds.txt | sed -e 's/ .*//' I think that for my various systems 'wc'...
-
GraphicsMagick 1.3.37 is now available
-
On Tue, 7 Dec 2021, Tim Mensch wrote: AND after some digging I fixed it by digging up the Visual Studio 2008 Redist installer, so this is, I guess, a documentation bug--or an installer bug? Somehow the installer didn't install the Redist package for me. What happened is that the Visual Studio 2019 installer offered to apply a Visual Studio 2008 SP1 update for me. I foolishly agreed. This update apparently has a bug in the SP1 re-distributables in that there is a mis-match between provided files....
-
On Mon, 29 Nov 2021, Weiqi Wang wrote: It seems the BMP parser in GraphicsMagick doesn't check the file_size and data read length mismatch. Does GraphicsMagick trust the value that is put into the file_size field? I'm wondering if there's a missing check. Or would it be good to add a warning if data read length mismatches the size specified in the file? As I recall, GraphicsMagick still supports concatenated BMP files so it does not make sense to require the claimed file_size to be the same as the...
-
On Mon, 29 Nov 2021, Weiqi Wang wrote: GraphicsMagick succeeds in parsing it, while ImageMagick complains InsufficientImageDataInFile ... error/bmp.c/ReadBMPImage/673. The corresponding check in ImageMagick is if ((MagickSizeType) bmp_info.number_colors > blob_size) ThrowReaderException(CorruptImageError,"InsufficientImageDataInFile"); It seems the bmp parser in GraphicsMagick doesn't check number colors. I'm wondering whether if there is a missing check on number_colors in GraphicsMagick's BMP parser....
-
On Sat, 13 Nov 2021, Tobias Fischer wrote: We avoid the trouble with the 'configure' program by using a modern cmake build. (see https://github.com/conda-forge/graphicsmagick-feedstock/blob/master/recipe/CMakeLists.txt for the CMakeLists). The CMakeLists.txt is then used to build GraphicsMagick with Visual Studio (one could also use clang if one wanted to do so): That is good. GraphicsMagick should be supporting Cmake directly in order to avoid the common problem that only one subset of the build...
-
It is interesting that this release request is related to Microsoft Windows. The primary inhibitor to a release is the Microsoft Windows build using Visual Studio. Repeated pleas have been made for Windows experts to assist with updating the Microsoft Windows build but only one person has been willing to offer even a few minutes of their time, and unfortunately it does not address the major issues. Changes in third party libraries like libtiff and JasPer require using Visual Studio 2015 or later...
-
Bug with gm identify
-
It seems to me that this GIF syntax is slightly defective (the transparent index is not in the colormap) but a workaround has been applied similar to that used in ImageMagick. Update to Mercurial changeset 16563:02742ac3634d to obtain the fix. Thanks for bringing this issue to our attention.
-
This problem is fixed by Mercurial changeset 16557:2067faf19869. When GraphicsMagick started, the MSL/conjure implementation was "experimental". Fuzz testing (starting with oss-fuzz) has exposed how fragile/broken the implementation was. This changeset should improve the robustness quite a lot since it addresses a fundamental error reporting issue. The MSL script itself should be considered "trusted" since it is able to request arbitrary commands. Non-trusted users should never be allowed to compose...
-
SEGV in gm at coders/msl.c:883
-
The list of issues discovered by oss-fuzz for GraphicsMagick may be found at https://bugs.chromium.org/p/oss-fuzz/issues/list?q=graphicsmagick&can=1 The open issues may be viewed at https://bugs.chromium.org/p/oss-fuzz/issues/list?q=graphicsmagick&can=2 Please note that I can likely see more open issues than you can since oss-fuzz waits a while before telling the whole world about them. The bugs marked as "Reproducible" are still reproducible. Some bugs marked as "Unreproducible" are actually fixed....
-
On Mon, 4 Oct 2021, Irfan Ariq wrote: Environment - OS: Ubuntu 18.04.5 LTS - GCC version: gcc 7.5.0 - GraphicsMagick version: GraphicsMagick 1.3.36 I strongly recommend testing using the latest code in Mercurial, or the latest development snapshot. MANY such issues have been fixed in MSL since the 1.3.36 release due to continuous oss-fuzz testing. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/...
-
On Thu, 9 Sep 2021, Paul Flo Williams wrote: In PerlMagick, fuzz is documented to have an integer parameter, but there is no indication of the allowed range, which is strange when converting from command line usage, where I've always used percentages. I can now see that the range depends on GraphicsMagick's "quantum depth", but there is no convenient way of reading this from the Perl API, except by creating a new image and reading back the "depth" attribute. I agree that this documentation topic...
-
On Wed, 1 Sep 2021, theguppyfish wrote: I just checked the imagemagick output, and it looks like it probably more tolerant of an out of bounds color. Frame broken[44] seems to have 129 colors I agree that being more tolerant is better than producing a hard error. 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 Wed, 1 Sep 2021, theguppyfish wrote: Hi Bob, I tried to download the source to see if I could help figure it out, but my C/C++ skills are about 20 years out of date. Based on the error message, it seems to be some off-by-1 array index type of error. If you do something like gm convert -debug coder,exception broken.gif info:- or gm identify +ping -debug coder,exception broken.gif then you should see a trace of the various logging statements, and also where the exception is thrown from. This will...
-
On Fri, 27 Aug 2021, theguppyfish wrote: broken.gif (558.5 kB; image/gif) Please re-upload broken.gif wrapped in a zip file or a tarball. Otherwise SourceForge will re-write the GIF file so that it is not the original file. 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, 10 Aug 2021, Davison wrote: Is there anything holding you back from going ahead with the transition to Visual Studio 2019? The software does build and works fine with Visual Studio 2019. Small changes are needed to the Inno Setup installer script (e.g. to not try to add the MSVC runtime DLLs which are no longer relevant). Otherwise, there is still the issue that the third party libraries should be updated. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Tue, 10 Aug 2021, Davison wrote: Thanks for the response. I'm not an expert with Visual Studio compiler issues either. I would be in favor of moving to require the latest version of Visual Studio runtime as any Windows 10+ environment should be able to use it without even installing a runtime. If I'm understanding things correctly Visual Studio 2015 and later use a universal runtime that is included in Windows 10. For those wanting to use GM on older (unsupported) Windows environments they can...
-
On Wed, 4 Aug 2021, Davison wrote: @bfriesen this is still a problem as of August 2021. I don't mind if you specify that Windows users need to download a redistributable package separately, but right now the binary is entirely broken without manually modifying a manifest file. It would seem that a minor release is warranted just to fix that specific issue. I agree that it is a problem which should be fixed. I need someone with Windows Visual Studio development expertise to help me. The project is...
-
On Wed, 4 Aug 2021, Nick J. wrote: I don't think GM's behavior of scaling the image is correct. The min/max sample value are not required tags, and if they are set, they do not mean the image cannot have pixel values outside the corrsponding range. From the TIFF specification about MaxSampleValue: "This field is not to be used to affect the visual appearance of an image when it is displayed or printed. Nor should this field affect the interpretation of any other field; it is used only for statistical...
-
Assertion failed using -label with PDF
-
This problem is fixed by Mercurial changeset 16545:22aaff86b4aa. Thank you very much for this report. If you have not done so already I strongly recommend opening a report in the Debian bug tracker so that they can update the Debian package with the fix.
-
On Tue, 20 Jul 2021, Kevin Locke wrote: Using GraphicsMagick 1.4 snapshot-20210228 Q16 from the Debian graphicsmagick package version 1.4+really1.3.36+hg16481-1 or GraphicsMagick 1.4 snapshot-20210718 Q8 built from current tip (59c8ee0db7b9), if the -label option is given when writing a PDF, the following assertion failure occurs: $ gm convert -label MyLabel xc:#ffffff labeled.pdf gm: magick/memory.c:678: _MagickReallocateResourceLimitedMemory: Assertion `memory_resource.signature == MagickSignature'...
-
Improper installation
-
Closing since this issue is due to the uninstall of the packages trying not to lose any existing customizations and apparently if the directory exists, the config files are not restored by install.
-
On Wed, 7 Jul 2021, Dieter wrote: ~~~ Searching for file "log.mgk" in path "/usr/share/GraphicsMagick-1.3.35/config/:/usr/lib/GraphicsMagick-1.3.35/config/" 19:20:00 0:0.000794 0.000u 11448 blob.c/GetConfigureBlob/2131/Configure: Tried: /usr/share/GraphicsMagick-1.3.35/config/log.mgk [Datei oder Verzeichnis nicht gefunden] 19:20:00 0:0.000926 0.000u 11448 blob.c/GetConfigureBlob/2131/Configure: Tried: /usr/lib/GraphicsMagick-1.3.35/config/log.mgk [Datei oder Verzeichnis nicht gefunden] 19:20:00 0:0.001116...
-
On Tue, 6 Jul 2021, Dieter wrote: I hope this is the right place, as I have not found a better one. Ubuntu 20.04 / Mint 20.1 GraphicsMagick 1.3.35, (re)-installed via application manger I am not responsible for Mint Linux! :-) The file should usually be at /usr/lib/GraphicsMagick-1.4/config/delegates.mgk or /usr/lib/GraphicsMagick-1.3.35/config/delegates.mgk depending on how it self-identifies itself. It is identifying itself as 1.3.35 although it seems to be based on unreleased sources from the...
-
PCX file not read correctly
-
Your final patch is applied and is Mercurial changeset 16532:73427aaeb329. Thanks for your help!
-
I see why I was confused. I was remembering the JPEG file which was provided. The correct result is apparently a green blob.
-
I am confused. The first patch you submitted contained many changed lines and it did appear to read your sample file correctly (it looked like a useful image). With the change from this latest patch (which only changes one line but similar to the original patch), your sample file is no longer read correctly. Are you able to supply a patch which reads your own PCX file correctly as well as the others I mentioned?
-
That is a good catch, and thanks for the patch. The patch is submitted to Mercurial via changeset 16530:b33792cfdb84.
-
Minor improvment webp
-
With the patch applied, GraphicsMagick is not able to read the two sample PCX files supplied with the "Encyclopedia Of Graphics File Formats" book. Are you able to improve your patch so that the test suite passes (including reading PerlMagick/t/input.pcx, which also fails)?
-
I am not sure why the PCX tests fail, but it is due to the image changing during the read/write test so it does not pass the round-trip sanity checks. Exceptions are not being thrown. It is not easy to evaluate exactly what the patch has changed since the indentation was changed while performing the edits.
-
All of the truecolor PCX/DCX tests in the GraphicsMagick test suite ('make check') fail with this patch applied.
-
PCX file not read correctly
-
On Fri, 11 Jun 2021, Emanuele wrote: Hi, in the last binary version till to 1.3.36, OLE component is missing unlike previous versions where i remembered was present. I need to install a 32bit GrapchicsMagick library with this component to run a custom vbscript with cscript.exe to resampling and downscale my images. So with this missing OLE component a runtime error "ActiveX component can't create object: 'ImageMagickObject.MagickImage.1'" is shown up and i can't go ahead. I assume that the component...
-
I see that jpeg-xl is implemented in C++. For cross-platform portability, this may necessitate linking the GraphicsMagick shared library (or gm if a static build) with the C++ compiler. Previously this was done when using the FlashPIX library.
-
FYI, just like the standard free() function, it is not necessary to prevent passing null pointers into the MagickFreeResourceLimitedMemory() macro. A nice thing about the macro is that it nulls the pointer if if it has been freed.
-
This is looking like a very good start to me. Are you planning to implement the writer? If a writer is implemented then it is easy to add it to the GraphicsMagick test suite for basic read/write sanity testing. Anything which is not tested is likely broken, or soon to be broken. Currently, the only reader-only testing we have is via the PerlMagick test suite which is provided with sample files and verifies that the returned image matches a reference image (stored in a different format) within some...
-
It does not appear that issue submitters can edit a ticket unless they are also members of the project. However, it is possible to request changes via subsequent comments. This is a good thing in order to avoid the "moving picture" problem. I suspect that MacPorts may be configuring GraphicsMagick with the --disable-installed configure option. This would be apparent in the output of 'gm -version'. Use the command 'gm convert -debug configure -list type' in order to see the steps which are being performed...
-
typemap will only include one "type.mgk" (and nothing else/more).
-
On Tue, 1 Jun 2021, Allan wrote: I've used Image Magick previously until I stumbled across Graphics Magick and I have found it a much better fit for my current needs. However, I've found that there are times I need a more than what the documentation provides - a static It seems that no one else has answered your question yet. The URL you provided is the best current documentation available and accurate, although not always intuitive. GraphicsMagick is compatible with ImageMagick 5.x, but ImageMagick...
-
On Tue, 25 May 2021, Tobias Mark wrote: I really didn't understanding anything of this. Therefore I decided to re-write the encoder myself to avoid all this license stuff. If it is simple enough to do so, then a rewrite is good. Longer term, I should see if the project can be updated suitably so that selected ImageMagick coders can be ported without much impact to the project. Still missing the Writer but now includes the configure stuff. Can you have a look if this is ok for you? https://sourceforge.net/u/tbsmark86/graphicsmagick/ci/de5b3c1ea7278b4bc51f3ec123bd6bf672ca3dae/...
-
On Fri, 21 May 2021, Tobias Mark wrote: For my personal use i have adapted the ImageMagick coder for this (with minor addition for setting the quality). See attachment. Any interest in merging this? If the license even allows this? What licence notes are required? The license that ImageMagick uses is more restrictive than the MIT/X11 style licence that GraphicsMagick uses, but it is not incompatible with it. However, it does bring some baggage such as a need to include the text in the LICENSE and...
-
On Mon, 10 May 2021, Peiqi Liu wrote: Thank for fix it, compiled successfully using Visual Studio. But I should add a compiler option "/Zc:cplusplus", otherwise cplusplus value will alway be 199711L and cause compilation errors. Thanks for this information. I have now updated the pre-processor logic so presumably VC++ will work properly without adding /Zc:cplusplus. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/...
-
On Mon, 10 May 2021, Peiqi Liu wrote: Thank for fix it, compiled successfully using Visual Studio. But I should add a compiler option "/Zc:cplusplus", otherwise cplusplus value will alway be 199711L and cause compilation errors. I see this discussion: https://stackoverflow.com/questions/2324658/how-to-determine-the-version-of-the-c-standard-used-by-the-compiler The __cplusplus value should always be set and starting with C++98 it will be something other than 1 However, the same discussion (posting...
-
On Sat, 8 May 2021, Bob Friesenhahn wrote: On Sat, 8 May 2021, Peiqi Liu wrote: Yes, "std::unary_function" cause many compilation errors under C++17 Visual Studio 2019. I see that I only removed it for DrawableBase (in Magick++/Drawable.h) but it still seems to be used heavily in Magick++/STL.h. Oops! The latest Mercurial/snapshot version is verified to compile and pass tests using C++'98 through C++'17 with GCC 11.1 on a Linux system. I have not yet tested C++'17 using Visual Studio under Windows....
-
On Sat, 8 May 2021, Peiqi Liu wrote: Yes, "std::unary_function" cause many compilation errors under C++17 Visual Studio 2019. I see that I only removed it for DrawableBase (in Magick++/Drawable.h) but it still seems to be used heavily in Magick++/STL.h. Oops! Technical help and source-code contributions from the user community would be appreciated. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/...
-
On Tue, 4 May 2021, Glenn wrote: Thank you, here is the output of both: gm.exe convert -list formats PDF P -w+ Portable Document Format Thanks for this helpful information. This is not a problem with the GraphicsMagick source code. This is a result of a problem with the procedure that I used to build GraphicsMagick 1.3.36 for Windows. I should have re-configured the project from scratch but instead I used existing project files. In fact, I think that this same issue exists for 1.3.35. There was a...
-
On Tue, 4 May 2021, Glenn wrote: Ok I tried rolling back to Ghostscript v9.52 and I still have the same error: gm.exe convert: No decode delegate for this image format I checked ticket #646 and that has a slightly different error: gm convert: Failed to find Ghostscript (not installed?) I'm not sure if that helps or not. It does indeed sound different. Please execute this and check if "PDF" is included in the list of supported formats: gm convert -list formats Also, make sure that the input file is...
-
On Mon, 3 May 2021, Glenn wrote: Hi Bob, The OS is Windows 10 / 20H2 GraphicsMagick 1.3.36 Q16 (64-bit) GPL Ghostscript 9.54.0 (64-bit) CLI commands to Ghostscript works as expected. I also added it the the PATH so it can be called with just gswin64c.exe This appears to be the same as SourceForge issue #636 which is now fixed in the source code but not yet released. If you can install a Ghostscript prior to 9.53 then it should work. The problem is that Ghostscript changed its naming strategy starting...
-
Please provide the operating system you are using and the versions of GraphicsMagick and Ghostscript you are using. If you are using Microsoft Windows, did you install a Ghostscript which matches the GraphicsMagick you installed (e.g. 64-bit/64-bit). That would be important for Windows. 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/pub...
-
Result of command "gm compare" depends on order of images
-
This problem is addressed by Mercurial changeset 16520:39f63789f297. Thanks for bringing it to our attention.
-
In my own testing, adding -matte does have the indended effect of enabling the opacity channel even though the first image does not have an opacity channel. Regardless my original assumption that the user knows that the first image is the original and wants the comparison to be done in terms of the original is somewhat faulty and I plan to fix that.
-
Result of command "gm compare" depends on order of images
-
On Thu, 22 Apr 2021, Chris Gravely wrote: A possible alternative I can think of would be to implement JPEGCoder as a C-callable C++ subsystem, which would allow you to use try...catch and throw a C++ exception instead of using setjmp/longjmp. Having said that, in some situations the exception would get thrown through intermediate JPEG code, which lives in a separate library, and that might complicate things. Unfortunately, throwing C++ exceptions through C code is not portable. In the case of JPEG...
-
Changeset 16518:2a0438efd812 eliminates the assignment of setjmp() to a variable. Please look/check again to make sure that all seems ok. 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, 22 Apr 2021, Chris Gravely wrote: It looks as though ISO-IEC 9899 doesn't allow assignment of the setjmp result, so it might be better to remove the assignment and its associated logging, as it's possible this might cause problems in the future. That is a very interesting finding. It appears that the return value needs to be consumed immediately as part of decision logic (e.g. a switch statement) or not used at all. I am not much of a fan of setjmp/longjmp but the only alternative I am aware...
-
SIGSEGV thrown performing longjmp in jpeg.c
-
This problem is fixed by Mercurial changeset 16516:1747878113cd. I am not sure exactly why the issue is fixed, but the change dramatically reduces the amount of data pushed to the stack, and it also relocates the jump buffer to the heap rather than the stack.
-
Memory leak when using CoalesceImages
-
No evidence of an actual memory leak has been provided. There have been no follow-up responses from the reporter.
-
On Thu, 15 Apr 2021, Alex wrote: I also tried to replace 9.0.30729.6161 with 9.0.21022.8. This also worked and I see the same output (as above) when I run gm.exe -version. I hope the temporary fix above helps anyone experience the same problem. I have no experience in Windows programming so I don't know how to fix this at coding level (maybe look for recent changes in the build process and/ or dependencies?). What happened is that when I installed and updated Visual Studio 2019, it quite helpfully...
-
On Tue, 6 Apr 2021, zhuo wrote: After printed "done!", using top will see about 1GB RES memory. I using valgrind found that leaking not by GM, mybe by malloc cache The classic C "heap" often does not release all memory to the operating system when the program programatically releases it. It retains memory as a "cache". In a multi-threaded program, there is a cache (an "arena") on a per-thread basis to make re-allocations from the same thread faster. Under Linux, the memory mapping/allocations may...
-
On Fri, 2 Apr 2021, Vitalii Martenkov wrote: I tried gm compare -matte -metric mae butterfly_with_black_bg.png butterfly_with_transparent_bg.png and it returned the same result. Then I tried gm compare +matte -metric mae butterfly_with_transparent_bg.png butterfly_with_black_bg.png and it likes that option mate doesn't have any effect. It seems like this issue needs more consideration and analysis so it both does what was intended, and what the user most likely expects. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us,...
-
The reason for this behavior is that the first image is the "reference" image. From reading the source code, it appears that if the -matte option is added like: gm compare -matte -metric mae butterfly_with_black_bg.png butterfly_with_transparent_bg.png that the opacity channel will always be included in the compare and the image without a matte channel has its matte channel set to opaque. If one uses +matte then the opacity channel should be ignored. I am not sure if the reason is a good reason.
-
On Sun, 21 Mar 2021, Alex wrote: Hi. Recently after upgrading to the latest version of GraphicsMagick 1.3.36 by using the GraphicsMagick-1.3.36-Q8-win64-dll.exe installer, the application cannot be started. Windows shows an error message saying that the application cannot be started correctly (0xc0150002). The Windows Event log shows the following: ~~~ Activation context generation failed for "C:\Program Files\GraphicsMagick-1.3.36-Q8\CORE_RL_magick_.dll".Error in manifest or policy file "C:\Program...
-
On Sun, 14 Mar 2021, Chris Gravely wrote: I've replaced libjpeg-turbo's jpeg library with an IJG one (I used jpeg-9d as that's the latest). I get crashes similar to my originals. Do you know anything about Cygwin's setjmp/longjmp implementations. I know mingw64 uses MSVCRT implementations, but I'm wondering if the Cygwin library providing the POSIX environment has its own implementation. If so, that could explain why the test works when built under Cygwin. I don't have any knowledge about this. The...
-
On Thu, 11 Mar 2021, Bob Friesenhahn wrote: If gm is invoked using the name 'convert' then it will behave like 'convert'. You can use symbolic links (or hard links) to create utility commands like this in the same directory where the gm command is installed (use 'which gm' to learn where that is): sudo ln -s gm convert I should mention that there may be an installable GraphicsMagick package which adds these symbolic links. It would be good to look for one. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us,...
-
On Thu, 11 Mar 2021, Troy D wrote: I installed GM based on information here: https://www.tecmint.com/install-imagemagick-in-linux/ Which said that imagemagick is not available on rhel 8 and to install GM. I did and if I do gm version, it show the information. If I do convert -version it does not work. If I do type convert, it is not found. Suggestions? All GraphicsMagick utility commands are normally invoked using the 'gm' utility. For example, to use convert you would invoke it like gm convert ......
-
On Thu, 11 Mar 2021, Andrew Sutton wrote: With convert can I specify xy sizes? Yes. It looks like gm convert infile.jpg -resize '800x600' outfile.jpg. Add an exclamation mark '!' to the end of the resize argument if you don't want to preserve the original aspect ratio. This is all described in the GraphicsMagick documentation, I suggest reading it. Also 'gm convert -help' provides some summary help. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick...
-
On Thu, 11 Mar 2021, Bob Friesenhahn wrote: convert infile.jpg -resize '50%' outfile.jpg That should have been gm convert infile.jpg -resize '50%' outfile.jpg otherwise you may be using different software. :-) 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, 11 Mar 2021, Andrew Sutton wrote: Good day everyone! I am using GM mogrify to resize an image but it overwrites the original file. Is there any way to specify an output file name? Thank you so much Yes. Use the 'convert' subcommand rather than 'mogrify'. For example, convert infile.jpg -resize '50%' outfile.jpg The only time that 'mogrify' does not overwrite its input file is if the format is changed using -format, or the output is sent to a different directory tree. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us,...
-
I just tested building under Cygwin with GCC 10.2.0 but apparently with a libjpeg which identifies itself as "IJG JPEG 80" in its version identification. In this case there are no crashes. It seems to me that the JPEG library used might have something to do with the crashes.
-
On Sat, 6 Mar 2021, Chris Gravely wrote: The problem is directly related to '-define jpeg:max-warnings=0'; there's only one warning issued when reading the jpeg file, so longjmp isn't called when max-warnings is one or greater. Yes. At this point there is no reason to believe that the JPEG error handling is working reliably at all with this compiler and/or libjpeg-turbo version. I would not trust something which only works 25-33% of the time. The PNG code also uses setjmp/longjmp so it might be similarly...
-
By the way, I am also using GCC 10.2.0.
-
Curioser and curioser! I thought that code edits where somehow making a difference. This is not the case. My Microsoft Windows system has 4 cores. What I have discovered is that if I run the program four times, it will usually segfault once.
-
I found that if I add 'volatile' before Image at line 247 of jpeg.c ('volatile Image'), it no longer crashes, although there are then many warnings.
-
I am able to reproduce this issue using mingw64 and MSYS2. The problem appears to be directly related to '-define jpeg:max-warnings=0' and if I change it to '-define jpeg:max-warnings=1' it does not crash. The crash does not occur under Linux and various memory checkers do not find anything wrong.
-
On Fri, 5 Mar 2021, Chris Gravely wrote: My suspicion is that gcc optimization and setjmp/longjmp don't play well together, in which case forcing functions that do setjmp/longjmp to build without optimization might be the right thing to do. It is indeed true that setjmp/longjmp are a terrible thing in that they do dangerous things and are platform and CPU specific. The setjmp "saves" the current stack and "longjmp" attempts to restore it as well as CPU registers so that the program appears to continue...
-
The gdb.txt backtrace shows that exception is zero upon entry into ReadJPEGImage(). This should not be possible. I suspect that the stack has been corrupted: #12 0x00007ff6b3843d22 in ReadJPEGImage (image_info=0x7ff600000000, exception=0x0) at coders/jpeg.c:1603 It is unlikely that I will be able to re-create this issue, particularly since it appears that optimization makes a difference. If you are able to debug the issue further on your end, that would help.
-
SIGSEGV thrown performing longjmp in jpeg.c
-
Please re-upload truncated_pool.jpg wrapped in an archive format such as zip or tar because SourceForge automatically re-writes JPEG, GIF, and PNG file uploads.
-
On Fri, 26 Feb 2021, leslie wrote: Thank you Bob. Sorry for my late response. I've been testing the ReadImage function by using perlMagick for many times. Now the conclusion is: 1. we can add a stegano image in a PNG file, and we can recover the watermark . 2. we CANNOT recover the watermark image from a JPG file. 3. the robustness of this watermarking API is not very good. After I cropped a little image vertically or change the resolution a little bit , the recovered wartermark was barely able to...
-
'Failed to find Ghostscript' with Ghostscript version 9.53.0+
-
This problem should be fixed by Mercurial changeset 16469:14555dd54b5b. Interestingly, I discovered that due to skipping a step in the build process, the Windows binary packages in the latest release do not have Ghostscript support at all! Please verify that everything is ok now.
-
On Fri, 12 Feb 2021, Tertionix wrote: Yes, I was using the same achitecture version for gm and ghostscipt. I noticed that ghostscript has changed the way of numbering versions from a.bb to a.bb.c so it might be just such a little change that lets gm not find the GS in the registry? That would be a very likely cause. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simple...
-
On Mon, 8 Feb 2021, asfasa asa wrote: There are some preferred ones used for pre-press paintings however CMYK is normally device-particular (e.G. For a printer) and accordingly it varies. Provided that your GraphicsMagick article has LCMS (LittleCMS) aid, then it should be capable of work with any ICC shade profiles that LMCS helps. It seems that the link to the article is actually a link regarding coffee brands. Was that intended? Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
Oh no! Some styles failed to load. 😵