From db3l at fitlinxx.com  Thu Sep  1 01:40:31 2005
From: db3l at fitlinxx.com (David Bolen)
Date: Wed, 31 Aug 2005 19:40:31 -0400
Subject: [Image-SIG] Use of Z_SYNC_FLUSH in libImaging/ZipEncode.c
Message-ID: <926F937512224245A616323693D3F16B0A541D54@ctmsg01.corp.fitlinxx.com>

While looking into why round-tripping a small PNG image through PIL expanded
the file size noticeable (several hundred % for very small images), I
isolated it to the explict flushing of the zlib compression engine during
zip encoding (via Z_SYNC_FLUSH), resulting in much less efficiency in
compression in some cases.

There's a FIXME comment in the source from 990709 indicating that it's a
workaround for a problem with recent (presumably as of that date) versions
of zlib.  Would anyone happen to have further information on the bug that
it's working around and whether or not that's still necessary?  I found some
e-mails in the archives from that timeframe but not much concrete
information.  The sample files on a web site showing the problem at the time
are, not surprisingly, no longer available.

It's true that it hurts most on small images, especially those in the Ks to
10Ks, but even larger images grow 5-10%, so if it's something that might be
removable (or perhaps conditional on a save option) it might help.

Thanks.

-- David


From stefano at pragma2000.com  Thu Sep  1 11:34:48 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Thu, 1 Sep 2005 11:34:48 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector), TIFF and PSD on windows
Message-ID: <432742240509010234725fec5d@mail.gmail.com>

Hi,

I've been digging around a bit and found a little too many different
libraries for dealing with image formats, so I'm a little confused...
here's my problem:

I need to read JPG (easy), TIFF (easy), EPS (both bitmap and vector)
and PSD (photoshop) files, and create small jpeg previews. This should
preferrably be done under windows, optionally under linux.

I know this must be not an easy problem to solve in its generality.
Just to mention one problem for all, a vector EPS files may contain
text set with a font that is only present on a given system. So in
order to create a jpeg preview I must rasterize the postscript on the
system containing that font, and my system must be able to use
whatever format the font is available on such platform.

My requirements are not totally stringent though:

1) I can give up PSD files, if I must.
2) I can give up windows platform, if I must.

I already have an ultimate solution: have a windows machine running at
all time, with Photoshop installed and running at all time as well. A
server listening on a tcp port waits for preview-generation requests,
and have Photoshop convert whatever format comes in to a jpeg preview,
that gets sent back to the client machine.

I think this solution is quite extreme though. And probably not very
efficient too.

There may even be some off the shelf command line tool that does all
the magic, I thought. In that case I could write some wrapper in order
to have its functionality available with a simple api. But I don't
know such tool.

So I'm wondering: what else can I do? Do I really have to write such a
monster of a distributed app to obtain simple image previews?

thanks in advance!
stefano

From mattnuzum at gmail.com  Thu Sep  1 15:09:58 2005
From: mattnuzum at gmail.com (Matthew Nuzum)
Date: Thu, 1 Sep 2005 08:09:58 -0500
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
In-Reply-To: <432742240509010234725fec5d@mail.gmail.com>
References: <432742240509010234725fec5d@mail.gmail.com>
Message-ID: <f3c0b40805090106093defd1d1@mail.gmail.com>

On 9/1/05, Stefano Masini <stefano at pragma2000.com> wrote:
> I need to read JPG (easy), TIFF (easy), EPS (both bitmap and vector)
> and PSD (photoshop) files, and create small jpeg previews. This should
> preferrably be done under windows, optionally under linux.

I haven't found a solution that can read PSD files that correctly
handles the layer effects created in 5.5 and newer versions of PSD
files.

For example, in Photoshop you can apply a gradient overlay or a drop
shadow by just appling an effect to the layer. As you change the
layer, the effect changes to match. When you open the file in Gimp,
you see the layer, but not the drop shadow or gradient.

I'd love to find out that I'm wrong and a new library has come out
that fully supports the layer effects.

> I already have an ultimate solution: have a windows machine running at
> all time, with Photoshop installed and running at all time as well. A
> server listening on a tcp port waits for preview-generation requests,
> and have Photoshop convert whatever format comes in to a jpeg preview,
> that gets sent back to the client machine.
> 
> I think this solution is quite extreme though. And probably not very
> efficient too.

It's worth a try... Obviously photoshop is a resource intensive
application, but once it's running it operates pretty quick.
-- 
Matthew Nuzum
www.bearfruit.org

From stefano at pragma2000.com  Thu Sep  1 15:27:59 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Thu, 1 Sep 2005 15:27:59 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
In-Reply-To: <f3c0b40805090106093defd1d1@mail.gmail.com>
References: <432742240509010234725fec5d@mail.gmail.com>
	<f3c0b40805090106093defd1d1@mail.gmail.com>
Message-ID: <4327422405090106273f71fa0c@mail.gmail.com>

On 9/1/05, Matthew Nuzum <mattnuzum at gmail.com> wrote:
> I haven't found a solution that can read PSD files that correctly
> handles the layer effects created in 5.5 and newer versions of PSD
> files.

Yeah... I can see that. Adobe keeps adding stuff to its products, no
wonder people can't keep up with updating the libraries for reading
the format.
By the way, luckily for me, I could live without psd files in my
problem, or better yet, have them, but assume no layers are used...

So, is it possible to use the gimp as a simple backend? I mean, wrap
some functionality inside a pythonic api, so that I can do stuff like:
open('foo.eps').save('preview.jpeg') ?

> It's worth a try... Obviously photoshop is a resource intensive
> application, but once it's running it operates pretty quick.

I've already done it. Scripting Photoshop with COM is ugly, but
possible. The problem is that since the architecture runs on a
separate machine, I have to implement a system that exports such
functionality over sockets. Again, possible, but quite tedious,
expecially because it easily grows into something that you have to
maintain more that you would like to, given the simple need to open a
file and save it in a different format! :(
So frustrating!

stefano

From fredrik at pythonware.com  Thu Sep  1 15:48:41 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 1 Sep 2005 15:48:41 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
References: <432742240509010234725fec5d@mail.gmail.com><f3c0b40805090106093defd1d1@mail.gmail.com>
	<4327422405090106273f71fa0c@mail.gmail.com>
Message-ID: <df70rj$is7$1@sea.gmane.org>

Stefano Masini wrote:

> So, is it possible to use the gimp as a simple backend? I mean, wrap
> some functionality inside a pythonic api, so that I can do stuff like:
> open('foo.eps').save('preview.jpeg') ?

have you tried installing PIL and doing

import Image
Image.open('foo.eps').save('preview.jpeg')

or, better

import Image
im = Image.open('foo.eps')
im.thumbnail((100, 100), Image.ANTIALIAS)
im.save('preview.jpeg')

?  it should work for most of your files, at least.  you may have
to add fallback paths for some kinds of data (e.g. non-EPS post-
script files and ccitt-encoded TIFF files; run "gs" and "tiffcp" to
turn them into a format that PIL can handle)

</F> 




From meyer at mesw.de  Thu Sep  1 15:57:04 2005
From: meyer at mesw.de (Markus Meyer)
Date: Thu, 01 Sep 2005 15:57:04 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
In-Reply-To: <432742240509010234725fec5d@mail.gmail.com>
References: <432742240509010234725fec5d@mail.gmail.com>
Message-ID: <431708B0.9070002@mesw.de>

Stefano,

at least for vector EPS, you definitely need a RIP (raster image 
processor). Of course, Photoshop has kind of a RIP built-in, so it can 
interpret vector formats. Ghostscript is a well-known open source RIP 
which can be used over command line, but it won't help you with reading 
PSD files. But there are commercial RIPs available which can read 
PhotoShop files, for a list see:

http://www.wide-formatimaging.com/resources/rips.shtml

Most of these programs should be able to create JPG previews. Commercial 
RIPs normally work using a "hot folder", that is, an application (or the 
user) copies the file to be converted into a folder, the RIP picks it 
up, processes it and writes the output to another folder automatically.


Markus


Stefano Masini schrieb:

>Hi,
>
>I've been digging around a bit and found a little too many different
>libraries for dealing with image formats, so I'm a little confused...
>here's my problem:
>
>I need to read JPG (easy), TIFF (easy), EPS (both bitmap and vector)
>and PSD (photoshop) files, and create small jpeg previews. This should
>preferrably be done under windows, optionally under linux.
>
>I know this must be not an easy problem to solve in its generality.
>Just to mention one problem for all, a vector EPS files may contain
>text set with a font that is only present on a given system. So in
>order to create a jpeg preview I must rasterize the postscript on the
>system containing that font, and my system must be able to use
>whatever format the font is available on such platform.
>
>My requirements are not totally stringent though:
>
>1) I can give up PSD files, if I must.
>2) I can give up windows platform, if I must.
>
>I already have an ultimate solution: have a windows machine running at
>all time, with Photoshop installed and running at all time as well. A
>server listening on a tcp port waits for preview-generation requests,
>and have Photoshop convert whatever format comes in to a jpeg preview,
>that gets sent back to the client machine.
>
>I think this solution is quite extreme though. And probably not very
>efficient too.
>
>There may even be some off the shelf command line tool that does all
>the magic, I thought. In that case I could write some wrapper in order
>to have its functionality available with a simple api. But I don't
>know such tool.
>
>So I'm wondering: what else can I do? Do I really have to write such a
>monster of a distributed app to obtain simple image previews?
>
>thanks in advance!
>stefano
>_______________________________________________
>Image-SIG maillist  -  Image-SIG at python.org
>http://mail.python.org/mailman/listinfo/image-sig
>
>  
>


From mattnuzum at gmail.com  Thu Sep  1 16:02:24 2005
From: mattnuzum at gmail.com (Matthew Nuzum)
Date: Thu, 1 Sep 2005 09:02:24 -0500
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
In-Reply-To: <4327422405090106273f71fa0c@mail.gmail.com>
References: <432742240509010234725fec5d@mail.gmail.com>
	<f3c0b40805090106093defd1d1@mail.gmail.com>
	<4327422405090106273f71fa0c@mail.gmail.com>
Message-ID: <f3c0b40805090107025496a51c@mail.gmail.com>

On 9/1/05, Stefano Masini <stefano at pragma2000.com> wrote:
> So, is it possible to use the gimp as a simple backend? I mean, wrap
> some functionality inside a pythonic api, so that I can do stuff like:
> open('foo.eps').save('preview.jpeg') ?

I think so.
http://www.gimp.org/tutorials/#Script
Also check http://www.jamesh.id.au/software/pygimp/ and look at the
details for the "console" plugin.

> > It's worth a try... Obviously photoshop is a resource intensive
> > application, but once it's running it operates pretty quick.
> 
> I've already done it. Scripting Photoshop with COM is ugly, but
> possible. The problem is that since the architecture runs on a
> separate machine, I have to implement a system that exports such
> functionality over sockets. Again, possible, but quite tedious,
> expecially because it easily grows into something that you have to
> maintain more that you would like to, given the simple need to open a
> file and save it in a different format! :(
> So frustrating!

I personally use imagemagick... I'm not 100% positive, but I think it
will do all you've mentioned, including working with the PSD files.
There are some python wrappers for this as well.
http://starship.python.net/crew/zack/pymagick/ (for one example)

The trick is building ImageMagick with all of the right libraries to
get the full functionality. I would do it on Linux, but that's me.

-- 
Matthew Nuzum
www.bearfruit.org

From stefano at pragma2000.com  Thu Sep  1 16:15:01 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Thu, 1 Sep 2005 16:15:01 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
In-Reply-To: <df70rj$is7$1@sea.gmane.org>
References: <432742240509010234725fec5d@mail.gmail.com>
	<f3c0b40805090106093defd1d1@mail.gmail.com>
	<4327422405090106273f71fa0c@mail.gmail.com>
	<df70rj$is7$1@sea.gmane.org>
Message-ID: <432742240509010715454c8ab6@mail.gmail.com>

On 9/1/05, Fredrik Lundh <fredrik at pythonware.com> wrote:
> have you tried installing PIL and doing
> 
> import Image
> Image.open('foo.eps').save('preview.jpeg')

yeehh... I've tried it... spent some time on it today, but not
successfully... :(

Of course, I probably stressed the poor ghostscript right away by
feeding it with the worst eps file I had around, but it looked like it
didn't wanna swallow it.
Then I looked at the implementation of PIL's ghostscript plugin, and
it seemed remarkably short comparing to the boatload of command line
parameters that gs has.
So I had the feeling that PIL isn't quite enough robust for my needs.

From stefano at pragma2000.com  Thu Sep  1 16:16:35 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Thu, 1 Sep 2005 16:16:35 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
In-Reply-To: <431708B0.9070002@mesw.de>
References: <432742240509010234725fec5d@mail.gmail.com>
	<431708B0.9070002@mesw.de>
Message-ID: <432742240509010716432374db@mail.gmail.com>

On 9/1/05, Markus Meyer <meyer at mesw.de> wrote:
> at least for vector EPS, you definitely need a RIP (raster image
> processor). Of course, Photoshop has kind of a RIP built-in, so it can

yep.

> Most of these programs should be able to create JPG previews. Commercial
> RIPs normally work using a "hot folder", that is, an application (or the

That's certainly a viable alternative.

But it sounds very similar my current system, where instead of a rip
listening for jobs, I have Photoshop doing the same.
So I'd rather keep it that way. At least Photoshop I've already paid for! ;)

From fredrik at pythonware.com  Thu Sep  1 16:25:22 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 1 Sep 2005 16:25:22 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
References: <432742240509010234725fec5d@mail.gmail.com><f3c0b40805090106093defd1d1@mail.gmail.com><4327422405090106273f71fa0c@mail.gmail.com><df70rj$is7$1@sea.gmane.org>
	<432742240509010715454c8ab6@mail.gmail.com>
Message-ID: <df730b$qgf$1@sea.gmane.org>

Stefano Masini wrote:

> Then I looked at the implementation of PIL's ghostscript plugin, and
> it seemed remarkably short comparing to the boatload of command line
> parameters that gs has.

I'm not sure I see the connection -- the EPS plugin simply looks for
EPS headers, and if found, tells ghostscript to render it to a suitable
bitmap image.  You don't need any "boatloads of command line
parameters" to do that...

(feel free to mail me a copy of your worst-case EPS file, btw.  my
internal PIL test suite can never have too many samples...).

</F> 




From stefano at pragma2000.com  Thu Sep  1 17:25:12 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Thu, 1 Sep 2005 17:25:12 +0200
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
In-Reply-To: <df730b$qgf$1@sea.gmane.org>
References: <432742240509010234725fec5d@mail.gmail.com>
	<f3c0b40805090106093defd1d1@mail.gmail.com>
	<4327422405090106273f71fa0c@mail.gmail.com>
	<df70rj$is7$1@sea.gmane.org>
	<432742240509010715454c8ab6@mail.gmail.com>
	<df730b$qgf$1@sea.gmane.org>
Message-ID: <43274224050901082563e127ef@mail.gmail.com>

On 9/1/05, Fredrik Lundh <fredrik at pythonware.com> wrote:
> I'm not sure I see the connection -- the EPS plugin simply looks for
> EPS headers, and if found, tells ghostscript to render it to a suitable

Here's what I got:

File "/usr/lib/python2.4/site-packages/PIL/EpsImagePlugin.py", line
75, in Ghostscript
    im = Image.core.open_ppm(file)
IOError: error when accessing file

Then I figured that for some reason gs was failing to write the
temporary file called "file".
So I printed the gs command line invocation, that looks like this:

gs -q -g142x155 -dNOPAUSE -dSAFER -sDEVICE=ppmraw
-sOutputFile=/tmp/tmpNJ2UG_ - >/dev/tty 2>/dev/tty

I tried to figure out if there could be something wrong. Since I don't
know ghostscript very well, I typed man gs, and got around a bit.
Enough to discourage me to go any further! ;)

So I though gs must be a complicated beast... I'm wondering if I'm
doing something wrong or my image is simply awful.

> (feel free to mail me a copy of your worst-case EPS file, btw.  my
> internal PIL test suite can never have too many samples...).

Sure! Thanks a lot.

stefano

From christianj at implicitnetworks.com  Thu Sep  1 18:20:21 2005
From: christianj at implicitnetworks.com (Christian M. Jensen)
Date: Thu, 1 Sep 2005 09:20:21 -0700
Subject: [Image-SIG] Read EPS (bitmap and vector),
	TIFF and PSD on windows
Message-ID: <326A1C8DE34E8E4189BE602CE7916784121F4A@corporate.implicit.implicitnetworks.com>

I have run into the same situation before for another client.

I used Visual Basic to control Photoshop. I put an HTTP server inside VB
and had it serve up requests. VB supports EPS and PDF nicely.

http://imageserver/path1/path2/image.[supported_extension].[output_exten
sion]?resize_mode=[absolute|relative|absolute_fill|absolute_fill]&x=[sca
ling_value]&y=[scaling_value]

This would open up the file with the name "image.[supported_extension]
and make a thumbnail out of it and send it back as a "output_extension"
I used MIME headers in the HTTP stream to have it render properly.

The resize mode made it so that I could request any image back at any
size and stretch, fit inside a given box or fill a box (maintaining
proportions by trimming)

I also had it so that they could request the base image as well.

I don't have the code any more :( nor could I give it out :(

Good Luck!

-----Original Message-----
From: image-sig-bounces at python.org [mailto:image-sig-bounces at python.org]
On Behalf Of Stefano Masini
Sent: Thursday, September 01, 2005 8:25 AM
To: image-sig at python.org
Subject: Re: [Image-SIG] Read EPS (bitmap and vector),TIFF and PSD on
windows

On 9/1/05, Fredrik Lundh <fredrik at pythonware.com> wrote:
> I'm not sure I see the connection -- the EPS plugin simply looks for
> EPS headers, and if found, tells ghostscript to render it to a
suitable

Here's what I got:

File "/usr/lib/python2.4/site-packages/PIL/EpsImagePlugin.py", line
75, in Ghostscript
    im = Image.core.open_ppm(file)
IOError: error when accessing file

Then I figured that for some reason gs was failing to write the
temporary file called "file".
So I printed the gs command line invocation, that looks like this:

gs -q -g142x155 -dNOPAUSE -dSAFER -sDEVICE=ppmraw
-sOutputFile=/tmp/tmpNJ2UG_ - >/dev/tty 2>/dev/tty

I tried to figure out if there could be something wrong. Since I don't
know ghostscript very well, I typed man gs, and got around a bit.
Enough to discourage me to go any further! ;)

So I though gs must be a complicated beast... I'm wondering if I'm
doing something wrong or my image is simply awful.

> (feel free to mail me a copy of your worst-case EPS file, btw.  my
> internal PIL test suite can never have too many samples...).

Sure! Thanks a lot.

stefano
_______________________________________________
Image-SIG maillist  -  Image-SIG at python.org
http://mail.python.org/mailman/listinfo/image-sig

From pete at jwgibbs.CChem.Berkeley.EDU  Sun Sep  4 23:41:25 2005
From: pete at jwgibbs.CChem.Berkeley.EDU (Pete Goodeve)
Date: Sun, 4 Sep 2005 14:41:25 -0700
Subject: [Image-SIG] Building for Python 1.5.2
Message-ID: <20050904144125.A25998@jwgibbs.CChem.Berkeley.EDU>

[I gather this is the place to send comments, even though I'm not on
the mailing list]

Folks, I feel I suffered unnecessary pain (:-/) in getting PIL working with
1.5.2 [which the README said it was supposed to work with).

(I'm using 1.5.2 rather than a newer edition for a couple of reasons:
a) It's the one currently on my Linux machine -- where I've been installing
PIL -- and I'm happy to stick with it as it meets my needs; b) my main
platform is still BeOS (!) which never got Python updated beyond that
version, and I'd rather keep parity across my systems.  Haven't even
tried to add PIL there yet...)

Anyway, I hit several blocks on the way to get PIL working (which it
now is).  Best to mention my solution first, I think.

In _imaging.c I had to add:

 #define PyObject_New PyObject_NEW
 #define PyMem_Del PyMem_DEL

because the Python header files (actually 'objimpl.h') define the
latter symbols, but the code uses the first!

The first mismatch showed up obscurely as a syntax error in compiling
(and it took a while to find the reason...), but the second didn't
show up until selftest.py, where I got the (apparently not uncommon!)
rather unhelpful message "_imaging C Module not installed".  I eventually
found this by patching out the try/except statements in selftest.py
and Image.py, so that I got an actual traceback (which told me 'PyMem_Del'
was undefined).

The "...not installed" message was puzzling, because I could *see*
"_imaging.so" sitting there!  Might I suggest that something like
"Could not import the _imaging C module" might be more appropriate?
Even better to pass the traceback on, so that problems such as I
hit become visible.

I encountered another slight apparent problem with setup.py.  It
seems that it looks for libjpeg, but doesn't test for the presence
of the header files, even though it needs them.  I originally had no
link from plain libjpeg.so to the libjpeg.62... files which were
actually present, so setup.py bypassed JPEG entirely.  When I made that
link, it accepted JPEG but then failed at the compile stage.  Installing
the headers gave me a full PIL.

Hope that's helpful.

Cheers,
					-- Pete --


From hoffman.mm at gmail.com  Wed Sep  7 18:07:10 2005
From: hoffman.mm at gmail.com (Michael Hoffman)
Date: Wed, 07 Sep 2005 17:07:10 +0100
Subject: [Image-SIG] ImageChops.logical_and not working?
Message-ID: <dfn37f$ehp$1@sea.gmane.org>

Hello. Using PIL 1.1.5, I am trying to do logical ands on bitmap
images using ImageChops.logical_and. I seem to always get completely 
black images instead, however.

Here's a simple testcase:

"""
import Image, ImageChops, ImageDraw

im1 = Image.new("1", (50, 50))
im2 = im1.copy()
im3 = im1.copy()

draw1 = ImageDraw.Draw(im1)
draw1.rectangle([0, 0, 40, 40], fill=255)

draw2 = ImageDraw.Draw(im2)
draw2.rectangle([10, 10, 50, 50], fill=255)

im1.show()
im2.show()

# this doesn't work:
ImageChops.logical_and(im1, im2).show()

# I expect it to work like this:
im3.putdata([x1 & x2 for x1, x2 in zip(im1.getdata(), im2.getdata())])
im3.show()

# this does work:
ImageChops.logical_or(im1, im2).show()
"""

Is there another way to perform a logical and operation?

Thank you,
--
Michael Hoffman


From Chris.Barker at noaa.gov  Wed Sep  7 19:00:27 2005
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Wed, 07 Sep 2005 10:00:27 -0700
Subject: [Image-SIG] Auto level with PIL?
Message-ID: <431F1CAB.1050202@noaa.gov>

Hi all,

I need to do something like Photoshop's Auto Level to a bunch of images. 
Honestly, I have only a vague idea of what it does, but I saw that 
someone posted a script to do it here about 6 years ago, but I can't 
seem to get that code from the list archives. It's also possible that 
someone has improved upon it in all those years. Has anyone got any code 
for this?

A pointer to a good description of what auto level is would be nice too.

-thanks,

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From gwidion at mpc.com.br  Wed Sep  7 19:12:57 2005
From: gwidion at mpc.com.br (Joao S. O. Bueno Calligaris)
Date: Wed, 7 Sep 2005 14:12:57 -0300
Subject: [Image-SIG] Auto level with PIL?
In-Reply-To: <431F1CAB.1050202@noaa.gov>
References: <431F1CAB.1050202@noaa.gov>
Message-ID: <200509071412.58515.gwidion@mpc.com.br>

Hi,

If you can't find an autolevel  to use with PIL, maybe yyou can use 
the GIMP instead.
It is scriptable in python as well.

	JS
	-><-

On Wednesday 07 September 2005 14:00, Chris Barker wrote:
> Hi all,
>
> I need to do something like Photoshop's Auto Level to a bunch of
> images. Honestly, I have only a vague idea of what it does, but I
> saw that someone posted a script to do it here about 6 years ago,
> but I can't seem to get that code from the list archives. It's also
> possible that someone has improved upon it in all those years. Has
> anyone got any code for this?
>
> A pointer to a good description of what auto level is would be nice
> too.
>
> -thanks,
>
> -Chris

From fredrik at pythonware.com  Wed Sep  7 19:53:16 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 7 Sep 2005 19:53:16 +0200
Subject: [Image-SIG] Auto level with PIL?
References: <431F1CAB.1050202@noaa.gov>
Message-ID: <dfn9e2$9r8$1@sea.gmane.org>

Chris Barker wrote:

> I need to do something like Photoshop's Auto Level to a bunch of images.
> Honestly, I have only a vague idea of what it does, but I saw that
> someone posted a script to do it here about 6 years ago, but I can't
> seem to get that code from the list archives.

this one?

http://aspn.activestate.com/ASPN/Mail/Message/image-sig/582729

here's the code from that post:

# adjust levels to fill histogram
# Kevin Cazabon, 1999.  kcazabon at rogers.wave.ca  kcaza at cymbolic.com

def levels(data, all_same = 0, clip = 0):

    if data.mode not in ['RGB', 'CMYK']:
        return data

    lut = makelut(data, all_same, clip)

    data = data.point(lut)

    return data

def find_hi_lo(lut, clip):
    min = None
    max = None

    for i in range(len(lut)):
        if lut[i] > clip:
            min = i
            break

    lut.reverse()

    for i in range(len(lut)):
        if lut[i] > clip:
            max = 255 - i
            break

    return min, max

def scale(channels, min, max):
    lut = []
    for i in range (channels):
        for i in range(256):
            value = int((i - min)*(255.0/float(max-min)))
            if value < 0:
                value = 0
            if value > 255:
                value = 255
            lut.append(value)

    return lut


def makelut(data, all_same, clip):
    import Image

    histogram = data.histogram()

    lut = []
    r, g, b, k = [], [], [], []

    channels = len(histogram)/256

    for i in range(256):
        r.append(histogram[i])
        g.append(histogram[256+i])
        b.append(histogram[512+i])
    if channels == 4:
        for i in range(256):
            k.append(histogram[768+i])


    rmin, rmax = find_hi_lo(r, clip)
    gmin, gmax = find_hi_lo(g, clip)
    bmin, bmax = find_hi_lo(b, clip)
    if channels == 4:
        kmin, kmax = find_hi_lo(k)
    else:
        kmin, kmax = 128, 128

    if all_same == 1:

        min_max = [rmin, gmin, bmin, kmin, rmax, gmax, bmax, kmax]
        min_max.sort()
        lut = scale(channels, min_max[0], min_max[-1])

    else:

        r_lut = scale(1, rmin, rmax)
        g_lut = scale(1, gmin, gmax)
        b_lut = scale(1, bmin, bmax)
        if channels == 4:
            k_lut = scale(1, kmin, kmax)

        lut = []

        for i in range (256):
            lut.append(r_lut[i])
        for i in range (256):
            lut.append(g_lut[i])
        for i in range (256):
            lut.append(b_lut[i])
        if channels == 4:
            for i in range (256):
                lut.append(k_lut[i])

    return lut




From stefano at pragma2000.com  Wed Sep  7 22:09:34 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Wed, 7 Sep 2005 22:09:34 +0200
Subject: [Image-SIG] Auto level with PIL?
In-Reply-To: <431F1CAB.1050202@noaa.gov>
References: <431F1CAB.1050202@noaa.gov>
Message-ID: <43274224050907130978a739e8@mail.gmail.com>

Autolevel basically works by analyzing the histogram of the image.
The histogram of an 8-bit image is basically a set of 256 counters
(32767 if working in 16-bit mode) for each channel. Each one counts
how many bits are the in the image for the specified intensity value.
A pixel with color (100, 200, 150) increments by one the 100th red
counter, the 200th green one and the 150th blue one.
After building the histogram, you look at the lowest value that counts
at least one pixel, and the highest. Say that in your image no pixel
has a colour darker than (10, 15, 7) and no one brighter than (250,
247, 200). It means that the range of your image is 7-250.
Last step, you scale the values of each pixels proportionally so that
7 becomes 0, 250 becomes 255 and whatever in between is proportionally
scaled.

it's a rough explanation... but I hope it helps.
-stefano

On 9/7/05, Chris Barker <Chris.Barker at noaa.gov> wrote:
> Hi all,
> 
> I need to do something like Photoshop's Auto Level to a bunch of images.
> Honestly, I have only a vague idea of what it does, but I saw that
> someone posted a script to do it here about 6 years ago, but I can't
> seem to get that code from the list archives. It's also possible that
> someone has improved upon it in all those years. Has anyone got any code
> for this?
> 
> A pointer to a good description of what auto level is would be nice too.
> 
> -thanks,
> 
> -Chris
> 
> 
> 
> --
> Christopher Barker, Ph.D.
> Oceanographer
> 
> NOAA/OR&R/HAZMAT         (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
> 
> Chris.Barker at noaa.gov
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From stefano at pragma2000.com  Wed Sep  7 22:10:14 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Wed, 7 Sep 2005 22:10:14 +0200
Subject: [Image-SIG] Auto level with PIL?
In-Reply-To: <dfn9e2$9r8$1@sea.gmane.org>
References: <431F1CAB.1050202@noaa.gov> <dfn9e2$9r8$1@sea.gmane.org>
Message-ID: <432742240509071310469fbbda@mail.gmail.com>

In this code all_same defaults to 0. The author says:
"I find the BEST way to color/density correct an image is to first set
the black/white point for each of the channels individually, so that
you use the entire available dynamic range."
While this is true, I must point out that you risk skewing the hue for
very dark colors and very bright ones. I think setting all_same to 1
would be a more color conservative option.

cheers,
-stefano

On 9/7/05, Fredrik Lundh <fredrik at pythonware.com> wrote:
> Chris Barker wrote:
> 
> > I need to do something like Photoshop's Auto Level to a bunch of images.
> > Honestly, I have only a vague idea of what it does, but I saw that
> > someone posted a script to do it here about 6 years ago, but I can't
> > seem to get that code from the list archives.
> 
> this one?
> 
> http://aspn.activestate.com/ASPN/Mail/Message/image-sig/582729
>

From Chris.Barker at noaa.gov  Wed Sep  7 23:47:53 2005
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Wed, 07 Sep 2005 14:47:53 -0700
Subject: [Image-SIG] Auto level with PIL?
In-Reply-To: <432742240509071310469fbbda@mail.gmail.com>
References: <431F1CAB.1050202@noaa.gov> <dfn9e2$9r8$1@sea.gmane.org>
	<432742240509071310469fbbda@mail.gmail.com>
Message-ID: <431F6009.3030608@noaa.gov>

Thanks Stefano, this make sit much more clear what's going on. I'll give 
this code a try.

-chris
-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From bend at bedel.mine.nu  Thu Sep  8 00:59:51 2005
From: bend at bedel.mine.nu (Ben de Luca)
Date: Thu, 8 Sep 2005 08:59:51 +1000
Subject: [Image-SIG] Auto level with PIL?
In-Reply-To: <200509071412.58515.gwidion@mpc.com.br>
References: <431F1CAB.1050202@noaa.gov> <200509071412.58515.gwidion@mpc.com.br>
Message-ID: <94884D28-814A-4248-9C02-FAB5C56D3654@bedel.mine.nu>

Could you point me at some information about the gimp scripting in  
python. The only python things I found were woefully out of date.


On 08/09/2005, at 3:12 AM, Joao S. O. Bueno Calligaris wrote:

> Hi,
>
> If you can't find an autolevel  to use with PIL, maybe yyou can use
> the GIMP instead.
> It is scriptable in python as well.
>
>     JS
>     -><-
>
> On Wednesday 07 September 2005 14:00, Chris Barker wrote:
>
>> Hi all,
>>
>> I need to do something like Photoshop's Auto Level to a bunch of
>> images. Honestly, I have only a vague idea of what it does, but I
>> saw that someone posted a script to do it here about 6 years ago,
>> but I can't seem to get that code from the list archives. It's also
>> possible that someone has improved upon it in all those years. Has
>> anyone got any code for this?
>>
>> A pointer to a good description of what auto level is would be nice
>> too.
>>
>> -thanks,
>>
>> -Chris
>>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>


From gwidion at mpc.com.br  Thu Sep  8 05:21:08 2005
From: gwidion at mpc.com.br (Joao S. O. Bueno Calligaris)
Date: Thu, 8 Sep 2005 00:21:08 -0300
Subject: [Image-SIG] Auto level with PIL?
In-Reply-To: <94884D28-814A-4248-9C02-FAB5C56D3654@bedel.mine.nu>
References: <431F1CAB.1050202@noaa.gov> <200509071412.58515.gwidion@mpc.com.br>
	<94884D28-814A-4248-9C02-FAB5C56D3654@bedel.mine.nu>
Message-ID: <200509080021.08681.gwidion@mpc.com.br>

On Wednesday 07 September 2005 19:59, Ben de Luca wrote:
> Could you point me at some information about the gimp scripting in
> python. The only python things I found were woefully out of date.
>

The cenonicakl reference is still the aparently out of date page at:

www.jamesh.id.au/software/pygimp/


The way the plugins are built did not change. Basically, the steps are 
these:
make a python script, and save it in a gimp - plugins directory (you 
can see which are these under the preferences dialog in the GIMP)
Include the module "gimpfu".
At the end of your script call both gimpfu.register function, as 
documented in the above url, and gimpfu.main ().
A call for yor script will show up in the menus in the GIMP.

What is newere than these documentation is the GIMP API - but this one 
can be consulted on ine with the Procedural Database Browser, in the 
GIMP  "Xtns" menu.

regards!
	JS
	-><-


> On 08/09/2005, at 3:12 AM, Joao S. O. Bueno Calligaris wrote:
> > Hi,
> >
> > If you can't find an autolevel  to use with PIL, maybe yyou can
> > use the GIMP instead.
> > It is scriptable in python as well.
> >
> >     JS
> >     -><-
> >
> > On Wednesday 07 September 2005 14:00, Chris Barker wrote:
> >> Hi all,
> >>
> >> I need to do something like Photoshop's Auto Level to a bunch of
> >> images. Honestly, I have only a vague idea of what it does, but
> >> I saw that someone posted a script to do it here about 6 years
> >> ago, but I can't seem to get that code from the list archives.
> >> It's also possible that someone has improved upon it in all
> >> those years. Has anyone got any code for this?
> >>
> >> A pointer to a good description of what auto level is would be
> >> nice too.
> >>
> >> -thanks,
> >>
> >> -Chris
> >
> > _______________________________________________
> > Image-SIG maillist  -  Image-SIG at python.org
> > http://mail.python.org/mailman/listinfo/image-sig

From stefano at pragma2000.com  Thu Sep  8 07:10:50 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Thu, 8 Sep 2005 07:10:50 +0200
Subject: [Image-SIG] Auto level with PIL?
In-Reply-To: <200509080021.08681.gwidion@mpc.com.br>
References: <431F1CAB.1050202@noaa.gov> <200509071412.58515.gwidion@mpc.com.br>
	<94884D28-814A-4248-9C02-FAB5C56D3654@bedel.mine.nu>
	<200509080021.08681.gwidion@mpc.com.br>
Message-ID: <432742240509072210570c095c@mail.gmail.com>

On 9/8/05, Joao S. O. Bueno Calligaris <gwidion at mpc.com.br> wrote:
> The cenonicakl reference is still the aparently out of date page at:
> 
> www.jamesh.id.au/software/pygimp/

This looks like a way to write python scripts that run _within_ Gimp.
In fact, the documentation says the system also takes care of details
like the gui, and all seems like running interactively.

Chris on the other hand seems like not wanting such an interactive
approach. Or, to say it differently, if he's ok with triggering the
thing with mouse clicks, why doesn't he simply create a Photoshop
action?

So, if what he really needs is batch processing of images, maybe out
of a crontab or driven by the click on a web interface, he can't
really use an interactive tool.

If PIL is not enough, or simply he does not want to go as low level as
reimplementing the algorithms himself, he could use gimp in batch
mode. I found this tutorial talking about it:
http://gimp.org/tutorials/Basic_Batch/

In the example it actually applies an unsharp mask to a bunch of
images in a directory, so probably something very similar to what
Chris needs to do.

Scriptfu can be quite powerful because it's basically a program
written in the Scheme language. But it's not python... :( I don't know
if pygimp allows batch processing as well. If it doesn't, then I guess
the only chance would be to use python to generate scheme code
snippets on the fly and feed them to gimp.

cheers,
stefano

From ajs17 at cornell.edu  Thu Sep  8 16:10:43 2005
From: ajs17 at cornell.edu (Adam J Smith)
Date: Thu, 8 Sep 2005 10:10:43 -0400 (EDT)
Subject: [Image-SIG] [Fwd: reaching memory limits with crop method]
Message-ID: <1373.69.207.47.7.1126188643.squirrel@69.207.47.7>


Just following up to see if anyone out there has any thoughts on my
original post below, as my own research into the issue has not gotten me
very far. Any help at all will be greatly appreciated.

---------------------------- Original Message ----------------------------
Subject: reaching memory limits with crop method
From:    "Adam J Smith" <ajs17 at cornell.edu>
Date:    Wed, August 31, 2005 10:20 am
To:      image-sig at python.org
--------------------------------------------------------------------------



We are encountering memory errors while processing very large images (over
3Gb TIFFs, 17888x45408 px). We are trying to make "tiles" of the image by
calling PIL's crop method and saving the resulting images. Eventually, we
see this error:

Traceback (most recent call last):
          File "/insitu1/lavers2/ZoomifyImage/ZoomifyFileProcessor.py",
line 135, in ?
            processor.ZoomifyProcess(sys.argv[1:])
          File "/insitu1/lavers2/ZoomifyImage/ZoomifyFileProcessor.py",
line 127, in ZoomifyProcess
            self.processImage()
          File "/home/lavers2/ZoomifyImage/ZoomifyBase.py", line 199,
in processImage
            imageRow = image.crop([0, ul_y, self.originalWidth, lr_y])
          File
"/home/lavers2/python/lib/python2.4/site-packages/PIL/Image.py",
line 673, in crop
            self.load()
          File
"/home/lavers2/python/lib/python2.4/site-packages/PIL/ImageFile.py", line
155, in load
            self.load_prepare()
          File
"/home/lavers2/python/lib/python2.4/site-packages/PIL/ImageFile.py", line
221, in load_prepare
            self.im = Image.core.new(self.mode, self.size)
        MemoryError

This is on a linux box with 2Gb of RAM, 3Gb of swap space, using PIL 1.1.4.

As I understand it, the load() method loads the entire image into memory,
and although there appears to be some ways to stream image data through
PIL for processing, it looks like you can't use this type of approach with
the crop() method. Am I wrong about this, or is there another way to
accomplish the same type of thing (saving a region of an image as an
image) without using crop()?

Thanks in advance for any guidance you can give.

____________________________
adam smith
ajs17 at cornell.edu
255-8893
215 ccc




From gwidion at mpc.com.br  Thu Sep  8 16:43:22 2005
From: gwidion at mpc.com.br (Joao S. O. Bueno Calligaris)
Date: Thu, 8 Sep 2005 11:43:22 -0300
Subject: [Image-SIG] [Fwd: reaching memory limits with crop method]
In-Reply-To: <1373.69.207.47.7.1126188643.squirrel@69.207.47.7>
References: <1373.69.207.47.7.1126188643.squirrel@69.207.47.7>
Message-ID: <200509081143.22634.gwidion@mpc.com.br>

On Thursday 08 September 2005 11:10, Adam J Smith wrote:
> Just following up to see if anyone out there has any thoughts on my
> original post below, as my own research into the issue has not
> gotten me very far. Any help at all will be greatly appreciated.


Hi, 
I've worked with some large tiffs using C and libtiff straigth, in the 
beggining of this year. At this low level one can choose how much of 
an image to read at a time. It is quite harde than doing so in 
Python, but maybe it is the way to go in this case. 

If you want to try it this way, feel free to contact me in private.

To the list: I apologize for suggesting solutions that are not PIL 
(this is the second thread in a row in which I do this). I like PIL, 
I am just suggesting other tools that I had used for similar tasks 
than those asked and which I do not know to acomplish with PIL.

Regards,

	JS
	-><-

>
> ---------------------------- Original Message
> ---------------------------- Subject: reaching memory limits with
> crop method
> From:    "Adam J Smith" <ajs17 at cornell.edu>
> Date:    Wed, August 31, 2005 10:20 am
> To:      image-sig at python.org
> -------------------------------------------------------------------
>-------
>
>
>
> We are encountering memory errors while processing very large
> images (over 3Gb TIFFs, 17888x45408 px). We are trying to make
> "tiles" of the image by calling PIL's crop method and saving the
> resulting images. Eventually, we see this error:
>
> Traceback (most recent call last):
>           File
> "/insitu1/lavers2/ZoomifyImage/ZoomifyFileProcessor.py", line 135,
> in ?
>             processor.ZoomifyProcess(sys.argv[1:])
>           File
> "/insitu1/lavers2/ZoomifyImage/ZoomifyFileProcessor.py", line 127,
> in ZoomifyProcess
>             self.processImage()
>           File "/home/lavers2/ZoomifyImage/ZoomifyBase.py", line
> 199, in processImage
>             imageRow = image.crop([0, ul_y, self.originalWidth,
> lr_y]) File
> "/home/lavers2/python/lib/python2.4/site-packages/PIL/Image.py",
> line 673, in crop
>             self.load()
>           File
> "/home/lavers2/python/lib/python2.4/site-packages/PIL/ImageFile.py"
>, line 155, in load
>             self.load_prepare()
>           File
> "/home/lavers2/python/lib/python2.4/site-packages/PIL/ImageFile.py"
>, line 221, in load_prepare
>             self.im = Image.core.new(self.mode, self.size)
>         MemoryError
>
> This is on a linux box with 2Gb of RAM, 3Gb of swap space, using
> PIL 1.1.4.
>
> As I understand it, the load() method loads the entire image into
> memory, and although there appears to be some ways to stream image
> data through PIL for processing, it looks like you can't use this
> type of approach with the crop() method. Am I wrong about this, or
> is there another way to accomplish the same type of thing (saving a
> region of an image as an image) without using crop()?
>
> Thanks in advance for any guidance you can give.
>
> ____________________________
> adam smith
> ajs17 at cornell.edu
> 255-8893
> 215 ccc
>
>
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig

From fredrik at pythonware.com  Thu Sep  8 16:47:23 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 8 Sep 2005 16:47:23 +0200
Subject: [Image-SIG] reaching memory limits with crop method]
References: <1373.69.207.47.7.1126188643.squirrel@69.207.47.7>
Message-ID: <dfpitg$ih6$1@sea.gmane.org>

Adam J Smith wrote:

> Just following up to see if anyone out there has any thoughts on my
> original post below, as my own research into the issue has not gotten me
> very far. Any help at all will be greatly appreciated.

following up to the response you got may also be a good
idea:

----- Original Message ----- 
From: "Fredrik Lundh" <fredrik at pythonware.com>
Newsgroups: gmane.comp.python.image
Sent: Wednesday, August 31, 2005 5:47 PM
Subject: Re: reaching memory limits with crop method


> Adam J Smith wrote:
>
>> We are encountering memory errors while processing very large images (over
>> 3Gb TIFFs, 17888x45408 px). We are trying to make "tiles" of the image by
>> calling PIL's crop method and saving the resulting images.
>
> if you open such a file in PIL, what does the "tile" attribute contain?
> can you try the following on your files and post the result?
>
>    >>> im = Image.open("verylargetiff.tif")
>    >>> im.mode
>    >>> im.size
>    >>> im.tile
>
> </F>




From ajs17 at cornell.edu  Fri Sep  9 12:32:58 2005
From: ajs17 at cornell.edu (Adam J Smith)
Date: Fri, 9 Sep 2005 06:32:58 -0400 (EDT)
Subject: [Image-SIG] reaching memory limits with crop method]
In-Reply-To: <dfpitg$ih6$1@sea.gmane.org>
References: <dfpitg$ih6$1@sea.gmane.org>
Message-ID: <27209.69.207.47.7.1126261978.squirrel@69.207.47.7>



Fredrik Lundh said:
>following up to the response you got may also be a good
>idea:

My apologies, I see that I accidentally replied to your personal email
instead of the list. Here is it again. Does this help?


---------------------------- Original Message ----------------------------
Subject: Re: [Image-SIG] reaching memory limits with crop method
From:    "Adam J Smith" <ajs17 at cornell.edu>
Date:    Wed, August 31, 2005 1:45 pm
To:      "Fredrik Lundh" <fredrik at pythonware.com>
--------------------------------------------------------------------------

Fredrik,

Thanks for the offer to help. The following information is from a
different image than the original one that I emailed about, but this image
also causes the same memory error.

Also, I tried modifying the code to do a EXTENT transform instead of a
crop, but that method also calls load() and gives me an identical error
message.

>>> im = PIL.Image.open('/home/ajs17/Desktop/test.tif');
>>> im.mode
'RGB'
>>> im.size
(24000, 36000)
>>> im.tile
[('raw', (0, 0, 24000, 64), 8, ('RGB', 0, 1)), ('raw', (0, 64, 24000,
128), 4608008, ('RGB', 0, 1)), ('raw', (0, 128, 24000, 192), 9216008,
('RGB', 0, 1)), ('raw', (0, 192, 24000, 256), 13824008, ('RGB', 0, 1)),
('raw', (0, 256, 24000, 320), 18432008, ('RGB', 0, 1)), ('raw', (0, 320,
24000, 384), 23040008, ('RGB', 0, 1)), ('raw', (0, 384, 24000, 448),
27648008, ('RGB', 0, 1)), ('raw', (0, 448, 24000, 512), 32256008, ('RGB',
0, 1)), ('raw', (0, 512, 24000, 576), 36864008, ('RGB', 0, 1)), ('raw',
(0, 576, 24000, 640), 41472008, ('RGB', 0, 1)), ('raw', (0, 640, 24000,
704), 46080008, ('RGB', 0, 1)), ('raw', (0, 704, 24000, 768), 50688008,
('RGB', 0, 1)), ('raw', (0, 768, 24000, 832), 55296008, ('RGB', 0, 1)),
('raw', (0, 832, 24000, 896), 59904008, ('RGB', 0, 1)), ('raw', (0, 896,
24000, 960), 64512008, ('RGB', 0, 1)), ('raw', (0, 960, 24000, 1024),
69120008, ('RGB', 0, 1)), ('raw', (0, 1024, 24000, 1088), 73728008,
('RGB', 0, 1)), ('raw', (0, 1088, 24000, 1152), 78336008, ('RGB', 0, 1)),
('raw', (0, 1152, 24000, 1216), 82944008, ('RGB', 0, 1)), ('raw', (0,
1216, 24000, 1280), 87552008, ('RGB', 0, 1)), ('raw', (0, 1280, 24000,
1344), 92160008, ('RGB', 0, 1)), ('raw', (0, 1344, 24000, 1408), 96768008,
('RGB', 0, 1)), ('raw', (0, 1408, 24000, 1472), 101376008, ('RGB', 0, 1)),
('raw', (0, 1472, 24000, 1536), 105984008, ('RGB', 0, 1)), ('raw', (0,
1536, 24000, 1600), 110592008, ('RGB', 0, 1)), ('raw', (0, 1600, 24000,
1664), 115200008, ('RGB', 0, 1)), ('raw', (0, 1664, 24000, 1728),
119808008, ('RGB', 0, 1)), ('raw', (0, 1728, 24000, 1792), 124416008,
('RGB', 0, 1)), ('raw', (0, 1792, 24000, 1856), 129024008, ('RGB', 0, 1)),
('raw', (0, 1856, 24000, 1920), 133632008, ('RGB', 0, 1)), ('raw', (0,
1920, 24000, 1984), 138240008, ('RGB', 0, 1)), ('raw', (0, 1984, 24000,
2048), 142848008, ('RGB', 0, 1)), ('raw', (0, 2048, 24000, 2112),
147456008, ('RGB', 0, 1)), ('raw', (0, 2112, 24000, 2176), 152064008,
('RGB', 0, 1)), ('raw', (0, 2176, 24000, 2240), 156672008, ('RGB', 0, 1)),
('raw', (0, 2240, 24000, 2304), 161280008, ('RGB', 0, 1)), ('raw', (0,
2304, 24000, 2368), 165888008, ('RGB', 0, 1)), ('raw', (0, 2368, 24000,
2432), 170496008, ('RGB', 0, 1)), ('raw', (0, 2432, 24000, 2496),
175104008, ('RGB', 0, 1)), ('raw', (0, 2496, 24000, 2560), 179712008,
('RGB', 0, 1)), ('raw', (0, 2560, 24000, 2624), 184320008, ('RGB', 0, 1)),
('raw', (0, 2624, 24000, 2688), 188928008, ('RGB', 0, 1)), ('raw', (0,
2688, 24000, 2752), 193536008, ('RGB', 0, 1)), ('raw', (0, 2752, 24000,
2816), 198144008, ('RGB', 0, 1)), ('raw', (0, 2816, 24000, 2880),
202752008, ('RGB', 0, 1)), ('raw', (0, 2880, 24000, 2944), 207360008,
('RGB', 0, 1)), ('raw', (0, 2944, 24000, 3008), 211968008, ('RGB', 0, 1)),
('raw', (0, 3008, 24000, 3072), 216576008, ('RGB', 0, 1)), ('raw', (0,
3072, 24000, 3136), 221184008, ('RGB', 0, 1)), ('raw', (0, 3136, 24000,
3200), 225792008, ('RGB', 0, 1)), ('raw', (0, 3200, 24000, 3264),
230400008, ('RGB', 0, 1)), ('raw', (0, 3264, 24000, 3328), 235008008,
('RGB', 0, 1)), ('raw', (0, 3328, 24000, 3392), 239616008, ('RGB', 0, 1)),
('raw', (0, 3392, 24000, 3456), 244224008, ('RGB', 0, 1)), ('raw', (0,
3456, 24000, 3520), 248832008, ('RGB', 0, 1)), ('raw', (0, 3520, 24000,
3584), 253440008, ('RGB', 0, 1)), ('raw', (0, 3584, 24000, 3648),
258048008, ('RGB', 0, 1)), ('raw', (0, 3648, 24000, 3712), 262656008,
('RGB', 0, 1)), ('raw', (0, 3712, 24000, 3776), 267264008, ('RGB', 0, 1)),
('raw', (0, 3776, 24000, 3840), 271872008, ('RGB', 0, 1)), ('raw', (0,
3840, 24000, 3904), 276480008, ('RGB', 0, 1)), ('raw', (0, 3904, 24000,
3968), 281088008, ('RGB', 0, 1)), ('raw', (0, 3968, 24000, 4032),
285696008, ('RGB', 0, 1)), ('raw', (0, 4032, 24000, 4096), 290304008,
('RGB', 0, 1)), ('raw', (0, 4096, 24000, 4160), 294912008, ('RGB', 0, 1)),
('raw', (0, 4160, 24000, 4224), 299520008, ('RGB', 0, 1)), ('raw', (0,
4224, 24000, 4288), 304128008, ('RGB', 0, 1)), ('raw', (0, 4288, 24000,
4352), 308736008, ('RGB', 0, 1)), ('raw', (0, 4352, 24000, 4416),
313344008, ('RGB', 0, 1)), ('raw', (0, 4416, 24000, 4480), 317952008,
('RGB', 0, 1)), ('raw', (0, 4480, 24000, 4544), 322560008, ('RGB', 0, 1)),
('raw', (0, 4544, 24000, 4608), 327168008, ('RGB', 0, 1)), ('raw', (0,
4608, 24000, 4672), 331776008, ('RGB', 0, 1)), ('raw', (0, 4672, 24000,
4736), 336384008, ('RGB', 0, 1)), ('raw', (0, 4736, 24000, 4800),
340992008, ('RGB', 0, 1)), ('raw', (0, 4800, 24000, 4864), 345600008,
('RGB', 0, 1)), ('raw', (0, 4864, 24000, 4928), 350208008, ('RGB', 0, 1)),
('raw', (0, 4928, 24000, 4992), 354816008, ('RGB', 0, 1)), ('raw', (0,
4992, 24000, 5056), 359424008, ('RGB', 0, 1)), ('raw', (0, 5056, 24000,
5120), 364032008, ('RGB', 0, 1)), ('raw', (0, 5120, 24000, 5184),
368640008, ('RGB', 0, 1)), ('raw', (0, 5184, 24000, 5248), 373248008,
('RGB', 0, 1)), ('raw', (0, 5248, 24000, 5312), 377856008, ('RGB', 0, 1)),
('raw', (0, 5312, 24000, 5376), 382464008, ('RGB', 0, 1)), ('raw', (0,
5376, 24000, 5440), 387072008, ('RGB', 0, 1)), ('raw', (0, 5440, 24000,
5504), 391680008, ('RGB', 0, 1)), ('raw', (0, 5504, 24000, 5568),
396288008, ('RGB', 0, 1)), ('raw', (0, 5568, 24000, 5632), 400896008,
('RGB', 0, 1)), ('raw', (0, 5632, 24000, 5696), 405504008, ('RGB', 0, 1)),
('raw', (0, 5696, 24000, 5760), 410112008, ('RGB', 0, 1)), ('raw', (0,
5760, 24000, 5824), 414720008, ('RGB', 0, 1)), ('raw', (0, 5824, 24000,
5888), 419328008, ('RGB', 0, 1)), ('raw', (0, 5888, 24000, 5952),
423936008, ('RGB', 0, 1)), ('raw', (0, 5952, 24000, 6016), 428544008,
('RGB', 0, 1)), ('raw', (0, 6016, 24000, 6080), 433152008, ('RGB', 0, 1)),
('raw', (0, 6080, 24000, 6144), 437760008, ('RGB', 0, 1)), ('raw', (0,
6144, 24000, 6208), 442368008, ('RGB', 0, 1)), ('raw', (0, 6208, 24000,
6272), 446976008, ('RGB', 0, 1)), ('raw', (0, 6272, 24000, 6336),
451584008, ('RGB', 0, 1)), ('raw', (0, 6336, 24000, 6400), 456192008,
('RGB', 0, 1)), ('raw', (0, 6400, 24000, 6464), 460800008, ('RGB', 0, 1)),
('raw', (0, 6464, 24000, 6528), 465408008, ('RGB', 0, 1)), ('raw', (0,
6528, 24000, 6592), 470016008, ('RGB', 0, 1)), ('raw', (0, 6592, 24000,
6656), 474624008, ('RGB', 0, 1)), ('raw', (0, 6656, 24000, 6720),
479232008, ('RGB', 0, 1)), ('raw', (0, 6720, 24000, 6784), 483840008,
('RGB', 0, 1)), ('raw', (0, 6784, 24000, 6848), 488448008, ('RGB', 0, 1)),
('raw', (0, 6848, 24000, 6912), 493056008, ('RGB', 0, 1)), ('raw', (0,
6912, 24000, 6976), 497664008, ('RGB', 0, 1)), ('raw', (0, 6976, 24000,
7040), 502272008, ('RGB', 0, 1)), ('raw', (0, 7040, 24000, 7104),
506880008, ('RGB', 0, 1)), ('raw', (0, 7104, 24000, 7168), 511488008,
('RGB', 0, 1)), ('raw', (0, 7168, 24000, 7232), 516096008, ('RGB', 0, 1)),
('raw', (0, 7232, 24000, 7296), 520704008, ('RGB', 0, 1)), ('raw', (0,
7296, 24000, 7360), 525312008, ('RGB', 0, 1)), ('raw', (0, 7360, 24000,
7424), 529920008, ('RGB', 0, 1)), ('raw', (0, 7424, 24000, 7488),
534528008, ('RGB', 0, 1)), ('raw', (0, 7488, 24000, 7552), 539136008,
('RGB', 0, 1)), ('raw', (0, 7552, 24000, 7616), 543744008, ('RGB', 0, 1)),
('raw', (0, 7616, 24000, 7680), 548352008, ('RGB', 0, 1)), ('raw', (0,
7680, 24000, 7744), 552960008, ('RGB', 0, 1)), ('raw', (0, 7744, 24000,
7808), 557568008, ('RGB', 0, 1)), ('raw', (0, 7808, 24000, 7872),
562176008, ('RGB', 0, 1)), ('raw', (0, 7872, 24000, 7936), 566784008,
('RGB', 0, 1)), ('raw', (0, 7936, 24000, 8000), 571392008, ('RGB', 0, 1)),
('raw', (0, 8000, 24000, 8064), 576000008, ('RGB', 0, 1)), ('raw', (0,
8064, 24000, 8128), 580608008, ('RGB', 0, 1)), ('raw', (0, 8128, 24000,
8192), 585216008, ('RGB', 0, 1)), ('raw', (0, 8192, 24000, 8256),
589824008, ('RGB', 0, 1)), ('raw', (0, 8256, 24000, 8320), 594432008,
('RGB', 0, 1)), ('raw', (0, 8320, 24000, 8384), 599040008, ('RGB', 0, 1)),
('raw', (0, 8384, 24000, 8448), 603648008, ('RGB', 0, 1)), ('raw', (0,
8448, 24000, 8512), 608256008, ('RGB', 0, 1)), ('raw', (0, 8512, 24000,
8576), 612864008, ('RGB', 0, 1)), ('raw', (0, 8576, 24000, 8640),
617472008, ('RGB', 0, 1)), ('raw', (0, 8640, 24000, 8704), 622080008,
('RGB', 0, 1)), ('raw', (0, 8704, 24000, 8768), 626688008, ('RGB', 0, 1)),
('raw', (0, 8768, 24000, 8832), 631296008, ('RGB', 0, 1)), ('raw', (0,
8832, 24000, 8896), 635904008, ('RGB', 0, 1)), ('raw', (0, 8896, 24000,
8960), 640512008, ('RGB', 0, 1)), ('raw', (0, 8960, 24000, 9024),
645120008, ('RGB', 0, 1)), ('raw', (0, 9024, 24000, 9088), 649728008,
('RGB', 0, 1)), ('raw', (0, 9088, 24000, 9152), 654336008, ('RGB', 0, 1)),
('raw', (0, 9152, 24000, 9216), 658944008, ('RGB', 0, 1)), ('raw', (0,
9216, 24000, 9280), 663552008, ('RGB', 0, 1)), ('raw', (0, 9280, 24000,
9344), 668160008, ('RGB', 0, 1)), ('raw', (0, 9344, 24000, 9408),
672768008, ('RGB', 0, 1)), ('raw', (0, 9408, 24000, 9472), 677376008,
('RGB', 0, 1)), ('raw', (0, 9472, 24000, 9536), 681984008, ('RGB', 0, 1)),
('raw', (0, 9536, 24000, 9600), 686592008, ('RGB', 0, 1)), ('raw', (0,
9600, 24000, 9664), 691200008, ('RGB', 0, 1)), ('raw', (0, 9664, 24000,
9728), 695808008, ('RGB', 0, 1)), ('raw', (0, 9728, 24000, 9792),
700416008, ('RGB', 0, 1)), ('raw', (0, 9792, 24000, 9856), 705024008,
('RGB', 0, 1)), ('raw', (0, 9856, 24000, 9920), 709632008, ('RGB', 0, 1)),
('raw', (0, 9920, 24000, 9984), 714240008, ('RGB', 0, 1)), ('raw', (0,
9984, 24000, 10048), 718848008, ('RGB', 0, 1)), ('raw', (0, 10048, 24000,
10112), 723456008, ('RGB', 0, 1)), ('raw', (0, 10112, 24000, 10176),
728064008, ('RGB', 0, 1)), ('raw', (0, 10176, 24000, 10240), 732672008,
('RGB', 0, 1)), ('raw', (0, 10240, 24000, 10304), 737280008, ('RGB', 0,
1)), ('raw', (0, 10304, 24000, 10368), 741888008, ('RGB', 0, 1)), ('raw',
(0, 10368, 24000, 10432), 746496008, ('RGB', 0, 1)), ('raw', (0, 10432,
24000, 10496), 751104008, ('RGB', 0, 1)), ('raw', (0, 10496, 24000,
10560), 755712008, ('RGB', 0, 1)), ('raw', (0, 10560, 24000, 10624),
760320008, ('RGB', 0, 1)), ('raw', (0, 10624, 24000, 10688), 764928008,
('RGB', 0, 1)), ('raw', (0, 10688, 24000, 10752), 769536008, ('RGB', 0,
1)), ('raw', (0, 10752, 24000, 10816), 774144008, ('RGB', 0, 1)), ('raw',
(0, 10816, 24000, 10880), 778752008, ('RGB', 0, 1)), ('raw', (0, 10880,
24000, 10944), 783360008, ('RGB', 0, 1)), ('raw', (0, 10944, 24000,
11008), 787968008, ('RGB', 0, 1)), ('raw', (0, 11008, 24000, 11072),
792576008, ('RGB', 0, 1)), ('raw', (0, 11072, 24000, 11136), 797184008,
('RGB', 0, 1)), ('raw', (0, 11136, 24000, 11200), 801792008, ('RGB', 0,
1)), ('raw', (0, 11200, 24000, 11264), 806400008, ('RGB', 0, 1)), ('raw',
(0, 11264, 24000, 11328), 811008008, ('RGB', 0, 1)), ('raw', (0, 11328,
24000, 11392), 815616008, ('RGB', 0, 1)), ('raw', (0, 11392, 24000,
11456), 820224008, ('RGB', 0, 1)), ('raw', (0, 11456, 24000, 11520),
824832008, ('RGB', 0, 1)), ('raw', (0, 11520, 24000, 11584), 829440008,
('RGB', 0, 1)), ('raw', (0, 11584, 24000, 11648), 834048008, ('RGB', 0,
1)), ('raw', (0, 11648, 24000, 11712), 838656008, ('RGB', 0, 1)), ('raw',
(0, 11712, 24000, 11776), 843264008, ('RGB', 0, 1)), ('raw', (0, 11776,
24000, 11840), 847872008, ('RGB', 0, 1)), ('raw', (0, 11840, 24000,
11904), 852480008, ('RGB', 0, 1)), ('raw', (0, 11904, 24000, 11968),
857088008, ('RGB', 0, 1)), ('raw', (0, 11968, 24000, 12032), 861696008,
('RGB', 0, 1)), ('raw', (0, 12032, 24000, 12096), 866304008, ('RGB', 0,
1)), ('raw', (0, 12096, 24000, 12160), 870912008, ('RGB', 0, 1)), ('raw',
(0, 12160, 24000, 12224), 875520008, ('RGB', 0, 1)), ('raw', (0, 12224,
24000, 12288), 880128008, ('RGB', 0, 1)), ('raw', (0, 12288, 24000,
12352), 884736008, ('RGB', 0, 1)), ('raw', (0, 12352, 24000, 12416),
889344008, ('RGB', 0, 1)), ('raw', (0, 12416, 24000, 12480), 893952008,
('RGB', 0, 1)), ('raw', (0, 12480, 24000, 12544), 898560008, ('RGB', 0,
1)), ('raw', (0, 12544, 24000, 12608), 903168008, ('RGB', 0, 1)), ('raw',
(0, 12608, 24000, 12672), 907776008, ('RGB', 0, 1)), ('raw', (0, 12672,
24000, 12736), 912384008, ('RGB', 0, 1)), ('raw', (0, 12736, 24000,
12800), 916992008, ('RGB', 0, 1)), ('raw', (0, 12800, 24000, 12864),
921600008, ('RGB', 0, 1)), ('raw', (0, 12864, 24000, 12928), 926208008,
('RGB', 0, 1)), ('raw', (0, 12928, 24000, 12992), 930816008, ('RGB', 0,
1)), ('raw', (0, 12992, 24000, 13056), 935424008, ('RGB', 0, 1)), ('raw',
(0, 13056, 24000, 13120), 940032008, ('RGB', 0, 1)), ('raw', (0, 13120,
24000, 13184), 944640008, ('RGB', 0, 1)), ('raw', (0, 13184, 24000,
13248), 949248008, ('RGB', 0, 1)), ('raw', (0, 13248, 24000, 13312),
953856008, ('RGB', 0, 1)), ('raw', (0, 13312, 24000, 13376), 958464008,
('RGB', 0, 1)), ('raw', (0, 13376, 24000, 13440), 963072008, ('RGB', 0,
1)), ('raw', (0, 13440, 24000, 13504), 967680008, ('RGB', 0, 1)), ('raw',
(0, 13504, 24000, 13568), 972288008, ('RGB', 0, 1)), ('raw', (0, 13568,
24000, 13632), 976896008, ('RGB', 0, 1)), ('raw', (0, 13632, 24000,
13696), 981504008, ('RGB', 0, 1)), ('raw', (0, 13696, 24000, 13760),
986112008, ('RGB', 0, 1)), ('raw', (0, 13760, 24000, 13824), 990720008,
('RGB', 0, 1)), ('raw', (0, 13824, 24000, 13888), 995328008, ('RGB', 0,
1)), ('raw', (0, 13888, 24000, 13952), 999936008, ('RGB', 0, 1)), ('raw',
(0, 13952, 24000, 14016), 1004544008, ('RGB', 0, 1)), ('raw', (0, 14016,
24000, 14080), 1009152008, ('RGB', 0, 1)), ('raw', (0, 14080, 24000,
14144), 1013760008, ('RGB', 0, 1)), ('raw', (0, 14144, 24000, 14208),
1018368008, ('RGB', 0, 1)), ('raw', (0, 14208, 24000, 14272), 1022976008,
('RGB', 0, 1)), ('raw', (0, 14272, 24000, 14336), 1027584008, ('RGB', 0,
1)), ('raw', (0, 14336, 24000, 14400), 1032192008, ('RGB', 0, 1)), ('raw',
(0, 14400, 24000, 14464), 1036800008, ('RGB', 0, 1)), ('raw', (0, 14464,
24000, 14528), 1041408008, ('RGB', 0, 1)), ('raw', (0, 14528, 24000,
14592), 1046016008, ('RGB', 0, 1)), ('raw', (0, 14592, 24000, 14656),
1050624008, ('RGB', 0, 1)), ('raw', (0, 14656, 24000, 14720), 1055232008,
('RGB', 0, 1)), ('raw', (0, 14720, 24000, 14784), 1059840008, ('RGB', 0,
1)), ('raw', (0, 14784, 24000, 14848), 1064448008, ('RGB', 0, 1)), ('raw',
(0, 14848, 24000, 14912), 1069056008, ('RGB', 0, 1)), ('raw', (0, 14912,
24000, 14976), 1073664008, ('RGB', 0, 1)), ('raw', (0, 14976, 24000,
15040), 1078272008, ('RGB', 0, 1)), ('raw', (0, 15040, 24000, 15104),
1082880008, ('RGB', 0, 1)), ('raw', (0, 15104, 24000, 15168), 1087488008,
('RGB', 0, 1)), ('raw', (0, 15168, 24000, 15232), 1092096008, ('RGB', 0,
1)), ('raw', (0, 15232, 24000, 15296), 1096704008, ('RGB', 0, 1)), ('raw',
(0, 15296, 24000, 15360), 1101312008, ('RGB', 0, 1)), ('raw', (0, 15360,
24000, 15424), 1105920008, ('RGB', 0, 1)), ('raw', (0, 15424, 24000,
15488), 1110528008, ('RGB', 0, 1)), ('raw', (0, 15488, 24000, 15552),
1115136008, ('RGB', 0, 1)), ('raw', (0, 15552, 24000, 15616), 1119744008,
('RGB', 0, 1)), ('raw', (0, 15616, 24000, 15680), 1124352008, ('RGB', 0,
1)), ('raw', (0, 15680, 24000, 15744), 1128960008, ('RGB', 0, 1)), ('raw',
(0, 15744, 24000, 15808), 1133568008, ('RGB', 0, 1)), ('raw', (0, 15808,
24000, 15872), 1138176008, ('RGB', 0, 1)), ('raw', (0, 15872, 24000,
15936), 1142784008, ('RGB', 0, 1)), ('raw', (0, 15936, 24000, 16000),
1147392008, ('RGB', 0, 1)), ('raw', (0, 16000, 24000, 16064), 1152000008,
('RGB', 0, 1)), ('raw', (0, 16064, 24000, 16128), 1156608008, ('RGB', 0,
1)), ('raw', (0, 16128, 24000, 16192), 1161216008, ('RGB', 0, 1)), ('raw',
(0, 16192, 24000, 16256), 1165824008, ('RGB', 0, 1)), ('raw', (0, 16256,
24000, 16320), 1170432008, ('RGB', 0, 1)), ('raw', (0, 16320, 24000,
16384), 1175040008, ('RGB', 0, 1)), ('raw', (0, 16384, 24000, 16448),
1179648008, ('RGB', 0, 1)), ('raw', (0, 16448, 24000, 16512), 1184256008,
('RGB', 0, 1)), ('raw', (0, 16512, 24000, 16576), 1188864008, ('RGB', 0,
1)), ('raw', (0, 16576, 24000, 16640), 1193472008, ('RGB', 0, 1)), ('raw',
(0, 16640, 24000, 16704), 1198080008, ('RGB', 0, 1)), ('raw', (0, 16704,
24000, 16768), 1202688008, ('RGB', 0, 1)), ('raw', (0, 16768, 24000,
16832), 1207296008, ('RGB', 0, 1)), ('raw', (0, 16832, 24000, 16896),
1211904008, ('RGB', 0, 1)), ('raw', (0, 16896, 24000, 16960), 1216512008,
('RGB', 0, 1)), ('raw', (0, 16960, 24000, 17024), 1221120008, ('RGB', 0,
1)), ('raw', (0, 17024, 24000, 17088), 1225728008, ('RGB', 0, 1)), ('raw',
(0, 17088, 24000, 17152), 1230336008, ('RGB', 0, 1)), ('raw', (0, 17152,
24000, 17216), 1234944008, ('RGB', 0, 1)), ('raw', (0, 17216, 24000,
17280), 1239552008, ('RGB', 0, 1)), ('raw', (0, 17280, 24000, 17344),
1244160008, ('RGB', 0, 1)), ('raw', (0, 17344, 24000, 17408), 1248768008,
('RGB', 0, 1)), ('raw', (0, 17408, 24000, 17472), 1253376008, ('RGB', 0,
1)), ('raw', (0, 17472, 24000, 17536), 1257984008, ('RGB', 0, 1)), ('raw',
(0, 17536, 24000, 17600), 1262592008, ('RGB', 0, 1)), ('raw', (0, 17600,
24000, 17664), 1267200008, ('RGB', 0, 1)), ('raw', (0, 17664, 24000,
17728), 1271808008, ('RGB', 0, 1)), ('raw', (0, 17728, 24000, 17792),
1276416008, ('RGB', 0, 1)), ('raw', (0, 17792, 24000, 17856), 1281024008,
('RGB', 0, 1)), ('raw', (0, 17856, 24000, 17920), 1285632008, ('RGB', 0,
1)), ('raw', (0, 17920, 24000, 17984), 1290240008, ('RGB', 0, 1)), ('raw',
(0, 17984, 24000, 18048), 1294848008, ('RGB', 0, 1)), ('raw', (0, 18048,
24000, 18112), 1299456008, ('RGB', 0, 1)), ('raw', (0, 18112, 24000,
18176), 1304064008, ('RGB', 0, 1)), ('raw', (0, 18176, 24000, 18240),
1308672008, ('RGB', 0, 1)), ('raw', (0, 18240, 24000, 18304), 1313280008,
('RGB', 0, 1)), ('raw', (0, 18304, 24000, 18368), 1317888008, ('RGB', 0,
1)), ('raw', (0, 18368, 24000, 18432), 1322496008, ('RGB', 0, 1)), ('raw',
(0, 18432, 24000, 18496), 1327104008, ('RGB', 0, 1)), ('raw', (0, 18496,
24000, 18560), 1331712008, ('RGB', 0, 1)), ('raw', (0, 18560, 24000,
18624), 1336320008, ('RGB', 0, 1)), ('raw', (0, 18624, 24000, 18688),
1340928008, ('RGB', 0, 1)), ('raw', (0, 18688, 24000, 18752), 1345536008,
('RGB', 0, 1)), ('raw', (0, 18752, 24000, 18816), 1350144008, ('RGB', 0,
1)), ('raw', (0, 18816, 24000, 18880), 1354752008, ('RGB', 0, 1)), ('raw',
(0, 18880, 24000, 18944), 1359360008, ('RGB', 0, 1)), ('raw', (0, 18944,
24000, 19008), 1363968008, ('RGB', 0, 1)), ('raw', (0, 19008, 24000,
19072), 1368576008, ('RGB', 0, 1)), ('raw', (0, 19072, 24000, 19136),
1373184008, ('RGB', 0, 1)), ('raw', (0, 19136, 24000, 19200), 1377792008,
('RGB', 0, 1)), ('raw', (0, 19200, 24000, 19264), 1382400008, ('RGB', 0,
1)), ('raw', (0, 19264, 24000, 19328), 1387008008, ('RGB', 0, 1)), ('raw',
(0, 19328, 24000, 19392), 1391616008, ('RGB', 0, 1)), ('raw', (0, 19392,
24000, 19456), 1396224008, ('RGB', 0, 1)), ('raw', (0, 19456, 24000,
19520), 1400832008, ('RGB', 0, 1)), ('raw', (0, 19520, 24000, 19584),
1405440008, ('RGB', 0, 1)), ('raw', (0, 19584, 24000, 19648), 1410048008,
('RGB', 0, 1)), ('raw', (0, 19648, 24000, 19712), 1414656008, ('RGB', 0,
1)), ('raw', (0, 19712, 24000, 19776), 1419264008, ('RGB', 0, 1)), ('raw',
(0, 19776, 24000, 19840), 1423872008, ('RGB', 0, 1)), ('raw', (0, 19840,
24000, 19904), 1428480008, ('RGB', 0, 1)), ('raw', (0, 19904, 24000,
19968), 1433088008, ('RGB', 0, 1)), ('raw', (0, 19968, 24000, 20032),
1437696008, ('RGB', 0, 1)), ('raw', (0, 20032, 24000, 20096), 1442304008,
('RGB', 0, 1)), ('raw', (0, 20096, 24000, 20160), 1446912008, ('RGB', 0,
1)), ('raw', (0, 20160, 24000, 20224), 1451520008, ('RGB', 0, 1)), ('raw',
(0, 20224, 24000, 20288), 1456128008, ('RGB', 0, 1)), ('raw', (0, 20288,
24000, 20352), 1460736008, ('RGB', 0, 1)), ('raw', (0, 20352, 24000,
20416), 1465344008, ('RGB', 0, 1)), ('raw', (0, 20416, 24000, 20480),
1469952008, ('RGB', 0, 1)), ('raw', (0, 20480, 24000, 20544), 1474560008,
('RGB', 0, 1)), ('raw', (0, 20544, 24000, 20608), 1479168008, ('RGB', 0,
1)), ('raw', (0, 20608, 24000, 20672), 1483776008, ('RGB', 0, 1)), ('raw',
(0, 20672, 24000, 20736), 1488384008, ('RGB', 0, 1)), ('raw', (0, 20736,
24000, 20800), 1492992008, ('RGB', 0, 1)), ('raw', (0, 20800, 24000,
20864), 1497600008, ('RGB', 0, 1)), ('raw', (0, 20864, 24000, 20928),
1502208008, ('RGB', 0, 1)), ('raw', (0, 20928, 24000, 20992), 1506816008,
('RGB', 0, 1)), ('raw', (0, 20992, 24000, 21056), 1511424008, ('RGB', 0,
1)), ('raw', (0, 21056, 24000, 21120), 1516032008, ('RGB', 0, 1)), ('raw',
(0, 21120, 24000, 21184), 1520640008, ('RGB', 0, 1)), ('raw', (0, 21184,
24000, 21248), 1525248008, ('RGB', 0, 1)), ('raw', (0, 21248, 24000,
21312), 1529856008, ('RGB', 0, 1)), ('raw', (0, 21312, 24000, 21376),
1534464008, ('RGB', 0, 1)), ('raw', (0, 21376, 24000, 21440), 1539072008,
('RGB', 0, 1)), ('raw', (0, 21440, 24000, 21504), 1543680008, ('RGB', 0,
1)), ('raw', (0, 21504, 24000, 21568), 1548288008, ('RGB', 0, 1)), ('raw',
(0, 21568, 24000, 21632), 1552896008, ('RGB', 0, 1)), ('raw', (0, 21632,
24000, 21696), 1557504008, ('RGB', 0, 1)), ('raw', (0, 21696, 24000,
21760), 1562112008, ('RGB', 0, 1)), ('raw', (0, 21760, 24000, 21824),
1566720008, ('RGB', 0, 1)), ('raw', (0, 21824, 24000, 21888), 1571328008,
('RGB', 0, 1)), ('raw', (0, 21888, 24000, 21952), 1575936008, ('RGB', 0,
1)), ('raw', (0, 21952, 24000, 22016), 1580544008, ('RGB', 0, 1)), ('raw',
(0, 22016, 24000, 22080), 1585152008, ('RGB', 0, 1)), ('raw', (0, 22080,
24000, 22144), 1589760008, ('RGB', 0, 1)), ('raw', (0, 22144, 24000,
22208), 1594368008, ('RGB', 0, 1)), ('raw', (0, 22208, 24000, 22272),
1598976008, ('RGB', 0, 1)), ('raw', (0, 22272, 24000, 22336), 1603584008,
('RGB', 0, 1)), ('raw', (0, 22336, 24000, 22400), 1608192008, ('RGB', 0,
1)), ('raw', (0, 22400, 24000, 22464), 1612800008, ('RGB', 0, 1)), ('raw',
(0, 22464, 24000, 22528), 1617408008, ('RGB', 0, 1)), ('raw', (0, 22528,
24000, 22592), 1622016008, ('RGB', 0, 1)), ('raw', (0, 22592, 24000,
22656), 1626624008, ('RGB', 0, 1)), ('raw', (0, 22656, 24000, 22720),
1631232008, ('RGB', 0, 1)), ('raw', (0, 22720, 24000, 22784), 1635840008,
('RGB', 0, 1)), ('raw', (0, 22784, 24000, 22848), 1640448008, ('RGB', 0,
1)), ('raw', (0, 22848, 24000, 22912), 1645056008, ('RGB', 0, 1)), ('raw',
(0, 22912, 24000, 22976), 1649664008, ('RGB', 0, 1)), ('raw', (0, 22976,
24000, 23040), 1654272008, ('RGB', 0, 1)), ('raw', (0, 23040, 24000,
23104), 1658880008, ('RGB', 0, 1)), ('raw', (0, 23104, 24000, 23168),
1663488008, ('RGB', 0, 1)), ('raw', (0, 23168, 24000, 23232), 1668096008,
('RGB', 0, 1)), ('raw', (0, 23232, 24000, 23296), 1672704008, ('RGB', 0,
1)), ('raw', (0, 23296, 24000, 23360), 1677312008, ('RGB', 0, 1)), ('raw',
(0, 23360, 24000, 23424), 1681920008, ('RGB', 0, 1)), ('raw', (0, 23424,
24000, 23488), 1686528008, ('RGB', 0, 1)), ('raw', (0, 23488, 24000,
23552), 1691136008, ('RGB', 0, 1)), ('raw', (0, 23552, 24000, 23616),
1695744008, ('RGB', 0, 1)), ('raw', (0, 23616, 24000, 23680), 1700352008,
('RGB', 0, 1)), ('raw', (0, 23680, 24000, 23744), 1704960008, ('RGB', 0,
1)), ('raw', (0, 23744, 24000, 23808), 1709568008, ('RGB', 0, 1)), ('raw',
(0, 23808, 24000, 23872), 1714176008, ('RGB', 0, 1)), ('raw', (0, 23872,
24000, 23936), 1718784008, ('RGB', 0, 1)), ('raw', (0, 23936, 24000,
24000), 1723392008, ('RGB', 0, 1)), ('raw', (0, 24000, 24000, 24064),
1728000008, ('RGB', 0, 1)), ('raw', (0, 24064, 24000, 24128), 1732608008,
('RGB', 0, 1)), ('raw', (0, 24128, 24000, 24192), 1737216008, ('RGB', 0,
1)), ('raw', (0, 24192, 24000, 24256), 1741824008, ('RGB', 0, 1)), ('raw',
(0, 24256, 24000, 24320), 1746432008, ('RGB', 0, 1)), ('raw', (0, 24320,
24000, 24384), 1751040008, ('RGB', 0, 1)), ('raw', (0, 24384, 24000,
24448), 1755648008, ('RGB', 0, 1)), ('raw', (0, 24448, 24000, 24512),
1760256008, ('RGB', 0, 1)), ('raw', (0, 24512, 24000, 24576), 1764864008,
('RGB', 0, 1)), ('raw', (0, 24576, 24000, 24640), 1769472008, ('RGB', 0,
1)), ('raw', (0, 24640, 24000, 24704), 1774080008, ('RGB', 0, 1)), ('raw',
(0, 24704, 24000, 24768), 1778688008, ('RGB', 0, 1)), ('raw', (0, 24768,
24000, 24832), 1783296008, ('RGB', 0, 1)), ('raw', (0, 24832, 24000,
24896), 1787904008, ('RGB', 0, 1)), ('raw', (0, 24896, 24000, 24960),
1792512008, ('RGB', 0, 1)), ('raw', (0, 24960, 24000, 25024), 1797120008,
('RGB', 0, 1)), ('raw', (0, 25024, 24000, 25088), 1801728008, ('RGB', 0,
1)), ('raw', (0, 25088, 24000, 25152), 1806336008, ('RGB', 0, 1)), ('raw',
(0, 25152, 24000, 25216), 1810944008, ('RGB', 0, 1)), ('raw', (0, 25216,
24000, 25280), 1815552008, ('RGB', 0, 1)), ('raw', (0, 25280, 24000,
25344), 1820160008, ('RGB', 0, 1)), ('raw', (0, 25344, 24000, 25408),
1824768008, ('RGB', 0, 1)), ('raw', (0, 25408, 24000, 25472), 1829376008,
('RGB', 0, 1)), ('raw', (0, 25472, 24000, 25536), 1833984008, ('RGB', 0,
1)), ('raw', (0, 25536, 24000, 25600), 1838592008, ('RGB', 0, 1)), ('raw',
(0, 25600, 24000, 25664), 1843200008, ('RGB', 0, 1)), ('raw', (0, 25664,
24000, 25728), 1847808008, ('RGB', 0, 1)), ('raw', (0, 25728, 24000,
25792), 1852416008, ('RGB', 0, 1)), ('raw', (0, 25792, 24000, 25856),
1857024008, ('RGB', 0, 1)), ('raw', (0, 25856, 24000, 25920), 1861632008,
('RGB', 0, 1)), ('raw', (0, 25920, 24000, 25984), 1866240008, ('RGB', 0,
1)), ('raw', (0, 25984, 24000, 26048), 1870848008, ('RGB', 0, 1)), ('raw',
(0, 26048, 24000, 26112), 1875456008, ('RGB', 0, 1)), ('raw', (0, 26112,
24000, 26176), 1880064008, ('RGB', 0, 1)), ('raw', (0, 26176, 24000,
26240), 1884672008, ('RGB', 0, 1)), ('raw', (0, 26240, 24000, 26304),
1889280008, ('RGB', 0, 1)), ('raw', (0, 26304, 24000, 26368), 1893888008,
('RGB', 0, 1)), ('raw', (0, 26368, 24000, 26432), 1898496008, ('RGB', 0,
1)), ('raw', (0, 26432, 24000, 26496), 1903104008, ('RGB', 0, 1)), ('raw',
(0, 26496, 24000, 26560), 1907712008, ('RGB', 0, 1)), ('raw', (0, 26560,
24000, 26624), 1912320008, ('RGB', 0, 1)), ('raw', (0, 26624, 24000,
26688), 1916928008, ('RGB', 0, 1)), ('raw', (0, 26688, 24000, 26752),
1921536008, ('RGB', 0, 1)), ('raw', (0, 26752, 24000, 26816), 1926144008,
('RGB', 0, 1)), ('raw', (0, 26816, 24000, 26880), 1930752008, ('RGB', 0,
1)), ('raw', (0, 26880, 24000, 26944), 1935360008, ('RGB', 0, 1)), ('raw',
(0, 26944, 24000, 27008), 1939968008, ('RGB', 0, 1)), ('raw', (0, 27008,
24000, 27072), 1944576008, ('RGB', 0, 1)), ('raw', (0, 27072, 24000,
27136), 1949184008, ('RGB', 0, 1)), ('raw', (0, 27136, 24000, 27200),
1953792008, ('RGB', 0, 1)), ('raw', (0, 27200, 24000, 27264), 1958400008,
('RGB', 0, 1)), ('raw', (0, 27264, 24000, 27328), 1963008008, ('RGB', 0,
1)), ('raw', (0, 27328, 24000, 27392), 1967616008, ('RGB', 0, 1)), ('raw',
(0, 27392, 24000, 27456), 1972224008, ('RGB', 0, 1)), ('raw', (0, 27456,
24000, 27520), 1976832008, ('RGB', 0, 1)), ('raw', (0, 27520, 24000,
27584), 1981440008, ('RGB', 0, 1)), ('raw', (0, 27584, 24000, 27648),
1986048008, ('RGB', 0, 1)), ('raw', (0, 27648, 24000, 27712), 1990656008,
('RGB', 0, 1)), ('raw', (0, 27712, 24000, 27776), 1995264008, ('RGB', 0,
1)), ('raw', (0, 27776, 24000, 27840), 1999872008, ('RGB', 0, 1)), ('raw',
(0, 27840, 24000, 27904), 2004480008, ('RGB', 0, 1)), ('raw', (0, 27904,
24000, 27968), 2009088008, ('RGB', 0, 1)), ('raw', (0, 27968, 24000,
28032), 2013696008, ('RGB', 0, 1)), ('raw', (0, 28032, 24000, 28096),
2018304008, ('RGB', 0, 1)), ('raw', (0, 28096, 24000, 28160), 2022912008,
('RGB', 0, 1)), ('raw', (0, 28160, 24000, 28224), 2027520008, ('RGB', 0,
1)), ('raw', (0, 28224, 24000, 28288), 2032128008, ('RGB', 0, 1)), ('raw',
(0, 28288, 24000, 28352), 2036736008, ('RGB', 0, 1)), ('raw', (0, 28352,
24000, 28416), 2041344008, ('RGB', 0, 1)), ('raw', (0, 28416, 24000,
28480), 2045952008, ('RGB', 0, 1)), ('raw', (0, 28480, 24000, 28544),
2050560008, ('RGB', 0, 1)), ('raw', (0, 28544, 24000, 28608), 2055168008,
('RGB', 0, 1)), ('raw', (0, 28608, 24000, 28672), 2059776008, ('RGB', 0,
1)), ('raw', (0, 28672, 24000, 28736), 2064384008, ('RGB', 0, 1)), ('raw',
(0, 28736, 24000, 28800), 2068992008, ('RGB', 0, 1)), ('raw', (0, 28800,
24000, 28864), 2073600008, ('RGB', 0, 1)), ('raw', (0, 28864, 24000,
28928), 2078208008, ('RGB', 0, 1)), ('raw', (0, 28928, 24000, 28992),
2082816008, ('RGB', 0, 1)), ('raw', (0, 28992, 24000, 29056), 2087424008,
('RGB', 0, 1)), ('raw', (0, 29056, 24000, 29120), 2092032008, ('RGB', 0,
1)), ('raw', (0, 29120, 24000, 29184), 2096640008, ('RGB', 0, 1)), ('raw',
(0, 29184, 24000, 29248), 2101248008, ('RGB', 0, 1)), ('raw', (0, 29248,
24000, 29312), 2105856008, ('RGB', 0, 1)), ('raw', (0, 29312, 24000,
29376), 2110464008, ('RGB', 0, 1)), ('raw', (0, 29376, 24000, 29440),
2115072008, ('RGB', 0, 1)), ('raw', (0, 29440, 24000, 29504), 2119680008,
('RGB', 0, 1)), ('raw', (0, 29504, 24000, 29568), 2124288008, ('RGB', 0,
1)), ('raw', (0, 29568, 24000, 29632), 2128896008, ('RGB', 0, 1)), ('raw',
(0, 29632, 24000, 29696), 2133504008, ('RGB', 0, 1)), ('raw', (0, 29696,
24000, 29760), 2138112008, ('RGB', 0, 1)), ('raw', (0, 29760, 24000,
29824), 2142720008, ('RGB', 0, 1)), ('raw', (0, 29824, 24000, 29888),
2147328008, ('RGB', 0, 1)), ('raw', (0, 29888, 24000, 29952), 2151936008L,
('RGB', 0, 1)), ('raw', (0, 29952, 24000, 30016), 2156544008L, ('RGB', 0,
1)), ('raw', (0, 30016, 24000, 30080), 2161152008L, ('RGB', 0, 1)),
('raw', (0, 30080, 24000, 30144), 2165760008L, ('RGB', 0, 1)), ('raw', (0,
30144, 24000, 30208), 2170368008L, ('RGB', 0, 1)), ('raw', (0, 30208,
24000, 30272), 2174976008L, ('RGB', 0, 1)), ('raw', (0, 30272, 24000,
30336), 2179584008L, ('RGB', 0, 1)), ('raw', (0, 30336, 24000, 30400),
2184192008L, ('RGB', 0, 1)), ('raw', (0, 30400, 24000, 30464),
2188800008L, ('RGB', 0, 1)), ('raw', (0, 30464, 24000, 30528),
2193408008L, ('RGB', 0, 1)), ('raw', (0, 30528, 24000, 30592),
2198016008L, ('RGB', 0, 1)), ('raw', (0, 30592, 24000, 30656),
2202624008L, ('RGB', 0, 1)), ('raw', (0, 30656, 24000, 30720),
2207232008L, ('RGB', 0, 1)), ('raw', (0, 30720, 24000, 30784),
2211840008L, ('RGB', 0, 1)), ('raw', (0, 30784, 24000, 30848),
2216448008L, ('RGB', 0, 1)), ('raw', (0, 30848, 24000, 30912),
2221056008L, ('RGB', 0, 1)), ('raw', (0, 30912, 24000, 30976),
2225664008L, ('RGB', 0, 1)), ('raw', (0, 30976, 24000, 31040),
2230272008L, ('RGB', 0, 1)), ('raw', (0, 31040, 24000, 31104),
2234880008L, ('RGB', 0, 1)), ('raw', (0, 31104, 24000, 31168),
2239488008L, ('RGB', 0, 1)), ('raw', (0, 31168, 24000, 31232),
2244096008L, ('RGB', 0, 1)), ('raw', (0, 31232, 24000, 31296),
2248704008L, ('RGB', 0, 1)), ('raw', (0, 31296, 24000, 31360),
2253312008L, ('RGB', 0, 1)), ('raw', (0, 31360, 24000, 31424),
2257920008L, ('RGB', 0, 1)), ('raw', (0, 31424, 24000, 31488),
2262528008L, ('RGB', 0, 1)), ('raw', (0, 31488, 24000, 31552),
2267136008L, ('RGB', 0, 1)), ('raw', (0, 31552, 24000, 31616),
2271744008L, ('RGB', 0, 1)), ('raw', (0, 31616, 24000, 31680),
2276352008L, ('RGB', 0, 1)), ('raw', (0, 31680, 24000, 31744),
2280960008L, ('RGB', 0, 1)), ('raw', (0, 31744, 24000, 31808),
2285568008L, ('RGB', 0, 1)), ('raw', (0, 31808, 24000, 31872),
2290176008L, ('RGB', 0, 1)), ('raw', (0, 31872, 24000, 31936),
2294784008L, ('RGB', 0, 1)), ('raw', (0, 31936, 24000, 32000),
2299392008L, ('RGB', 0, 1)), ('raw', (0, 32000, 24000, 32064),
2304000008L, ('RGB', 0, 1)), ('raw', (0, 32064, 24000, 32128),
2308608008L, ('RGB', 0, 1)), ('raw', (0, 32128, 24000, 32192),
2313216008L, ('RGB', 0, 1)), ('raw', (0, 32192, 24000, 32256),
2317824008L, ('RGB', 0, 1)), ('raw', (0, 32256, 24000, 32320),
2322432008L, ('RGB', 0, 1)), ('raw', (0, 32320, 24000, 32384),
2327040008L, ('RGB', 0, 1)), ('raw', (0, 32384, 24000, 32448),
2331648008L, ('RGB', 0, 1)), ('raw', (0, 32448, 24000, 32512),
2336256008L, ('RGB', 0, 1)), ('raw', (0, 32512, 24000, 32576),
2340864008L, ('RGB', 0, 1)), ('raw', (0, 32576, 24000, 32640),
2345472008L, ('RGB', 0, 1)), ('raw', (0, 32640, 24000, 32704),
2350080008L, ('RGB', 0, 1)), ('raw', (0, 32704, 24000, 32768),
2354688008L, ('RGB', 0, 1)), ('raw', (0, 32768, 24000, 32832),
2359296008L, ('RGB', 0, 1)), ('raw', (0, 32832, 24000, 32896),
2363904008L, ('RGB', 0, 1)), ('raw', (0, 32896, 24000, 32960),
2368512008L, ('RGB', 0, 1)), ('raw', (0, 32960, 24000, 33024),
2373120008L, ('RGB', 0, 1)), ('raw', (0, 33024, 24000, 33088),
2377728008L, ('RGB', 0, 1)), ('raw', (0, 33088, 24000, 33152),
2382336008L, ('RGB', 0, 1)), ('raw', (0, 33152, 24000, 33216),
2386944008L, ('RGB', 0, 1)), ('raw', (0, 33216, 24000, 33280),
2391552008L, ('RGB', 0, 1)), ('raw', (0, 33280, 24000, 33344),
2396160008L, ('RGB', 0, 1)), ('raw', (0, 33344, 24000, 33408),
2400768008L, ('RGB', 0, 1)), ('raw', (0, 33408, 24000, 33472),
2405376008L, ('RGB', 0, 1)), ('raw', (0, 33472, 24000, 33536),
2409984008L, ('RGB', 0, 1)), ('raw', (0, 33536, 24000, 33600),
2414592008L, ('RGB', 0, 1)), ('raw', (0, 33600, 24000, 33664),
2419200008L, ('RGB', 0, 1)), ('raw', (0, 33664, 24000, 33728),
2423808008L, ('RGB', 0, 1)), ('raw', (0, 33728, 24000, 33792),
2428416008L, ('RGB', 0, 1)), ('raw', (0, 33792, 24000, 33856),
2433024008L, ('RGB', 0, 1)), ('raw', (0, 33856, 24000, 33920),
2437632008L, ('RGB', 0, 1)), ('raw', (0, 33920, 24000, 33984),
2442240008L, ('RGB', 0, 1)), ('raw', (0, 33984, 24000, 34048),
2446848008L, ('RGB', 0, 1)), ('raw', (0, 34048, 24000, 34112),
2451456008L, ('RGB', 0, 1)), ('raw', (0, 34112, 24000, 34176),
2456064008L, ('RGB', 0, 1)), ('raw', (0, 34176, 24000, 34240),
2460672008L, ('RGB', 0, 1)), ('raw', (0, 34240, 24000, 34304),
2465280008L, ('RGB', 0, 1)), ('raw', (0, 34304, 24000, 34368),
2469888008L, ('RGB', 0, 1)), ('raw', (0, 34368, 24000, 34432),
2474496008L, ('RGB', 0, 1)), ('raw', (0, 34432, 24000, 34496),
2479104008L, ('RGB', 0, 1)), ('raw', (0, 34496, 24000, 34560),
2483712008L, ('RGB', 0, 1)), ('raw', (0, 34560, 24000, 34624),
2488320008L, ('RGB', 0, 1)), ('raw', (0, 34624, 24000, 34688),
2492928008L, ('RGB', 0, 1)), ('raw', (0, 34688, 24000, 34752),
2497536008L, ('RGB', 0, 1)), ('raw', (0, 34752, 24000, 34816),
2502144008L, ('RGB', 0, 1)), ('raw', (0, 34816, 24000, 34880),
2506752008L, ('RGB', 0, 1)), ('raw', (0, 34880, 24000, 34944),
2511360008L, ('RGB', 0, 1)), ('raw', (0, 34944, 24000, 35008),
2515968008L, ('RGB', 0, 1)), ('raw', (0, 35008, 24000, 35072),
2520576008L, ('RGB', 0, 1)), ('raw', (0, 35072, 24000, 35136),
2525184008L, ('RGB', 0, 1)), ('raw', (0, 35136, 24000, 35200),
2529792008L, ('RGB', 0, 1)), ('raw', (0, 35200, 24000, 35264),
2534400008L, ('RGB', 0, 1)), ('raw', (0, 35264, 24000, 35328),
2539008008L, ('RGB', 0, 1)), ('raw', (0, 35328, 24000, 35392),
2543616008L, ('RGB', 0, 1)), ('raw', (0, 35392, 24000, 35456),
2548224008L, ('RGB', 0, 1)), ('raw', (0, 35456, 24000, 35520),
2552832008L, ('RGB', 0, 1)), ('raw', (0, 35520, 24000, 35584),
2557440008L, ('RGB', 0, 1)), ('raw', (0, 35584, 24000, 35648),
2562048008L, ('RGB', 0, 1)), ('raw', (0, 35648, 24000, 35712),
2566656008L, ('RGB', 0, 1)), ('raw', (0, 35712, 24000, 35776),
2571264008L, ('RGB', 0, 1)), ('raw', (0, 35776, 24000, 35840),
2575872008L, ('RGB', 0, 1)), ('raw', (0, 35840, 24000, 35904),
2580480008L, ('RGB', 0, 1)), ('raw', (0, 35904, 24000, 35968),
2585088008L, ('RGB', 0, 1)), ('raw', (0, 35968, 24000, 36000),
2589696008L, ('RGB', 0, 1))]



Fredrik Lundh said:
> Adam J Smith wrote:
>
>> We are encountering memory errors while processing very large images (over
>> 3Gb TIFFs, 17888x45408 px). We are trying to make "tiles" of the image by
>> calling PIL's crop method and saving the resulting images.
>
> if you open such a file in PIL, what does the "tile" attribute contain?
can you try the following on your files and post the result?
>
>     >>> im = Image.open("verylargetiff.tif")
>     >>> im.mode
>     >>> im.size
>     >>> im.tile
>
> </F>
>
>
>
>
>


____________________________
adam smith
ajs17 at cornell.edu
255-8893
215 ccc



____________________________
adam smith
ajs17 at cornell.edu
255-8893
215 ccc

Fredrik Lundh said:
> Adam J Smith wrote:
>
>> Just following up to see if anyone out there has any thoughts on my
>> original post below, as my own research into the issue has not gotten me
>> very far. Any help at all will be greatly appreciated.
>
> following up to the response you got may also be a good
> idea:
>
> ----- Original Message -----
> From: "Fredrik Lundh" <fredrik at pythonware.com>
> Newsgroups: gmane.comp.python.image
> Sent: Wednesday, August 31, 2005 5:47 PM
> Subject: Re: reaching memory limits with crop method
>
>
>> Adam J Smith wrote:
>>
>>> We are encountering memory errors while processing very large images
>>> (over
>>> 3Gb TIFFs, 17888x45408 px). We are trying to make "tiles" of the image
>>> by
>>> calling PIL's crop method and saving the resulting images.
>>
>> if you open such a file in PIL, what does the "tile" attribute contain?
>> can you try the following on your files and post the result?
>>
>>    >>> im = Image.open("verylargetiff.tif")
>>    >>> im.mode
>>    >>> im.size
>>    >>> im.tile
>>
>> </F>
>
>
>
>
>


____________________________
adam smith
ajs17 at cornell.edu
255-8893
215 ccc


From fredrik at pythonware.com  Fri Sep  9 12:46:53 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 9 Sep 2005 12:46:53 +0200
Subject: [Image-SIG] reaching memory limits with crop method]
References: <dfpitg$ih6$1@sea.gmane.org>
	<27209.69.207.47.7.1126261978.squirrel@69.207.47.7>
Message-ID: <dfrp6t$2qu$1@sea.gmane.org>

Adam J Smith wrote:

>>following up to the response you got may also be a good
>>idea:
>
> My apologies, I see that I accidentally replied to your personal email
> instead of the list.

that's not a problem in itself, but I never got it (from what I can tell).
probably a spam filter issue :-(

> Here is it again. Does this help?

this shows that the image is sliced and uncompressed, which means
that you should be able to read the image piece by piece simply by
manipulating the contents of the "size" and "tile" attributes before you
load the image.

I don't have time to dig up a tested example right now, but here's an
"off the top of my head and completely untested" outline:

    im = Image.open(...)
    tiles = im.tile

    for tile in tiles:

        # get the tile parameters
        layout, extent, offset, args = tile

        # where in the image should this data go
        x0, y0, x1, y1 = extent

        assert layout == "raw"

        im = Image.open(...)

        # read a single tile
        im.size = x1-x0, y1-y0
        im.tile = [(layout, (0, 0) + im.size, offset, args]

        ... process the image ...

to speed things up, you may want to process multiple tiles in each iteration
(to get this right, you need to calculate a proper size for a group of tiles, and
set the tile extent properly for each subtile).

</F> 




From ajs17 at cornell.edu  Sat Sep 10 12:22:19 2005
From: ajs17 at cornell.edu (Adam J Smith)
Date: Sat, 10 Sep 2005 06:22:19 -0400 (EDT)
Subject: [Image-SIG] reaching memory limits with crop method]
In-Reply-To: <dfrp6t$2qu$1@sea.gmane.org>
References: <dfrp6t$2qu$1@sea.gmane.org>
Message-ID: <24299.69.207.47.7.1126347739.squirrel@69.207.47.7>

Very interesting, thank you. Although I think the PIL documentation is
quite excellent, there are a few aspects of PIL that have always been
unclear to me, and the tile attribute is one of them. This actually works
really well for me because I am calling crop many times, so perhaps I can
easily add (or replace crop with) this tile approach--I hope. I will try
this approach very soon and respond to the list again with my results.

So it also sounds like this only works for uncompressed images, and that
somehow checking for this is a good idea? Sorry for such basic questions,
this kind of image processing is still pretty new to me.

Fredrik Lundh said:
> Adam J Smith wrote:
>
>>>following up to the response you got may also be a good
>>>idea:
>>
>> My apologies, I see that I accidentally replied to your personal email
>> instead of the list.
>
> that's not a problem in itself, but I never got it (from what I can tell).
> probably a spam filter issue :-(
>
>> Here is it again. Does this help?
>
> this shows that the image is sliced and uncompressed, which means
> that you should be able to read the image piece by piece simply by
> manipulating the contents of the "size" and "tile" attributes before you
> load the image.
>
> I don't have time to dig up a tested example right now, but here's an
> "off the top of my head and completely untested" outline:
>
>     im = Image.open(...)
>     tiles = im.tile
>
>     for tile in tiles:
>
>         # get the tile parameters
>         layout, extent, offset, args = tile
>
>         # where in the image should this data go
>         x0, y0, x1, y1 = extent
>
>         assert layout == "raw"
>
>         im = Image.open(...)
>
>         # read a single tile
>         im.size = x1-x0, y1-y0
>         im.tile = [(layout, (0, 0) + im.size, offset, args]
>
>         ... process the image ...
>
> to speed things up, you may want to process multiple tiles in each
> iteration
> (to get this right, you need to calculate a proper size for a group of
> tiles, and
> set the tile extent properly for each subtile).
>
> </F>
>
>
>
>
>


____________________________
adam smith
ajs17 at cornell.edu
255-8893
215 ccc


From fredrik at pythonware.com  Sat Sep 10 15:37:50 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sat, 10 Sep 2005 15:37:50 +0200
Subject: [Image-SIG] reaching memory limits with crop method]
References: <dfrp6t$2qu$1@sea.gmane.org>
	<24299.69.207.47.7.1126347739.squirrel@69.207.47.7>
Message-ID: <dfunj4$nlg$1@sea.gmane.org>

Adam J Smith wrote:

> Very interesting, thank you. Although I think the PIL documentation is
> quite excellent, there are a few aspects of PIL that have always been
> unclear to me, and the tile attribute is one of them.

if you look at the stuff I release, I tend to separate "official interfaces"
from "experimental" stuff (not always documented) and "internal stuff"'
(usually not documented); the tile attribute is more of the latter.

(but it is discussed in the "Writing Your Own File Decoder" appendix,
together with a description of the raw codec, so I guess it's at least
half-official by now...)

> So it also sounds like this only works for uncompressed images, and that
> somehow checking for this is a good idea? Sorry for such basic questions,
> this kind of image processing is still pretty new to me.

my mistake; the example I had in mind showed how you could split huge
tiles into smaller tiles.  to do that, you have to manipulate the tile offsets,
which only works well for uncompressed images (where you can use the
stride argument).

if you're reading individual tiles, or combining tiles, your code will work
for any compression mode.

</F> 




From fredrik at pythonware.com  Sat Sep 10 16:43:37 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sat, 10 Sep 2005 16:43:37 +0200
Subject: [Image-SIG] ImageChops.logical_and not working?
References: <dfn37f$ehp$1@sea.gmane.org>
Message-ID: <dfuref$qk$1@sea.gmane.org>

Michael Hoffman wrote:

> Hello. Using PIL 1.1.5, I am trying to do logical ands on bitmap
> images using ImageChops.logical_and. I seem to always get completely
> black images instead, however.

hmm.  this works just fine on windows...

are you running this on unix?

the operations do work, but logical_and sets the output bytes to 1
instead of 255, and the ImagingSavePPM function that's used by the
"show" method on Unix cheats and saves mode "1" images as "PGM"
images without normalizing the values.  that's not very smart.

if you convert the images to mode "L" on the way out, they should look
right.

I'll fix this (both the operator and the save method) in 1.1.6.

</F> 




From august at develop.ment.org  Wed Sep  7 04:44:37 2005
From: august at develop.ment.org (august)
Date: Wed, 7 Sep 2005 04:44:37 +0200 (CEST)
Subject: [Image-SIG] copy pixels from one image to another
Message-ID: <Pine.LNX.4.58.0509070440290.25057@alien.mur.at>


hello,

I'm sort of in a  hurry to do a simple operation, and am just now looking
at PIL to solve it.

Alls I want to do is take a very large image and chop it up into tiles of
smaller images (without having to copy the large image on every
operation - the original image is just large enough to fit in RAM).

However, I can't find any function in PIL that will allow my to copy
pixels.  Can this be?  There is no im.copyTo() function or something like
that.  I can use region = im.crop(bbox), but that actually crops the
original image.

any help on this one.  please respond to me directly as I am not on this
list.

thanks a million - august.

From sli1que at yahoo.com  Wed Sep  7 15:24:54 2005
From: sli1que at yahoo.com (Eric Walker)
Date: Wed, 7 Sep 2005 06:24:54 -0700 (PDT)
Subject: [Image-SIG] jpeg windows info
Message-ID: <20050907132455.29881.qmail@web60123.mail.yahoo.com>

Is there a way to get the saved data that windows has for an image file. like onthe properties tab. comment author etc...
 
Thanks
 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/image-sig/attachments/20050907/17f7e125/attachment.html

From tom_harris at aapl.com.au  Fri Sep  9 02:46:24 2005
From: tom_harris at aapl.com.au (Tom Harris)
Date: Fri, 9 Sep 2005 10:46:24 +1000
Subject: [Image-SIG] Creating multi-image TIFFs
Message-ID: <3D991E061AD24F4D84E15948D72A834306A22C@aaplcdex2.aapl.com.au>

Greetings

I have a simple requirement that I can't figure out from the docs. I want to create a multi image TIFF from several other images, but I can find no information on how to create a multi-image TIFF in PIL. Possible in PIL, or should I look at netPBM?

TomH

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/image-sig/attachments/20050909/9afb613a/attachment.htm

From kevin at cazabon.com  Sat Sep 10 20:34:20 2005
From: kevin at cazabon.com (kevin@cazabon.com)
Date: Sat, 10 Sep 2005 20:34:20 +0200
Subject: [Image-SIG] copy pixels from one image to another
References: <Pine.LNX.4.58.0509070440290.25057@alien.mur.at>
Message-ID: <00bc01c5b636$475fb130$650aa8c0@duallie>

Search the image-sig archives for the .tile attribute - you can do what you
need with that.  Fredrik has posted a number of replies helping people with
it in the past.

Kevin.
----- Original Message ----- 
From: "august" <august at develop.ment.org>
To: <image-sig at python.org>
Sent: Wednesday, September 07, 2005 4:44 AM
Subject: [Image-SIG] copy pixels from one image to another


>
> hello,
>
> I'm sort of in a  hurry to do a simple operation, and am just now looking
> at PIL to solve it.
>
> Alls I want to do is take a very large image and chop it up into tiles of
> smaller images (without having to copy the large image on every
> operation - the original image is just large enough to fit in RAM).
>
> However, I can't find any function in PIL that will allow my to copy
> pixels.  Can this be?  There is no im.copyTo() function or something like
> that.  I can use region = im.crop(bbox), but that actually crops the
> original image.
>
> any help on this one.  please respond to me directly as I am not on this
> list.
>
> thanks a million - august.
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>
>



From don.rozenberg at gmail.com  Sun Sep 11 03:40:42 2005
From: don.rozenberg at gmail.com (Don Rozenberg)
Date: Sat, 10 Sep 2005 18:40:42 -0700
Subject: [Image-SIG] Information about PythonMagick
Message-ID: <43238B1A.40909@gmail.com>

Hi,

Is this the right place to inquire about PythonMagick?  I have the 
notion that I would like to try the Python interface to ImageMagick but 
I am unable to successfully install and run it.  So I have a couple of 
questions.

My interest arises because I want to manipulate the image in ways that 
are not canned in PIL; I think that I want to get at the pixels to 
implement my own image transformations. Another thing that I need is a 
Gaussian blur, which I have not seen in PIL.

First, am I missing something important about PIL?  Is there a way of 
programming pixel manipulation using PIL?  Should I forget PythonMagick 
and use PIL?

If I should stick to PythonMagick, can anyone point me to the author to 
inquire about its installation.  Someone at ImageMagick suggested 
contacting the author/maintainer but I can't determine who he is.

I am flailing and afraid I may have to go back to C.  So I will 
appreciate any suggestion or help.

Thanks in Advance,
Don
-- 
Don Rozenberg
707-882-3601
don.rozenberg at gmail.com

From david at ddahl.com  Sun Sep 11 05:02:47 2005
From: david at ddahl.com (David Dahl)
Date: Sat, 10 Sep 2005 22:02:47 -0500
Subject: [Image-SIG] Image.resize problem
Message-ID: <0C080FE3-4DE1-4406-AF08-ED54C8C97F93@ddahl.com>

For some reason Image.resize will not work for me. Here is my method:

import Image

def resize_image(self,infile,outfile):
         im = Image.open(infile)
         size = 800, 600
         im.resize(size)
         im.save(outfile,'JPEG' )


The files is written, but it is the same size as the original file.  
The thumbnail function works fine, maybe that is all I need? What is  
the real difference between resize() and thumbnail()?


Best Regards,

David



From steve at holdenweb.com  Sun Sep 11 06:28:18 2005
From: steve at holdenweb.com (Steve Holden)
Date: Sun, 11 Sep 2005 00:28:18 -0400
Subject: [Image-SIG] Image.resize problem
In-Reply-To: <0C080FE3-4DE1-4406-AF08-ED54C8C97F93@ddahl.com>
References: <0C080FE3-4DE1-4406-AF08-ED54C8C97F93@ddahl.com>
Message-ID: <4323B262.1080306@holdenweb.com>

David Dahl wrote:
> For some reason Image.resize will not work for me. Here is my method:
> 
> import Image
> 
> def resize_image(self,infile,outfile):
>          im = Image.open(infile)
>          size = 800, 600
>          im.resize(size)
>          im.save(outfile,'JPEG' )
> 
> 
> The files is written, but it is the same size as the original file.  
> The thumbnail function works fine, maybe that is all I need? What is  
> the real difference between resize() and thumbnail()?
> 
The problem is occurring because im.resize() isn't an in-place update: 
it returns a new image!

Try

         im = im.resize(size)

and see if that improves things.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/

From david at ddahl.com  Sun Sep 11 06:40:16 2005
From: david at ddahl.com (David Dahl)
Date: Sat, 10 Sep 2005 23:40:16 -0500
Subject: [Image-SIG] Image.resize problem
In-Reply-To: <4323B262.1080306@holdenweb.com>
References: <0C080FE3-4DE1-4406-AF08-ED54C8C97F93@ddahl.com>
	<4323B262.1080306@holdenweb.com>
Message-ID: <9C555DAE-0E46-4DF2-B151-B1A8F1B56652@ddahl.com>

Ah, yes... I am a python newbie, so it's takes a little time ot get  
used to.

That worked, Thanks!

d

On 10 Sep 2005, at 23:28, Steve Holden wrote:

> David Dahl wrote:
>
>> For some reason Image.resize will not work for me. Here is my method:
>> import Image
>> def resize_image(self,infile,outfile):
>>          im = Image.open(infile)
>>          size = 800, 600
>>          im.resize(size)
>>          im.save(outfile,'JPEG' )
>> The files is written, but it is the same size as the original  
>> file.  The thumbnail function works fine, maybe that is all I  
>> need? What is  the real difference between resize() and thumbnail()?
>>
> The problem is occurring because im.resize() isn't an in-place  
> update: it returns a new image!
>
> Try
>
>         im = im.resize(size)
>
> and see if that improves things.
>
> regards
>  Steve
> -- 
> Steve Holden       +44 150 684 7255  +1 800 494 3119
> Holden Web LLC             http://www.holdenweb.com/
>


From nadavh at visionsense.com  Sun Sep 11 08:19:49 2005
From: nadavh at visionsense.com (Nadav Horesh)
Date: Sun, 11 Sep 2005 08:19:49 +0200
Subject: [Image-SIG] Creating multi-image TIFFs
Message-ID: <07C6A61102C94148B8104D42DE95F7E86DF021@exchange2k.envision.co.il>

The quick way is probably ImagMagick package (the utility convert). If you insist on python, there is PythonMagick.

  Nadav.

-----Original Message-----
From:	image-sig-bounces at python.org on behalf of Tom Harris
Sent:	Fri 09-Sep-05 02:46
To:	image-sig at python.org
Cc:	
Subject:	[Image-SIG] Creating multi-image TIFFs

Greetings

I have a simple requirement that I can't figure out from the docs. I want to create a multi image TIFF from several other images, but I can find no information on how to create a multi-image TIFF in PIL. Possible in PIL, or should I look at netPBM?

TomH





From fredrik at pythonware.com  Sun Sep 11 11:37:47 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 11 Sep 2005 11:37:47 +0200
Subject: [Image-SIG] Information about PythonMagick
References: <43238B1A.40909@gmail.com>
Message-ID: <dg0ttb$4ao$1@sea.gmane.org>

Don Rozenberg wrote:

> My interest arises because I want to manipulate the image in ways that
> are not canned in PIL; I think that I want to get at the pixels to
> implement my own image transformations.

slow:

    value = im.getpixel((x, y))
    im.putpixel((x, y), value)

faster:

    values = im.getdata()
    im.putdata(values)

fastest:

    http://effbot.org/zone/pil-numpy.htm
    http://effbot.org/imagingbook/imagemath.htm (in 1.1.6)

(note that Python's not well-suited for writing pixel-by-pixel
algorithms; the more you can build on existing primitives, the
faster your program gets.  on the other hand, you can always
start in pure python, and migrate to C/C++ or Pyrex or Inline
C when you're done experimenting)

</F> 




From fredrik at pythonware.com  Sun Sep 11 12:54:07 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 11 Sep 2005 12:54:07 +0200
Subject: [Image-SIG] Creating multi-image TIFFs
References: <3D991E061AD24F4D84E15948D72A834306A22C@aaplcdex2.aapl.com.au>
Message-ID: <dg12cf$dlv$1@sea.gmane.org>

Creating multi-image TIFFs(please don't send "rich text" mails to this list)

Tom Harris wrote:

> I have a simple requirement that I can't figure out from the docs. I want to create
> a multi image TIFF from several other images, but I can find no information on
> how to create a multi-image TIFF in PIL. Possible in PIL, or should I look at
> netPBM?

a simple way to do this is to use PIL to save the individual frames,
and use the "tiffcp" utility to create the final multipage image.

"tiffcp" is part of the "libtiff" tool suite, and is installed by default on
many (most?) linuxes.  source code and windows binaries can be
found here:

    http://www.remotesensing.org/libtiff/

</F> 




From don.rozenberg at gmail.com  Sun Sep 11 23:52:40 2005
From: don.rozenberg at gmail.com (Don Rozenberg)
Date: Sun, 11 Sep 2005 14:52:40 -0700
Subject: [Image-SIG] Information about PythonMagick
In-Reply-To: <dg0ttb$4ao$1@sea.gmane.org>
References: <43238B1A.40909@gmail.com> <dg0ttb$4ao$1@sea.gmane.org>
Message-ID: <4324A728.90406@gmail.com>

Fredrik Lundh wrote:
> Don Rozenberg wrote:
> 
> 
>>My interest arises because I want to manipulate the image in ways that
>>are not canned in PIL; I think that I want to get at the pixels to
>>implement my own image transformations.
> 
> 
> slow:
> 
>     value = im.getpixel((x, y))
>     im.putpixel((x, y), value)
> 
> faster:
> 
>     values = im.getdata()
>     im.putdata(values)
> 
> fastest:
> 
>     http://effbot.org/zone/pil-numpy.htm
>     http://effbot.org/imagingbook/imagemath.htm (in 1.1.6)
> 
> (note that Python's not well-suited for writing pixel-by-pixel
> algorithms; the more you can build on existing primitives, the
> faster your program gets.  on the other hand, you can always
> start in pure python, and migrate to C/C++ or Pyrex or Inline
> C when you're done experimenting)
> 
> </F> 
> 
> 
> 
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
> 

Hi,

It was my intention to experiment in python and then go to a faster 
implementation.

Following up your mention of 1.1.6, I downloaded and built 
Imaging-1.1.6a0.tar.gz; however, when I ran 'python selftest.py' I got 
two failures:

*****************************************************************
Failure in example: im = ImageMath.eval("float(im + 20)", 
im=im.convert("L"))
from line #116 of selftest.testimage
Exception raised:
Traceback (most recent call last):
   File "./doctest.py", line 499, in _run_examples_inner
     exec compile(source, "<string>", "single") in globs
   File "<string>", line 1, in ?
   File "PIL/ImageMath.py", line 200, in eval
     out =__builtin__.eval(expression, args)
   File "<string>", line 0, in ?
TypeError: __float__ returned non-float (type instance)
*****************************************************************
Failure in example: im.mode, im.size
from line #117 of selftest.testimage
Expected: ('F', (128, 128))
Got: ('RGB', (128, 128))
1 items had failures:
    2 of  57 in selftest.testimage
***Test Failed*** 2 failures.
*** 2 tests of 57 failed.

I am running python 2.4.1 on a Knoppix/Debian system.  I installed 
python from source. It seems that these failures involve exactly what I 
want to do.  I then tried using python 2.3.5 and '57 tests passed.'. 
Is this a known problem in python 2.4.1?  I guess that I can do my thing 
on the older version of python.

Thanks for your help,
Don

-- 
Don Rozenberg
707-882-3601
don.rozenberg at gmail.com

From fredrik at pythonware.com  Mon Sep 12 19:31:56 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 12 Sep 2005 19:31:56 +0200
Subject: [Image-SIG] Information about PythonMagick
References: <43238B1A.40909@gmail.com> <dg0ttb$4ao$1@sea.gmane.org>
	<4324A728.90406@gmail.com>
Message-ID: <dg4e2b$cbr$1@sea.gmane.org>

Don Rozenberg wrote:

> *****************************************************************
> Failure in example: im = ImageMath.eval("float(im + 20)",
> im=im.convert("L"))
> from line #116 of selftest.testimage
> Exception raised:
> Traceback (most recent call last):
>   File "./doctest.py", line 499, in _run_examples_inner
>     exec compile(source, "<string>", "single") in globs
>   File "<string>", line 1, in ?
>   File "PIL/ImageMath.py", line 200, in eval
>     out =__builtin__.eval(expression, args)
>   File "<string>", line 0, in ?
> TypeError: __float__ returned non-float (type instance)
> *****************************************************************
>
> I am running python 2.4.1 on a Knoppix/Debian system.  I installed
> python from source. It seems that these failures involve exactly what I
> want to do.  I then tried using python 2.3.5 and '57 tests passed.'.
> Is this a known problem in python 2.4.1?

it's not a known problem, but it looks like it's a 2.4[.1]-specific problem,
which only affects the int() and float() operations.  this shouldn't be hard
to fix; I'll see if I can come up with a patch.

</F> 




From fredrik at pythonware.com  Mon Sep 12 20:13:28 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 12 Sep 2005 20:13:28 +0200
Subject: [Image-SIG] Information about PythonMagick
References: <43238B1A.40909@gmail.com>
	<dg0ttb$4ao$1@sea.gmane.org><4324A728.90406@gmail.com>
	<dg4e2b$cbr$1@sea.gmane.org>
Message-ID: <dg4gg6$kut$1@sea.gmane.org>

I wrote:

> it's not a known problem, but it looks like it's a 2.4[.1]-specific problem,
> which only affects the int() and float() operations.  this shouldn't be hard
> to fix; I'll see if I can come up with a patch.

it was easier than I thought:

$ diff -u PIL/ImageMath.py~ PIL/ImageMath.py
--- PIL/ImageMath.py~   2005-05-15 12:12:20.000000000 +0200
+++ PIL/ImageMath.py    2005-09-12 20:05:26.000000000 +0200
@@ -153,11 +153,11 @@
     def __ge__(self, other):
         return self.apply("ge", self, other)

-    # conversions
-    def __int__(self):
-        return _Operand(self.im.convert("I"))
-    def __float__(self):
-        return _Operand(self.im.convert("F"))
+# conversions
+def imagemath_int(self):
+    return _Operand(self.im.convert("I"))
+def imagemath_float(self):
+    return _Operand(self.im.convert("F"))

 # logical
 def imagemath_equal(self, other):

</F> 




From david.f at village.uunet.be  Wed Sep 14 12:52:12 2005
From: david.f at village.uunet.be (david)
Date: Wed, 14 Sep 2005 12:52:12 +0200
Subject: [Image-SIG] Gif transparency
Message-ID: <432800DC.7040205@village.uunet.be>

Hello,

I have problem with transparency, when I write :

im = Image.new("RGBA", size, (255,255,255,0))
im.save('test.gif')

If I write : im.save('test.png'), it's works.

Many thanks for your support.

    David

From reservations at aiadc.com  Wed Sep 14 16:06:59 2005
From: reservations at aiadc.com (reservations@aiadc.com)
Date: Wed, 14 Sep 2005 10:06:59 -0400
Subject: [Image-SIG] Delivery reports about your e-mail
In-Reply-To: <200509141406.j8EE6wwc019005@host27.webserver1010.com>
References: <200509141406.j8EE6wwc019005@host27.webserver1010.com>
Message-ID: <200509141406.j8EE6xwr019020@host27.webserver1010.com>

Thank you for contact AIA/DC.  The Washington Post listings for Architecture Week are incorrect.  We are very sorry for the inconvenience.  The Capitol Visitor's Center tour, the L'Enfant Plaza tour, How to work with architect, the Kid's Tour and the Watercolor class are all sold out.  There is still room in the Loft Tour on 9/10 and the lecture on Santiago Calatrava on 9/15.  If you would like to attend any of these events please log on to our website at www.aiadc.com and register there.

From michele.petrazzo at unipex.it  Wed Sep 14 16:30:39 2005
From: michele.petrazzo at unipex.it (Michele Petrazzo)
Date: Wed, 14 Sep 2005 16:30:39 +0200
Subject: [Image-SIG] [ANN] FreeImagePy 1.0.0
Message-ID: <4328340F.6000008@unipex.it>

What is?
  It' a python wrapper for FreeImage, Open Source library for developers
   who would like to support popular graphics image formats.

How work?
  It use a binary freeimage library present on the system and ctypes.

It 's released with the two public license GPL/FIPL:
GPL: GNU GENERAL PUBLIC LICENSE - freeimagepy.sf.net/license-gpl.txt
FIPL: FreeImage Public License - freeimagepy.sf.net/license-fi.tx

More informations can be found here:
http://freeimagepy.sf.net/

Michele Petrazzo

From fredrik at pythonware.com  Wed Sep 14 17:09:49 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 14 Sep 2005 17:09:49 +0200
Subject: [Image-SIG] Gif transparency
References: <432800DC.7040205@village.uunet.be>
Message-ID: <dg9efv$tnb$1@sea.gmane.org>

"david" wrote:

> I have problem with transparency, when I write :
>
> im = Image.new("RGBA", size, (255,255,255,0))
> im.save('test.gif')
>
> If I write : im.save('test.png'), it's works.

GIF doesn't support RGBA images (it only supports "P" images with
one color flagged as "transparent")

the best way to convert from RGBA to P+transparency depends,
to some extent, on your application.  what's the use case in this
case?

</F>




From akonsu at gmail.com  Wed Sep 14 18:44:42 2005
From: akonsu at gmail.com (akonsu)
Date: Wed, 14 Sep 2005 09:44:42 -0700
Subject: [Image-SIG] image.transform problem
Message-ID: <acfb5bdc050914094470c5bc08@mail.gmail.com>

Hello, is there a way to change the colour of the background that is
output when performing an image transform?
 
image = Image.new("L", w, h, 0xff)
...
image = image.transform(image.size, Image.QUAD, (0, 0, 0, 2 * h, w -
1, h - 1, w - 1, 0))

produces black area at the bottom (or wherever the destination image
does not correspond to the source image)
 
how to make this area white? i tried to change the "fill" parameter,
but this did not work. I am using the latest free release of PIL.
 
thank you in advance
konstantin

From fredrik at pythonware.com  Thu Sep 15 09:57:09 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 15 Sep 2005 09:57:09 +0200
Subject: [Image-SIG] image.transform problem
References: <acfb5bdc050914094470c5bc08@mail.gmail.com>
Message-ID: <dgb9gn$qpa$1@sea.gmane.org>

"akonsu" <akonsu at gmail.com> wrote:

> Hello, is there a way to change the colour of the background that is
> output when performing an image transform?
>
> image = Image.new("L", w, h, 0xff)
> ...
> image = image.transform(image.size, Image.QUAD, (0, 0, 0, 2 * h, w -
> 1, h - 1, w - 1, 0))
>
> produces black area at the bottom (or wherever the destination image
> does not correspond to the source image)

in current PIL versions, you have to resort to brute force (which isn't
that bad, really):

    mask = Image.new("1", image.size, 1)

    image = image.transform(... params ...)
    mask = mask.transform(... same params ...)

    out = Image.new(image.mode, image.size, background_color)
    out.paste(image, mask)

(if you're not using NEAREST sampling, you can try using a "L" mask
instead, with the pixels set to 255)

</F>




From michele.petrazzo at unipex.it  Thu Sep 15 10:32:16 2005
From: michele.petrazzo at unipex.it (Michele Petrazzo)
Date: Thu, 15 Sep 2005 10:32:16 +0200
Subject: [Image-SIG] [ANN] FreeImagePy 1.0.0
In-Reply-To: <4328AFE7.6000505@gmail.com>
References: <4328AFE7.6000505@gmail.com>
Message-ID: <43293190.4020409@unipex.it>

SPE - Stani's Python Editor wrote:
> Great! Thank you for wrapping it.

I'm very happy to contribute. I had always use the work (the code) of
the other python developers, an now I want to contribute by myself to
the community.

> What are the advantages over PIL (speed, features, ...)?

FI -> FreeImage
FIPY -> FreeImagePy

Good question :)
I don't know very well PIL, but this is that I saw:

First is to work well with the TIFF g3/g4 without problem, that is the
first reason that push me to create the wrapper, because in my fax
client, I must use this compression (of course), and second (with the
same importance) is that, in the same program, I use the multipage
tiff+resize+set correct DPI function for create a "standard" fax page.

The image type and its depth supported by FI library, so by FIPY (I only
wrap the functions, not the code), is largest because it support (by FI
site) :
"Support for High Dynamic Range images. FI supports RGB float images as
well a 48-bit HDR images and provides tone mapping operators to convert
these images to 24-bit LDR images."

FI (FIPY) support Metadata information: "Comments, Exif (including GPS
and maker notes), IPTC, Adobe XMP and GeoTIFF metadata models."

With FI you don't need to worry to what type of image "modes" you are 
working on, example: PIL:
im = Image.open("test.tif")
im.save("out.png", "PNG")
---->IOError: cannot write mode CMYK as PNG

Ok, if a developer working on the image he has to know its type, but for 
people like me that not know what is a CMYK mode :), it's very difficult 
to find a immediate solution for resolve this problem. With FIPY this 
not happen, because the library make all the conversion for me!

But, in the other hand, PIL support types like pdf, font (ttf, ...) that
FI not support.
PIL is more "pythonic", so it not need methods like Initialize,
DeInitialize, Unload (image), when the developer have to do something on
a image, for example, resize the image, with PIL you can do
image.resize, with FIPY you must use the FIPY instance and do
FIPY.Resize(image, ...)
With PIL you don't need to work with pointers or other strange and
"magic" (for me :) ) C/C++ code, but in FIPY yes, like you can read on
the Palette and Invert functions.

The speed in my tries is the same (more or less), or better in same
tests with a big (16 MB) tiff image (without compression) 24 color,
where I load, rotate, rescale with highest quality, save all the image
to png format, seem that PIL time is lesser than FI dll + FIPY to about
0,05 0,1 seconds, so I think that is not a real difference.

I think that the documentation is better in FI. It has a simple pdf that
explain all the features with same examples. For me the PIL
documentation is not so simple that the other.

That's all, for me.
If you have other questions, I'm here.

> Stani

Michele

From zlli at nlpr.ia.ac.cn  Thu Sep 15 16:28:32 2005
From: zlli at nlpr.ia.ac.cn (Zhenglong Li)
Date: Thu, 15 Sep 2005 22:28:32 +0800
Subject: [Image-SIG] help for conversion of NUMARRAY to PIL object
Message-ID: <43298510.3050807@nlpr.ia.ac.cn>

hi, everybody here,

	I am a newbie to python. I encounter a problem that how to convert an 
array of numarray to pil object. For example, the data in an image is 
extracted using Image.getdata, then the data are converted into  an 
array in numarray. But when the array is needed to convert to the pil 
object, I lose my mind. Could somebody here provide some solutions to 
this problem?  (In other words, all I need is the interface between 
reading/writing image data and NUMARRAY.)

	Thanks in advance.


From fredrik at pythonware.com  Thu Sep 15 16:47:57 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 15 Sep 2005 16:47:57 +0200
Subject: [Image-SIG] help for conversion of NUMARRAY to PIL object
References: <43298510.3050807@nlpr.ia.ac.cn>
Message-ID: <dgc1ir$avl$1@sea.gmane.org>

Zhenglong Li wrote:

> I am a newbie to python. I encounter a problem that how to convert an
> array of numarray to pil object. For example, the data in an image is
> extracted using Image.getdata, then the data are converted into  an
> array in numarray. But when the array is needed to convert to the pil
> object, I lose my mind. Could somebody here provide some solutions to
> this problem?  (In other words, all I need is the interface between
> reading/writing image data and NUMARRAY.)

this page might help:

    http://effbot.org/zone/pil-numpy.htm

</F> 




From zlli at nlpr.ia.ac.cn  Fri Sep 16 04:02:53 2005
From: zlli at nlpr.ia.ac.cn (Zhenglong Li)
Date: Fri, 16 Sep 2005 10:02:53 +0800
Subject: [Image-SIG] help for conversion of NUMARRAY to PIL object
In-Reply-To: <dgc1ir$avl$1@sea.gmane.org>
References: <43298510.3050807@nlpr.ia.ac.cn> <dgc1ir$avl$1@sea.gmane.org>
Message-ID: <432A27CD.5080303@nlpr.ia.ac.cn>

Hi, Fredrik,

	Thank you very much for your help. But there still exists a problem 
that the code cann't deal with 3-channel RGB image. If I want to read a 
len*width*3 matrix from PIL object into NumArray, and vice versa, what 
should I do?

	Thanks again!

Fredrik Lundh wrote:
> Zhenglong Li wrote:
> 
> 
>>I am a newbie to python. I encounter a problem that how to convert an
>>array of numarray to pil object. For example, the data in an image is
>>extracted using Image.getdata, then the data are converted into  an
>>array in numarray. But when the array is needed to convert to the pil
>>object, I lose my mind. Could somebody here provide some solutions to
>>this problem?  (In other words, all I need is the interface between
>>reading/writing image data and NUMARRAY.)
> 
> 
> this page might help:
> 
>     http://effbot.org/zone/pil-numpy.htm
> 
> </F> 
> 
> 
> 
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
> 
> 



From michele.petrazzo at unipex.it  Fri Sep 16 10:09:04 2005
From: michele.petrazzo at unipex.it (Michele Petrazzo)
Date: Fri, 16 Sep 2005 10:09:04 +0200
Subject: [Image-SIG] [ANN] FreeImagePy 1.0.0
In-Reply-To: <4329E9A4.8020306@grc.nasa.gov>
References: <4328AFE7.6000505@gmail.com> <43293190.4020409@unipex.it>
	<4329E9A4.8020306@grc.nasa.gov>
Message-ID: <432A7DA0.50207@unipex.it>

Bob Klimek wrote:
> Michele Petrazzo wrote:
> 
>>> What are the advantages over PIL (speed, features, ...)?
>>>   
>>
>> FI -> FreeImage
>> FIPY -> FreeImagePy
>>
>> Good question :)
>> I don't know very well PIL, but this is that I saw: ...
>>  
>>
> Hi Michele,
> 
> I have high hopes for FreeImagePy as I definitely intend to use it. 

Fantastic!

> But 
> after installation on my Win2000 machine running python 2.4.1, when I 
> typed the import statement, this is what I got.
> 
>  >>> import FreeImagePy
> 
> Traceback (most recent call last):
>  File "<pyshell#1>", line 1, in -toplevel-
>    import FreeImagePy
>  File "H:\Python24\Lib\site-packages\FreeImagePy\FreeImagePy.py", line 
> 29, in -toplevel-
>    import ctypes as C
> ImportError: No module named ctypes
>  >>>

This problem has a very simple solution. FIPY need ctypes for work (for 
call the external FI library). You can find it here:

http://starship.python.net/crew/theller/ctypes/
or here:
http://sourceforge.net/project/showfiles.php?group_id=71702

> 
> Bob
> 

Michele

From klimek at grc.nasa.gov  Fri Sep 16 14:19:25 2005
From: klimek at grc.nasa.gov (Bob Klimek)
Date: Fri, 16 Sep 2005 08:19:25 -0400
Subject: [Image-SIG] help for conversion of NUMARRAY to PIL object
In-Reply-To: <432A27CD.5080303@nlpr.ia.ac.cn>
References: <43298510.3050807@nlpr.ia.ac.cn> <dgc1ir$avl$1@sea.gmane.org> 
	<432A27CD.5080303@nlpr.ia.ac.cn>
Message-ID: <432AB84D.8010904@grc.nasa.gov>

Zhenglong Li wrote:

>Hi, Fredrik,
>
>	Thank you very much for your help. But there still exists a problem 
>that the code cann't deal with 3-channel RGB image. If I want to read a 
>len*width*3 matrix from PIL object into NumArray, and vice versa, what 
>should I do?
>  
>
Try this.

import numarray as N
import Image

screenLevels = 255.0 # we have 8 bit video cards

def image2array(im, convertType='UInt8'):
    """
    Convert PIL image to Numarray array
    """
    if im.mode == "L":
        a = N.fromstring(im.tostring(), N.UInt8)
        a = N.reshape(a, (im.size[1], im.size[0]))
        #a.shape = (im.size[1], im.size[0], 1)  # alternate way
    elif (im.mode=='RGB'):
        a = N.fromstring(im.tostring(), N.UInt8)
        a.shape = (im.size[1], im.size[0], 3)
    else:
        raise ValueError, im.mode+" mode not considered"

    if convertType == 'Float32':
        a = a.astype(N.Float32)
    return a

def array2image(a):
    """
    Converts array object (numarray) to image object (PIL).
    """
    h, w = a.shape[:2]
    int32 = N.Int32
    uint32 = N.UInt32
    float32 = N.Float32
    float64 = N.Float64

    if a.type()==int32 or a.type()==uint32 or a.type()==float32 or 
a.type()==float64:
        a = a.astype(N.UInt8) # convert to 8-bit
    if len(a.shape)==3:
        if a.shape[2]==3:  # a.shape == (y, x, 3)
            r = Image.fromstring("L", (w, h), a[:,:,0].tostring())
            g = Image.fromstring("L", (w, h), a[:,:,1].tostring())
            b = Image.fromstring("L", (w, h), a[:,:,2].tostring())
            return Image.merge("RGB", (r,g,b))
        elif a.shape[2]==1:  # a.shape == (y, x, 1)
            return Image.fromstring("L", (w, h), a.tostring())
    elif len(a.shape)==2:  # a.shape == (y, x)
        return Image.fromstring("L", (w, h), a.tostring())
    else:
        raise ValueError, "unsupported image mode"

Bob


From zlli at nlpr.ia.ac.cn  Fri Sep 16 15:43:39 2005
From: zlli at nlpr.ia.ac.cn (Zhenglong Li)
Date: Fri, 16 Sep 2005 21:43:39 +0800
Subject: [Image-SIG] help for conversion of NUMARRAY to PIL object
In-Reply-To: <432AB84D.8010904@grc.nasa.gov>
References: <43298510.3050807@nlpr.ia.ac.cn> <dgc1ir$avl$1@sea.gmane.org>
	<432A27CD.5080303@nlpr.ia.ac.cn> <432AB84D.8010904@grc.nasa.gov>
Message-ID: <432ACC0B.9070406@nlpr.ia.ac.cn>

Thank you very much for your generous help.


Bob Klimek wrote:
> Zhenglong Li wrote:
> 
>> Hi, Fredrik,
>>
>>     Thank you very much for your help. But there still exists a 
>> problem that the code cann't deal with 3-channel RGB image. If I want 
>> to read a len*width*3 matrix from PIL object into NumArray, and vice 
>> versa, what should I do?
>>  
>>
> Try this.
> 
> import numarray as N
> import Image
> 
> screenLevels = 255.0 # we have 8 bit video cards
> 
> def image2array(im, convertType='UInt8'):
>    """
>    Convert PIL image to Numarray array
>    """
>    if im.mode == "L":
>        a = N.fromstring(im.tostring(), N.UInt8)
>        a = N.reshape(a, (im.size[1], im.size[0]))
>        #a.shape = (im.size[1], im.size[0], 1)  # alternate way
>    elif (im.mode=='RGB'):
>        a = N.fromstring(im.tostring(), N.UInt8)
>        a.shape = (im.size[1], im.size[0], 3)
>    else:
>        raise ValueError, im.mode+" mode not considered"
> 
>    if convertType == 'Float32':
>        a = a.astype(N.Float32)
>    return a
> 
> def array2image(a):
>    """
>    Converts array object (numarray) to image object (PIL).
>    """
>    h, w = a.shape[:2]
>    int32 = N.Int32
>    uint32 = N.UInt32
>    float32 = N.Float32
>    float64 = N.Float64
> 
>    if a.type()==int32 or a.type()==uint32 or a.type()==float32 or 
> a.type()==float64:
>        a = a.astype(N.UInt8) # convert to 8-bit
>    if len(a.shape)==3:
>        if a.shape[2]==3:  # a.shape == (y, x, 3)
>            r = Image.fromstring("L", (w, h), a[:,:,0].tostring())
>            g = Image.fromstring("L", (w, h), a[:,:,1].tostring())
>            b = Image.fromstring("L", (w, h), a[:,:,2].tostring())
>            return Image.merge("RGB", (r,g,b))
>        elif a.shape[2]==1:  # a.shape == (y, x, 1)
>            return Image.fromstring("L", (w, h), a.tostring())
>    elif len(a.shape)==2:  # a.shape == (y, x)
>        return Image.fromstring("L", (w, h), a.tostring())
>    else:
>        raise ValueError, "unsupported image mode"
> 
> Bob
> 
> 
> 


From gandalf at designaproduct.biz  Fri Sep 16 15:54:58 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Fri, 16 Sep 2005 15:54:58 +0200
Subject: [Image-SIG] Loading OpenType font (PIL 1.1.5, Python 2.4.1,
	Windows XP)
Message-ID: <432ACEB2.3040304@designaproduct.biz>

  Hello,

This two liner:

import ImageFont
font = ImageFont.truetype('arial.ttf',14)


Gives me this error:

Traceback (most recent call last):
  File "T:\Python\Projects\PILTest\test.py", line 2, in ?
    font = ImageFont.truetype('arial.ttf',14)
  File "C:\Python24\Lib\site-packages\PIL\ImageFont.py", line 202, in 
truetype
    return FreeTypeFont(filename, size, index, encoding)
  File "C:\Python24\Lib\site-packages\PIL\ImageFont.py", line 121, in 
__init__
    self.font = _imagingft.getfont(file, size, index, encoding)
TypeError: function takes at most 3 arguments (4 given)

What am I doing wrong?



From fredrik at pythonware.com  Fri Sep 16 16:45:24 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 16 Sep 2005 16:45:24 +0200
Subject: [Image-SIG] Loading OpenType font (PIL 1.1.5, Python 2.4.1,
	Windows XP)
References: <432ACEB2.3040304@designaproduct.biz>
Message-ID: <dgelq1$nn$1@sea.gmane.org>

Laszlo Zsolt Nagy wrote:

> This two liner:
>
> import ImageFont
> font = ImageFont.truetype('arial.ttf',14)
>
> Gives me this error:
>
> Traceback (most recent call last):
>  File "T:\Python\Projects\PILTest\test.py", line 2, in ?
>    font = ImageFont.truetype('arial.ttf',14)
>  File "C:\Python24\Lib\site-packages\PIL\ImageFont.py", line 202, in
> truetype
>    return FreeTypeFont(filename, size, index, encoding)
>  File "C:\Python24\Lib\site-packages\PIL\ImageFont.py", line 121, in
> __init__
>    self.font = _imagingft.getfont(file, size, index, encoding)
> TypeError: function takes at most 3 arguments (4 given)
>
> What am I doing wrong?

make sure _imagingft.pyd is the one that came with PIL 1.1.5, and
not some earlier version.  to see what pyd it's using, do this:

    >>> import _imagingft
    >>> _imagingft.__file__

</F> 




From michele.petrazzo at unipex.it  Fri Sep 16 19:03:55 2005
From: michele.petrazzo at unipex.it (Michele Petrazzo)
Date: Fri, 16 Sep 2005 19:03:55 +0200
Subject: [Image-SIG] [ANN] FreeImagePy 1.0.0
In-Reply-To: <432AED30.4090801@grc.nasa.gov>
References: <4328AFE7.6000505@gmail.com> <43293190.4020409@unipex.it>
	<4329E9A4.8020306@grc.nasa.gov> <432A7DA0.50207@unipex.it>
	<432AED30.4090801@grc.nasa.gov>
Message-ID: <432AFAFB.4060900@unipex.it>

Bob Klimek wrote:
> Michele Petrazzo wrote:
> 
> This fixed that error. But there is another one. Here is a traceback.
> 
> 
>>>> import FreeImagePy FIPY = FreeImagePy.freeimage()
> 

<-cut traceback->

> FreeImagePy_LibraryNotFound: 'I cannot find the library at 
> H:\\Python24\\Lib\\site-packages\\FreeImagePy\\FreeImage.dll. Did you
>  pass me a vaid path?'
>>>> 
> 
> I searched my drive for "FreeImage.dll" and found it in:
> 
> H:\Python24\Python23\Lib\site-packages\FreeImagePy
> 
> I didn't notice this before but apparently the installation of 
> FreeImagePy created a Python23 with its own Lib and site-packages 
> folders, etc., and that's where it put the dll file. I copied the dll
>  file into: H:\Python24\Lib\site-packages\FreeImagePy and now the two
>  lines (above) seem to work ok without error.
> 
> BTW, Also the image 'freeimage.jpg' is located in:
> 
> H:\Python24\Python23\Lib\site-packages\FreeImagePy\test
> 

You had found two problems:
- I have to create two different exe files, one for python versions
- I don't know why, but exe package pass to the setup application an
"invalid" path, that is not the same passed to the source setup!

(c:\python23\python23 for the .exe and c:\python23 for the source)

I'll investigate and create the new packages.

> Now that I got it to work I'll test reading in some images including
> a 48-bit image and let you know if it works.

Yes, I'll wait for the response.

> 
> Bob
> 
> 

Thanks,
Michele

From esr at snark.thyrsus.com  Sun Sep 18 00:53:55 2005
From: esr at snark.thyrsus.com (Eric S. Raymond)
Date: Sat, 17 Sep 2005 18:53:55 -0400
Subject: [Image-SIG] Here's a better flood-fill technique
Message-ID: <200509172253.j8HMrtrs018277@snark.thyrsus.com>

On 25 June 2005 William Baxter posted a request for a flood-fill
algorithm in Python, The following day Bob Klimek posted an effective
but extremely complex implementation to this list.

At the time I was not interested in this problem.  In the last few
days I have become so.  I'm translating some old C graphics code of
mine into Python, and my naive recursive flood-fill blew the
interpreter stack.

I found Mr. Klimek's answer while Googling for a Python flood-fill.  I
looked at the code, went "Bletch! This is complicated!  I don't want
to maintain this!" and decided to invent a simpler way.

With all due respect to Mr. Klimek, he wasn't thinking like a Python
programmer.  The right thing to do is exploit Python's list-handling.
Here is the code:

def __flood_fill(image, x, y, value):
    "Flood fill on a region of non-BORDER_COLOR pixels."
    if not image.within(x, y) or image.get_pixel(x, y) == BORDER_COLOR:
        return
    edge = [(x, y)]
    image.set_pixel(x, y, value)
    while edge:
        newedge = []
        for (x, y) in edge:
            for (s, t) in ((x+1, y), (x-1, y), (x, y+1), (x, y-1)):
                if image.within(s, t) and \
                	image.get_pixel(s, t) not in (BORDER_COLOR, value):
                    image.set_pixel(s, t, value)
                    newedge.append((s, t))
        edge = newedge

At each step there is a list of edge pixels for the flood-filled 
region.  You check every pixel adjacent to the edge; for each, if it is
eligible to be colored, you color it and add it to a new edge list.
Then you replace the old edge list with the new one.  Stop when the
list is empty.

(The methods have slightly different names than in PIL because I'm
using a thin wrapper class around Image.  Translation is trivial.)

This is nonrecursive and the storage requirement is bounded by the
number of pixels in the region perimeter.  Each pixel will be accessed
at most three times and set just once.  It's simple and efficient.
Even, dare I say it, elegant.

The lesson: when writing Python, don't forget that you have dynamic
data types!

Frederik, say the word and I'll ship you a generalized version for PIL.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The abortion rights and gun control debates are twin aspects of a deeper
question --- does an individual ever have the right to make decisions
that are literally life-or-death?  And if not the individual, who does?

From gandalf at designaproduct.biz  Sun Sep 18 09:38:21 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Sun, 18 Sep 2005 09:38:21 +0200
Subject: [Image-SIG] Loading OpenType font (PIL 1.1.5, Python 2.4.1,
 Windows XP)
In-Reply-To: <dgelq1$nn$1@sea.gmane.org>
References: <432ACEB2.3040304@designaproduct.biz> <dgelq1$nn$1@sea.gmane.org>
Message-ID: <432D196D.4080205@designaproduct.biz>


>>
>>What am I doing wrong?
>>    
>>
>
>make sure _imagingft.pyd is the one that came with PIL 1.1.5, and
>not some earlier version.  to see what pyd it's using, do this:
>
>    >>> import _imagingft
>    >>> _imagingft.__file__
>  
>
C:\Documents and Settings\Gandalf>python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import _imagingft
 >>> _imagingft.__file__
'C:\\Python24\\DLLs\\_imagingft.pyd'
 >>>

You were right, thank you. The good one is under site-packages but I had 
one under DLLs too.
I don't know how could this happen. :-)

   Les


From gandalf at designaproduct.biz  Sun Sep 18 09:55:57 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Sun, 18 Sep 2005 09:55:57 +0200
Subject: [Image-SIG] HTML Library needed
Message-ID: <432D1D8D.8060104@designaproduct.biz>


  Hello All,

Do you know a library for Python that renders simple HTML pages on images?
I need this to be used from command line (e.g. withouth a windowing system).
I started to develop my own, but it is in early stage. I do not want to 
duplicate free code. :)

  Les


From gandalf at designaproduct.biz  Sun Sep 18 11:16:11 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Sun, 18 Sep 2005 11:16:11 +0200
Subject: [Image-SIG] How to convert from transparent PIL to transparent
	wx.Image ?
Message-ID: <432D305B.30709@designaproduct.biz>

Hello,

This is what I have now:

def piltoimage(pil):
    """Convert PIL Image to wx.Image."""
    image = wx.EmptyImage(pil.size[0], pil.size[1])
    new_image = pil.convert('RGB')
    data = new_image.tostring()
    image.SetData(data)
    return image

But this does not work if I try to use 'RGBA' mode. Do you know a solution?

  Les


From gandalf at designaproduct.biz  Sun Sep 18 11:29:33 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Sun, 18 Sep 2005 11:29:33 +0200
Subject: [Image-SIG] How to convert from transparent PIL to transparent
 wx.Image ?
In-Reply-To: <432D305B.30709@designaproduct.biz>
References: <432D305B.30709@designaproduct.biz>
Message-ID: <432D337D.9070202@designaproduct.biz>


>But this does not work if I try to use 'RGBA' mode. Do you know a solution?
>
>  
>
I found one. Here it is:

def piltoimage(pil,alpha=True):
    """Convert PIL Image to wx.Image."""
    if alpha:
        image = apply( wx.EmptyImage, pil.size )
        image.SetData( pil.convert( "RGB").tostring() )
        image.SetAlphaData(pil.convert("RGBA").tostring()[3::4])
    else:
        image = wx.EmptyImage(pil.size[0], pil.size[1])
        new_image = pil.convert('RGB')
        data = new_image.tostring()
        image.SetData(data)
    return image


From gandalf at designaproduct.biz  Mon Sep 19 10:42:20 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Mon, 19 Sep 2005 10:42:20 +0200
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)
Message-ID: <432E79EC.9060503@designaproduct.biz>

I create a fully transparent red image this way:

size = (400,400)
img = Image.new('RGBA',size,(255,0,0,0))

Then I draw an (antialiased) text on it:

drawer = ImageDraw.Draw(img)
font = ImageFont.truetype('arc.ttf',12)
drawer.text((0,0),"This text is 12pt",font=font,fill=(0,0,0,255))

This is what I get (image drawn on a gray background):

http://mess.hu/download/bad_antialias.png

Apparently, antialiasing will use a mixture of the background color and 
the text color on the edges.
I think this is good only if the background is fully opaque. Is there a 
workaround?

Is this a PIL bug or a feature?

Thanks,

  Les



From gandalf at designaproduct.biz  Mon Sep 19 11:48:10 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Mon, 19 Sep 2005 11:48:10 +0200
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)
In-Reply-To: <432E79EC.9060503@designaproduct.biz>
References: <432E79EC.9060503@designaproduct.biz>
Message-ID: <432E895A.4090308@designaproduct.biz>


>Apparently, antialiasing will use a mixture of the background color and 
>the text color on the edges.
>I think this is good only if the background is fully opaque. Is there a 
>workaround?
>  
>
I can already give the correct transformation (I checked this with a 
very slow putpixel/getpixel iteration):


function overlay(image1,image2) -> image

For each pixel

INPUT:
    image1 = R1,G1,B1,A1
    image2 = R2,G2,B2,A2

OUTPUT:
    (R1*A1 + R2*A2)/A1+A2,(G1*A1 + G2*A2)/A1+A2,(B1*A1 + B2*A2)/A1+A2,A1+A2

But I cannot do this in PIL. Is it possible at all? This would be a very 
good extension, and it would solve the text antialiasing problem too.

  Les

From gandalf at designaproduct.biz  Mon Sep 19 15:30:34 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Mon, 19 Sep 2005 15:30:34 +0200
Subject: [Image-SIG] New patch to PIL (was: Re: Bad antialias? (in Python
 Imaging Library 1.1.5))
In-Reply-To: <432E895A.4090308@designaproduct.biz>
References: <432E79EC.9060503@designaproduct.biz>
	<432E895A.4090308@designaproduct.biz>
Message-ID: <432EBD79.6030103@designaproduct.biz>


   Hello,

I created a patch for PIL, exporting a new factory function:

Image.overlay(image1,image2) -> image

[image1 and image2 must be in RGBA mode]

The resulting image looks like image2 placed over image1. It handles 
transparency correctly. E.g. if image1 has opacity 50% and image2 has 
opacity 50% then the resulting image will have opacity 75%  ( 100% * 
(0.5 + 0.5*0.5 ) and pixel values will be weighted using the opacity 
values. I found no way in Python to do this. I believe that Draw.text 
should use this method for RGBA images and antialiased fonts (instead of 
what it is using now). I explained why and included a faulty text() output.

I read in the PIL documentation that this list is the right place to get 
answers about PIL. Since nobody could give me an answer to my problem, I 
created this patch. But I got no answers since 6 hours. I do not know 
what it means. Either it is a time zone issue or it is because this list 
is abandoned. I'm going to wait some more and re-post in the main python 
list.

  Les

p.s.: I think I have another improvement, I really want to touch base 
with the authors of PIL.



From meyer at mesw.de  Mon Sep 19 15:58:41 2005
From: meyer at mesw.de (Markus Meyer)
Date: Mon, 19 Sep 2005 15:58:41 +0200
Subject: [Image-SIG] New patch to PIL
In-Reply-To: <432EBD79.6030103@designaproduct.biz>
References: <432E79EC.9060503@designaproduct.biz>	<432E895A.4090308@designaproduct.biz>
	<432EBD79.6030103@designaproduct.biz>
Message-ID: <432EC411.2000802@mesw.de>

Hi Laszlo,

Laszlo Zsolt Nagy schrieb:

>I read in the PIL documentation that this list is the right place to get 
>answers about PIL. Since nobody could give me an answer to my problem, I 
>created this patch. But I got no answers since 6 hours. I do not know 
>what it means. Either it is a time zone issue or it is because this list 
>is abandoned. I'm going to wait some more and re-post in the main python 
>list.
>  
>
If you had looked into the list archive, you would have seen that this 
list is not abandoned at all, but also not very high-volume. If you 
would have got no answer for 6 days, I would have understood your 
concern, but 6 hours really is no time (especially considering things 
like the different time zones). Please remember that this is free 
software and the maintainers likely have some other things todo than 
lurking on the mailing list for 24/7.

Anway, I'm sure that the PIL maintainers will appreciate your interest 
in and support for PIL and will answer you as soon as they find the time 
to do so.

Cheers,
Markus


From gandalf at designaproduct.biz  Mon Sep 19 16:13:54 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Mon, 19 Sep 2005 16:13:54 +0200
Subject: [Image-SIG] New patch to PIL
In-Reply-To: <432EC411.2000802@mesw.de>
References: <432E79EC.9060503@designaproduct.biz>	<432E895A.4090308@designaproduct.biz>
	<432EBD79.6030103@designaproduct.biz> <432EC411.2000802@mesw.de>
Message-ID: <432EC7A2.8040006@designaproduct.biz>


> If you had looked into the list archive, you would have seen that this 
> list is not abandoned at all, but also not very high-volume. If you 
> would have got no answer for 6 days, I would have understood your 
> concern, but 6 hours really is no time (especially considering things 
> like the different time zones).

Please forgive me. I'm new on this list and I do not know the usual 
turnaround time.

> Please remember that this is free software and the maintainers likely 
> have some other things todo than lurking on the mailing list for 24/7.

Of course, I understand. I just wanted to know if this is the right 
place to ask. The latest documentation is from 2003, this is why I was 
not sure.

> Anway, I'm sure that the PIL maintainers will appreciate your interest 
> in and support for PIL and will answer you as soon as they find the 
> time to do so.

Great, looking forward. :-) Thanks

   Les


From fredrik at pythonware.com  Mon Sep 19 16:13:27 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 19 Sep 2005 16:13:27 +0200
Subject: [Image-SIG] New patch to PIL (was: Re: Bad antialias? (in
	Python Imaging Library 1.1.5))
References: <432E79EC.9060503@designaproduct.biz><432E895A.4090308@designaproduct.biz>
	<432EBD79.6030103@designaproduct.biz>
Message-ID: <dgmh27$9s$1@sea.gmane.org>

Laszlo Zsolt Nagy wrote:

> Since nobody could give me an answer to my problem, I created
> this patch. But I got no answers since 6 hours. I do not know
> what it means.   Either it is a time zone issue or it is because this
> list is abandoned.

Or maybe you need to adjust your expectations, and ask yourself if
posts like the one above really is the best way to encourage anyone
to help you...

</F> 




From gwidion at mpc.com.br  Mon Sep 19 16:37:21 2005
From: gwidion at mpc.com.br (Joao S. O. Bueno Calligaris)
Date: Mon, 19 Sep 2005 11:37:21 -0300
Subject: [Image-SIG] New patch to PIL (was: Re: Bad antialias? (in
	Python Imaging Library 1.1.5))
In-Reply-To: <432EBD79.6030103@designaproduct.biz>
References: <432E79EC.9060503@designaproduct.biz>
	<432E895A.4090308@designaproduct.biz>
	<432EBD79.6030103@designaproduct.biz>
Message-ID: <200509191137.21366.gwidion@mpc.com.br>

HI,

I am no PIL developer - I do n't even recall if I ever even built it 
at all - but I have some code I wrote a while ago that could do a 
"generic" combination of two given images, maybe somewhat fast, given 
a kind of  "bytecode"  representing an algebraic expression to use 
with the pixels (just like your expression in the "output" of the 
first e-mail).

If your improvements is going into pil, maybe it will be worth for 
everyone consider adding some of that code as well. (So that, for 
example, any of the GIMP's mare than 20 image combination modes would 
be available in PIL doing as little as adding a constant bytecode for 
each mode).

Regards,
	JS
	-><-


On Monday 19 September 2005 10:30, Laszlo Zsolt Nagy wrote:
>    Hello,
>
> I created a patch for PIL, exporting a new factory function:
>
> Image.overlay(image1,image2) -> image
>
> [image1 and image2 must be in RGBA mode]
>
> The resulting image looks like image2 placed over image1. It
> handles transparency correctly. E.g. if image1 has opacity 50% and
> image2 has opacity 50% then the resulting image will have opacity
> 75%  ( 100% * (0.5 + 0.5*0.5 ) and pixel values will be weighted
> using the opacity values. I found no way in Python to do this. I
> believe that Draw.text should use this method for RGBA images and
> antialiased fonts (instead of what it is using now). I explained
> why and included a faulty text() output.
>
> I read in the PIL documentation that this list is the right place
> to get answers about PIL. Since nobody could give me an answer to
> my problem, I created this patch. But I got no answers since 6
> hours. I do not know what it means. Either it is a time zone issue
> or it is because this list is abandoned. I'm going to wait some
> more and re-post in the main python list.
>
>   Les
>
> p.s.: I think I have another improvement, I really want to touch
> base with the authors of PIL.
>
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig

From spamslam23 at yahoo.com  Mon Sep 19 16:40:49 2005
From: spamslam23 at yahoo.com (David Edwards)
Date: Mon, 19 Sep 2005 07:40:49 -0700 (PDT)
Subject: [Image-SIG] PIL Install Problems
Message-ID: <20050919144050.61791.qmail@web51303.mail.yahoo.com>

I'm trying to install the Imaging Library (v 1.1.5),
but it's not finding the Freetype2 component that it
says it needs and I downloaded. I put it in the same
directory as the zlib and jpeg components.

I've tried modifying the setup.py file to tell it
exactly where to look, but it makes no difference in
the results. Trying to install what it does find gives
me this error:

creating
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages
error: could not create
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages':
File exists

Can anyone help with this?

Maybe this is a naive question, but I don't understand
why the library isn't available as standard
installable package for Mac OS X, just like many other
commercial, freeware, and shareware items. It can't be
that hard, since Apple gives you the tools as part of
the OS, and it would eliminate these types of
problems.

Thank you.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From gandalf at designaproduct.biz  Mon Sep 19 16:54:06 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Mon, 19 Sep 2005 16:54:06 +0200
Subject: [Image-SIG] New patch to PIL
In-Reply-To: <200509191137.21366.gwidion@mpc.com.br>
References: <432E79EC.9060503@designaproduct.biz>	<432E895A.4090308@designaproduct.biz>	<432EBD79.6030103@designaproduct.biz>
	<200509191137.21366.gwidion@mpc.com.br>
Message-ID: <432ED10E.1020008@designaproduct.biz>

Joao S. O. Bueno Calligaris wrote:

>HI,
>
>I am no PIL developer - I do n't even recall if I ever even built it 
>at all - but I have some code I wrote a while ago that could do a 
>"generic" combination of two given images, maybe somewhat fast, given 
>a kind of  "bytecode"  representing an algebraic expression to use 
>with the pixels (just like your expression in the "output" of the 
>first e-mail).
>
>If your improvements is going into pil, maybe it will be worth for 
>everyone consider adding some of that code as well. (So that, for 
>example, any of the GIMP's mare than 20 image combination modes would 
>be available in PIL doing as little as adding a constant bytecode for 
>each mode).
>  
>
Have you checked the ImageMath module? It is in the upcoming release of PIL.

http://effbot.org/imagingbook/imagemath.htm

The problem with it is that it can only process one band images. 
Sometimes split -> imagemath -> merge cannot do what you need.

  Les

From fredrik at pythonware.com  Mon Sep 19 16:52:32 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 19 Sep 2005 16:52:32 +0200
Subject: [Image-SIG] PIL Install Problems
References: <20050919144050.61791.qmail@web51303.mail.yahoo.com>
Message-ID: <dgmjbg$8ja$1@sea.gmane.org>

David Edwards wrote:

> Maybe this is a naive question, but I don't understand
> why the library isn't available as standard
> installable package for Mac OS X, just like many other
> commercial, freeware, and shareware items.

Bob Ippolito offers prebuilt binaries for lots of Python extensions:

    http://pythonmac.org/packages/

> It can't be that hard, since Apple gives you the tools as part of
> the OS, and it would eliminate these types of problems.

Apple's giving away free computers if I buy the OS?  Where do I
sign up?

</F> 




From gandalf at designaproduct.biz  Mon Sep 19 16:59:28 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Mon, 19 Sep 2005 16:59:28 +0200
Subject: [Image-SIG] PIL Install Problems
In-Reply-To: <20050919144050.61791.qmail@web51303.mail.yahoo.com>
References: <20050919144050.61791.qmail@web51303.mail.yahoo.com>
Message-ID: <432ED250.2060900@designaproduct.biz>

David Edwards wrote:

>I'm trying to install the Imaging Library (v 1.1.5),
>but it's not finding the Freetype2 component that it
>says it needs and I downloaded. I put it in the same
>directory as the zlib and jpeg components.
>
>I've tried modifying the setup.py file to tell it
>exactly where to look, but it makes no difference in
>the results. Trying to install what it does find gives
>me this error:
>
>creating
>/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages
>error: could not create
>'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages':
>File exists
>
>Can anyone help with this?
>  
>
I cannot help you building on MAC. I do not own MAC. :-( AFAIK
But possibly you cannot build truetype support on MAC at all. MAC has 
its own font format.

In the documentation

http://www.pythonware.com/library/pil/handbook/imagedraw.htm

under 'Fonts' there is a sentence:

"Note that OpenType/TrueType support is optional, and may not be 
supported by all PIL builds."

  Les


From stefano at pragma2000.com  Mon Sep 19 20:09:37 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Mon, 19 Sep 2005 20:09:37 +0200
Subject: [Image-SIG] Correctly determine image size of a Photoshop EPS
Message-ID: <4327422405091911095dd3d39d@mail.gmail.com>

Hello,

I got hold of some EPS files evidently made with Photoshop.
It seems I can't convert them to jpeg while retaining the correct
size. The problem is that I need to know the original size because I
have to make decisions depending on that.

I've got one that when opened in Photoshop is 1315x890, but anything
else gives me a 316x214 image. I tried with pil, imagemagick, exiftool
and freeimage. I think all of them except exiftool rely on
ghostscript.

I figured the problem must be the BoundingBox being set to 0 0 316 214.

This is extracted from the eps file:

%%Creator: Adobe Photoshop Version 7.0
%%Title: 102251N_c.eps
%%CreationDate: Fri Sep 16 2005 18:31:35
%%BoundingBox: 0 0 316 214
%%HiResBoundingBox: 0 0 315.6 213.6
%%SuppressDotGainCompensation
%%DocumentProcessColors: Cyan Magenta Yellow Black
%%EndComments
%%BeginProlog
%%EndProlog
%%BeginSetup
%%EndSetup
%ImageData: 1315 890 8 4 0 1 6 "beginimage"
%BeginPhotoshop: 6362

So, first question: why is the BoundingBox set this way? Is it plain
wrong, or is there a rationale behind?

Then I see the non standard %ImageData field. I found the following
info bout it:

Photoshop 6.0 SDK
EPS Parameters for ImageData (Photoshop 3.0 and later)

columns      Width of the image in pixels
rows         Height of the image in pixels
depth        Number of bits per channel. Must be 1 or 8
mode         Image mode. Bitmap/grayscale = 1; Lab = 2; RGB = 3; CMYK = 4
pad channels Number of other channels stored in the file.
             Ignored when reading...
block size   Number of bytes per row per channel.
             Will be either 1 or formula (below):
             1 = Data is interleaved
             (columns*depth+7)/8 = Data is stored in line interleaved format
             or there is only one channel
binary/ascii 1 = Data is in binary format
             2 = Data is in hex ascii format
data start   Entire PostScriptline immediately preceding the image data.
             This entire line should not occur elewhere in the PostScript
             header code, but it may occur at part of line   

So, since this is documented, why is it not implemented in any tool?
I guess I can answer that: because it's not standard and could change
without notice.

But then I wonder: isn't there any support at all? How can a poor soul
know the size of a photoshop eps file without opening it with
photoshop?

I can't believe others didn't have this problem. Did everybody have to
implement their own dirty parser and search for the %ImageData field
by themselves?

Please help a poor soul,
thanks!
stefano

From kevin at cazabon.com  Mon Sep 19 20:36:26 2005
From: kevin at cazabon.com (kevin@cazabon.com)
Date: Mon, 19 Sep 2005 20:36:26 +0200
Subject: [Image-SIG] Correctly determine image size of a Photoshop EPS
References: <4327422405091911095dd3d39d@mail.gmail.com>
Message-ID: <012301c5bd49$0b491b90$650aa8c0@duallie>

EPS files don't have specific pixel dimensions - they're essentially a
vector format.  You may happen to have raster data embedded in it, but
that's besides the point.

The issue is likely the DPI or pixels/inch setting used to convert the image
to raster format.  Photoshop probably defaults to 300 pixels/inch or
something, while the others default to 72.

I'm not sure how you change the rendering res in PILfor EPS imports - but I
almost guarantee that's where you need to look.

Kevin.
----- Original Message ----- 
From: "Stefano Masini" <stefano at pragma2000.com>
To: <image-sig at python.org>
Sent: Monday, September 19, 2005 8:09 PM
Subject: [Image-SIG] Correctly determine image size of a Photoshop EPS


> Hello,
>
> I got hold of some EPS files evidently made with Photoshop.
> It seems I can't convert them to jpeg while retaining the correct
> size. The problem is that I need to know the original size because I
> have to make decisions depending on that.
>
> I've got one that when opened in Photoshop is 1315x890, but anything
> else gives me a 316x214 image. I tried with pil, imagemagick, exiftool
> and freeimage. I think all of them except exiftool rely on
> ghostscript.
>
> I figured the problem must be the BoundingBox being set to 0 0 316 214.
>
> This is extracted from the eps file:
>
> %%Creator: Adobe Photoshop Version 7.0
> %%Title: 102251N_c.eps
> %%CreationDate: Fri Sep 16 2005 18:31:35
> %%BoundingBox: 0 0 316 214
> %%HiResBoundingBox: 0 0 315.6 213.6
> %%SuppressDotGainCompensation
> %%DocumentProcessColors: Cyan Magenta Yellow Black
> %%EndComments
> %%BeginProlog
> %%EndProlog
> %%BeginSetup
> %%EndSetup
> %ImageData: 1315 890 8 4 0 1 6 "beginimage"
> %BeginPhotoshop: 6362
>
> So, first question: why is the BoundingBox set this way? Is it plain
> wrong, or is there a rationale behind?
>
> Then I see the non standard %ImageData field. I found the following
> info bout it:
>
> Photoshop 6.0 SDK
> EPS Parameters for ImageData (Photoshop 3.0 and later)
>
> columns      Width of the image in pixels
> rows         Height of the image in pixels
> depth        Number of bits per channel. Must be 1 or 8
> mode         Image mode. Bitmap/grayscale = 1; Lab = 2; RGB = 3; CMYK = 4
> pad channels Number of other channels stored in the file.
>              Ignored when reading...
> block size   Number of bytes per row per channel.
>              Will be either 1 or formula (below):
>              1 = Data is interleaved
>              (columns*depth+7)/8 = Data is stored in line interleaved
format
>              or there is only one channel
> binary/ascii 1 = Data is in binary format
>              2 = Data is in hex ascii format
> data start   Entire PostScriptline immediately preceding the image data.
>              This entire line should not occur elewhere in the PostScript
>              header code, but it may occur at part of line
>
> So, since this is documented, why is it not implemented in any tool?
> I guess I can answer that: because it's not standard and could change
> without notice.
>
> But then I wonder: isn't there any support at all? How can a poor soul
> know the size of a photoshop eps file without opening it with
> photoshop?
>
> I can't believe others didn't have this problem. Did everybody have to
> implement their own dirty parser and search for the %ImageData field
> by themselves?
>
> Please help a poor soul,
> thanks!
> stefano
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>



From kevin at cazabon.com  Mon Sep 19 20:45:03 2005
From: kevin at cazabon.com (kevin@cazabon.com)
Date: Mon, 19 Sep 2005 20:45:03 +0200
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)
References: <432E79EC.9060503@designaproduct.biz>
Message-ID: <013901c5bd4a$3f487570$650aa8c0@duallie>

I've managed to do fairly decent anti-aliased text from bitmap PIL fonts,
even including colored text, as follows:

1)  render the text at 2x the desired size (or 3x or 4x depending on how
fine you want the anti-aliasing to be...).  Render it in black on a plain
white background of the correct size for the text only.

2)  resize the text to the right size (using im.resize()), using bicubic
interpolation (i.e. use the method = Image.BICUBIC arg to resize)

3)  create a colored image the same size as the text - in the color you want
the text to be in the final output.

4)  paste the lot into the final image, using the text image as a mask.
(i.e.  final = original.paste(colorImage, (x, y), textMask)


Resizing using BICUBIC will give the text anti-aliased edges as desired.

Kevin.

----- Original Message ----- 
From: "Laszlo Zsolt Nagy" <gandalf at designaproduct.biz>
To: <image-sig at python.org>
Sent: Monday, September 19, 2005 10:42 AM
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)


> I create a fully transparent red image this way:
>
> size = (400,400)
> img = Image.new('RGBA',size,(255,0,0,0))
>
> Then I draw an (antialiased) text on it:
>
> drawer = ImageDraw.Draw(img)
> font = ImageFont.truetype('arc.ttf',12)
> drawer.text((0,0),"This text is 12pt",font=font,fill=(0,0,0,255))
>
> This is what I get (image drawn on a gray background):
>
> http://mess.hu/download/bad_antialias.png
>
> Apparently, antialiasing will use a mixture of the background color and
> the text color on the edges.
> I think this is good only if the background is fully opaque. Is there a
> workaround?
>
> Is this a PIL bug or a feature?
>
> Thanks,
>
>   Les
>
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>
>



From stefano at pragma2000.com  Tue Sep 20 08:10:02 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Tue, 20 Sep 2005 08:10:02 +0200
Subject: [Image-SIG] Correctly determine image size of a Photoshop EPS
In-Reply-To: <012301c5bd49$0b491b90$650aa8c0@duallie>
References: <4327422405091911095dd3d39d@mail.gmail.com>
	<012301c5bd49$0b491b90$650aa8c0@duallie>
Message-ID: <4327422405091923105e9ad72f@mail.gmail.com>

On 9/19/05, kevin at cazabon.com <kevin at cazabon.com> wrote:
> EPS files don't have specific pixel dimensions - they're essentially a
> vector format.  You may happen to have raster data embedded in it, but
> that's besides the point.

I know, but correctly determining the pixel size of the embedded
raster image is not besides the point. As I said, I have to take
decisions basing on that. Namely, determine whether they're too small
for print.

> The issue is likely the DPI or pixels/inch setting used to convert the image
> to raster format.  Photoshop probably defaults to 300 pixels/inch or
> something, while the others default to 72.

Nope.
Photoshop stores inside the eps metadata section the information about
the original image resolution.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.1-111">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about="" xmlns:tiff="http://ns.adobe.com/tiff/1.0/">
         <tiff:XResolution>3000000/10000</tiff:XResolution>
         <tiff:YResolution>3000000/10000</tiff:YResolution>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

This way when you open a Photoshop EPS file in Photoshop, unlike Gimp
or whatever else, it doesn't ask you your target device resolution,
but just opens it. If instead, you open a generic eps, _then_ it asks
for the intended resolution, of course.

A "Photoshop EPS" file is not a generic EPS. Infact I doubt Photoshop
even has a full blown postscript interpreter (mhmm... maybe it uses
that of illustrator... I'd have to try).
It's a very particular case of EPS, used exclusively for raster
images, with a whole bunch of extra metainformation about it, that
_happens_ to be also an embeddable Postscript! :)

So, my point: since I have so many images to batch process, do I have
to implement my own thing, or did someone else took the trouble of
writing code for reading metadata from Photoshop EPS files?

stefano

From fredrik at pythonware.com  Tue Sep 20 08:19:47 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 20 Sep 2005 08:19:47 +0200
Subject: [Image-SIG] Correctly determine image size of a Photoshop EPS
References: <4327422405091911095dd3d39d@mail.gmail.com>
Message-ID: <dgo9m5$1vs$1@sea.gmane.org>

Stefano Masini wrote:

> I figured the problem must be the BoundingBox being set to 0 0 316 214.
>
> This is extracted from the eps file:
>
> %%Creator: Adobe Photoshop Version 7.0
> %%Title: 102251N_c.eps
> %%CreationDate: Fri Sep 16 2005 18:31:35
> %%BoundingBox: 0 0 316 214
> %%HiResBoundingBox: 0 0 315.6 213.6
> %%SuppressDotGainCompensation
> %%DocumentProcessColors: Cyan Magenta Yellow Black
> %%EndComments
> %%BeginProlog
> %%EndProlog
> %%BeginSetup
> %%EndSetup
> %ImageData: 1315 890 8 4 0 1 6 "beginimage"
> %BeginPhotoshop: 6362
>
> So, first question: why is the BoundingBox set this way? Is it plain
> wrong, or is there a rationale behind?

as Kevin says, it's probably because the image is saved with a specific DPI
(the bounding box is in points, so it's only the same thing as the number of
pixels for images where the DPI is set to 72)

> Then I see the non standard %ImageData field. I found the following
> info bout it:
>
> Photoshop 6.0 SDK
> EPS Parameters for ImageData (Photoshop 3.0 and later)
>
> columns      Width of the image in pixels
> rows         Height of the image in pixels
> depth        Number of bits per channel. Must be 1 or 8
> mode         Image mode. Bitmap/grayscale = 1; Lab = 2; RGB = 3; CMYK = 4
> pad channels Number of other channels stored in the file.
>              Ignored when reading...
> block size   Number of bytes per row per channel.
>              Will be either 1 or formula (below):
>              1 = Data is interleaved
>              (columns*depth+7)/8 = Data is stored in line interleaved format
>              or there is only one channel
> binary/ascii 1 = Data is in binary format
>              2 = Data is in hex ascii format
> data start   Entire PostScriptline immediately preceding the image data.
>              This entire line should not occur elewhere in the PostScript
>              header code, but it may occur at part of line
>
> So, since this is documented, why is it not implemented in any tool?

PIL is supposed to support ImageData tags, and it should pick the size from
the ImageData header over the bounding box, but I suppose it's not robust
enough to handle your file.

if you can mail me a copy of the file (off-list), I can take a look when I find
the time.

</F>




From gandalf at designaproduct.biz  Tue Sep 20 10:27:14 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Tue, 20 Sep 2005 10:27:14 +0200
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)
In-Reply-To: <013901c5bd4a$3f487570$650aa8c0@duallie>
References: <432E79EC.9060503@designaproduct.biz>
	<013901c5bd4a$3f487570$650aa8c0@duallie>
Message-ID: <432FC7E2.3040007@designaproduct.biz>

kevin at cazabon.com wrote:

>I've managed to do fairly decent anti-aliased text from bitmap PIL fonts,
>even including colored text, as follows:
>  
>
   Kevin,

Have you seen my example PNG?

My problem is not with bitmap fonts. BTW I tried to do what you said 
before I wrote to this list. Create a B&W image from the text and use it 
as an alpha channel while interpolating between the text color image and 
the original image. fonts. Then I realized that I have problems  with 
overlaying one image onto another in general. The problem comes when 
'original' is a transparent image. Paste will only handle one mask 
(textMask), but it doesn't care about the alpha channel of your original 
image. E.g. if your original image had this colour:  (255,0,0,0) and 
your text color is (0,0,255,255) then the result will have lilac pixels 
(127,0,127,255)  around the text, instead of  (0,0,255,127).

I created a short but detailed example with some source images, a python 
program and the explanation of the error.

http://mess.hu/download/python/PIL_BUG.zip


   Les


From stefano at pragma2000.com  Tue Sep 20 11:30:28 2005
From: stefano at pragma2000.com (Stefano Masini)
Date: Tue, 20 Sep 2005 11:30:28 +0200
Subject: [Image-SIG] Correctly determine image size of a Photoshop EPS
In-Reply-To: <dgo9m5$1vs$1@sea.gmane.org>
References: <4327422405091911095dd3d39d@mail.gmail.com>
	<dgo9m5$1vs$1@sea.gmane.org>
Message-ID: <4327422405092002303976cd85@mail.gmail.com>

On 9/20/05, Fredrik Lundh <fredrik at pythonware.com> wrote:
> PIL is supposed to support ImageData tags, and it should pick the size from
> the ImageData header over the bounding box, but I suppose it's not robust
> enough to handle your file.

Thanks for the hint, Fredrik. Indeed I went and looked at the code and
found the reason:
EpsImagePlugin.py around line 237.
After reading ImageData, before setting self.size to the according
values, it tries to determine the decoder type. According to the
specification, even the one I posted previously, the only supported
values are 1 and 2 (binary and hex, respectively). But in my case,
there's a value of 6. At this point the code exits with a break, and
doesn't reach the point where it sets the size.
So, I guess a quick fix would be to move the self.size = x,y code a
little upper, but maybe there's a reason this should not be done, I
don't know.

By the way, I experimentally found out what the various values mean,
by generating different eps files with Photoshop. Here's the list:

1 - binary
2 - ascii
3 - jpeg low quality
4 - jpeg medium quality
5 - jpeg high quality
6 - jpeg maximum quality
7 - ascii85

These correspond to the options you get in the save dialog in Photoshop.
Actually, I'm not sure what use you make with this information, since
it's ghostscript's job to convert the file to ppmraw format, and I
found no other reference in PIL's code to the above decoder type,
except for self.tile2, which is not referenced anywhere as well.

Furthermore, as I already noticed on another image previously (that I
think I wrote to you about), pil can't get ghostscript to successfully
process the file, and doesn't generate any output. I don't know why is
that, but I was able to successfully convert it with imagemagick, that
uses ghostscript too, so I figured there's got to be some way to do
it. I just don't know enough ghostscript to fix pil and make it work!
:(

> if you can mail me a copy of the file (off-list), I can take a look when I find
> the time.

I will, thanks!

cheers,
stefano

From klimek at grc.nasa.gov  Tue Sep 20 20:58:03 2005
From: klimek at grc.nasa.gov (Bob Klimek)
Date: Tue, 20 Sep 2005 14:58:03 -0400
Subject: [Image-SIG] Here's a better flood-fill technique
In-Reply-To: <200509172253.j8HMrtrs018277@snark.thyrsus.com>
References: <200509172253.j8HMrtrs018277@snark.thyrsus.com>
Message-ID: <43305BBB.3040205@grc.nasa.gov>

The code is a direct implementation of the pseudo-code in Graphics Gems 
1. Nothing more, nothing less. I suppose that I could have gone to the 
next step and made it more "pythonic", but... it works! Personally I 
would love to see a better and faster version of flood-fill function in PIL.

Bob


Eric S. Raymond wrote:

>On 25 June 2005 William Baxter posted a request for a flood-fill
>algorithm in Python, The following day Bob Klimek posted an effective
>but extremely complex implementation to this list.
>
>At the time I was not interested in this problem.  In the last few
>days I have become so.  I'm translating some old C graphics code of
>mine into Python, and my naive recursive flood-fill blew the
>interpreter stack.
>
>I found Mr. Klimek's answer while Googling for a Python flood-fill.  I
>looked at the code, went "Bletch! This is complicated!  I don't want
>to maintain this!" and decided to invent a simpler way.
>
>With all due respect to Mr. Klimek, he wasn't thinking like a Python
>programmer.  The right thing to do is exploit Python's list-handling.
>Here is the code:
>
>def __flood_fill(image, x, y, value):
>    "Flood fill on a region of non-BORDER_COLOR pixels."
>    if not image.within(x, y) or image.get_pixel(x, y) == BORDER_COLOR:
>        return
>    edge = [(x, y)]
>    image.set_pixel(x, y, value)
>    while edge:
>        newedge = []
>        for (x, y) in edge:
>            for (s, t) in ((x+1, y), (x-1, y), (x, y+1), (x, y-1)):
>                if image.within(s, t) and \
>                	image.get_pixel(s, t) not in (BORDER_COLOR, value):
>                    image.set_pixel(s, t, value)
>                    newedge.append((s, t))
>        edge = newedge
>
>At each step there is a list of edge pixels for the flood-filled 
>region.  You check every pixel adjacent to the edge; for each, if it is
>eligible to be colored, you color it and add it to a new edge list.
>Then you replace the old edge list with the new one.  Stop when the
>list is empty.
>
>(The methods have slightly different names than in PIL because I'm
>using a thin wrapper class around Image.  Translation is trivial.)
>
>This is nonrecursive and the storage requirement is bounded by the
>number of pixels in the region perimeter.  Each pixel will be accessed
>at most three times and set just once.  It's simple and efficient.
>Even, dare I say it, elegant.
>
>The lesson: when writing Python, don't forget that you have dynamic
>data types!
>
>Frederik, say the word and I'll ship you a generalized version for PIL.
>  
>


From mailadmin at soundconcept.net  Wed Sep 21 02:39:02 2005
From: mailadmin at soundconcept.net (mailadmin@soundconcept.net)
Date: 21 Sep 2005 00:39:02 -0000
Subject: [Image-SIG] FROM ADDRESS NOT FOUND
Message-ID: <20050921003902.90524.qmail@mail1.soundconcept.net>

This mailing list does not accept messages from email addresses that are not on the mailing list.



From fredrik at pythonware.com  Wed Sep 21 12:41:36 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 21 Sep 2005 12:41:36 +0200
Subject: [Image-SIG] Here's a better flood-fill technique
References: <200509172253.j8HMrtrs018277@snark.thyrsus.com>
Message-ID: <dgrdd0$eue$1@sea.gmane.org>

Eric S. Raymond wrote:

> This is nonrecursive and the storage requirement is bounded by the
> number of pixels in the region perimeter.  Each pixel will be accessed
> at most three times and set just once.  It's simple and efficient.
> Even, dare I say it, elegant.

worklist-based algorithms are often simple and elegant, and this is of
course no exception.

> Frederik, say the word and I'll ship you a generalized version for PIL.

no need; this looks like a nice addition to 1.1.6, and I can take it from
here...

thanks! /F 




From fredrik at pythonware.com  Wed Sep 21 12:43:22 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 21 Sep 2005 12:43:22 +0200
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)
References: <432E79EC.9060503@designaproduct.biz>
Message-ID: <dgrdga$f7r$1@sea.gmane.org>

Laszlo Zsolt Nagy wrote:

>I create a fully transparent red image this way:
>
> size = (400,400)
> img = Image.new('RGBA',size,(255,0,0,0))
>
> Then I draw an (antialiased) text on it:
>
> drawer = ImageDraw.Draw(img)
> font = ImageFont.truetype('arc.ttf',12)
> drawer.text((0,0),"This text is 12pt",font=font,fill=(0,0,0,255))
>
> This is what I get (image drawn on a gray background):
>
> http://mess.hu/download/bad_antialias.png
>
> Apparently, antialiasing will use a mixture of the background color and
> the text color on the edges.

the blending code seems to treat RGBA as yet another color layer.  I'll
look into this (and your patches) when I find the time.

> I think this is good only if the background is fully opaque. Is there a
> workaround?

a brute-force workaround is to draw into the alpha layer instead...

cheers /F 




From gandalf at designaproduct.biz  Wed Sep 21 12:56:14 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Wed, 21 Sep 2005 12:56:14 +0200
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)
In-Reply-To: <dgrdga$f7r$1@sea.gmane.org>
References: <432E79EC.9060503@designaproduct.biz> <dgrdga$f7r$1@sea.gmane.org>
Message-ID: <43313C4E.1000301@designaproduct.biz>


>the blending code seems to treat RGBA as yet another color layer.  I'll
>look into this (and your patches) when I find the time.
>  
>
Thank you very much.
If you think this would be a good improvement in 1.1.6 then just drop me 
an e-mail and
I'll gladly send the C code to you.


  Les



From fredrik at pythonware.com  Wed Sep 21 13:09:11 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 21 Sep 2005 13:09:11 +0200
Subject: [Image-SIG] Correctly determine image size of a Photoshop EPS
References: <4327422405091911095dd3d39d@mail.gmail.com><dgo9m5$1vs$1@sea.gmane.org>
	<4327422405092002303976cd85@mail.gmail.com>
Message-ID: <dgrf0n$jsh$1@sea.gmane.org>

Stefano Masini wrote:

> So, I guess a quick fix would be to move the self.size = x,y code a
> little upper, but maybe there's a reason this should not be done, I
> don't know.

I don't see any problems with that; after all, the ImageData tag shouldn't be
used for EPS files that don't contain raster data, so the encoding shouldn't
really matter.

> By the way, I experimentally found out what the various values mean,
> by generating different eps files with Photoshop. Here's the list:
>
> 1 - binary
> 2 - ascii
> 3 - jpeg low quality
> 4 - jpeg medium quality
> 5 - jpeg high quality
> 6 - jpeg maximum quality
> 7 - ascii85
>
> These correspond to the options you get in the save dialog in Photoshop.
> Actually, I'm not sure what use you make with this information, since
> it's ghostscript's job to convert the file to ppmraw format, and I
> found no other reference in PIL's code to the above decoder type,
> except for self.tile2, which is not referenced anywhere as well.

the tile2 code is probably a left-over from an old experiment.  since PIL can
decode the various formats itself, it can skip the Ghostscript step and get the
image data directly from the file.  but it looks like that code has never been
enabled (probably due to a lack of samples).

>> if you can mail me a copy of the file (off-list), I can take a look when I find
>> the time.
>
> I will, thanks!

if you have the time to spare, (small) samples of all the above encoding types
would be nice to have.  (to avoid stupid mistakes, rectangular color images are
preferred.  it also helps if the colors are chosen so that a human viewer can
determine if they're right or wrong without having to think too much... ;-)

</F> 




From fredrik at pythonware.com  Wed Sep 21 14:39:51 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 21 Sep 2005 14:39:51 +0200
Subject: [Image-SIG] Bad antialias? (in Python Imaging Library 1.1.5)
References: <432E79EC.9060503@designaproduct.biz> <dgrdga$f7r$1@sea.gmane.org>
Message-ID: <dgrkan$535$1@sea.gmane.org>

> the blending code seems to treat RGBA as yet another color layer.  I'll
> look into this (and your patches) when I find the time.

treat the "A" in "RGBA" as yet another color layer, that is.

</F> 




From peter at engcorp.com  Thu Sep 22 23:22:11 2005
From: peter at engcorp.com (Peter Hansen)
Date: Thu, 22 Sep 2005 17:22:11 -0400
Subject: [Image-SIG] Loading OpenType font (PIL 1.1.5, Python 2.4.1,
 Windows XP)
Message-ID: <43332083.1010905@engcorp.com>

Laszlo Zsolt Nagy gandalf at designaproduct.biz wrote:
 >Fredrik Lundh wrote:
 >>make sure _imagingft.pyd is the one that came with PIL 1.1.5, and
 >>not some earlier version.  to see what pyd it's using, do this:
 >>
 >>    >>> import _imagingft
 >>    >>> _imagingft.__file__
 >>
 >C:\Documents and Settings\Gandalf>python
 > >>> import _imagingft
 > >>> _imagingft.__file__
 >'C:\\Python24\\DLLs\\_imagingft.pyd'
 >
 >You were right, thank you. The good one is under site-packages but I
 >had one under DLLs too.
 >
 >I don't know how could this happen. :-)

I just stumbled across the same thing, found this response, and realized 
I had the same problem.

So, thanks for the help!

More importantly, I can solve the mystery of "how could this happen".  I 
had installed the ReportLab package a couple of days ago, including the 
Windows binaries file "win32-dlls-py24.zip" which they conveniently 
provide.  That file contains the out of date _imagingft.pyd (and other 
PIL files) and the instructions for installing it suggest putting it in 
the DLLs folder instead of under site-packages/PIL.  So that's how this 
could happen. :-)

-Peter

From fredrik at pythonware.com  Sun Sep 25 14:22:06 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 25 Sep 2005 14:22:06 +0200
Subject: [Image-SIG] AGG-based drawing for PIL
References: <d966j5$rj4$1@sea.gmane.org>
Message-ID: <dh64pa$o15$1@sea.gmane.org>

> the "aggdraw" module is a prerelease of a new drawing library for PIL,
> based on Maxim Shemanarev's antigrain (AGG) graphics library.  This
> module implements a WCK-style drawing interface (see below), and
> provides anti-aliasing and alpha compositing.

a new version is now available from

    http://effbot.org/downloads/#aggdraw

documentation:

    http://effbot.org/zone/draw-agg.htm (overview)
    http://effbot.org/zone/pythondoc-aggdraw.htm (api reference)

for a list of changes in this release, see:

    http://effbot.org/downloads/index.cgi/aggdraw-1.1b3-20050925.zip/CHANGES

enjoy /F 




From spoettl at hotmail.com  Wed Sep 14 16:07:04 2005
From: spoettl at hotmail.com (Stefan Spoettl)
Date: Wed, 14 Sep 2005 16:07:04 +0200
Subject: [Image-SIG] Is this a bug in PIL 1.1.5?
Message-ID: <BAY104-DAV532BEDC879F9B6586EFE3AA9F0@phx.gbl>

Environment:

Windows XP
Python 2.4.1 with IDLE
PIL 1.1.5


Problem:

My class 'Bildbeschrifter' is reading an image from background. The image could be a .gif or a .png or a .jpg and nothing else. After opening the Bildbeschrifter produces a text image with transparent background and the same size as the opened image. Finally the Bildbeschrifter pastes the
text image to the opened image and saves the result on background.
My class is working fine with .jpg. But it does not with .gif and .png. The pasted text is not readable any longer. Here a .gif output of my class:

What I am doing wrong?

Python Code (fragment):

(sorry for German identifiers)

class Bildbeschrifter:

    def __init__(self, bild, zeilenliste, font,                          \
                 rand = 0, zeilenabstand = 4,                            \
                 satz = 'mittig', schriftfarbe = (0x00, 0x00, 0x00, 0xFF)):
        if bild.urbild.bild and bild.drehwinkel == 0 and zeilenliste:
            grund = Image.open(bild.pfad)
            zeilenhoehe = font.zeilenausdehnung(zeilenliste[0])[1]
            hoehe = 2 * rand + len(zeilenliste) * (zeilenhoehe + zeilenabstand) - zeilenabstand
            schreibgrund = ImageDraw.Draw(grund)
            zeilenbreiten = []
            breite = 0
            for z in zeilenliste:
                zb= 2 * rand + font.zeilenausdehnung(z)[0]
                zeilenbreiten.append(zb)
                if breite < zb:
                    breite = zb
            if breite <= grund.size[0] and hoehe <= grund.size[1]:
                folie = Image.new('RGBA', grund.size, (0xFF, 0xFF, 0xFF, 0x00))
                schreibgrund = ImageDraw.Draw(folie)
                ausdehnung = grund.size
                h = (ausdehnung[1] - hoehe) / 2 + rand
                for i in range(0, len(zeilenliste), 1):
                    z = zeilenliste[i]
                    if satz == 'links':
                        links = rand
                    elif satz == 'rechts':
                        links = rand + ausdehnung[0] - zeilenbreiten[i]
                    else:
                        links = rand + (ausdehnung[0] - zeilenbreiten[i]) / 2
                    schreibgrund.text((links, h), z, schriftfarbe, font.font)
                    h = h + zeilenhoehe + zeilenabstand
                del schreibgrund
                grund.paste(folie, mask = folie)
                if bild.urbild.bildart == '.gif':
                    grund.save(bild.pfad, 'GIF', **grund.info)
                elif bild.urbild.bildart == '.png':
                    grund.save(bild.pfad, 'PNG', **grund.info)
                else:
                    grund.save(bild.pfad, 'JPEG')
                
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/image-sig/attachments/20050914/15fce2fe/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 4413 bytes
Desc: not available
Url : http://mail.python.org/pipermail/image-sig/attachments/20050914/15fce2fe/attachment.gif

From mikael at isy.liu.se  Mon Sep 19 08:22:52 2005
From: mikael at isy.liu.se (Mikael Olofsson)
Date: Mon, 19 Sep 2005 08:22:52 +0200
Subject: [Image-SIG] Loading OpenType font (PIL 1.1.5, Python 2.4.1,
 Windows XP)
In-Reply-To: <432D196D.4080205@designaproduct.biz>
References: <432ACEB2.3040304@designaproduct.biz> <dgelq1$nn$1@sea.gmane.org>
	<432D196D.4080205@designaproduct.biz>
Message-ID: <432E593C.4040506@isy.liu.se>

Laszlo Zsolt Nagy wrote:

>C:\Documents and Settings\Gandalf>python
>Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on 
>win32
>Type "help", "copyright", "credits" or "license" for more information.
> >>> import _imagingft
> >>> _imagingft.__file__
>'C:\\Python24\\DLLs\\_imagingft.pyd'
> >>>
>
>You were right, thank you. The good one is under site-packages but I had 
>one under DLLs too.
>I don't know how could this happen. :-)
>

Do you have reportlab installed? This happened to me when I installed 
reportlab. Also, look out for _imaging.pyd in the same way.

/MiO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/image-sig/attachments/20050919/69eafce9/attachment.html

From gandalf at designaproduct.biz  Mon Sep 19 10:10:01 2005
From: gandalf at designaproduct.biz (Laszlo Zsolt Nagy)
Date: Mon, 19 Sep 2005 10:10:01 +0200
Subject: [Image-SIG] Bad antialias in PIL 1.1.5
Message-ID: <432E7259.6080408@designaproduct.biz>

I create a fully transparent red image this way:

size = (400,400)
img = Image.new('RGBA',size,(255,0,0,0))

Then I draw an (antialiased) text on it:

drawer = ImageDraw.Draw(img)
font = ImageFont.truetype('arc.ttf',12)
drawer.text((0,0),"This text is 12pt",font=font,fill=(0,0,0,255))

This is what I get (image drawn on a gray background):

http://mess.hu/download/bad_antialias.png

Apparently, antialiasing will use a mixture of the background color and 
the text color on the edges.
I think this is good only if the background is fully opaque. The good 
solution is (of course) is to
use the antialiased B&W text as an alpha channel, apply it to a fully 
opaque rectangle (using text color),
and finally make a composite of the target image and the antialiased 
text. Is there a faster workaround
for this problem than  crop, new, composite, paste?

Is this a PIL bug or a feature?

Thanks,

   Les


From ilango_m85 at yahoo.com  Wed Sep 21 17:16:11 2005
From: ilango_m85 at yahoo.com (ILANGO VAN)
Date: Wed, 21 Sep 2005 08:16:11 -0700 (PDT)
Subject: [Image-SIG] request
Message-ID: <20050921151611.81923.qmail@web30403.mail.mud.yahoo.com>

dear sir
    i am ilangovan.m studing in psg tech,india.i need
your guidence forus about extracting a number from a
image.We need this information to finish our
project(TRAFFIC RULES SIMULATION).If u can help us by
givig the above requested information it will be more
helpfull to us.
                  thanking you
                                         yours
faithfully
                                           ilangovan.m
 


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

From mtebeka at qualcomm.com  Mon Sep 26 15:20:09 2005
From: mtebeka at qualcomm.com (Miki Tebeka)
Date: Mon, 26 Sep 2005 16:20:09 +0300
Subject: [Image-SIG] Patch for compiling PIL under cygwin
Message-ID: <20050926132009.GN18368@qualcomm.com>

Hello,

To whom it may concern.

Currently PIL (1.1.5) does not build OOTB under cygwin.
The reason is that the setup.py script does not add the directory where the
pythonX.Y.dll.a is located.

Just add the below lines somewhere in pil_build_ext/build_extension:

        # add standard directories

+        # In cygwin pythonX.Y.dll.a is in /usr/lib/pythonX.Y/config directory
+        if sys.platform == "cygwin": 
+            cfgdir = os.path.join("/usr/lib", "python%s" % sys.version[:3],
+                                  "config")
+            add_directory(library_dirs, cfgdir)

        add_directory(library_dirs, "/usr/local/lib")

Bye.
--
------------------------------------------------------------------------
Miki Tebeka <mtebeka at qualcomm.com>
http://tebeka.bizhat.com
The only difference between children and adults is the price of the toys
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.python.org/pipermail/image-sig/attachments/20050926/aa2031e0/attachment-0001.pgp

From fabian at mareyen.de  Tue Sep 27 14:54:14 2005
From: fabian at mareyen.de (Fabian Mareyen)
Date: Tue, 27 Sep 2005 14:54:14 +0200
Subject: [Image-SIG] How to save ICO-Images
Message-ID: <PM-EX.20050927145414.3C9BD.1.1D@smtp.1und1.com>

I would need a possibility to save an BMP-Image as an ICO-Image.

It's nearly the same as the BMP-Format but I can't fix it because I
don't know enough about ICO-Format (there is no description about it
in the IcoImagePlugin).

Could you fix the ICO-save-method?

Thank you (even if you coudn't),

Fabian Mareyen


From fredrik at pythonware.com  Wed Sep 28 12:39:21 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 28 Sep 2005 12:39:21 +0200
Subject: [Image-SIG] Patch for compiling PIL under cygwin
References: <20050926132009.GN18368@qualcomm.com>
Message-ID: <dhdrsp$inq$1@sea.gmane.org>

Miki Tebeka wrote:

> Currently PIL (1.1.5) does not build OOTB under cygwin.
>
> The reason is that the setup.py script does not add the directory where the
> pythonX.Y.dll.a is located.

and I just told someone that he might be the only one still using Python
on Cygwin ;-)

(your patch was just checked in, and will be in the next 1.1.6 alpha)

thanks /F 




From steve at holdenweb.com  Wed Sep 28 12:54:28 2005
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 28 Sep 2005 11:54:28 +0100
Subject: [Image-SIG] Patch for compiling PIL under cygwin
In-Reply-To: <dhdrsp$inq$1@sea.gmane.org>
References: <20050926132009.GN18368@qualcomm.com> <dhdrsp$inq$1@sea.gmane.org>
Message-ID: <433A7664.7050000@holdenweb.com>

Fredrik Lundh wrote:
> Miki Tebeka wrote:
> 
> 
>>Currently PIL (1.1.5) does not build OOTB under cygwin.
>>
>>The reason is that the setup.py script does not add the directory where the
>>pythonX.Y.dll.a is located.
> 
> 
> and I just told someone that he might be the only one still using Python
> on Cygwin ;-)
> 
> (your patch was just checked in, and will be in the next 1.1.6 alpha)
> 
That's cool, we're both on the list!

Miki, can I ask you if you've tried using TrueType and OpenType fonts in 
your implementation? I'm having problems over here, and some comparison 
of our environments might be helpful.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                          www.pycon.org

From x12345jp at yahoo.com.hk  Fri Sep 30 11:07:42 2005
From: x12345jp at yahoo.com.hk (john taylor)
Date: Fri, 30 Sep 2005 17:07:42 +0800 (CST)
Subject: [Image-SIG] How to get the PIL object from an image buffer created
	in C++?
Message-ID: <20050930090742.52880.qmail@web50407.mail.yahoo.com>

Hi all,

I've produced a DLL from my C++ program, which gets an
image from external hardware and saves to a buffer.
How can I get the image data from the DLL in Python?

The C functions are somehow implemented as follows:

static char *ImageBuffer = NULL;

int WriteImageBuffer(void)
{
    // acquire an image and write to the buffer
    AcquireImg(ImageBuffer, params);
}

PyObject* GetImage(void)
{
    return Py_BuildValue("s#", &ImageBuffer, 640*480);
}

In Python I got (I am using ctypes for calling DLL's),

(... some code here to load the library)

>>> @cdecl(c_char_p, dll, [])
... def GetImage():
... 	return GetImage._api_()
... 
>>> data = GetImage()
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "<interactive input>", line 3, in GetImage
WindowsError: exception: access violation reading
0x0181D000

If i could get the PIL string here, I'd like to use
image = Image.fromstring("L", (640, 480), data)
to have a PIL Image object.

Any body can help?  Thanks a lot in advance!!

John

From fredrik at pythonware.com  Fri Sep 30 11:47:21 2005
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 30 Sep 2005 11:47:21 +0200
Subject: [Image-SIG] How to get the PIL object from an image buffer
	createdin C++?
References: <20050930090742.52880.qmail@web50407.mail.yahoo.com>
Message-ID: <dhj1j9$m4p$1@sea.gmane.org>

"john taylor" wrote:

> I've produced a DLL from my C++ program, which gets an
> image from external hardware and saves to a buffer.
> How can I get the image data from the DLL in Python?
>
> The C functions are somehow implemented as follows:
>
> static char *ImageBuffer = NULL;
>
> int WriteImageBuffer(void)
> {
>    // acquire an image and write to the buffer
>    AcquireImg(ImageBuffer, params);
> }
>
> PyObject* GetImage(void)
> {
>    return Py_BuildValue("s#", &ImageBuffer, 640*480);
> }

you're passing in the address of the pointer, not the address of the
buffer.  try changing this to:

    return Py_BuildValue("s#", ImageBuffer, 640*480);

or, better:

    return PyString_FromStringAndSize(ImageBuffer, 640*480);

(your malloc/pystring/fromstring approach does a of extra copying, but
I suppose you can start worrying about that only if you find that it's not
fast enough...)

</F> 




From alainlioret at wanadoo.fr  Mon Sep 26 17:39:35 2005
From: alainlioret at wanadoo.fr (alainlioret)
Date: Mon, 26 Sep 2005 17:39:35 +0200
Subject: [Image-SIG] Usage of getpixel
Message-ID: <000a01c5c2b0$7fa37aa0$057d7053@dell>

Hi,

I try to use getpixel(xy) ...
But I can't ..

for example, I try :

pix = im.getpixel(0,0)

But I have an error. What's wrong ?

Can you give me an example ?

Thanks for all

Alain Lioret

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/image-sig/attachments/20050926/92c6ecfd/attachment.htm