Activity for Bob Friesenhahn
-
Bob Friesenhahn posted a comment on ticket #671
The problem seems to be that when libjpeg is built, the link library (".lib") is either not built, or does not use the naming expected by the rest of the code. If someone is able to assist with this who is fluent with Visual Studio, it would be greatly appreciated. Otherwise I will wait for the developer who did the JPEG updates to return.
-
Mercurial changeset 16720:171c0dd24d8a partially addresses issues. In the Visual Studio build, source files for formats not supported are not excluded so they still need to successfully compile. Now the jxl and heif modules will build without warning or error in Visual Studio. The issue with JPEG remains. The developer who committed the JPEG updates will not be available to look at this for another week.
-
I installed Visual Studio 2022 and ran into the same issue with the current sources. However, it does work with older sources. In between times, libjpeg was updated (by someone else) and it seems that the associated project file is producing something unexpected. I also see an issue related to JXL. There are no JXL sources in the project so the failure is likely due to something I did wrong.
-
On Fri, 29 Jul 2022, William wrote: I'm having issues with compiling latest graphicmagick on Windows 10. Put simply, the issue is 'migrating project(s) from visual studio 7 (2002) to visual studio 2022' breaks successful compiling. Here is detailed description of the process. I have not tried this yet. The most recent Visual Studio I have tried is 2019. There is no need to have Visual Studio 7 installed. The configure.exe program writes Visual Studio 7 compatible project files. Then when opening...
-
On Thu, 28 Jul 2022, tiefensuche wrote: Thank you for clarification. I noticed it by skimming through the code and looking into the changeset 15991:bc99af93614d. Since it is the only occurrence that was not changed while the same case was changed on other lines, it looked to me it was accidentally forgotten rather than intentionally kept as is, although it has no impact. Source code inspections are always appreciated. Even better are volunteers willing to help with development and testing. Bob Bob...
-
Missing cast
-
I have implemented the suggested change as Mercurial changeset 16717:0a06f497d588. Thanks for bringing this issue to my attention.
-
On Wed, 27 Jul 2022, tiefensuche wrote: I think in coders/miff.c line 392, there is a cast missing. It looks like quantum|=(*p++); but should actually be quantum|=((unsigned int) *p++); Did something other than code inspection cause you to notice this? The type of p is 'unsigned char' and the type of 'quantum' is 'unsigned int'. I believe that the rules say that the value is automatically cast to the type of the value it is assigned to. The value is the least significant byte of a two-byte value....
-
Segmentation fault caused by null pointer dereference
-
On my system (Ubuntu 20.04 LTS) I do not get the null pointer and SIGSEGV. Valgrind does not report any issues. I see that the crash happens pretty deep into libxml2 functions and not directly in GM code. In recent experience with libxml2 (e.g. via oss-fuzz) I see that recent libxml2 is all over the map as if the developers are trying different things and reacting when things go wrong. So problems can be detected and go away a few days later. The issues are often not reproducible with older libxml2...
-
On Fri, 22 Jul 2022, Jaroslav Fojtik wrote: Previous version before my update is even much more worse. It does not convert provided JPG at all. I have found this issue in work when I atempted to convert JPG on stable gm from 2020. This JPG has been created from Samsung Galaxy S3 mobile phone. I could try to even go step further and use newer JPG library. I assume that it is not easy to support sequential JPEG, which is really more like a video/movie. Supporting it properly would require generating...
-
On Fri, 22 Jul 2022, Jaroslav Fojtik wrote: It is interesting that other programs does not complain with this issue. The latest gm compiled from sources converts JPG to BMP and only displays this error. ~~~ M:\temp>"D:\Program Files\GraphicsMagick-1.3.31-Q8\gm.exe" convert 20220721_1203 53_resized.jpg 20220721_120353_resized.bmp D:\Program Files\GraphicsMagick-1.3.31-Q8\gm.exe convert: Invalid SOS parameters for sequential JPEG (20220721_120353_resized.jpg). As I recall, you updated libjpeg so you...
-
On Mon, 11 Jul 2022, Jan Kohnert wrote: I think, the change would probably change ABI. The reason I submitted this patch was, that the current behaviour introduces a whole bunch of deprecation warnings when using modern compilers (such as gcc-12.X). And though I agree that patch updates should not break ABI, I do not see a reason why a minor update should keep ABI compatibiliy under all circumstances. YMMV, of course. It is useful to know about warnings with GCC 12. I have not used it yet. The C++...
-
On Sun, 10 Jul 2022, Jan Kohnert wrote: In this commit std::unary_function was removed if C++17 is active. Since std::unary_function is deprecated in C++11 already, and std::function is it's successor, and available in C++11; this patch changes behaviour to use std::function, if C++11 is available. The reason why the code works the way it does is that it seemed that changing this would change the shared library ABI so there would be impact to existing users. Is there reason to believe that the shared...
-
GraphicsMagick is a totally open project under a permissive (MIT/X11) license. All of the source code, (including the Visual Studio project generation) is available for anyone to access. No one is being prevented from taking action and doing things independently, or contributing. There are a number of GraphicsMagick build recipes which are developed and maintained independently, including targeting Microsoft windows using the Microsoft compiler. Nothing prevents from creating a Docker image as you...
-
Well, the words 'tech savvy' cover a HUGE range. When I wrote those words, I was thinking about a user that is tech savvy enough to download a docker image, get it running, and run the commands necessary to compile the project. Not necessarily a user that could modify the graphics processing engine of the solution successfully. There are tech savvy people that can write small scripts, stage data to data lakes, understand large platforms like Azure, secure their social media accounts properly, and...
-
On Mon, 27 Jun 2022, Pudnik wrote: ...Bob, If you don't have the time nor the skill to update gm properly....give it up to a person who does. This person should have the skill and experience to port the build environment, with all OS dependencies, libs, correct versions, etc, into a container image. Then, this person could publish the container image and link to it via the downloads link on the gm home page, periodically, when the source code changes. All a tech savvy user such as myself would then...
-
On Fri, 24 Jun 2022, swede sjolund wrote: Any plans to distribute the installer package for the 1.3.38 version It almost boggles my mind, but after requesting assistance from the Windows community for well over a year, a volunteer has yet to appear to help with updating the Visual Studio project files to make this more feasable again. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key,...
-
On Wed, 1 Jun 2022, bat wrote: Hi In the delegates.mkg.in file there are strange entries like this... ~~~ command='"@DCRAWDecodeDelegate@" "@BrowseDelegate@ ~~~" This would be the original template file. The file you would edit is 'delegates.mgk'. The configure script searches for programs and does substitutions so that the @FOO@ value becomes the path to the program, or just the generic name of the program if it was not found. The end result is 'delegates.mgk' (e.g. /usr/local/lib/GraphicsMagick-1.4/config/delegates.mgk)/...
-
On Wed, 1 Jun 2022, bat wrote: But with GraphicsMagick it doesn't work... Like this... ~~~ ~ $ gm display -verbose 003.bpg gm display: No decode delegate for this image format (003.bpg). Untitled=>LOGO GIF 654x418+0+0 PseudoClass 128c 8-bit 21.6Ki 0.000u 0m:0.002669s (97.7Mi pixels/s) Make sure that your configuration was loaded appropriately by doing 'gm convert -list delegates' If there is no line output for 'bpg' then something is wrong. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Wed, 1 Jun 2022, bat wrote: I realize there isn't much demand for bpg support, but could GraphicsMagick be told to use bpgdec same as ImageMagick does? I have not heard of this format before. It it is read via an external delegate (as ImageMagick apparently does) then support could be added by editing the text file 'delegates.mgk'. If this works for you, then please send us the tested 'delegates.mgk' additions. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Sat, 28 May 2022, bat wrote: This works OK :-) ~ gm convert foo.avif foo.png Good. It might be useful to have write capability for AVIF in GraphicsMagick too. But (imho) I don't think there is a big demand to write HEIC files. Yes, it is good to have writers. If writing HEIC is supported, then it would need to be enabled via a configure option due to the many patent issues (the responsibility must be on someone other than me). Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Sat, 28 May 2022, bat wrote: With ImageMagick convert -list format it shows:- AVIF rw+ AV1 Image File Format (1.12.0) HEIC rw+ High Efficiency Image Format (1.12.0) HEIF rw+ High Efficiency Image Format (1.12.0) With GraphicsMagick convert -list format it shows:- HEIC P r-- HEIF Image Format (heif v12.0.0) HEIF P r-- HEIF Image Format (heif v12.0.0) No mention of avif with GraphicsMagick. I compiled and installed libaom first. Then when I compiled and installed libheif it picked up libaom. Then...
-
Libjxl made big changes to its APIs, and the new APIs to appear be the ones to use for the future. The contributed code did not use this API but I updated everything to use the newer JxlEncoderFrameSettings interface. The older interfaces are marked as "deprecated". I was not aware that the new APIs had not made it into a release yet. See https://github.com/libjxl/libjxl/blob/main/lib/include/jxl/encode.h There is then a quandary of if one should write lots of code for the now deprecated APIs, or...
-
On Sat, 7 May 2022, Nathan Niu wrote: me@Macbook ~/bin [0|1]> brew install jpeg-xl Running brew update --preinstall... Warning: jpeg-xl 0.6.1 is already installed and up-to-date. To reinstall 0.6.1, run: brew reinstall jpeg-xl I see that this is the "latest" release. For my development I installed libjxl from what was then current sources (couple of months ago) and did not use the 0.6.1 release tag. The library is very much under active development and has added APIs which are not in the "latest"...
-
On Fri, 6 May 2022, Nathan Niu wrote: On macOS (version is 12.3.1, Intel CPU), when I install Octave by brew (brew install octave), the build error below shows: ==> Downloading https://ftp.gnu.org/gnu/octave/octave-7.1.0.tar.xz Already downloaded: /Users/me/Library/Caches/Homebrew/downloads/513342404d0cc161bb823fae8ccdd8e302e2fc359eccb171e95f8c41ef84a239--octave-7.1.0.tar.xz ==> Installing dependencies for octave: graphicsmagick, libaec, hdf5, libogg, flac, libvorbis, opus, libsndfile, portaudio,...
-
GraphicsMagick 1.3.38 is now available
-
This issue is addressed by Mercurial changeset 16689:94f4bcf448ad and the latest development snapshot (GraphicsMagick-1.4.020220326.tar.xz). Thank you for reporting this issue!
-
[bug]Heap buffer overflow when parsing MIFF
-
I see the cause of the problem. Only builds with bzip support are impacted.
-
I am able to reproduce this strange issue.
-
[bug]Heap buffer overflow when parsing MIFF
-
On Wed, 16 Mar 2022, asd wrote: 1.3.36 my centos 7 is going to EOL Package GraphicsMagick-1.3.36-1.el7.x86_64 already installed and latest version Bummer! You can always build GraphicsMagick from source code. As long as your OS provides the necessary development packages and compiler, it should be easy. maybe is time to upgrade to Debian ;) Unless you need CentOS for binary compatibility purposes, Debian is a good choice since it has proven to be well maintained for a great many years. Bob Bob Friesenhahn...
-
Invalid colormap index (index 128 >= 128 colors
-
I am not encountering this issue with current 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 Tue, 15 Mar 2022, asd wrote: https://drive.google.com/file/d/1Ko6k2mfVMD3lFqxxGWdJW-MsCwilGW6g/view?usp=sharing today got another some error on my image proxy What GraphicsMagick version are you using? An issue similar to this was fixed in GraphicsMagick 1.3.37. I have not yet looked at your sample to see if I can reproduce the issue with current software. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/...
-
As some very good news, the JXL writer is now working for me. I am using JXL latest rather than 0.6.1. Can you please test latest GraphicsMagick with 0.6.1 and see if any changes are necessary for it to compile and work with that version? There is certainly more development to make the JXL support all that it should be, but it is passing basic sanity tests now.
-
On Mon, 7 Feb 2022, Stian Giltvedt wrote: @bfriesen: Thank you for clarify! I definitely overlooked the detail that -colorized value should be in percentage. I was a bit overwhelmed of all details in documentation when I fiddled with my script and wrote wrong kind of the range. Now I've changed to percentage and get exact same result in both setup. Interesting way to discover this strange bug even it was wrong kind of the range, by mistake. Thank you for your time, help and amazing work of GraphicsMagick....
-
Apparently animated WebP is "WEBM". Regardless, this is a RIFF structured format which requires significant re-work of the existing WebP reader regardless of if it reads just one frame, or a sequence. So I think this is a major feature request rather than a "bug".
-
Broken -colorize
-
I am marking this as fixed, although the result will be different than either GM build you have using the values you supplied.
-
Mercurial changeset 16659:3207580e44c9 has fixes for this and the fix is in today's development snapshot.
-
To clarify, the expected range of the values provided -colorize are indeed 0-100 (a percentage) so 255 is out of range. But it will make it handle the out of range values by clipping.
-
The clarify, the expected range of the values provided -colorize are indeed 0-100 (a percentage) so 255 is out of range. But it will make it handle the out of range values by clipping.
-
I cropped your original from the PNG file and used that for testing. I did find a bug but also decided that neither of the results are ok. The documentation for -colorize says this: -colorize <value> colorize the image with the pen color Specify the amount of colorization as a percentage. You can apply separate colorization values to the red, green, and blue channels of the image with a colorization value list delimited with slashes (e.g. 0/0/50). The -colorize option may be used in conjunction with...
-
Can you please attach the input JPEG file gzipped or a common archive format which will protect it from modification by SourceForge? The input file might be relevant.
-
Please provide the full output from 'gm -version' for the working and non-working versions. Perhaps the compiler and OpenMP used are different. For example, GCC/GOMP vs Clang/OMP. Regardless, I will investigate. 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
-
JXL is in my build now. The problem is happening in the case for JXL_DEC_NEED_MORE_INPUT. Perhaps it is consuming data too rapidly and losing data so that JxlDecoderSetInput() always returns JXL_DEC_NEED_MORE_INPUT until the data has already run out.
-
There is obviously something (in GM) missing since configure does a lot of happy looking things for JXL but in the end it does not show up in 'gm convert -list formats' and it does not know how to open that format. It is possible that a merge removed changes from the other merge.
-
There is obviously something (in GM) missing since configure does a lot of happy looking things for JXL but in the end it does not show up in 'gm convert -list formats' and it does not know how to open that format.
-
% ./utilities/gm convert logo: crap.jxl % ./utilities/gm convert -debug blob,coder,exception crap.jxl info:- 13:44:15 0:0.000119 0.000u 337180 blob.c/OpenBlob/2731/Blob: Opening blob stream: image 0x5643743bce90, blob 0x5643743bfcf0, mode ReadBinary ... 13:44:15 0:0.000132 0.000u 337180 blob.c/DetachBlob/1275/Blob: Detach (reset) blob: blob 0x5643743bfcf0, ref 1 13:44:15 0:0.000138 0.000u 337180 blob.c/OpenBlob/2919/Blob: I/O buffer set to 16384 bytes 13:44:15 0:0.000141 0.000u 337180 blob.c/OpenBlob/2941/Blob:...
-
So I configured like: ../GM/configure 'CC=gcc-9' 'CXX=g++-9' 'CFLAGS=-O0 -g -g3 -ggdb -gdwarf-2 -Wall -Winline -W -Wformat-security -Wpointer-arith -Wdisabled-optimization -Wmissing-noreturn -Wno-unknown-pragmas -Wdeclaration-after-statement' 'CXXFLAGS=-O0 -g -g3 -ggdb -fno-omit-frame-pointer -Wall -Winline -W -Wextra -Wno-unknown-pragmas' 'LDFLAGS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib' '--with-quantum-depth=16' '--disable-shared' '--enable-static' '--enable-silent-rules' '--disable-openmp'...
-
On Sun, 30 Jan 2022, Alex Hall wrote: Conversely, if I run: gm convert -size 600x480 xc:#f800fcfe 600x480_sRGB_f800fcfe.png I get a nearly transparent image. This is the inverse of what I understand and expect alpha to be. This is very interesting given that internally GraphicsMagick uses inverted alpha so that zero is opaque. The documentation says that the colors are supposed to be in the same form as used by SVG. I doubt that SVG uses inverted alpha. So this does indeed seem like a bug. Bob
-
On Sun, 30 Jan 2022, asd wrote: that will be awesome better than no data returned gm 1.3.36 What is the origin of the GraphicsMagick build you are using? What operating system are you using? 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
-
GraphicsMagick does not currently support animated WebP. In my testing I do get data returned but it is just the first frame from the GIF file.
-
Fixes for JXL and HEIF
-
Regardless, your changes have now been merged.
-
I have yet to see 'make check' succeed for JXL. The failure is always an unexpected EOF on input.
-
I have yet to see 'make check' succeed for JXL. The failure is always an unexpected EOF on input.
-
For purpose of GraphicsMagick, it would be good to add -Wdeclaration-after-statement to the compilation CFLAGS since this will expose certain things which do not work in C'90. In CFLAGS I am using (at least) this: '-Wall -Winline -W -Wformat-security -Wpointer-arith -Wdisabled-optimization -Wmissing-noreturn -Wno-unknown-pragmas -Wdeclaration-after-statement'
-
Under Ubuntu 20.04 I find that if I install libheif-dev ,that this is sufficient for linking. With the configure.ac change to add a dependency on libde265 I find that the library test then fails unless I also install libde265-dev. It seems that without the -dev package, libde265 is not suitable for being used with the linker. If it is implicitly used, then there is not a problem. I will figure out what to do about this since there is also a long term goal to not require libde265 when 'heic' is not...
-
Info about AVIF and Firefox: https://avif.io/blog/tutorials/firefox/
-
Tobias, while libheif may optionally depend on -lde265 (as it does on my Ubuntu 20.04 LTS system), libheif has also added AVIF support, which I am very interested in given that AVIF does not have the HVEC patent issues and AVI seems to be supported by popular web browsers now (at least Chrome and Firefox). You may see that there is already a bit of AVIF logic added in anticipation that libheif will be used to read/write AVIF. Given this, it seems that there is a bit more to do regarding library dependencies....
-
Can not escape $0 in a batch command
-
The issue was found to be a very slightly corrupt input file (one extra appended character). The MIFF reader has been updated to avoid reporting an error in such cases. The escaping of $0 in the batch command was not found to have an issue so I am closing this case now. If it is later found that GraphicsMagick has somehow been responsible for producing the slightly corrupted file, please open an issue related to that.
-
This seems like a fascinating and brilliant solution. Is there still a problem to be solved? Has it been found that GraphicsMagick is somehow writing MIFF files that it is then unable to read (due to an extra appended character)?
-
While executing the script on my machine (removing all the full path components) I did not generate/encounter any MIFFs with an extra character appended. Regardless, I just pushed Mercurial changeset 16645:a45a3d5e77ae, which causes the MIFF reader to return what it has already read if it encounters a non-'i' character rather than an EOF. The first character of a MIFF file (and for a component of a MIFF sequence) should be an 'i' for 'id'. It is still to be determined how this file got an extra character...
-
What is the origin of this bad file? How did it come to be? ImageMagick (as delivered by Ubuntu 20.04) does not like this file either, but it likes all of the other ones. The MIFF format supports a sequence by concatenating MIFF "files". When it gets to the end of reading the last file in a sequence, it expects that the next character read will be an EOF character. However, it appear that a 'n' is read instead, and in fact the last character of the problematic file is an 'n'. The big question is...
-
If you have a MIFF file which is reported to have an invalid header (the apparent actual complaint), please gzip it and attach it to this issue so we can see what is wrong with it.
-
Can not escape $0 in a batch command
-
Andrew, I downloaded your input file and copied your original script (no backslash) to a file. I stripped the path part of the file names so that all of the files are in the same directory. I executed the script as you described. There were no errors reported and the image appeared to render perfectly with the $ symbols as intended. Since it works perfectly for me, I suspect that there is an issue due to font files, or your locale, or perhaps something to do with character encoding (e.g. UTF-8)....
-
It is true that the issue with C++ needs to be addressed. I think that this is also an issue with the HEIF support since it is also linked with the C++ library. There is more than one possible C++ library. For example, clang provides its own C++ library, which may optionally be used. One possible solution is to rename the C files as if they are C++ files and add a bit of extra code so that they interface with the C code ok. This may cause Automake to behave differently (I am not sure) such as to...
-
Your work has been merged. I took opportunity to do a bunch of other edits not necessarily related to your work. Support for this format is disabled by default so that it does not get picked up by accident (may primarily apply to me) while it is still not quite finished. This merge went better in that it did not add an unwanted branch to the GraphicsMagick repository. Apparently it is not necessary to add a branch in order to submit a merge request. It would be good to get the writer working since...
-
Added (basic) jpeg-xl support
-
I spent most of Saturday installing or building/installing prerequisites on my Ubuntu 20.04 LTS system and then doing all of the merging/improvements to integrate JPEG XL support. Unfortunately, I found that the test suite is failing. After some investigation I found that GM reads JPEG XL OK but it appears to write a somewhat truncated/corrupted JPEG XL file (the file is a bit smaller than with cjxl). Testing with cjxl and djxl produced expected results. Since quite a lot has been done already, I...
-
On Fri, 14 Jan 2022, Bob Friesenhahn wrote: On Fri, 14 Jan 2022, Tobias Mark wrote: Well in that case maybe it's better if(or your) close the merge request again? No point leaving it open if you don't wan't to merge it. I only meant that I need to spend some time researching the issue to see what is safe to do. This does not mean that I am not interested in your merge request. I am still not totally sure what is safe to do regarding HVEC coding but thanks to Tobias Mark we now have optional support...
-
Likewise if image drawing/annotation is broken by a $ symbol, that would clearly be a bug.
-
As far as I can see, it should not be necessary to escape $0 because batch mode does not pay attention to things which look like shell variables and it has no special support for $ at all. If this $ symbol is breaking the MIFF format then that would clearly be a bug.
-
I have merged in this Heif reader since I have the heif library on my system and it was less work. I did some re-formatting of the code to assure that it uses the same conventions as the rest of the code. Using SourceForge's procedure adds a new branch, which is really annoying. Even after closing the branch, the branch is still visible.
-
Added minimal heif support
-
GM fails to open multiframe GIF
-
Thanks to Tobias Mark for noticing that GM reads this file ok. In all honesty, since there were already some bug reports pertaining to long/large GIF sequences, I don't think that I downloaded the test file so assure that I could reproduce it for myself. I just downloaded the file from the referenced web site and current GM does indeed read it without problems.
-
On Fri, 14 Jan 2022, Tobias Mark wrote: Well in that case maybe it's better if(or your) close the merge request again? No point leaving it open if you don't wan't to merge it. I only meant that I need to spend some time researching the issue to see what is safe to do. This does not mean that I am not interested in your merge request. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key,...
-
On Thu, 13 Jan 2022, Tobias Mark wrote: @bfriesen Maybe if making this lib explicit opt-in for configure and warning about the possible patent problems this could be taken upstream? The code calling the lib should not be under any Patents so no harm for anyone who does not opt-in? Thanks for the merge request. I am unsure of patent details related to HEIC so I don't know if patents usage restrictions only apply to writers, or to readers and writers, or if there is special dispensation granted. The...
-
On Thu, 13 Jan 2022, Andrew Dryga wrote: @bfriesen I'm not good at languages gm is written in but I can try to take a look at that scripting language if you can point me to a place in the source code :) That would be great. If you can find the point of the logic error, and see how to fix it, that would save a lot of time. The problem is almost certainly in magick/command.c and in the ParseUnixCommandLine() function: while (c != EOF) { switch (c) { case '\'': while((c = fgetc(in)) != '\'') { if (p...
-
It is good that you have isolated this to being specifically related to 'batch' mode. I believe that this mode has its own shell parsing syntax to emulate the parsing by a real Unix shell. It would be interesting to see if using the '-escape windows' mode avoids it. Of course, Windows command shell syntax/parsing is flimsy compared with a Unix shell.
-
On Sun, 26 Dec 2021, Mattias Wadman wrote: No problem and thanks for the fix. On vacation at the moment so no access to the affected file. But can verify in january. In my case if i remember correctly the huge XMP profile didn't look like it contained any meaningful data, looked more like produced by bug in some software etc. I did not do any actual performance testing. I was aware that a performance penalty was added in GraphicsMagick vs the original ImageMagick implementation. It could still be...
-
Slow to read JPEG with big APP1 profile
-
The inefficiency with large JPEG profiles should be solved by Mercurial changeset 16603:ba930c1fc380. Thanks for reminding me of this problem. According to the XMP spec, XMP profiles are supposed to fit in one 64k chunk. GraphicsMagick does not enforce that.
-
Be able to affect libpng user_chunk_malloc_max
-
Mercurial changeset 16601:083c790c4850 provides support for a png:chunk-malloc-max=limit define in order to adjust libpng's chunk size limit.
-
I downloaded the PNG file pertaining to the ImageMagick issue 1301. I see that it has a raw profile which decompresses to 117,048,920 bytes! This is very convincing that it would be wrong to use your patch directly because then it would be very easy to attack using highly-compressed PNG files. The error message produced by libpng is not helpful since it does not indicated its maximum chunk size or the size that the user would need to specify in order to successfully decode a file. It appears that...
-
typemap will only include one "type.mgk" (and nothing else/more).
-
A response to questions asked is needed before any action can be taken due to this bug report.
-
Image attributes not working and not as documented for PerlMagick
-
I discovered that the implementation was setting the fill color to transparent. This is fixed and now doing Get() for "fill" and "stroke" works. Note that colors are returned as comma-delimited values. This work is part of Mercurial changeset 16600:3c58991d3b9b. Thanks for bringing this to our attention, and my apologies that I have not had opportunity to address this until now.
-
The GraphicsMagick CAPTION has no support for gravity at this time. More significantly, the ability to capture the '-gravity Center' request so that it can be used later when CAPTION is invoked to create the image does not exist. Internally this would be done by recording settings in an ImageInfo structure which is then passed in the caption coder when creating the image. A possible way to accomplish this would be to store it as an image attribute (existing 'attributes' list in ImageInfo).
-
convert: warning when using -gravity with -trim
-
After some investigation, I found that the easiest way to address this issue is to reset the gravity to NorthWest in the trim implementation. The fix is provided by Mercurial changeset 16599:cfb1055afd82. Thanks very much for bringing this oddity to our attention.
1 >
Oh no! Some styles failed to load. 😵