graphicsmagick-help — Requests for help with GraphicsMagick.

[GM-help] JPEG encoding parameters

[Rutger N. <rut...@gm...>]

Hi all,

I am changing JPEG files but the output files are different from the
input files:
the size in Kb is about half. This is probably something which I can fix with
-quality to get about the same size to lose as little as possible.

But I will also need a way to specify what kind of JPEG I'm writing, since the
JPEGs which I create will be stored in a medical-image container (DICOM file)
which specifies what kind of JPEG is embedded. Examples are:
    JPEG Baseline (Process 1)
    JPEG Extended (Process 2 & 4)
    JPEG Spectral Selection, Non-Hierarchical (Process 6 & 8)
    ...

So what I'm searching for are the parameters which I can use to specify how
the JPEG is encoded. So far I've found from reading the Changelog:
    jpeg:dct-method
    jpeg:optimize-coding=true
    quality

Are there more? Are there ways to keep the encoding as close as possible to
the input JPEG?

Thanks,
Rutger.

Re: [GM-help] Blanking a rectangle with gm conjure MSL

[Rutger N. <rut...@gm...>]

>>   gm convert in.jpg -draw "rectangle 10,10,30,30" out.jpg
>>
>> However, since I need to do this on a large number of JPG files (say,
>> 1000) on the same location, I wanted to use MSL to negate the overhead of
>> starting up 'gm'.
>
> You could consider using 'mogrify', which is designed to process many files
> at once.  See
> "http://www.graphicsmagick.org/FAQ.html#how-can-i-process-many-files-at-once".
> Note that the @files.txt syntax is flawed in GM 1.3.5 and earlier, but is
> corrected in the snapshot releases, and will be corrected in 1.3.6.

Thanks! This is just what I needed. I will probably create a separate
directory to put the files in to overcome the '@files.txt' problem. I
will now read the whole FAQ to make sure my other questions are not
already answered.

>>
>> What should I do instead?
>> (PS. It would help to have a list of example scripts to learn from;
>> Googling doesn't get me very
>> far with this...)
>
> There is a sample script to test MSL composite as
> utilities/tests/msl_composite.sh in GraphicsMagick CVS. Unforunately, it is
> a Unix shell script which writes a temporary MSL script, making it more
> difficult to understand. Here is the body of that script, but with some Unix
> shell variables mixed in:
>
[snip]

I don't mind reading script files, and hadn't found this one. But I
had the problem
that I wanted to create an empty image and composite that to emulate
'draw rectangle' which seems not to be available in MSL. However, when
the image misses a <read>, it complains about having no image, which
is what I wanted to overcome.

But the 'mogrify' option is way better anyways, so I need no MSL any more ;)

> A continuing problem with MSL/Conjure is the "chicken and egg" syndrome in
> which not enough people become knowledgeable enough in the syntax and
> contribute examples so that the rest can learn.

It does seem to be quite a niche language since (observations, no critique):
  - it is very sparsely documented
  - most people will probably use a scripting language as wrapper anyways
  - XML is never fun to program in
  - no examples exist for Google to find
  - GM is already powerful enough to do a lot without MSL (like
mogrify shows!) and very mature and stable in comparison.

I would have gone for the scripted route myself (using RMagick) if the
bindings would be portable across Ruby VMs (not a chance). Looking at
MSL seemed for me the last option (before knowing 'mogrify' ;) and was
the only reason to put relative much effort into getting that to work.
So getting past the Chicken & Egg problem is quite difficult I think.

Thanks,
Rutger.

Re: [GM-help] Blanking a rectangle with gm conjure MSL

[Bob F. <bfr...@si...>]

On Wed, 8 Jul 2009, Rutger Nijlunsing wrote:

> I am currently trying to blank out part of JPG files by overwriting it
> with a rectangle.
> This does work:
>    gm convert in.jpg -draw "rectangle 10,10,30,30" out.jpg
>
> However, since I need to do this on a large number of JPG files 
> (say, 1000) on the same location, I wanted to use MSL to negate the 
> overhead of starting up 'gm'.

You could consider using 'mogrify', which is designed to process many 
files at once.  See 
"http://www.graphicsmagick.org/FAQ.html#how-can-i-process-many-files-at-once". 
Note that the @files.txt syntax is flawed in GM 1.3.5 and earlier, but 
is corrected in the snapshot releases, and will be corrected in 1.3.6.

> For this, I created this MSL to blank in one JPG:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <group>
>  <image id="rectangle" size="32x32" background="black">
>  </image>
>  <image>
>    <read filename="in.jpg"/>
>    <composite image="rectangle" geometry="+40+20"/>
>  </image>
>  <write filename="out.jpg"/>
> </group>
>
> ...and tried to run it with 'gm conjure my.msl', but this gives the error
>    c:\Program Files\GraphicsMagick-1.3.5-Q16\gm.exe conjure: No
> images defined (composite).
>    c:\Program Files\GraphicsMagick-1.3.5-Q16\gm.exe conjure: No
> images defined (composite).
>
> What should I do instead?
> (PS. It would help to have a list of example scripts to learn from;
> Googling doesn't get me very
> far with this...)

There is a sample script to test MSL composite 
as utilities/tests/msl_composite.sh in GraphicsMagick CVS. 
Unforunately, it is a Unix shell script which writes a temporary MSL 
script, making it more difficult to understand. Here is the body of 
that script, but with some Unix shell variables mixed in:

<?xml version="1.0" encoding="utf-8" ?>
<group>
     <image id="1"><read filename="$CENTER"/></image>
     <image id="2"><read filename="$NORTH"/></image>
     <image id="3"><read filename="$NORTHEAST"/></image>
     <image id="4"><read filename="$EAST"/></image>
     <image id="5"><read filename="$SOUTHEAST"/></image>
     <image id="6"><read filename="$SOUTH"/></image>
     <image id="7"><read filename="$SOUTHWEST"/></image>
     <image id="8"><read filename="$WEST"/></image>
     <image id="9"><read filename="$NORTHWEST"/></image>
     <image>
         <read filename="$BLANK"/>
         <composite image="1" gravity="Center"/>
         <composite image="2" gravity="North"/>
         <composite image="3" gravity="NorthEast"/>
         <composite image="4" gravity="East"/>
         <composite image="5" gravity="SouthEast"/>
         <composite image="6" gravity="South"/>
         <composite image="7" gravity="SouthWest"/>
         <composite image="8" gravity="West"/>
         <composite image="9" gravity="NorthWest"/>
     </image>
     <write filename="$CONJURE_RESULT"/>
</group>

A continuing problem with MSL/Conjure is the "chicken and egg" 
syndrome in which not enough people become knowledgeable enough in the 
syntax and contribute examples so that the rest can learn.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[GM-help] Blanking a rectangle with gm conjure MSL

[Rutger N. <rut...@gm...>]

Hi,

I am currently trying to blank out part of JPG files by overwriting it
with a rectangle.
This does work:
    gm convert in.jpg -draw "rectangle 10,10,30,30" out.jpg

However, since I need to do this on a large number of JPG files (say,
1000) on the
same location, I wanted to use MSL to negate the overhead of starting up 'gm'.

For this, I created this MSL to blank in one JPG:

<?xml version="1.0" encoding="UTF-8"?>
<group>
  <image id="rectangle" size="32x32" background="black">
  </image>
  <image>
    <read filename="in.jpg"/>
    <composite image="rectangle" geometry="+40+20"/>
  </image>
  <write filename="out.jpg"/>
</group>

...and tried to run it with 'gm conjure my.msl', but this gives the error
    c:\Program Files\GraphicsMagick-1.3.5-Q16\gm.exe conjure: No
images defined (composite).
    c:\Program Files\GraphicsMagick-1.3.5-Q16\gm.exe conjure: No
images defined (composite).

What should I do instead?

(PS. It would help to have a list of example scripts to learn from;
Googling doesn't get me very
far with this...)

Thanks in advance,
Rutger.

Re: [GM-help] gm equivalent of -extent in ImageMagick

[Bob F. <bfr...@si...>]

On Tue, 30 Jun 2009, Ari Awan wrote:

> I am trying to replace ImageMagick with GraphicsMagick, but at the
> moment having a hard time to come up with the command equivalent to
> below :
>
> convert -thumbnail 205x155^ -gravity center -extent 205x155 [filename]
> [filethumb]
>
> I would like to make a thumbnail, by resizing and then cropping the
> image, so the thumbnail would have the exact fit to the specified size.
>
> I am using this command :
> gm convert -size 205x155 [filename] -gravity center -crop 205x155
> +profile "*" [filethumb]
>
> but it endup producing tiles of the original images.

If you supply offset information to the -crop argument then it should 
no longer produce tiles.  For example, use the argument 205x155+0+0.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[GM-help] gm equivalent of -extent in ImageMagick

[Ari A. <ari...@gm...>]

I am trying to replace ImageMagick with GraphicsMagick, but at the  
moment having a hard time to come up with the command equivalent to  
below :

convert -thumbnail 205x155^ -gravity center -extent 205x155 [filename]  
[filethumb]

I would like to make a thumbnail, by resizing and then cropping the  
image, so the thumbnail would have the exact fit to the specified size.

I am using this command :
gm convert -size 205x155 [filename] -gravity center -crop 205x155  
+profile "*" [filethumb]

but it endup producing tiles of the original images.

Any help would be greatly appreciated.

Thank you,
Ari

Re: [GM-help] Resize Quality

[Derek E. <de...@sp...>]

Sorry just realised I hadn't replied to this.This worked a charm. Am
figuring out the orientation doing the resize and then rotating.
If you are interested you can see the results here: http://dereke.zavam.com

Thanks for all your help!


2009/6/5 Bob Friesenhahn <bfr...@si...>

> On Fri, 5 Jun 2009, Derek Ekins wrote:
>
>  So after doing some more testing I found the real cause of my problem.
>> As mentioned in a previous post I am using jhead to rotate my image and if
>> I
>> do that before resizing then the quality of the resize is terrible. I
>> didn't
>> have this problem with ImageMagick as it supports rotating the image
>> natively.
>>
>
> By supports rotating the image natively, do you mean "automatically", or
> via some instruction to a modified libJPEG?
>
>  Bob you had mentioned that gm can get the orientation of an image from
>> exif.
>> How do you do that? (I can't find any info on this??)
>>
>
> Based on a quick look at an EXIF fortified image, this does the trick:
>
> % gm identify -format "%[EXIF:Orientation]" Sunrise.jpg
> 1
>
> I did a quick search and found this explanation of the EXIF orientation
> tags:
>
>  http://sylvana.net/jpegcrop/exif_orientation.html
>
> So it seems that the EXIF orientation codes match the TIFF orientation
> codes, and also match GraphicsMagick's preliminary start at an orientation
> code:
>
> typedef enum               /* Line direction / Frame Direction */
> {                          /* -------------- / --------------- */
>  UndefinedOrientation,    /* Unknown        / Unknown         */
>  TopLeftOrientation,      /* Left to right  / Top to bottom   */
>  TopRightOrientation,     /* Right to left  / Top to bottom   */
>  BottomRightOrientation,  /* Right to left  / Bottom to top   */
>  BottomLeftOrientation,   /* Left to right  / Bottom to top   */
>  LeftTopOrientation,      /* Top to bottom  / Left to right   */
>  RightTopOrientation,     /* Top to bottom  / Right to left   */
>  RightBottomOrientation,  /* Bottom to top  / Right to left   */
>  LeftBottomOrientation    /* Bottom to top  / Left to right   */
> } OrientationType;
>
> Since GraphicsMagick already supports storing the orientation code then an
> autorotate feature could be added without changing GM's ABI.
>
>
> Bob
> --
> Bob Friesenhahn
> bfr...@si..., http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>

Re: [GM-help] identify format "%r"

[Stijn S. <San...@sp...>]

>> Unless you can point me at something else I could use, I'm about
>> to binary search for 0xD9FF and 0xC0FF and the colours count...
>
> What do these binary values represent?

Have a look at the "Syntax and strcuture" section of
http://en.wikipedia.org/wiki/JPEG
(it looks like I got my byte precedence reversed, but still:
- FFD8 is the 'Start Of Image' marker,
- FFC0 is the 'Start Of Frame' marker, which has a 'number of components' value

and this turns out to be 1, 3 or 4 with grayscale, rgb or cmyk images

Re: [GM-help] identify format "%r"

[<gl...@co...>]

----- Original Message -----
From: "Bob Friesenhahn" <bfr...@si...>
To: "Stijn Sanders" <San...@sp...>
Cc: "Requests for help with GraphicsMagick" <gra...@li...>

JPEG itself does not have a colors count so computing the number of 
colors would be very time consuming.

     Strictly speaking, there is no "number of colors" because the color
     count in the decoded image depends on the decoder implementation,
     rounding, etc.

     Glenn

Re: [GM-help] identify format "%r"

[Bob F. <bfr...@si...>]

On Tue, 9 Jun 2009, Stijn Sanders wrote:
> So I'm trying to correct this while switching to GM.
>
> The thing is that we export JPEG's here to machines that print them, 
> and they have a hard time with 'deviating' JPEG's that hold 
> something else than 3 colour-levels of 8-bits per sample. (24 bits 
> per pixel)

Of course I would like to help you, but need to understand the problem 
better.  Problem JPEG files could be true grayscale (one channel), or 
they could be CMYK (four channels).  There are also JPEG files in ITU 
LAB colorspace (which GM currently does not really support).

> Unless you can point me at something else I could use, I'm about to 
> binary search for 0xD9FF and 0xC0FF and the colours count...

What do these binary values represent?

JPEG itself does not have a colors count so computing the number of 
colors would be very time consuming.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] identify format "%r"

[Stijn S. <San...@sp...>]

> I don't think that you will like my answers ...

I don't dislike them. They even confirm IM wasn't used properly.
So I'm trying to correct this while switching to GM.

The thing is that we export JPEG's here to machines that print them, and they have a hard time with 'deviating' JPEG's that hold something else than 3 colour-levels of 8-bits per sample. (24 bits per pixel)

identify was used before to check for this, but apparently the type/class info isn't really what I nee.

Unless you can point me at something else I could use, I'm about to binary search for 0xD9FF and 0xC0FF and the colours count...

Re: [GM-help] trouble reading EXIF date picture taken

[Bob F. <bfr...@si...>]

On Mon, 8 Jun 2009, Bob Friesenhahn wrote:
>
> Looking at the GM code, it does include a provision to preserve these
> NULL bytes but they are not printed out by identify since there is no
> way to print them.

In the next GM snapshot, unprintable bytes will be printed as 
backslash delimited octal codes (e.g. \000).

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] trouble reading EXIF date picture taken

[Bob F. <bfr...@si...>]

On Mon, 8 Jun 2009, Stijn Sanders wrote:

> is there a reason why
>  gm identify -format "%[EXIF:DateTimeOriginal]" aa.jpg
> returns
>  2
> instead of the full date the EXIF data holds?

Yes.  I suspect that the string value is stored as a variant of UTF-16 
or UCS-2 (http://en.wikipedia.org/wiki/UTF-16) rather than plain ASCII 
as required.  The values are similar to ASCII values except that every 
other byte is a NULL byte.  The string is declared to be 20 bytes long 
but it seems that 20 of these 16 byte values would be required to 
store the complete value so the length is also declared incorrectly. 
Since C strings are terminated by a NULL byte, only the first value is 
printed.

Looking at the GM code, it does include a provision to preserve these 
NULL bytes but they are not printed out by identify since there is no 
way to print them.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] identify format "%r"

[Bob F. <bfr...@si...>]

On Mon, 8 Jun 2009, Stijn Sanders wrote:
> Or can I savely assume all "Bilevel" images are already truecolor?

Bilevel images have these additional properties:

  * They are a type of grayscale image
  * They are a type of truecolor image (grayscale image is special case
    of TrueColor).

You may notice that GraphicsMagick 'identify' often reports Bilevel 
images as PseudoClass.  This is because it is easy to load a Bilevel 
image as a two-color palette image but may take quite a lot of CPU to 
create a palette later if the file is to be saved in a format like 
GIF.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] identify format "%r"

[Bob F. <bfr...@si...>]

On Mon, 8 Jun 2009, Stijn Sanders wrote:

I don't think that you will like my answers ...

> Hmm, I'm getting "Bilevel" for format "%r" on page that are entirely white,
> and are failing the test that converts grayscale images to truecolor on the fly...

The image type analysis is based on a "deep" inspection where the 
properties of the actual image pixels are analyzed rather than looking 
at how the image was stored in the file it was read from.  A white 
image can be stored without loss using 1 bit per pixel so it is 
declared to be "Bilevel", even if the original image file was using as 
much as 12 bytes per pixel.

The priority of classification is as follows:

  1) CMYK
  2) Monochrome (bilevel)
  3) Grayscale
  4) Palette
  5) TrueColor (RGB)

and the first match wins.  In summary, the representation format which 
can represent the image in the smallest size without loss wins.

> Is there a format-code to list the number of bits per pixel, or the 
> number of color-channels of the image? Or can I savely assume all 
> "Bilevel" images are already truecolor?

There is the format code 'q' but this one is also based on a "deep" 
pixel inspection.  If you take a white image stored with 16-bits per 
pixel, the format code 'q' is still likely to report a bit depth of 
'1' since only one bit is required to store the pixel successfully.

Likewise, if you read an image from a 16-bit/sample format but the 
image could be stored without any loss in a 8-bit/sample format, then 
the depth will be reported as 8 (but maybe even as 4 or 7).

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] identify format "%r"

[Stijn S. <San...@sp...>]

>The possible values are:
>...
>   Bilevel

Hmm, I'm getting "Bilevel" for format "%r" on page that are entirely white,
and are failing the test that converts grayscale images to truecolor on the fly...

Is there a format-code to list the number of bits per pixel, or the number of color-channels of the image?
Or can I savely assume all "Bilevel" images are already truecolor?

Re: [GM-help] bug on Windows 2003 server

[Stijn S. <San...@sp...>]

I'm completely confused.
Coming back this monday morning, I'm no longer able to reproduce the problem on the server, and "xc:white" works just fine.
I'll try to find out if anything happened over the weekend.

Re: [GM-help] Resize Quality

[Bob F. <bfr...@si...>]

FYI, GraphicsMagick development CVS is now updated with support for 
the '^' geometry option.  This will be in the next development 
snapshot and next release.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] Question about enum_strings.h

[Bob F. <bfr...@si...>]

On Fri, 5 Jun 2009, Griffin Myers wrote:

> I'm very new to GM, and am investigating using it as a front end to for
> an already existing image processing tool for the purpose of format
> conversion.  Anyway, I've been toying around with Magick++ just to get a
> feel for the library and how to use it.  For reference I'm using GM 1.3.5.
>
> In the source tree I noticed enum_strings.h/.c which have a bunch of
> nifty xyzToString() functions for "translating" enumerated types to
> strings.  I would like to call some of these functions from my
> application, but enum_strings.h is not installed upon building the library.

The reason why it is not installed is that these are internal 
implementation functions and if the header is installed, then they 
will be used, thereby denying us the ability to change or remove them 
in the future.

> If I manually define the MAGICK_IMPLEMENTATION preprocessor variable
> when compiling my code (g++ -D MAGICK_IMPLEMENTATION ...), then I get a
> compiler error as enum_strings.h can not be found.  The manual
> definition of this variable is probably not an expected behavior, but
> nonetheless this seems like it might be a bug.

The MAGICK_IMPLEMENTATION preprocessor variable is used to try to 
block out implementation details.  It is more convenient than 
maintaining sets of public and private headers as ImageMagick is now 
doing.

> For the time being, in order to access the desired functions, I've
> grabbed a copy of enum_strings.h from the source tree and manually
> dumped it in the include area of the installed library.  Then in my
> program I added the "namespace...#include..." code from about.  I guess
> my question is twofold, 1)is this a bad thing to do; and 2) is there
> some other way to access these functions that I am completely
> overlooking?  And furthermore, is there a reason for not installing
> enum_strings.h by default?  I can't imagine I'm the only person that
> might want access to these functions.

You are free to do what you want with enum_strings.h as long as you 
are aware that these functions are not part of the public interface 
and they might be changed or even removed in a later version.  There 
is no plan to change or remove the functions at the moment.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] bug on Windows 2003 server

[Bob F. <bfr...@si...>]

On Fri, 5 Jun 2009, Stijn Sanders wrote:

> I have an ugly bug breaking an application that uses GraphicsMagick.
> It uses composite and "xc:white" to put a white border around an image,
> but on Windows 2003 Server the command returns:
>
> "Unable to open file (white) [No such file or directory]"

As a bit of additional clarification, since Windows uses logical drive 
letters, GM contains code which attempts to disambiguate between 
colon-delimited prefixes which are part of path specifications or are 
intended to be format specifications.  For example, is "C:foo" a 
filename, or is it a "C" image format and the filename is "foo"?

If putting the "xc:white" into a file does not solve the problem, then 
there may be something wrong with GM's disambiguation code on Windows 
2003 server.

If the server happend to have a drive letter of "xc:" then there would 
obviously be a problem.

Windows does not actually require these drive letters any more but it 
seems that continued usage is still normal and GM needs to account for 
it.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [GM-help] bug on Windows 2003 server

[Bob F. <bfr...@si...>]

On Fri, 5 Jun 2009, Stijn Sanders wrote:

> I have an ugly bug breaking an application that uses GraphicsMagick.
> It uses composite and "xc:white" to put a white border around an image,
> but on Windows 2003 Server the command returns:
>
> "Unable to open file (white) [No such file or directory]"
>
> It seems like Windows 2003 Server leaves out the "xc:" part. It works fine on Windows XP.

That sounds very annoying.  Does this trick from the documentation 
help?

      When running a commandline utility, you can  prepend  an  at
      sign  @ to a filename to read a list of image filenames from
      that file. This is convenient in the event you have too many
      image filenames to fit on the command line.

So you should be able to write "xc:white" as a line in a text file, 
and then reference it like "@filename".

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[GM-help] Question about enum_strings.h

[Griffin M. <gm...@si...>]

I'm very new to GM, and am investigating using it as a front end to for 
an already existing image processing tool for the purpose of format 
conversion.  Anyway, I've been toying around with Magick++ just to get a 
feel for the library and how to use it.  For reference I'm using GM 1.3.5.

In the source tree I noticed enum_strings.h/.c which have a bunch of 
nifty xyzToString() functions for "translating" enumerated types to 
strings.  I would like to call some of these functions from my 
application, but enum_strings.h is not installed upon building the library.

Tracing through the code, I noticed the following in Magick++/Include.h:

#if defined(MAGICK_IMPLEMENTATION)
namespace MagickLib
{
#  include "magick/enum_strings.h"
}
#endif

If I manually define the MAGICK_IMPLEMENTATION preprocessor variable 
when compiling my code (g++ -D MAGICK_IMPLEMENTATION ...), then I get a 
compiler error as enum_strings.h can not be found.  The manual 
definition of this variable is probably not an expected behavior, but 
nonetheless this seems like it might be a bug.

For the time being, in order to access the desired functions, I've 
grabbed a copy of enum_strings.h from the source tree and manually 
dumped it in the include area of the installed library.  Then in my 
program I added the "namespace...#include..." code from about.  I guess 
my question is twofold, 1)is this a bad thing to do; and 2) is there 
some other way to access these functions that I am completely 
overlooking?  And furthermore, is there a reason for not installing 
enum_strings.h by default?  I can't imagine I'm the only person that 
might want access to these functions.

Thanks,
Griffin Myers

Re: [GM-help] Resize Quality

[Bob F. <bfr...@si...>]

On Fri, 5 Jun 2009, Derek Ekins wrote:

> So after doing some more testing I found the real cause of my problem.
> As mentioned in a previous post I am using jhead to rotate my image and if I
> do that before resizing then the quality of the resize is terrible. I didn't
> have this problem with ImageMagick as it supports rotating the image
> natively.

By supports rotating the image natively, do you mean "automatically", 
or via some instruction to a modified libJPEG?

> Bob you had mentioned that gm can get the orientation of an image from exif.
> How do you do that? (I can't find any info on this??)

Based on a quick look at an EXIF fortified image, this does the trick:

% gm identify -format "%[EXIF:Orientation]" Sunrise.jpg
1

I did a quick search and found this explanation of the EXIF 
orientation tags:

   http://sylvana.net/jpegcrop/exif_orientation.html

So it seems that the EXIF orientation codes match the TIFF orientation 
codes, and also match GraphicsMagick's preliminary start at an 
orientation code:

typedef enum               /* Line direction / Frame Direction */
{                          /* -------------- / --------------- */
   UndefinedOrientation,    /* Unknown        / Unknown         */
   TopLeftOrientation,      /* Left to right  / Top to bottom   */
   TopRightOrientation,     /* Right to left  / Top to bottom   */
   BottomRightOrientation,  /* Right to left  / Bottom to top   */
   BottomLeftOrientation,   /* Left to right  / Bottom to top   */
   LeftTopOrientation,      /* Top to bottom  / Left to right   */
   RightTopOrientation,     /* Top to bottom  / Right to left   */
   RightBottomOrientation,  /* Bottom to top  / Right to left   */
   LeftBottomOrientation    /* Bottom to top  / Left to right   */
} OrientationType;

Since GraphicsMagick already supports storing the orientation code 
then an autorotate feature could be added without changing GM's ABI.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[GM-help] bug on Windows 2003 server

[Stijn S. <San...@sp...>]

I have an ugly bug breaking an application that uses GraphicsMagick.
It uses composite and "xc:white" to put a white border around an image,
but on Windows 2003 Server the command returns:

"Unable to open file (white) [No such file or directory]"

It seems like Windows 2003 Server leaves out the "xc:" part. It works fine on Windows XP.

Re: [GM-help] Resize Quality

[Derek E. <de...@sp...>]

 So after doing some more testing I found the real cause of my problem.
As mentioned in a previous post I am using jhead to rotate my image and if I
do that before resizing then the quality of the resize is terrible. I didn't
have this problem with ImageMagick as it supports rotating the image
natively.

Bob you had mentioned that gm can get the orientation of an image from exif.
How do you do that? (I can't find any info on this??)


2009/6/5 Bob Friesenhahn <bfr...@si...>

> On Thu, 4 Jun 2009, Mark Rebec wrote:
>
> > Just out of curiosity (and suppose I could probably look this up :) I
> > noticed Derek isn't using the -quality flag.  Does GM default to '-
> > quality 100' when it's not specified?  ...or could that possibly help
> > him in this case?
>
> The default quality factor for JPEG is 75 (same as used by the JPEG
> library).  ImageMagick may have changed its default.
>
> Bob
> --
> Bob Friesenhahn
> bfr...@si..., http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Graphicsmagick-help mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help
>