-font-dir) has been added to specify the directory
where the OpenType fonts reside, rather than leaving this to the
configure script to maybe find it.
A new template configuration file (config/type-urw-base35-otf.mgk.in)
has been added which is tailored to the OpenType fonts.
Bob
--
Bob
libraries it uses (e.g. libpng) do appear to use time_t in interface
definitions.
Regardless, it is necessary to assure that all libraries are built
with a consistent time_t definition if there is any case of time_t
appearing in an explicit/implicit interface definition.
Bob
--
Bob Friesenhahn
ope to get this fixed, or be
informed of a work-around.
Bob
--
Bob Friesenhahn
bfrie...@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
Illumos
(Solaris derivative) and it was able to run tens of thousands of loops
without any memory leak or other anomaly.
In this case GCC 7.5.0 was used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
On Sun, 4 Jun 2023, László Böszörményi wrote:
Hi,
On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
wrote:
I am definitely able to confirm that memory consumption builds due to
invoking GetImageDepth() via a POSIX thread. The rate that it builds
is image sensitive since some images cause
(including
"heap") building at once.
Running under valgrind reports no leaks.
I changed the sole memory allocation used in GetImageDepth() to use
the resource-limited memory allocator and it did not report any leaks.
My own testing is under Ubuntu 20.04 using GCC 10.
Bob
--
Bob Friesen
down a little bit, but the overall average trends
up.
Looking at /proc/PID/smaps, the size attributed to 'heap' seems
stable.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.o
ot;thread arena"s that you are talking
about likely do.
For allocations which specifically use a memory allocator, I have had
some good luck using Glibc's mtrace.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick M
nfig. I am not sure
what the impact of doing so (e.g. run-time performance) is. I have
not studied it at all.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://w
s the path has been overridden, or the fonts-urw-base35 package
was not installed when the configure script was executed, or there is
a bug.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagic
On Mon, 5 Sep 2022, László Böszörményi wrote:
On Mon, Sep 5, 2022 at 4:09 PM Bob Friesenhahn
wrote:
On Sun, 4 Sep 2022, Paul Gevers wrote:
gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0:
undefined symbol: _ZN6Magick5Image12colorMapSizeEv
This issue is caused by
: _ZN6Magick5Image12colorMapSizeEv
This issue is caused by Mercurial changeset 16712:acb5f7fa99cf:
"colorMapSize() method for returning the number of colormap entries
should be a const method."
Apparently this change impacts the ABI.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.t
On Thu, 4 Aug 2022, Bob Friesenhahn wrote:
Testing with ImageMagick 6.9.12-38 on an Illumos system shows the image the
other way around with the bright pink cone laying on what might be a gray
floor. Due to the nature of the image, it is difficult to tell what the
right way up is.
It
do not display the
same output!
Bob
--
Bob Friesenhahn
bfrie...@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, 4 Aug 2022, Bob Friesenhahn wrote:
On Thu, 4 Aug 2022, László Böszörményi (GCS) wrote:
I see that a bit of code in 'tga.c' dealing with image orientation was
commented out because the compiler warned that it produced an invalid
result. That was unfortunately not attended to
]? I don't have time to compile
and check it ATM, but might package it tomorrow if it's a proper fix.
No it is not fixed yet. I fixed a different bug, which caused some
sample files to not be read at all.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystem
aling with image orientation was
commented out because the compiler warned that it produced an invalid
result. That was unfortunately not attended to.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintaine
efficiency if there are many
tiny chunks.
The purpose of 'ping' mode is to avoid expensive operations while
retrieving basic properties. In this particular case, the harm would
already have been done even in 'ping' mode so returning the profiles
does not in
On Fri, 25 Feb 2022, Bob Friesenhahn wrote:
There is dependency on the JPEG library so some change in the JPEG library
could impact code which works "fine" on some other system.
I am using Ubuntu 20.04 LTS and the JPEG that comes with that OS.
I made a mis-statement. For this
On Fri, 25 Feb 2022, László Böszörményi (GCS) wrote:
On Fri, Feb 25, 2022 at 4:35 PM Bob Friesenhahn
wrote:
On Fri, 25 Feb 2022, László Böszörményi (GCS) wrote:
Wild guess only, as I'm away from home right now. But that image can
be exif.jpg [1] or any other from the 'fixtures'
Capture Type: 0
Image UniqueID: A16LSIA00VM A16LSIL02SM\012
Profile-XMP: 4102 bytes
Tainted: False
Elapsed Time: 0m:0.000187s
Pixels Per Second: 20.6Mi
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
.
What is the minimum that I need to do to reproduce the issue in
GraphicsMagick?
Is the specific JPEG file which caused the issue available?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
sr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec
--pattern ./spec/\*\*/\*_spec.rb --format documentation failed
mv ./.gem2deb.lib lib
autopkgtest [10:17:01]: test gem2deb-test-runner
--
Bob Friesenhahn
bfrie...@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
http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/28f8bacd4bbf
Please adjust the affected versions in the BTS as needed.
Regards,
Salvatore
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick
would
not have been invoked before.
There is no proper fix other than to make sure that InitializeMagick()
has been invoked before any other API elments are used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintaine
ode is used:
Magick::InitializeMagick(nullptr);
MagickLib::SetMagickResourceLimit(MagickLib::MemoryResource,
10);
MagickLib::SetMagickResourceLimit(MagickLib::WidthResource, 2048);
MagickLib::SetMagickResourceLimit(MagickLib::HeightResource, 2048);
and this is diving int
re is
involved.
Bob
--
Bob Friesenhahn
bfrie...@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
This issue (and some similar issues in the dib.c code) is addressed by
Mercurial changeset 15880:c38fc0e3e465.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http
On Sun, 3 Feb 2019, László Böszörményi (GCS) wrote:
Hi Bob,
On Sun, Jan 6, 2019 at 12:11 AM Bob Friesenhahn
wrote:
On Sat, 5 Jan 2019, Salvatore Bonaccorso wrote:
Did you found time for further investigation of the report from the
SuSE maintainer? Is the original fix as per
http
On Sat, 5 Jan 2019, Salvatore Bonaccorso wrote:
Hi Bob,
On Fri, Dec 21, 2018 at 07:56:24AM -0600, Bob Friesenhahn wrote:
On Fri, 21 Dec 2018, Debian Bug Tracking System wrote:
Your message dated Fri, 21 Dec 2018 01:49:12 +
with message-id
and subject line Bug#916719: fixed in
.
It has been suggested to me by the Suse Linux maintainer that the fix
I submitted for CVE-2018-20185 may be less than adequate. However, I
will be away for 1-1/2 weeks and will not have time to investigate.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org
This bug is fixed by GraphicsMagick Mercurial changeset
15811:1950b22122df.
Sorry for introducing a problem.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
introduced by changeset 1330 "Use
a lazy-loader for static modules".
Regardless, I plan to have an upstream fix for this tomorrow.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
s as to if GraphicsMagick's compare is similar
enough to satisfy common usages.
Just for the record, the 'stream' binary also seems to be missing in GM.
Yes, and there is no plan to implement such a thing.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us,
to include 'compare' would this
satisfy your expectations?
That said, installing commands with generic names like 'convert' and
'compare' has always seemed problematic to me since it could conflict
with other software.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx
On Sat, 28 Oct 2017, Salvatore Bonaccorso wrote:
While testing I was as well not able to reach the NULL pointer
dereference but made the same observation as Bob Friesenhahn, that
graphicsmagick spends a lot of time convertingthe image crating a huge
temporary file, in my case reaching no space
_t) (i) == ((magick_int64_t) (span)-1)))
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Sat, 14 Oct 2017, Salvatore Bonaccorso wrote:
Does this helps?
Yes. I am able to reproduce the problem and see the root cause of it.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
copy of 'POC1' so I can reproduce the issue?
I see that 'montage' is involved. This could be factor since it is
less well tested than some other sub-commands.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
On Sun, 9 Jul 2017, László Böszörményi wrote:
On Sun, Jul 9, 2017 at 4:32 PM, László Böszörményi (GCS)
wrote:
On Sun, Jul 9, 2017 at 3:42 PM, Bob Friesenhahn
wrote:
On Sun, 9 Jul 2017, László Böszörményi wrote:
As far as I am aware, I do not have any email from you about this. While
there
0 are
believed to solve the assertion problem, as well as solve a memory
leak problem in the error path. The test suite is completely passing.
hg diff -r 15059 -r 15066 coders/png.c
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maint
enough. All related changesets to
mat.c since the above one should be taken into account. I got this
comment as reply to filling this bugreport directly from Bob
Friesenhahn (upstream).
I've found seven commits (after releasing 1.3.25), but I think the
first may not be relevant to the security
ifies to use 'Negate' for this purpose.
This is not a bug.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Mon, 5 Dec 2016, Salvatore Bonaccorso wrote:
Hi Chris, hi Bob,
On Mon, Dec 05, 2016 at 05:26:23PM +0100, Chris Lamb wrote:
[Please retain 847...@bugs.debian.org in CC]
Bob Friesenhahn wrote:
Is this CVE fixed upstream? I am not aware of this number.
I do not know, sorry.
The CVE
r and reset age.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Fri, 16 Sep 2016, László Böszörményi wrote:
On Fri, Sep 16, 2016 at 11:56 AM, Niko Tyni wrote:
On Tue, Sep 13, 2016 at 10:48:42PM -0500, Bob Friesenhahn wrote:
It may be necessary to prove where the problem is occuring by manually
overwriting updated files in the magick directory with
ay be necessary to prove where the problem is occuring by manually
overwriting updated files in the magick directory with those from the
previous working version until the problem goes away (assuming that it
does).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
ps magick/utility.c would be a good starting point.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Mon, 8 Aug 2016, Paul Gevers wrote:
Hi Bob,
On 07-08-16 15:47, Bob Friesenhahn wrote:
The code in GraphicsMagick Mercurial is working with this file.
I don't know what Mercurial is, but I assume it is an upstream version.
For me, I have 1.3.24-2 and/or 1.3.24-2+b1 installed fo
working with this file.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Mon, 25 Jul 2016, László Böszörményi (GCS) wrote:
On Sun, Jul 24, 2016 at 3:16 PM, Paul Gevers wrote:
On Sun, 3 Jul 2016 13:39:40 -0500 (CDT) Bob Friesenhahn
wrote:
While the SVG rendering properties are not improved, this error is
fixed by GraphicsMagick Mercurial changeset 14869
release a 1.3.25 which primarily fixes parsing issues introduced with
1.3.24 as well as fixes heap/stack overflow/overrun issues in the
rendering code.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintaine
.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ch is now being
reported. I had already noticed this issue just prior to the most
recent release but did not realize that it was changed behavior.
I opened GraphicsMagick bug 392
(https://sourceforge.net/p/graphicsmagick/bugs/392/) to track this
problem.
Bob
--
Bob Friesenhahn
bfrie...@simple.dal
s might be useful, and particularly to
lessen the overall development burden of making the utilities secure.
Please let us know if other software does have a dependency on
particular utilities which are being removed.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems
and
more modern than Jasper. There is no panacea.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
ronment with an argument like
'4MP'.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
GraphicsMagick bug 322 has been opened at SourceForge to track this
issue.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Tue, 22 Sep 2015, László Böszörményi wrote:
On Tue, Sep 22, 2015 at 8:27 PM, Bob Friesenhahn
wrote:
If there are two packages with different quantum depth, then they should be
able to co-exist without conflict. Likewise, the existing package should be
able to co-exist with new packages
library rather than the old one.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Mon, 10 Aug 2015, László Böszörményi wrote:
On Mon, Aug 10, 2015 at 8:27 PM, Bob Friesenhahn
wrote:
On Mon, 10 Aug 2015, Jakub Wilk wrote:
Perhaps this issue is due to g++ defaulting to a newer version of the C++
standard and thus it requires a new C++ ABI?
I don't think so. I
the linker
did find the library but not the method.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
C++ ABI?
If this is the case, then requesting an older C++ standard may allow
linking with the previous libgraphicsmagick++1-dev.
Existing apps (not-recompiled) should still be able to use the
previous library.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simples
UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages graphicsmagick-imagemagick-compat depends on:
ii graphicsmagick 1.3.20-3+b1
ii html2ps 1.0b7-1
graphicsmagick-imagemagick-compat recommends no packages.
gra
, you
need to be careful that the colormap fits the specified bits/sample.
Sorry to hear that the SourceForge web interface is unusable.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
caused by something else?
It turns out that this issue was caused by improved error handling in
render.c combined with a poor return status choice in AnnotateImage().
The attached patch solves the problem.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org
raw 'text 10,100 ""' null:
gm convert: Non-conforming drawing primitive definition (text).
%
I am not sure when this problem started but I am not seeing it in
GraphicsMagick 1.3.13 (which I happend to have readily available).
Bob
--
Bob Friesenhahn
bfrie...@simple.da
y good for
any display/web application), but it does not handle the basic
requirements for desktop publishing, which needs more color
resolution.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
phicsMagick releases it is possible to build and
install both versions since the build is able to use disambiguated
library naming. It is only possible to develop with one version at a
time though.
This would require a second Debian package for the Q16 version.
Bob
--
Bob Friesenhahn
bfrie...
other software which cares (e.g.
ImageMagick & GraphicsMagick) has been doing this stuff for many
years.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to
ay be accomplished via the
MIT/X11-licensed lcms library.
If the colorspace enumeration is for a colorspace which has a precise
definition (e.g. sRGB), then that can be used to select a
locally-stored ICC profile (or hard-coded transform) so that the
client can view it correctly.
Bob
-
ux 3.2.0-3-rt-686-pae (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.o
ender its own logo but it exhibits a similar flaw
with some other SVGs so it may be something image specific such as a
rounding error.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
in 1.3.17.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
On Tue, 28 Aug 2012, Bastien ROUCARIES wrote:
On Tue, Aug 28, 2012 at 5:55 PM, Bob Friesenhahn
wrote:
I was confused. I see that the problem report is actually with reading XPM
rather than SVG. I tried reading the XPM on a Solaris 10 SPARC system and
it did not cause GM to crash. Testing
00:00 0
ffd5a000-ffd84000 rw-p 00:00 0 [stack]
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to debian-bu
On Fri, 10 Aug 2012, latlet wrote:
On Wed, 2 Mar 2011, Laurențiu Păncescu wrote:
On 3/2/11 16:10 , Bob Friesenhahn wrote:
It seems unlikely that Debian can afford to displace the existing 8-bit
package since it would break existing dependencies. A parallel
installable GraphicsMagick Q16
dding Jonathan to CC, who's managing this)
Cheers,
Moritz
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.
#x27;, 'char *', 'char **', 'const
char *', 'double', 'float', 'int', 'long', 'short', 'size_t', 'ssize_t',
'time_t', 'unsigned', 'unsigned char', 'unsigned char *
sys 0m3.564s
% env OMP_NUM_THREADS=24 OMP_WAIT_POLICY=PASSIVE ./benchparallel.sh 24 1
'-gaussian 0x1'
Executing 1x: gm benchmark -iterations 24 convert -size 4000x3000 tile:logo:
-gaussian 0x1 null: ...
Results: 24 threads 24 iter 237.87s user 11.30s total 2.124 iter/s (
-duration 5 convert -size 4000x3000
tile:model.pnm -resize 50% null:
Results: 24 threads 37 iter 88.86s user 5.08s total 7.283 iter/s (0.416 iter/s
cpu)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Gra
et/hgweb/graphicsmagick/graphicsmagick/rev/961a787f781d
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
its GROUP4 FAX compression, and perhaps introduced by a
Debian security fix. The tests which failed uses
WriteGROUP4RAWImage() in coders/tiff.c and ImageToHuffman2DBlob() in
magick/compress.c. A TIFF temporary file is created and the
compressed strip is extracted from it.
Bob
--
Bob Friesen
allel would be useful for this.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
On Wed, 2 Mar 2011, Laurențiu Păncescu wrote:
Hello Daniel,
Bob Friesenhahn, the upstream GraphicsMagick maintainer, also recommends
building GraphicsMagick with a 16-bit quantum depth [1]:
It has been a while since 2004, but today that is still my
recommendation if (almost) all the
to
verify multi-frame reading/writing with blobs and files.
There is another bug I am aware of which impacts Linux but it is in a
different area (pixel cache) and deserves a new bug report. That bug
results in a deadlock.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
t;next)
-if (p->blob != image->blob)
- *p->blob=(*image->blob);
+
status=0;
switch (image->blob->type)
{
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://w
On Thu, 27 Jan 2011, Reuben Thomas wrote:
On 27 January 2011 16:22, Bob Friesenhahn wrote:
This bug does look ugly. It seems that you are using a version of Ubuntu
which offers a newer GraphicsMagick than the one 10.04 is offering (10.04
only offers 1.3.5-6). On the Ubuntu I have here, I
stscript PostScript/PDF
ii gsfo 1:8.11+urwcyr1.0.7~pre44-4.2ubuntu1 Fonts for the Ghostscript interpre
Versions of packages libgraphicsmagick3 suggests:
pn graphicsmagick-dbg (no description available)
-- no debconf information
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
but am not sure how reliable that might be.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
ates.mgk file entries so that the shell
command runs in the background. Current releases have this. For
example:
Without the ampersand, the foreground program (display) blocks waiting
for the subordinate program to exit.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www
urceForge issue 2886560).
The problem was triggered by a TYPO3 bug which has been fixed for a
long time now.
It may be that this bug report is for something new, but it is
worthwhile to check that it is not a re-occurance of an already known
scenario.
Bob
--
Bob Friesenhahn
bfrie...@simple.dal
agick except that
-channel is already used for a different purpose (since ImageMagick
days) and ImageMagick subsequently changed the purpose of -channel.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://ww
On Wed, 3 Mar 2010, Daniel Kobras wrote:
Hi Bob!
On Tue, Mar 02, 2010 at 06:54:42PM -0600, Bob Friesenhahn wrote:
Thanks for reporting this issue. There is indeed a problem in
GraphicsMagick. I think that I have a good solution now (now in CVS
HEAD) and there will be test cases to make sure
s:
pn graphicsmagick-dbg (no description available)
-- no debconf information
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to debian-bugs-di
:
ssize_t pread(int fildes, void *buf, size_t nbyte, off_t offset);
ssize_t pwrite(int fildes, const void *buf, size_t nbyte, off_t offset);
which should normally be sufficient, but apparently not sufficient for
Linux.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
I am told that this bug is not evident in GraphicsMagick on a
"powerpc64-unknown-linux-gnu" Debian system, with a binary build as
"ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.8".
Bob
--
B
e=37600, io_file_offset=2147486400
) = 96
pwrite64(4,
"\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1"..., 37600,
18446744071562070720) = -1 EINVAL (Invalid argument)
The same code works fine on 32 bit Solaris, FreeBSD, and OS-X. It
also works fine on 64-bi
filename
systems. And tests.
This patch seems fine (and worthwhile) to me.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
To UNSUBSCRIBE, email to [EMAIL
99 matches
Mail list logo
