This has to do with the free version of Visual Studio, which does not have everything. To solve, it look in the Solution Explorer, and remove 'UTIL_imdisplay'. At least that is what I think it is called. It will be the build target which is failing. Just removed it from the project file. Bob
GraphicsMagick 1.3.43 is now available
Added tag GraphicsMagick-1_3_43 for changeset eff5b40bc770
Copyright year is 2024!
This has to do with the free version of Visual Studio, which does not have everything. To solve, it look in the Solution Explorer, and remove 'UTIL_imdisplay'. At least that is what I think it is called. It will be the build target which is failing. Just removed it from the project file. Bob On 3/23/2024 10:41 AM, ltk19 wrote: Thank you for your help, please find my details for error messages below, C1083 Cannot open include file: afxwin.h': No such file or directory LNK1181 cannot open input file...
Thank you for your help, please find my details for error messages below, C1083 Cannot open include file: afxwin.h': No such file or directory LNK1181 cannot open input file 'CORE_RL_magick_lib'
I am not able to answer any PHP specific questions. I can say that development GraphicsMagick (as obtained via Mercurial) has been observed to compile under Visual Studio 2013, 2019, and 2022. I have not tried 2017. If you are using binaries built by someone else, then it seems important to try to match the Visual Studio versions. Regarding errors, it is useful to provide the actual error messages rather than just the codes. Seeing warnings is usual, especially pertaining to the Visual Studio project...
Merge updates from tip for expected TGA signatures
Merge changes for the 1.3.43 release
PerlMagick/t/{read.t, write.t}: Update expected TGA signatures
Updates in preparation for the 1.3.43 release
I have an issue on building Gmagick PHP extension on Windows server 2019. I would like to build a Gmagick PHP extension on my server. I am using PHP 7.3.9. I am trying to build GraphicMagick from source. I would like to know what version of Visual Studio I should install. Now I am using Visual Studio 2022. The version of PHP I downloaded from website version is PHP 7.3.9-Win32-VC15-x64 which used Visual C++ 15.0 (Visual Studio 2017) to compile. If I want to build an extension on this PHP, shall I...
Update generated files
VisualMagick/tests/runtest.bat: Enable additional logging with setting "set MAGICK_DEBUG=exception".
VisualMagick/tests/runtest.bat: Remove tests for format identifiers which are not testable.
runtest.bat: Skip even more format identifiers which will fail.
runtest.bat: Skip more format identifiers which will fail.
runtest.bat: Disable format tests which will never work.
Writing to SVG is not supported, so do not test that!
Fix spelling of palette
Test scripts should identify themselves!
Enable echo in run_constitute.bat
tests/constitute.c: Handle capital 'Y' and 'K' while checking if a CMYK map is specified.
VisualMagick/tests/run_constitute.bat: Re-generate test script based on what current tests/constitute.tap does.
Rename VisualMagick log.mgk to log-eventlog.mgk and create log.mgk for logging to stderr.
FTP is now a "deprecated" protocol, so libxml2 likely has it disabled by default. Bob On Mar 16, 2024, 8:44 PM, at 8:44 PM, Hanspeter Niederstrasser nieder@users.sourceforge.net wrote: Yeah, it was the old jasper. Bumping to latest 4.2.2 fixes the pointer issue. Getting a separate implicit declaration of function 'xmlNanoFTPInit' error in coders/url.c, but will look through dependencies to make sure they're not at fault (libxml2-2.12.4) before filing. This ticket can be closed. [bugs:#736] incompatible...
Yeah, it was the old jasper. Bumping to latest 4.2.2 fixes the pointer issue. Getting a separate implicit declaration of function 'xmlNanoFTPInit' error in coders/url.c, but will look through dependencies to make sure they're not at fault (libxml2-2.12.4) before filing. This ticket can be closed.
GraphicsMagick compiles with the latest Jasper, and I am not aware of a reason to not use it. Newer versions have fewer security issues. Bob Sent from BlueMail On Mar 16, 2024, 2:33 PM, at 2:33 PM, Hanspeter Niederstrasser nieder@users.sourceforge.net wrote: Thanks for the quick response. I'm running 1.900.1 because we thought libjasper had gone dead. But now it looks like it's been back for a while and we just never noticed. Is there a specific version that GraphicsMagick prefers (latest 4.x,...
Thanks for the quick response. I'm running 1.900.1 because we thought libjasper had gone dead. But now it looks like it's been back for a while and we just never noticed. Is there a specific version that GraphicsMagick prefers (latest 4.x, 3.x, ???) ? thanks.
Update the news
Compilation failure with libjpeg-turbo 3.0.0
Should be all good now!
As of 2024-02-11, GraphicsMagick is fully updated for ibjpeg-turbo 3.0.0, including the ability to read/write 12 and 16 bit JPEG.
Convert with gm.exe PDF
I have tried to reproduce this issue, but I am not certain that there is one. Particularly related to a missing "endstream".
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...
ErrorOpenFile when using readImages
Issue was discovered to be with using wrong/unexpected library.
Update types.rst documentation
Mio, your changes are in Mercurial changeset 17448:86ef5ece9e47, and then changeset 17449:5d3812a1ee77 fixes a couple of glitches, as well as updates the formatted HTML pages. Thanks for your valuable contribution!
Fix spelling errors and out-of-date information in types.rst
Fix spelling errors and out-of-date information in types.rst
Update types.rst documentation
I am not seeing any warnings from GCC 10 or Clang 12 under Linux when using JasPer 4.2.2 (latest version at this time). I do not have a system running MacOS here. JasPer did make some annoying C API interface changes in this area over time. Hopefully it is stable now. JasPer's build does the unusual thing of promoting the requested C version to the newest version supported by the C compiler and perhaps this causes an issue with Xcode15. From https://en.wikipedia.org/wiki/Xcode I see that Xcode 15...
incompatible pointer types error in jp2.c
This bug report lacks the specific JasPer version which exhibits this issue. What version of JasPer is being used?
incompatible pointer types error in jp2.c
Thank you for fixing this.
[MagickWand] Potential regression when creating GIFs
This issue is fixed by Mercurial changeset 17447:ee005758e1a6, which assures that functions using AppendImageToList() update wand->images to point to the beginning of the list. This fix is in today's GraphicsMagick snapshot tarball.
wand/magick_wand.c: Assure that functions using AppendImageToList() update wand->images to point to the beginning of the list.
After a bit more study, it appears that all functions currently using AppendImageToList() need to also update wand->images to point to the start of the list since that is what the other APIs expect. The behavior of AppendImageToList() was changed.
There is also the possibility of modifying MagickReadImageFile() to store the beginning of the list in wand->images, but this would also penalize your read algorithm.
The strategy being used is not a documented feature of MagickReadImage(). Regardless, if this undocumented "feature" worked before, and no longer works now, it seems to be a form of regression. There was no change to the MagickReadImage() code. These two lines of code do the work: AppendImageToList(&wand->images,images); wand->image=GetLastImageInList(wand->images); From this, one may determine that wand->image should always have been pointing to the last image in the list. The problem seems to be...
AppendImageToList() now always updates the images pointer to be the last image in the list. This helps immensely when appending more images. Ah, okay. I remember reading that the changes were for the better. It makes sense to avoid re-traversing the list each time. I see that there are both "wand->images" and "wand->image" so there are two references to the list. When the operation is completed, "wand->image" is set to the last image in the list and "wand->images" also refers to the last image in...
Never mind. I can immediately see that the images are not being appended.
There appear to be three input PNG files. I am not sure if order matters, but can you please provide the exact argument list you are testing with?
[MagickWand] Potential regression when creating GIFs
AppendImageToList() now always updates the images pointer to be the last image in the list. This helps immensely when appending more images. I see that there are both "wand->images" and "wand->image" so there are two references to the list. When the operation is completed, "wand->image" is set to the last image in the list and "wand->images" also refers to the last image in the list, but previously perhaps it referred to the first frame of the image list which was just appended. I will investiga...
[MagickWand] Potential regression when creating GIFs
Update types.rst documentation
ghostscript executable search path (with graphicsmagick)
It can be expected that programs run under a web server, or via a web application will be provided with a restricted executable search path, and even restricted privileges. This issue does not appear to be a bug.
This is a test to see if email makes it into the issue tracker. 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
It seems like you have still been proceeding with GraphicsMagick so perhaps you solved this issue already? If the issue is with the executable search paths to find delegate "helper" programs, then sometimes using --with-frozenpaths may help with that.
No decode delegate for this image format (build from source)
I expect that what happened is that GraphicsMagick configure/build was done first, then used to discover that there was an issue, the development packages were installed, and then the configure/build was done again. Regardless, there is no bug here.
I do that because I optimize the image in steps. I just add the new extension so it's easy to get a grasp of the whole "chain" when debugging The file could also be something like: file.pdf.png.tif
in the .png.png file I think I run it through opencv and do some optimization before OCR