Legacy ImageMagick Discussions Archive

See https://imagemagick.org/script/architec ... tera-pixel.

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

See https://imagemagick.org/script/architecture.php. Its likely you ran out of heap memory so the image pixels are pushed to disk. You can verify by adding -debug cache to your command-line. The debugging output tells you where the cache resides (e.g. memory, disk, etc.). On our 32GB system, we ...

Done.

It appears a dependency is missing, libgomp. Mod the Cmake configuration files to find libgomp and add it to the linker statement or disable OpenMP or build ImageMagick with autoconf/automake (e.g. run the `configure` script then `make`).

Ok, we can reproduce the problem now. We should be able to fix the problem and export a new release by late this weekend.

The min version of libwebpmux is 0.4.4. Any chance you can upgrade your library and let us know if that fixes the problem?

Try this command on the command-line: convert logo: -thumbnail 100x100 logo.webp Can you read/view logo.webp? Hope so, that command works fine for us and produces a valid image in the WebP image format. If it fails, post a link to the image so we can inspect it and also post the results of this ...

This statement does not grok: convert xc: -format "%[fx:($p3x)cos(pi*$angle/180)-($p3y+$len)sin(pi*$angle/180)+$x1]" info: instead it likely should be convert xc: -format "%[fx:($p3x)*cos(pi*$angle/180)-($p3y+$len)*sin(pi*$angle/180)+$x1]" info: Its possible older versions of the parser assumed an ...

The Windows configure script auto-generates magick-baseconfig.h. It includes a define for ssize_t as follows:

Sure, you can clone the image, operate on it and composite the results back to the source image. This is exactly what IMv6 does, -region was simply a convenience to do all the operations with one -region option.

See https://imagemagick.org/script/porting.php: -region: This option sets a write mask for the region you define. In IMv6, a separate image was cloned instead, operated on, and the results were composited to the source image. In addition, the draw transformations are relative to the upper left ...

Let us know your work-around. IMv7 behavior differs from IMv6 per https://imagemagick.org/script/porting.php but in some cases, it could be a bug.

Thanks for the analysis. We reverted the text offset patch but kept the DstOut composition patch. You will bet proper text edges now.

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.