Activity for Bob Friesenhahn
-
Bob Friesenhahn modified ticket #396
dpi not retrived (no default value)
-
Not all images have a resolution. Regardless, since more than one person is interested in having defaults reported rather than zero values, I have added Mercurial changeset 16462:70d333d238c5 which fabricates default values if the actual values are zero. It is possible that this decsision will be reversed if I hear that it then breaks someone's workflow.
-
I took a peek at ImageMagick code and see that it is doing this while retrieving the x and y resolution properties: fabs(image->resolution.y) > MagickEpsilon ? image->resolution.y : 72.0) So if the resolution value is impossibly small, it is using a default. I can do something like that. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/pu...
-
On Sat, 6 Feb 2021, Carlos Nobrega wrote: Hi, gm is much faster than imagemagick, but does not correctly return dpi (ResolutionX or Resolution Y) in a file without exif. I also need a lot to continue my project. Is there another alternative? GraphicsMagick assumes a resolution of 72x72 DPI wherever it must assume it. However, the lack of resolution information from a file does not mean that the actual resolution was 72x72 DPI. GraphicsMagick: gm identify -format "%xx%y" 400x400.jpg output: 0x0 and...
-
On Sat, 6 Feb 2021, sourcer42 wrote: My current test show that IMDisplay has several memory leaks due to allocation at memory.c line 242 This is using a special Windows aligned memory allocator (_aligned_malloc()) so your memory leak checker might be giving you a false report. An allocation by _aligned_malloc() must be released using _aligned_free(). I suspect that very little Windows software uses these APIs. If in doubt, comment out the definition of HAVE__ALIGNED_MALLOC so that the normal memory...
-
On Fri, 5 Feb 2021, sourcer42 wrote: After several days of fiddling with the various options, I think I have been able to get the MSVC 2015 single library 64-bit version to compile and link. From the above, I assume that you built a DLL with magick/coders/filters (and maybe more) combined? For now my current 64-bit version will give me what I really need and as 'time permits', I might work on combining the 64 & 32 bit version. The other versions - multi-lib etc would need similar fixes and so it...
-
On Fri, 5 Feb 2021, leslie wrote: but How can I recover the watermark image and verify it? what API should I use? To be honest, I have never used this feature before. I am sure that it pales in comparison to commercial offerings such as Digimarc. The problem is that digital watermark's may be used for different purposes, such as detecting if the image has been processed/altered in some way, or detecting images from a source (e.g. for copyright purposes) even if they have been somewhat modified. Saving...
-
On Tue, 2 Feb 2021, sourcer42 wrote: In the past I have used MSYS and its relatives , but being steeped in MSVC, I find them more of something I can (reluctantly) use if I have to. Same goes for CMake based projects and they too fall into the same category, I'm afraid. Just how feature complete the vcpkg package(s) is/are, I have not sorted out yet, since I had only installed the basic version. It is very likely, I might investigate it a bit more. For me, the important thing is that it supports what...
-
On Tue, 2 Feb 2021, sourcer42 wrote: Back at it a bit more. From other projects I am used to the various versions of MSVC having issues with loading and updating older projects. On the whole, things have gotten a bit better, with fewer hiccups from older project with MSVC 2019. Unfortunately, M$ have changed much in their default expectations and hence all the warnings. I have not yet tracked down the issue with the 64-bit All project and am not sure it is worth the trouble. It can likely be solved...
-
The 'All' project files are delivered in VisualMagick/All. Presumably the All.vcproj.in file becomes All.vcproj after running the configure program. I am not sure what gets substituted in it. In Visual Studio 2008 I was able to use the configuration properties section to add a new 'x64' target for 'All'. After doing an 'apply' and 'save' then it was perfectly happy with 'All'. Previous to that it was unable to show me the properties for All, but it was happy to allow me to build the project starting...
-
On Mon, 1 Feb 2021, sourcer42 wrote: OK, restarted the 64-bit with fresh download of the repo to a separate directory, then run configure to build a 64-bit DLL version. After conversion of the old sln file, MSVC 2019 (up-to-date) complains: "Current solution contains incorrect configuration mappings. It may cause projects to not work correctly. Open the Configuration manager to fix them" Opening the Configuration manager shows the All project locked to Win 32 for all solution and platform configuration...
-
On Mon, 1 Feb 2021, sourcer42 wrote: It does take a lot of time to upgrade from the original VS 7 solution files - what would it take to eliminate or improve on that? :-) We would need to have a way to write modern MS build project files. In the process maybe one could also eliminate some of the warnings. The warnings seem to be due to the project names being different than the actual target names. The actual target names were different because they vary based on debug or release build (as well as...
-
On Mon, 1 Feb 2021, sourcer42 wrote: Just downloaded the latest 1.3.6 code and started to compile for 64-bit libraries. Using MSVC 2019 I get several warnings regarding jbig85.c(904,31): warning C4267: '-=': conversion from 'size_t' to 'unsigned long', possible loss of data others show in gzread.c & gzwrite.c also libtiff\tif_webp.c(169,55): warning C4244: '+=': conversion from 'tmsize_t' to 'int', possible loss of data The above is indeed true. This is third-party code. It seems that plenty of software...
-
On Wed, 6 Jan 2021, Bob Friesenhahn wrote: On Wed, 6 Jan 2021, Philipp Lutz wrote: It seems I can't find any documentation of this 'analyze' module :/ Can you point me do a manual or some how-to? This is what is supposed to happen: gm convert logo: -process analyze= \ -format "%[BrightnessMean],%[BrightnessStddev],%[SaturationMean],%[SaturationStddev]" \ info:- 51952,23294,11367,24518 I did some investigation and learned why the above did not work given the dynamic modules build. The problem is that...
-
Since it appears that use of virustotal.com is free, I will of course be persuing this issue in order to find the cause. Google tells me that packages based on the popular Inno Setup installer that GraphicsMagick uses have had positive results from this claimed virus in the past. Since only one virus scanner of many reports detecting a virus signature, it seems likely to be a false alarm. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick...
-
Where did you download your GraphicsMagick installer from? It is useful to know the origin of a GraphicsMagick installer which may or may not have an actual virus. 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, 22 Jan 2021, Andre Pastusnyn wrote: Could you give a clarification about the detection of viruses by VirusTotal in GraphicsMagick windows versions? SecureAge APEX -> Malicious McAfee-GW-Edition -> BehavesLike.Win32.CSDIMonetize.tc This is not possible since I am not responsible for the anti-virus software from McAfee and not an expert at anti-viral software or viruses in general. I do see many complaints about false positives for this test via a Google search. I suggest providing the content...
-
Are you using a Ghostscript which targets the same 32-bit or 64-bit architecture as the GraphicsMagick build does? For example, a 64-bit GraphicsMagick needs a 64-bit Ghostscript. It may well be something else since I have not tried this newer Ghostscript yet. FYI, there is a 1.3.36 release now, although it does not address anything related to Ghostscript as far as I can recall.
-
Incorrect MediaBox in PDF export
-
Your patch is applied as Mercurial changeset 16445:caa63b6051f5. Thanks for your help!
-
Build fails with MinGW
-
This problem only occurred with 32-bit MinGW. With 64-bit, the configure script was successful. Regardless, this issue was already fixed shortly after the 1.3.36 release.
-
n019003l.pfb error on gm convert -text operation
-
Guidance was provided.
-
On Sun, 10 Jan 2021, Aleksei wrote: Hi, I'm trying to place a string on the image, starting with example from man page: $ gm convert woodpecker.png -draw 'text 100,100 "String01"' temp1.png gm convert: Unable to read font (/usr/share/fonts/Type1/n019003l.pfb) [No such file or directory]. This could happen if you don't have the URL font package installed. You did not say what operating system you are using but if you take a look at http://www.graphicsmagick.org/INSTALL-unix.html and search for "--with-gs-font-dir"...
-
As it turns out, there were fixes to configure.ac which were made shortly after the 1.3.36 release and which should solve this problem: changeset: 16438:49c33f0323e1 user: Bob Friesenhahn bfriesen@GraphicsMagick.org date: Fri Jan 01 13:52:34 2021 -0600 files: ChangeLog configure configure.ac www/Changelog.html description: Skip library symbol tests for gdi32 since they fail for i686 MSYS2/Cygwin changeset: 16430:0a252b21e156 user: Bob Friesenhahn bfriesen@GraphicsMagick.org date: Tue Dec 29 17:32:31...
-
I can live without the GDI32 support, so not meeting the requirements is ok for me. But in that case, the compilation of all modules/coders/etc. which depend on lib gdi32 should be disabled. Unfortunately I'm not skilled enough to fix the autotools configuration for that. I suggest trying --without-gdi32. Please let me know if it works. Which "MinGW" are you using? I only tested with MinGW-w64 under MSYS2. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Wed, 6 Jan 2021, Philipp Lutz wrote: You're completely right! Now I also completely understood this command too :D The idea seems pretty clever. I didn't write those lines but just volunteered to make those lines compatible with GraphicsMagick too. I guess with your help I'll be able to implement a path for GraphicsMagick! I appreciate that. Give that it seems that I broke something to do with the module loading pertaining to filters (might work in the version you are using) it is unfortunate...
-
It does look like there is some bug with the analyze filter and the "modules" build. Another way to get the same info (without using the analyze filter) is this: gm convert logo: -threshold '99%' -verbose info:- | grep 'Mean:' and then a line like Mean: 47820.76 (0.7297) will come out. You would need to parse out the value you want to use. The (0.7297) value is normalized to a range of 0.0 to 1.0. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick...
-
On Wed, 6 Jan 2021, Philipp Lutz wrote: It seems I can't find any documentation of this 'analyze' module :/ Can you point me do a manual or some how-to? This is what is supposed to happen: gm convert logo: -process analyze= \ -format "%[BrightnessMean],%[BrightnessStddev],%[SaturationMean],%[SaturationStddev]" \ info:- 51952,23294,11367,24518 so one could do gm convert logo: -threshold '99%' -process analyze= \ -format "%[BrightnessMean]" info:- 47821 Just change "logo:" to "$ImageFile". In this...
-
On Wed, 6 Jan 2021, Philipp Lutz wrote: Hi Bob, wow, thanks for your quick reply and the direction you pointed me. I was also totally confused why such an awfully complex command was used to just retrieve the mean luminosity of an image ;) This 'analyze' module sounds like it can do what we want to achieve much easier. Will have a look in the meantime. What the command appears to be doing is to try to find the percentage of pixels which are over 99% intensity level. I will remind myself of the analyze...
-
On Wed, 6 Jan 2021, Philipp Lutz wrote: Hi, I'm currently re-working a script used by the RAW converter software darktable which is only compatible with ImageMagick. Because the C API of darktable is already compatible with ImageMagick and GraphicsMagick I want to also make the scripts compatible with both frameworks, hence finding GraphicsMagick equivalent command to the following ImageMagick command: convert "$ImageFile" -define registry:temporary-path=/tmp -channel RGB -threshold 99% -separate...
-
Import of raw RGB image data fails since 1.3.27
-
This problem is fixed by Mercurial changeset 16435:19d52281bfdb. Test suite coverage has been added so it will not happen again. Thank you very much for reporting this issue!
-
Import of raw RGB image data fails since 1.3.27
-
GraphicsMagick 1.3.36 is now available
-
On Thu, 24 Dec 2020, Dan Rossiter wrote: I've been attempting to build/deploy GM in such a way that Graphviz files are able to be processed, but so far no luck. The documentation ( http://www.graphicsmagick.org/README.html#add-on-libraries-programs) suggests this is supported, but doesn't provide any indication what exactly is necessary from Graphviz in order for this to work. If the extension on the input file is '.dot' and the 'dot' program is installed, then it should be automatically rendered...
-
Slow to convert HP PCL printer data
-
This issue is fixed by Mercurial changeset 16395:4fc18176a211. PCL files are no longer sent to the HPGL delegate.
-
I am testing under Ubuntu 18 and when using ImageMagick 6.9.7-4 I see that it tries to use a 'pcl6' external program, which I don't have, and don't know how to install. If it is doing something similar in your environment (and there is no 'pcl6' external program) then that would explain why ImageMagick quits immediately.
-
When comparing output from Inkscape and using current development GM, I see a much better match between GM output and Inkscape output (although there are still many serious defects). This causes me to think that the version of GM used may be rather old. What version of GraphicsMagick was used to produce your sample PNG file?
-
ping(blob) reports JPG and JNX files as monochrome BilevelType
-
I see that the GetImageType() implementation is based on GetImageCharacteristics() and if that function does not have an actual read image to rummage through, it only has the boolean properties: colorspace, is_grayscale, is_monochrome, matte, storage_class to use as input. Out of these, I expect that storage_class should be reliably set by 'ping', and the others may or may not get set. It may be that JPEG (and JNX which is based on JPEG) may be implemented differently than most.
-
gm convert failure from .pgm to .eps
-
This problem is fixed by Mercurial changeset 16360:e34c82fe2b99. Thanks for reporting the bug!
-
It seems that the problem is that the image associated with the broken output is determined to be bi-level yet it also has a 256 color colormap. The EPS encoder is mis-behaving in that case.
-
On Fri, 20 Nov 2020, Dave Brondsema wrote: Hello, Thanks for reporting this. I see this issue is affecting some mercurial repositories over http. I have run hg verify on the server to confirm this repository is not corrupted or anything. If you are able to use an ssh:// connection instead of https:// I see that is working fine, as a short-term workaround. It is normal for free/open source code repositories to be free/open so that anyone can access the source files. Does SourceForge provide a way...
-
On Fri, 20 Nov 2020, Dave Brondsema wrote: Hello, Thanks for reporting this. I see this issue is affecting some mercurial repositories over http. I have run hg verify on the server to confirm this repository is not corrupted or anything. If you are able to use an ssh:// connection instead of https:// I see that is working fine, as a short-term workaround. Unfortunately, Google's oss-fuzz can not use an ssh:// connection because everything they use is exposed to the public. So if a ssh private key...
-
Clone of GraphicsMagick Mercurial repository fails immediately
-
gm convert failure from .pgm to .eps
-
It seems that the problem is that the image associated with the broken output is determined internally to be bi-level yet it also has a 256 color colormap. The EPS encoder is mis-behaving in that case. It is likely that the issue is actually in the ASCII PGM reader which may be producing a nonsensical internal representation which confuses the EPS encoder. If I do gm convert structure_bitmap2.pgm -type truecolor -type bilevel crap.eps then I get a valid EPS file.
-
On Wed, 23 Sep 2020, bigjimmyd wrote: Hi Bob, Did you pick up on me wanting to change the aspect ratio in resize? Not really. :-) You can use '-resize 720x540!' (adding an exclamation mark) to force the aspect ratio to change during the resize. Otherwise it will do a best-fit without changing the aspect ratio. If you wanted some sort of border added instead of changing the aspect ratio, then that would take a different command. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
MagickSetSamplingFactors() API mismatch - comma separated values instead of 1x1
-
This problem is fixed by Mercurial changeset 16339:7a86c56bc6aa. Thanks very much for reporting it.
-
On Mon, 14 Sep 2020, Roy C wrote: Hello, I am attempting to use graphicsmagick as part of a script to resize a large number of images, while maintaining as much of the original image quality as possible. Which this utility can do (thank you!). However, my question is as follows: Is there a way to have gm skip files it has modified in the past? There is not an existing way for gm to do that. In order for this to be possible, gm would need to add something to the file to record that it has been processed....
-
On Sun, 13 Sep 2020, bigjimmyd wrote: Sorry, I must have been editing previous post as you replied. Still searching subject: Is the default output, 32bit uncompressed? The default output is to use similar settings as the input files. 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, 11 Sep 2020, bigjimmyd wrote: Hi Bob, All my work will be in tiff sequence. You have covered everything I would be likely to need. I have a question: Would saving over image be faster, because the app would not need to re-write the complete file? No. It is unlikely to be faster. In fact, mogrify always writes its output to a "new" file even though the original file exists. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,...
-
On Fri, 11 Sep 2020, bigjimmyd wrote: I want to reduce the height of 10,000 tiff images in sequence using Lanczos resample. Created folder C/a/a00001.tif Folder contains tiff images a00001.tif to a10000.tif The tiffs original dimensions are 720x576. Required size is 720x540. Am I right in understanding? Open folder in full screen and use the code below in Command Window? gm mogrify -size 720x540 *.tif -resize 720x540 It is not normally necessary to specify the input size. It is useful with JPEG files...
-
MagickTrimImage with extreme fuzz can produce image with negative width
-
This problem has been fixed using the solution suggested by Troy Patteson. The fix is provided by Mercurial changeset 16336:1a4bc46dca46. Thanks for the report!
-
On Fri, 21 Aug 2020, Mattias Wadman wrote: I've run into a JPEG file that decodes quite slowly and the source of the slowness seems to be that the JPEG has a APP1 profile divied into 2624 parts. I guess it's using extended XMP? What version of GraphicsMagick are you using? If you can do gm convert -debug coder infile.jpg null: and capture the log output , then that may be helpful. Also, the output of gm identify -verbose infile.jpg would be helpful. Unfortently I can't share the image because of...
-
On Mon, 10 Aug 2020, Graham Leggett wrote: The MagickSetSamplingFactors() function however accepts a list if doubles, which are then converted into comma separated values, like this: 0,0,0,0 Either I'm going mad or this makes no sense. Googling for MagickSetSamplingFactors doesn't seem to show any code that uses this API, so it could be people have tried to use it, seen it doesn't work, and ignored it. Is this a bug, or am I reading the code wrong? This MagickSetSamplingFactors() implementation was...
-
On Wed, 5 Aug 2020, Greg Traub wrote: Testing with the +matte option did not remove or change the artifacts. I think the reason you're not seeing it in your tests is because your command isn't converting it to .jpg . My process always outputs JPEG. If I used the command you gave above it kept the image PNG and didn't produce the artifacts. Is there perhaps another option I should employ if converting from PNG to JPEG? Removing the alpha channel makes sense but didn't produce any changes in artifacts....
-
On Tue, 4 Aug 2020, Greg Traub wrote: I'm attaching a zip file of the original image and convert command that I'm testing in both GraphicsMagick and ImageMagick . The command I've been using is: convert original.png -geometry '3360x3360^' -gravity Center -extent '3360x3360' -quality 100 -units PixelsPerInch -density 300x300 output.jpg Your original.png includes an alpha (transparency) channel, even though you can't really see it. If you add the +matte option to remove the alpha channel similar to...
-
add resize, extent(Geometry) & extent(Geometry, Color) to Magick++
-
add resize, extent(Geometry) & extent(Geometry, Color) to Magick++
-
add more operations
-
add pdf-stop-on-error option to pass -dPDFSTOPONERROR to gs
-
add pdf-stop-on-error option to pass -dPDFSTOPONERROR to gs
-
add pdf-stop-on-error option to pass -dPDFSTOPONERROR to gs
-
add pdf-stop-on-error option to pass -dPDFSTOPONERROR to gs
-
add pdf-stop-on-error option to pass -dPDFSTOPONERROR to gs
-
It seems that these changes may no longer be needed. Although it came later (sorry about that!), changes were submitted by Jan Spitalnik and incorporated on 2017-11-11 to support reading/writing EXIF, ICC, and possibly XMP. Is there something missing in the current functionality?
-
Thanks for noticing this and submitting a fix.
-
Some duplicate "verbose" should be "version"
-
I ended up manually 'merging' this changeset because using the automated pull and merge proceedure introduced a new 'matte' branch into the GraphicsMagick repository. The implementation was substantially simplified by avoiding adding a new public function. Also, I made sure that the opacity channel is initialized to opaque values if it was not enabled before. Please check to make sure that I have not introduced a problem.
-
Make matte available
-
Configure: add --with(out)-compressed-files option
-
On Tue, 14 Jul 2020, Greg Traub wrote: Hi I'm just wondering what number of colors the value for the '-colors' color reduction feature represents? When I use a number like 64 I get no perceptual change in the image but I assume that doesn't mean I reduced it to 64 colors? Also, why does this significantly increase the file size? It is supposed to reduce the number of image colors to no more than 64-colors by using a palette (colormap) and then the image pixels are references (offsets) into this palette....
-
On Wed, 17 Jun 2020, Игорь Гончаров wrote: I compiled GraphicsMagick-1.3.35-windows-source successfully by MS visial studio 2019 Than I tried to compile PerlMagic and the result was negative. Detailed log in atach. Some details heree too. CORE_RL_magick.lib ia absent difinitiones of magick_int64_t, magick_uint16_t, magick_int16_t, magick_uint32_t, magick_int32_t are absant in Magic.c but they are in attribute.c There is only magick.c script in Makefile The last time I built PerlMagick for Windows...
-
On Mon, 15 Jun 2020, KMDay wrote: gcc and clang seem to still have it(but deprecated), while VS has removed the definition. This means that including headers like Magick++.h which transitively get you Drawable.h and STL.h will cause compilation errors. Is there a recommended work around? There is not yet a recommended work around since this is the first time I have heard of it. I see that unary_function was announced to be deprecated in the future by the C++'11 specification. I have not been following...
-
On Mon, 15 Jun 2020, Greg Traub wrote: While debugging I did a lot of reading on scaling filters thinking the blockiness I was seeing at high zoom level was a result of how some filters are better for scaling up and others for scaling down. This leads me to one more question :) If my objective is to get the highest quality JPEG out of an input JPEG file, is one scaling operator or combination of operators better over another with respect to 'geometry', 'resize', 'scale' and 'resample' operators?...
-
Greg, As a reminder, you are using software from 2018. It is 2020 already. Before reporting bugs to an upstream maintainer, you might want to consider if the bug should go to the operating system distribution maintainers (e.g. Debian), or the upstream maintainer (e.g. me). Usually upstream maintainers focus entirely on the latest code. Only a limited number of projects do maintain older versions. On the flip-side, sometimes operating system distribution maintainers can fix issues using a patch or...
-
On Sat, 13 Jun 2020, Greg Traub wrote: A few more question, the image looks great but not the exact same as the ImageMagick version. I'm seeing more solid grey in areas that are speckled white grey using my method for viewing artifacts in PS. I also tried a few different filters without much change. Can I expect that given the same input image (I realize one tool might need settings configured that the other doesn't), should I be able to get the exact same output from both GraphicsMagick and ImageMagick...
-
Greg, I do not know how the Node GM library functions. What I do know is that with the current GraphicsMagick release (1.3.35) executing on two totally different operating systems, I am not seeing the issue here. I found that the command: gm convert output.png -operator gray Threshold-White-Negate '99.78%' examine.png worked well to expose the blocky artifacts that you are finding in your output files which are written by "GraphicMagick". This command converts extremely bright pixels to black pixels....
-
Greg, I have never heard of such a problem before. I have not yet found a ready-made algorithm which shows me an image of noise in the lower bit or two as your algorithm supposedly does. I will see if I can invent one. Since JPEG has been involved, it is possible that the JPEG compression is influencing the results. Have you tried a different filter such as Mitchell or Sinc to see if using a different filter makes a difference? Have you tried a modern GraphicsMagick and run the equivalent command...
-
Greg, A major factor is that the JPEG image has attached profiles such as an ICC color profile. The libpng I am using says this while writing the PNG: "profile matches sRGB but writing iCCP instead" However, I see that the original profiles are all still in the output file. I suggest executing the command with the -strip option and see if Photoshop still shows such a defective-looking image. The strange results may be due to processing within Photoshop. For example: gm convert original.jpg -geometry...
-
Greg, Please also include the original JPEG wrapped up in a zip file to protect it from SourceForge. Thanks, 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
-
What versions of ImageMagick and GraphicsMagick are you using? What operating system are you using? Please post the output of 'gm -version' so I can see the options used while building. 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 Sat, 30 May 2020, Johannes Linkels wrote: Hello, I am trying to build TclMagick on Debian Jessie. Kernel: 3.16.0-4-amd64 The error is below: ~~~ make[3]: Entering directory '/home/jlinkels/src/GraphicsMagick-1.3.35/TclMagick/generic' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/jlinkels/src/GraphicsMagick-1.3.35/TclMagick/debian/tclmagick/usr/lib/TclMagick0.46' /bin/bash ../libtool --mode=install /bin/bash ./config/install-sh -c libttkcommon.la libTclMagick.la libTkMagick.la...
-
On Tue, 26 May 2020, 0nobody0 wrote: no problem. i'm not sure exactly what's going wrong but i think it has to do with how their web application is calling gmagick? "Failure is due to the gmagick setResourceLimit() API function throwing an exception in all cases." https://collectiveaccess.atlassian.net/browse/PROV-2723 https://collectiveaccess.org/support/index.php?p=/discussion/comment/321837/#Comment_321837 That is interesting. In the latest release (1.3.35) I added this fix: Fix broken definition...
-
On Tue, 26 May 2020, 0nobody0 wrote: entered directory, switched to the 1.3.31 source, configured with the --enable-shared option, and installed: Are you able to share why the 1.3.31 version was required? Does 'gmagick' have a problem with the latest release? 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, 26 May 2020, 0nobody0 wrote: hello, trying to use the older, distro unsupported (running Centos 8), 1.3.31 version of graphicsmagick (gm) to compile the gmagick pecl extension. newer versions of gm cause an issue with a program i am testing. Do you man newer versions of gm as provided by CentOS? have been able to compile and install gm 1.3.31 from the mercurial repo. to compile the pecl extension it looks like you also need what is normally packaged in the GraphicsMagick-devel rpm (or libgraphicsmagick1-dev...
-
dpx:swap-samples not functioning in 1.3.35?
-
The dpx:swap-samples define has always supported 10-bit DPX only and addresses a specific concern with 10-bit DPX. The documentation addresses this topic. A workable solution has been provided so I am closing this issue.
-
While it does not address your concern with 12-bit samples, I have added dpx:swap-samples-read and dpx:swap-samples-write define support to address the problem that the effect may be null if dpx:swap-samples is used in processing with a command like 'mogrify' which does both read and write.
-
On Tue, 21 Apr 2020, Garrett wrote: Brilliant, hadn't thought about using the recolor command to accomplish the same thing; it does indeed work with mogrify on 12-bit DPX's, so I'm in business. As far as the swap-sample modifier, it seems to be restricted to bit depth and not packing method. It worked with 10-bit DPX's in both packed and filled (A-style) packing, but would not work with 12-bit DPX's in either packing method. I see. I did not conceive that there was also an ordering issue with 12/16-bits....
-
On Tue, 21 Apr 2020, Garrett wrote: Yes, using the convert command instead of mogrify gives the expected result on a 10-bit DPX. It does not work on a 12-bit DPX, however, which is what I actually have an issue with; is there a reason this option is limited to 10-bit DPX's? Actualy, yes. It is limited to packed sample types since sometimes there was a difference in interpretation as to sample order in the packed pixle. Just to clarify: when you mention adding explicit options on read or write only,...
-
On Tue, 21 Apr 2020, Garrett wrote: New user to GM, so apoligizes if this is user error. I have a series of DPX images that have swapped Red and Blue channels (hardware recorded), so I was attempting to use GM to flip the channels. However, the "swap samples" define doesn't appear to be working. My command line is this: gm mogrify -define dpx:swap-samples=true -output-directory ../gmconvert *.dpx I've also tried setting it to false, but same result. The issue is with 12-bit DPX's, but I get the same...
-
On Wed, 15 Apr 2020, dancx wrote: What should I do? can you try to get a solution for the A4 format and this closed endstream? Dancx, at the moment I am being selfish and focusing on my own survival (and of my family) given the considerable impact of the on-going pandemic, and a recent equipment failure that I need to attend to before it becomes significant. Priorities will be to assure that GraphicsMagick has a good chance of survival, to get the next GraphicsMagick release out, and to addend to...
Oh no! Some styles failed to load. 😵
Please try reloading this page