From hans.svedaker@bytbil.com Thu Jul 4 08:43:28 2002 From: hans.svedaker@bytbil.com (=?ISO-8859-1?Q?Hans_Sved=E5ker?=) Date: Thu, 04 Jul 2002 09:43:28 +0200 Subject: [Image-SIG] Convert to CMYK Message-ID: <3D23FCA0.70702@bytbil.com> Hi I'm trying to convert JPG image to CMYK format. And it works fine, except for one thing. When there is black (or gray) in the image it is converted to (255,255,255,0) instead of (0,0,0,255). There are never any black in the image, insted i blends max cyan, magenta and yellow to get black. How shuld i do to get that? /Hans Svedåker From rtrocca@libero.it Wed Jul 3 09:09:34 2002 From: rtrocca@libero.it (Riccardo Trocca) Date: Wed, 03 Jul 2002 10:09:34 +0200 Subject: [Image-SIG] Averaging each pixel over sequential images References: <20020624143201.1136.TORU@oldriver.org> Message-ID: <3D22B13E.9020300@libero.it> Just read you message (a bit late). Even if I don't have the code handy now, I'd suggest to convert each image to a numeric array (with the fromstring/tostring methods), do all the calc on the arrays and then convert again to an image. Ric toru wrote: >I am trying to obtain the average brightness of each pixel over a set of >grayscale images, using PIL. > >The following code works correctly but looks a little tedious. I would >like to know if any common idiom exists for this solution. > >---- BEGINS ---- >import Image >import struct >import string > ># Obtain image size, assuming all are in the same size >img = Image.open(files[0]) >width, height = img.size > ># Sum brightness of every pixel >sum = [0 for i in xrange(width*height)] >for file in files: > img = Image.open(file) > img.convert("L") > str = img.tostring() > for i in xrange(width*height): > p = struct.unpack("B", str[i])[0] > sum[i] += p > ># Devide sum of each pixel by the number of images >avg = [] >for x in sum: > avg.append(struct.pack("B", x/len(files))) >avg_str = string.join(avg, "") >avg_img = Image.fromstring("L", (width, height), avg_str) >---- ENDS ---- > >Toru Furukawa >toru@oldriver.org > > > >_______________________________________________ >Image-SIG maillist - Image-SIG@python.org >http://mail.python.org/mailman/listinfo/image-sig > > > From pierpaolo.glave@ciaolab.com Fri Jul 5 13:55:45 2002 From: pierpaolo.glave@ciaolab.com (Pier Paolo Glave) Date: Fri, 05 Jul 2002 14:55:45 +0200 Subject: [Image-SIG] GIF frame extraction problem Message-ID: <3D259751.9010909@ciaolab.com> Hello, I'm using PIL version 1.1.3 to manage animated GIFs, and I'm facing a problem with the GIF image that you can find at this web address: http://digilander.libero.it/pglave/sole24oreabbonamento.gif The image is a sequence composed of 12 frames. The problem is that PIL sees as "black" the last four frames of the sequence. Other players, such as Netscape or Internet Explorer, correctly show all frames, including the last four. Can you tell what could be the problem with this GIF? Thank you for any help. -- Pier Paolo Glave From kevin@cazabon.com Sat Jul 6 03:58:46 2002 From: kevin@cazabon.com (Kevin@Cazabon.com) Date: Fri, 5 Jul 2002 20:58:46 -0600 Subject: [Image-SIG] Convert to CMYK References: <3D23FCA0.70702@bytbil.com> Message-ID: <001301c22499$0c01dc80$320aa8c0@duallie> The built-in RGB/CMYK conversion in PIL is not an optomized one... there's no GCR/UCR, it's basically a RGB/CMY flop. Formulas for UCR/GCR are fairly easily available, maybe we should look at implementing a tunable conversion method in the core of PIL? I've mentioned this before, I just haven't had the time to do anything myself yet... Kevin. ----- Original Message ----- From: "Hans Svedåker" To: "image-sig" Sent: Thursday, July 04, 2002 1:43 AM Subject: [Image-SIG] Convert to CMYK > Hi > > I'm trying to convert JPG image to CMYK format. And it works fine, > except for one thing. When there is black (or gray) in the image it is > converted to (255,255,255,0) instead of (0,0,0,255). There are never any > black in the image, insted i blends max cyan, magenta and yellow to > get black. How shuld i do to get that? > > /Hans Svedåker > > > > _______________________________________________ > Image-SIG maillist - Image-SIG@python.org > http://mail.python.org/mailman/listinfo/image-sig > From gspeer@cortech.org Sat Jul 6 22:17:46 2002 From: gspeer@cortech.org (Gary Speer) Date: Sat, 6 Jul 2002 14:17:46 -0700 Subject: [Image-SIG] Convert to CMYK References: <3D23FCA0.70702@bytbil.com> <001301c22499$0c01dc80$320aa8c0@duallie> Message-ID: <005101c22532$935970a0$1302a8c0@linkline.com> Hans & Kevin - As a user that does a lot of design for print, it does not make sense to me to build a complex converter to CMYK. Just about every printer driver has an optimized CMYK GCR/UCR converter that closely matches the printer's characteristics when you send it an RGB print job. A PIL based generic converter to a light (under 20%) GCR will always look worse than the printer driver's formula optimized to the specific printer's characteristics. If the converter matching the printer is not adequate, then no amount of PIL tweaking will come close to adjusting on the client side using something like Photoshop. There is no real on-screen way to produce a browser app that will display the results of the separation curve since it will always go back to the same RGB values on the browser screen. Unless I'm missing something, I just don't see the value in converting server-side. Kevin - I would hate to see you waste time on an optimized converter without a purpose. All I can think of as a benefit is a method of increasing contrast with on-line tools without throwing in a color shift. If so, switch to LAB and expand the luminosity histogram - a much easier and reliable method than doing so in RGB or CMYK. Now, color enhancing using colorspace shifting filter curves - that could be cool! Hans - If you can expand on the purpose, perhaps we can suggest a better technique. Otherwise, the RGB version of the JPEG will always look better on your CMYK printer because of the printer-specific optimized driver is doing the grey color replacement optimized to avoid over-inking.and produce even color replacement based largely on the paper selection and its total ink limits. Gary . ----- Original Message ----- From: "Kevin@Cazabon.com" To: "Hans Svedåker" ; "image-sig" Sent: Friday, July 05, 2002 7:58 PM Subject: Re: [Image-SIG] Convert to CMYK > The built-in RGB/CMYK conversion in PIL is not an optomized one... there's > no GCR/UCR, it's basically a RGB/CMY flop. > > Formulas for UCR/GCR are fairly easily available, maybe we should look at > implementing a tunable conversion method in the core of PIL? I've mentioned > this before, I just haven't had the time to do anything myself yet... > > Kevin. > > > ----- Original Message ----- > From: "Hans Svedåker" > To: "image-sig" > Sent: Thursday, July 04, 2002 1:43 AM > Subject: [Image-SIG] Convert to CMYK > > > > Hi > > > > I'm trying to convert JPG image to CMYK format. And it works fine, > > except for one thing. When there is black (or gray) in the image it is > > converted to (255,255,255,0) instead of (0,0,0,255). There are never any > > black in the image, insted i blends max cyan, magenta and yellow to > > get black. How shuld i do to get that? > > > > /Hans Svedåker > > > > > > > > _______________________________________________ > > Image-SIG maillist - Image-SIG@python.org > > http://mail.python.org/mailman/listinfo/image-sig > > > > > > > > From ThePloppies@bigpond.com Sun Jul 7 11:30:04 2002 From: ThePloppies@bigpond.com (Tom Harris) Date: Sun, 7 Jul 2002 20:30:04 +1000 Subject: [Image-SIG] JPEG2000 support Message-ID: <008901c225a1$42560050$0301a8c0@home.net> Greetings Are there any plans to add support for the JPEG2000 format to the PIL? The Jasper C library appears to have a suitable license, and it would allow the PIL to use lossy or lossless compression with images with any number of bits, from 1 to 32, which is a fine thing. Pity about the commercial support for JPEG2000, though I have high hopes for it. Regards TomH funes@bigpond.com From Serpil.Dogan@telenity.com Mon Jul 8 15:46:32 2002 From: Serpil.Dogan@telenity.com (Serpil Dogan) Date: Mon, 8 Jul 2002 17:46:32 +0300 Subject: [Image-SIG] Python Imaging Library Message-ID: <566C72F44B0EFE46A5A133D248F8ED163FA37A@trexchange.telenity.com> RGVhciBzaXJzLA0KV2UgYXJlIGxvb2tpbmcgZm9yIGFuIGltYWdpbmcgbGlicmFyeSBmb3Igb3Vy IGNvbnZlcnNpb24gcHVycG9zZXMuIFBJTCBzZWVtcyB0byBiZSBhcHByb3ByaWF0ZSBzb2x1dGlv biB0byB1cy4gSG93ZXZlciBsZXQgdXMgY2xlYXIgc29tZSBhZGRpdGlvbmFsIHBvaW50cyBvbiBQ SUwgOg0KMS4gV2hpY2ggcGxhdGZvcm1zIFBJTCBzdXBwb3J0ID8gKFdpbmRvd3MsIFNvbGFyaXMs Li4uKQ0KMi4gV2hhdCBhcmUgbWVkaWEgZm9ybWF0cyBzdXBwb3J0ZWQgYnkgUElMPyBCZWNhdXNl IHdlIHJlcXVpcmUgY29udmVyc2lvbiBiZXR3ZWVuIGltYWdlIGZvcm1hdHMoanBlZywgZ2lmLC4u LiksIGF1ZGlvIGZvcm1hdHMobXAzLCBhbXIsLi4uKSBhbmQgbWVkaWEgZm9ybWF0cyhtcGVnLC4u LilDb3VsZCB5b3UgY2xhcmlmeSB0aGUgUElMIHN1cHBvcnRlZCBmb3JtYXRzPw0KMy4gV2hpY2gg bGFuZ3VhZ2VzIHN1cHBvcnQgdXNhZ2Ugb2YgUElMPyBUbyBkZXZlbG9wIG91ciBvd24gY29udmVy c2lvbiBhcHBsaWNhdGlvbiwgd2hhdCBpcyB0aGUgYmVzdCBsYW5ndWFnZSB0byB1c2UgUElMPw0K VGhhbmsgeW91IGZvciB5b3VyIHVyZ2VudCByZXBseSwNClJlZ2FyZHMsDQpTZXJwaWwgRG9nYW4N ClNvZnR3YXJlIEVuZ2luZWVyDQo= From mrroach@uhg.net Mon Jul 8 16:21:48 2002 From: mrroach@uhg.net (Roach, Mark R.) Date: 08 Jul 2002 10:21:48 -0500 Subject: [Image-SIG] Python Imaging Library In-Reply-To: <566C72F44B0EFE46A5A133D248F8ED163FA37A@trexchange.telenity.com> References: <566C72F44B0EFE46A5A133D248F8ED163FA37A@trexchange.telenity.com> Message-ID: <1026141708.19478.20.camel@tncorpmrr001.uhg> On Mon, 2002-07-08 at 09:46, Serpil Dogan wrote: > Dear sirs, > We are looking for an imaging library for our conversion purposes. PIL seems to be appropriate solution to us. However let us clear some additional points on PIL : > 1. Which platforms PIL support ? (Windows, Solaris,...) The website (http://www.pythonware.com/products/pil/index.htm) indicates support for windows and Unixes not sure about macos > 2. What are media formats supported by PIL? Because we require conversion between image formats(jpeg, gif,...), audio formats(mp3, amr,...) and media formats(mpeg,...)Could you clarify the PIL supported formats? This _Imaging_ library supports image formats only, not audio or video look here for supported formats (again, on the product's website) http://www.pythonware.com/library/pil/handbook/image-file-formats.htm > 3. Which languages support usage of PIL? To develop our own conversion application, what is the best language to use PIL? PIL is the _Python_ Imaging Library, soooo... -Mark Roach From gspeer@cortech.org Mon Jul 8 20:45:37 2002 From: gspeer@cortech.org (Gary Speer) Date: Mon, 8 Jul 2002 12:45:37 -0700 Subject: [Image-SIG] Python Imaging Library References: <566C72F44B0EFE46A5A133D248F8ED163FA37A@trexchange.telenity.com> Message-ID: <00a101c226b8$08d96ca0$1302a8c0@linkline.com> This SIG is for the independent developer/end user community and is not moderated (though it is sometimes watched) by Secret Labs, the developer of PIL. If you are looking for 'a vendor' you need to correspond with Secret Labs directly via the www.pythonware.org website. The Python Imaging Library is written in Python and will therefore install on all platforms that host Python. See the www.python.org site. It compliments all applications developed in Python such as Zope ( www.zope.com www.zope.org ). It is an imaging library which means it is a library of tools for converting, manipulating and displaying images in the context of a Python / Zope / other RDB or server-based repository. Imaging tools work with images, not audio or video. Other Zope & Python products built on PIL manage the display and navigation of image collections. FWIW, Gary ----- Original Message ----- From: "Serpil Dogan" To: Sent: Monday, July 08, 2002 7:46 AM Subject: [Image-SIG] Python Imaging Library > Dear sirs, > We are looking for an imaging library for our conversion purposes. PIL seems to be appropriate solution to us. However let us clear some additional points on PIL : > 1. Which platforms PIL support ? (Windows, Solaris,...) > 2. What are media formats supported by PIL? Because we require conversion between image formats(jpeg, gif,...), audio formats(mp3, amr,...) and media formats(mpeg,...)Could you clarify the PIL supported formats? > 3. Which languages support usage of PIL? To develop our own conversion application, what is the best language to use PIL? > Thank you for your urgent reply, > Regards, > Serpil Dogan > Software Engineer > From klimek@grc.nasa.gov Mon Jul 8 22:32:08 2002 From: klimek@grc.nasa.gov (Robert Klimek) Date: Mon, 8 Jul 2002 17:32:08 -0400 Subject: [Image-SIG] morphological functions In-Reply-To: <200206242125.RAA07185@behemoth.lerc.nasa.gov> References: <200206242125.RAA07185@behemoth.lerc.nasa.gov> Message-ID: <200207082129.RAA11561@behemoth.lerc.nasa.gov> On Monday 24 June 2002 05:27 pm, you wrote: > I need to add some morphological function capability to my PIL based > program, such as erosion, dilation, hole fill, border, and skeletonizin= g. > I'd rather not re-invent the wheel if I don't have to. So, does anybody > have and this written and are willing to share the code? > For those interested, I've written a couple of PIL-based functions that=20 perform a 4-point erosion and dilation and I thought I'd share the code. = Note=20 that these functions work only on thresholded images (not on general=20 grayscale). These functions are fairly fast., compared to my earlier atte= mpts=20 where I looped through all the pixels in the image getting min of a 3x3=20 neighborhood. Bob def erode(image): paddedImage =3D createPaddedImage(image, 1) thresholdImg =3D paddedImage.point(lambda i, v=3D128: i > v and 255) filteredImg =3D thresholdImg.filter(ImageFilter.FIND_EDGES) thresholdImg =3D filteredImg.point(lambda i, v=3D128: i > v and 255) arithImg =3D ImageChops.subtract(paddedImage, thresholdImg) box =3D (1, 1, arithImg.size[0]-1, arithImg.size[1]-1) outImage =3D arithImg.crop(box) return outImage def dilate(image): paddedImage =3D createPaddedImage(image, 1) thresholdImg =3D paddedImage.point(lambda i, v=3D128: i > v and 255) thresholdImg =3D ImageChops.invert(thresholdImg) filteredImg =3D thresholdImg.filter(ImageFilter.FIND_EDGES) thresholdImg =3D filteredImg.point(lambda i, v=3D128: i > v and 255) arithImg =3D ImageChops.add(paddedImage, thresholdImg) box =3D (1, 1, arithImg.size[0]-1, arithImg.size[1]-1) outImage =3D arithImg.crop(box) return outImage def createPaddedImage(img, pad): '''Create an padded image - since it is created with resize() the bor= der =20 pixels will be same (almost) as the original edge pixels.''' sizeX, sizeY =3D img.size paddedImage =3D img.resize((sizeX+2*pad, sizeY+2*pad)) # paste original image into the new big image with an offset paddedImage.paste(img, (pad, pad)) return paddedImage From gspeer@cortech.org Tue Jul 9 18:55:23 2002 From: gspeer@cortech.org (Gary Speer) Date: Tue, 9 Jul 2002 10:55:23 -0700 Subject: [Image-SIG] Convert to CMYK References: <3D23FCA0.70702@bytbil.com> <001301c22499$0c01dc80$320aa8c0@duallie> <005101c22532$935970a0$1302a8c0@linkline.com> <3D2942CE.1060502@bytbil.com> <007401c226a7$a889eb00$1302a8c0@linkline.com> <3D2A92F1.8080501@bytbil.com> Message-ID: <003701c22771$cd08f820$1302a8c0@linkline.com> Hi Hans - See below ----- Original Message ----- From: "Hans Svedåker" To: "Gary Speer" Sent: Tuesday, July 09, 2002 12:38 AM Subject: Re: [Image-SIG] Convert to CMYK > Hi Gary > > I use the PIL library to prepare the images for priting (inserted in a > template for printing). Not to view them on screen (server based). And I > have a "optimized" ICC profile that I uses. But why should PIL have the > option to convert to CMYK if it isn't worth using. Are there other > applications then printing that uses CMYK colorspace? I would guess the reasons they built the CMYK converter was to have technical Completeness - to have a full set of any-to-any converters just in case it was needed. Coding RGB to CMY is a straight forward application of technical formulas and doesn't require knowing ICC standards or any discretion. There is a single 'right' answer to the conversion. PIL does this conversion correctly, it just may not be of value to you. In essence it is the same as converting in photoshop with GCR=0. Coding RGB to CMYK is a bit of an art as the amount of GCR to use is variable depending on the specific application and print process. Coding in one (which one, 18%, 20%) or several GCR curves, or even a single curve with a total ink limit of 280 (or 240 or 300?) is a lot more work and the result/effect is simply not viewable in a browser. Replacing as much CM&Y as you can with the equivalent black(gray) is far worse than replacing none. The 'right answer' is different for every image, printer, paper, and artist's eye. Too many aesthetic variables for a mere technical converter with no means of displaying the result.. Perhaps the licensed-for-fee version of PIL has GCR curves where the free version does not. Still, this is the domain of print applications, not web applications, so there is little value to complicate PIL with what I expect would be a limited use feature. Just use littlecms. Other uses of CMYK - Image manipulation to enhance contrast (cyan channel), correct skin tones by the numbers, or emphasize a spot color (all Photoshop stuff) for print. Undo-able on-screen special effects achievable in the CMYK colorspace in which the image occupies the CMY layers and the K layer is totally available to render over-image text or watermarks that can be stripped out later by discarding the black channel without affecting the underlying image. Example - free v. pay websites for actor/actress photos or a photographer's site. On import of an RGB photo, use PIL to convert to CMY (with transparent K), use PIL to render the watermark-style site logo across the image in only the K channel. Place the image in the database. On 'free tours' convert to RGB to permanently embed the watermark and display the altered image. For thumbnails and logged in / paid viewers, pass the image through a PIL filter to strip the K channel before converting back to RGB and display a clean image. One image, one file, a completely removeable mark, simplified administration. Again, if the goal is to print-optimize what you see on the screen, stay in RGB and let the print process apply the optimized ICC profile and preferred GCR of your printer or use littlecms if you are doing straight to plate separations. None of the advantages of working in the CMYK colorspace as opposed to the RGB colorspace are available until you create an on-line equivalent of Photoshop that would let you select and manage the GCR curve, selectively edit/enhance by channel, and use the printer-specific ICC profile and/or give the user iterative access to the printer's output that they are optizing for. PIL was designed for on-line images in web pages. Its a lot to ask for to have PIL accomodate the many more variables associated with print optimization (plug-ins like littlecms, uploading and selecting ICC profiles, knowing if it is rendering to screen (unconverted profile) as opposed to print (converted profile) since the target is always a browser, tweaking the GCR and UCR curves, the results of which can only be viewed on a printer and vary printer-to-printer. In essence, concerning PIL is designed for multiple users, what is displayed through a browser should be ICC neutral so anyone can view it, use it, print it using the profile of their printer. The ICC neutral version of an image that starts out as RGB is to stay RGB. The moment you decide how the K channel is to be rendered by converting to the same CMYK version for everyone and without any special reason to (like to generically modify the K channel content to have a watermark) you make it so that someone going to print the image using their printer's wider profile (say, using a lighter GCR than you specified) must convert the image back to RGB in order to convert to CMYK again with a different GCR value. In short, the process you describe should not be distributed on the web for everyone to manage differently when they cannot see the effect on the actual printer, but should be a single-user process at print time. > > Maybe add support för littlecms to PIL? That would help me a lot. No > need to convert images before, just load any format into PIL and apply > the ICC profile and save it in CMYK format, ready for print. Again, the reason you would convert sooner than print-time is because you plan to manipulate the image in a manner specific to the CMYK color space, which is hard to do in a browser without an extensive application toolset, (can you say Java) in which case the CMYK conversion is one of the more trivial aspects of building one. This is certainly way beyond the capabilities of HTML and Javascript. I just don't think PIL is the right tool to use to get from submitted RGB images in templates that are uploaded on a server and display well in a browser, to ICC-optimized plate separations for a newsprinter. One opinion, for what its worth! Gary > > Gary Speer wrote: > > Hi - > > The ICC profile of each specific printer is different and it is the ICC > > profile of the printer that optimizes GCR as you shift from an ICC standard > > colorspace to printer-specific values. I would understand going through the > > effort to doing a PIL conversion if an intranet-style system was being used > > to layout newspaper pages that print straight to the newsprinter. For a > > webuser that has no visibility to a test print, it does not make sense to > > shift away from a non-printer-specific colorspace. Ideally all images would > > come in optimized for how the submitter sees them, in RGB, and enhanced for > > printing in general by how they look on the submitter's printer, converted > > via that user's ICC profile for his printer. If the submitter is going to > > use a tool that will enhance by channel (eg photoshop), let that tool do the > > RGB to CMYK conversion with GCR set by that image professional to get the > > result they want. When they are done, they submit the CMYK result that will > > adapt to the newsprint printer via that printer's ICC profile at print time. > > To apply a printer profile before print time will distort the onscreen > > appearance and cause people to try to adjust out the apparent distortion you > > would see on screen after an image has been converted to the printer's color > > curves. > > > > I'm suggesting that users see images in the colorspace they work in - RGB. > > If they are going to enhance an image to optimize it for print over how RGB > > would translate to CMYK via the newsprinter's ICC profile, then they either > > need direct access to the printer's output to see their tweaks (hence you > > are no longer in a browser app) or they need to work in a pre-conversion > > colorspace so the image will adapt to each printer via that printer's ICC > > profile. > > > > In short, to apply a printer-specific ICC conversion via PIL will distort > > the image as viewed on screen after such conversion, and impair the ability > > of submitters to optimize the CMYK separation to achieve a desired effect. > > If they are not optimizing, again there is no reason to convert to the > > printer's colorspace until after the RGB-optimized image is inserted into a > > printable page and submitted for printing. At that point a server-based > > converter like littlecms can do separations according to the ICC profile of > > the newsprinter and spool the printjob to that printer. > > > > Thank you for sharing the project details. To embed a printer-specific ICC > > conversion in PIL just to avoid using either Littlecms or the printer driver > > when the print job is submitted doesn't seem to make sense. To use it > > before then, distorts the image as seen in the browser. > > Regards, > > Gary > > > > ----- Original Message ----- > > From: "Hans Svedåker" > > To: "Gary Speer" > > Sent: Monday, July 08, 2002 12:44 AM > > Subject: Re: [Image-SIG] Convert to CMYK > > > > > > > >>Hi > >> > >>Gary Speer wrote: > >> > >>>Hans & Kevin - > >>>As a user that does a lot of design for print, it does not make sense to > >> > > me > > > >>>to build a complex converter to CMYK. Just about every printer driver > >> > > has > > > >>>an optimized CMYK GCR/UCR converter that closely matches the printer's > >>>characteristics when you send it an RGB print job. A PIL based generic > >>>converter to a light (under 20%) GCR will always look worse than the > >> > > printer > > > >>>driver's formula optimized to the specific printer's characteristics. > >> > > If > > > >>>the converter matching the printer is not adequate, then no amount of > >> > > PIL > > > >>>tweaking will come close to adjusting on the client side using something > >>>like Photoshop. There is no real on-screen way to produce a browser app > >>>that will display the results of the separation curve since it will > >> > > always > > > >>>go back to the same RGB values on the browser screen. Unless I'm > >> > > missing > > > >>>something, I just don't see the value in converting server-side. > >>> > >>>Kevin - I would hate to see you waste time on an optimized converter > >> > > without > > > >>>a purpose. All I can think of as a benefit is a method of increasing > >>>contrast with on-line tools without throwing in a color shift. If so, > >>>switch to LAB and expand the luminosity histogram - a much easier and > >>>reliable method than doing so in RGB or CMYK. Now, color enhancing > >> > > using > > > >>>colorspace shifting filter curves - that could be cool! > >>> > >>>Hans - If you can expand on the purpose, perhaps we can suggest a better > >>>technique. Otherwise, the RGB version of the JPEG will always look > >> > > better > > > >>>on your CMYK printer because of the printer-specific optimized driver is > >>>doing the grey color replacement optimized to avoid over-inking.and > >> > > produce > > > >>>even color replacement based largely on the paper selection and its > >> > > total > > > >>>ink limits. > >>>Gary > >> > >>I use a program called "tifficc" that i found at > >>"http://www.littlecms.com/" that uses ICC profiles to convert the > >>picture (www.color.org). If you use an ICC profile in PIL, then i maybe > >>would be worhth implementing in PIL. The purpose of the software is to > >>convert pictures so that they are ready for print in a news papper. > >> > >>/Hans > >> > >> > >>>----- Original Message ----- > >>>From: "Kevin@Cazabon.com" > >>>To: "Hans Svedåker" ; "image-sig" > >>> > >>>Sent: Friday, July 05, 2002 7:58 PM > >>>Subject: Re: [Image-SIG] Convert to CMYK > >>> > >>> > >>> > >>> > >>>>The built-in RGB/CMYK conversion in PIL is not an optomized one... > >>> > > there's > > > >>>>no GCR/UCR, it's basically a RGB/CMY flop. > >>>> > >>>>Formulas for UCR/GCR are fairly easily available, maybe we should look > >>> > > at > > > >>>>implementing a tunable conversion method in the core of PIL? I've > >>> > >>>mentioned > >>> > >>> > >>>>this before, I just haven't had the time to do anything myself yet... > >>>> > >>>>Kevin. > >>>> > >>>> > >>>>----- Original Message ----- > >>>>From: "Hans Svedåker" > >>>>To: "image-sig" > >>>>Sent: Thursday, July 04, 2002 1:43 AM > >>>>Subject: [Image-SIG] Convert to CMYK > >>>> > >>>> > >>>> > >>>> > >>>>>Hi > >>>>> > >>>>>I'm trying to convert JPG image to CMYK format. And it works fine, > >>>>>except for one thing. When there is black (or gray) in the image it is > >>>>>converted to (255,255,255,0) instead of (0,0,0,255). There are never > >>>> > > any > > > >>>>> black in the image, insted i blends max cyan, magenta and yellow to > >>>>>get black. How shuld i do to get that? > >>>>> > >>>>>/Hans Svedåker > >>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Image-SIG maillist - Image-SIG@python.org > >>>>>http://mail.python.org/mailman/listinfo/image-sig > >>>> > > From Schutte@fel.tno.nl Wed Jul 10 00:15:06 2002 From: Schutte@fel.tno.nl (Klamer Schutte) Date: Wed, 10 Jul 2002 01:15:06 +0200 Subject: [Image-SIG] TK image interface with compute intensive code Message-ID: <3D2B6E7A.E4CE54F1@fel.tno.nl> I am looking for a way to integrate my pyhton code capable of (interactively) displaying an image (through PIL) with some computation intensive C code. What I have seen this far in the following code: PyRun_SimpleString("frame=Toplevel()"); sprintf(comm, "viewer.viewer(frame, '%s',im)", argv[1]); PyRun_SimpleString(comm); PyRun_SimpleString("root.update()"); sleep(10); PyRun_SimpleString("frame=Toplevel()"); sprintf(comm, "viewer.viewer(frame, '%s',im)", argv[1]); PyRun_SimpleString(comm); PyRun_SimpleString("root.update()"); here I try to visualize something from my C++ code. im is the Python name for my image, and viewer.viewer() the python viewer with callbacks on mouse clicks. The sleep(10) is a placeholder for what might happen in my own code. 10 seconds of not being able to handle the image window is not what I want. I tried to have a Tkinter root.mainloop() set up before as separate thread: PyRun_SimpleString("thread.start_new_thread(root.mainloop,())"); However, this also didn't give me the responsive image viewer I am looking for. Anybody a hint how to get the C++ code running independent of the python interface? Klamer From csx239@coventry.ac.uk Wed Jul 10 16:05:49 2002 From: csx239@coventry.ac.uk (James Shuttleworth) Date: Wed, 10 Jul 2002 16:05:49 +0100 Subject: [Image-SIG] Low level access Message-ID: <200207101605.49647.csx239@coventry.ac.uk> Hi, I've just been playing with the PIL and I'm quite impressed. It's my f= irst=20 use of python, so I've been having lots of fun. I do have a question=20 though... I've been writing a tool that alters an image based on the content of ano= ther. =20 The first way I tried it, I hust used getpixel and putpixel. This worked= =20 fine, but it was very very slow. I speeded things up a little (actually,= I=20 doubled the speed) by using getdata to retrieve the pixel info from the t= wo=20 files. What I then wanted to do was to remove the use of putpixel. Firs= t I=20 thought I'd use getdata to get an object of the right size and then alter= it=20 for the new image, but I can't (it's immutable?). Is there any way to=20 quickly manipulate the image data at the pixel level? I've been using th= e=20 fromstring method to speed things up a little (creating a list and then=20 joining it to create the string rather than using concatenation), but it'= s=20 hardly a big improvement. Am I going about this in the wrong way? Is PIL the right tool for the jo= b? =20 It's taking around 23s per image pair, which is just too slow. Ideally, = this=20 is intended for frame by frame compositing of rendered movie passes. Any ideas? Thanks, James csx239@cov.ac.uk From klimek@grc.nasa.gov Thu Jul 11 16:07:51 2002 From: klimek@grc.nasa.gov (Robert Klimek) Date: Thu, 11 Jul 2002 11:07:51 -0400 Subject: [Image-SIG] Low level access In-Reply-To: <200207101605.49647.csx239@coventry.ac.uk> References: <200207101605.49647.csx239@coventry.ac.uk> Message-ID: <200207111505.LAA13763@behemoth.lerc.nasa.gov> On Wednesday 10 July 2002 11:05 am, you wrote: > Hi, > I've just been playing with the PIL and I'm quite impressed. It's my > first use of python, so I've been having lots of fun. I do have a ques= tion > though... > > I've been writing a tool that alters an image based on the content of > another. The first way I tried it, I hust used getpixel and putpixel. = This > worked fine, but it was very very slow. I speeded things up a little > (actually, I doubled the speed) by using getdata to retrieve the pixel = info > from the two files. What I then wanted to do was to remove the use of > putpixel. First I thought I'd use getdata to get an object of the righ= t > size and then alter it for the new image, but I can't (it's immutable?)= =2E=20 > Is there any way to quickly manipulate the image data at the pixel leve= l?=20 > I've been using the fromstring method to speed things up a little (crea= ting > a list and then joining it to create the string rather than using > concatenation), but it's hardly a big improvement. > > Am I going about this in the wrong way? Is PIL the right tool for the = job? > It's taking around 23s per image pair, which is just too slow. Ideally= , > this is intended for frame by frame compositing of rendered movie passe= s. > > Any ideas? > I'm often frustrated by this as well, where you need to loop through all = the=20 pixels of an image and perform some operation, like on a 3x3 neighborhood= =2E=20 I'm currently looking at a floodfill operation and I'm running into the s= peed=20 problem. The one thing in PIL that is very fast is the point() function. = It=20 may be coupled with lambda such as this simple threshold operation below: def Threshold(image, value=3D128): # set to 255 if pixel greater than value t =3D image.point(lambda i, v=3Dvalue: i > v and 255) return t Maybe you can modify it to suit your requirement? However, there are many= =20 situations where I don't know how to implement this scheme, such as the o= ne=20 you're requesting. Hope this helps! Bob From jal@cinesite.co.uk Thu Jul 11 17:24:52 2002 From: jal@cinesite.co.uk (John Lockwood) Date: Thu, 11 Jul 2002 17:24:52 +0100 Subject: [Image-SIG] Re: Low level access References: <20020711160003.24960.51740.Mailman@mail.python.org> Message-ID: <3D2DB154.4ADE39EE@cinesite.co.uk> Using numerical python might be faster for you. Use the tostring and fromstring fuction in both packages to convert from one to the other. http://www.pfdubois.com/numpy/ jal image-sig-request@python.org wrote: > Send Image-SIG mailing list submissions to > image-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/image-sig > or, via email, send a message with subject or body 'help' to > image-sig-request@python.org > > You can reach the person managing the list at > image-sig-admin@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Image-SIG digest..." > > ------------------------------------------------------------------------ > Today's Topics: > > 1. Re: Low level access (Robert Klimek) > > ------------------------------------------------------------------------ > > Subject: Re: [Image-SIG] Low level access > Date: Thu, 11 Jul 2002 11:07:51 -0400 > From: Robert Klimek > To: James Shuttleworth > CC: "mailing List (PIL)" > References: <200207101605.49647.csx239@coventry.ac.uk> > > On Wednesday 10 July 2002 11:05 am, you wrote: > > Hi, > > I've just been playing with the PIL and I'm quite impressed. It's my > > first use of python, so I've been having lots of fun. I do have a question > > though... > > > > I've been writing a tool that alters an image based on the content of > > another. The first way I tried it, I hust used getpixel and putpixel. This > > worked fine, but it was very very slow. I speeded things up a little > > (actually, I doubled the speed) by using getdata to retrieve the pixel info > > from the two files. What I then wanted to do was to remove the use of > > putpixel. First I thought I'd use getdata to get an object of the right > > size and then alter it for the new image, but I can't (it's immutable?). > > Is there any way to quickly manipulate the image data at the pixel level? > > I've been using the fromstring method to speed things up a little (creating > > a list and then joining it to create the string rather than using > > concatenation), but it's hardly a big improvement. > > > > Am I going about this in the wrong way? Is PIL the right tool for the job? > > It's taking around 23s per image pair, which is just too slow. Ideally, > > this is intended for frame by frame compositing of rendered movie passes. > > > > Any ideas? > > > > I'm often frustrated by this as well, where you need to loop through all the > pixels of an image and perform some operation, like on a 3x3 neighborhood. > I'm currently looking at a floodfill operation and I'm running into the speed > problem. The one thing in PIL that is very fast is the point() function. It > may be coupled with lambda such as this simple threshold operation below: > > def Threshold(image, value=128): > # set to 255 if pixel greater than value > t = image.point(lambda i, v=value: i > v and 255) > return t > > Maybe you can modify it to suit your requirement? However, there are many > situations where I don't know how to implement this scheme, such as the one > you're requesting. > > Hope this helps! > Bob From csx239@coventry.ac.uk Thu Jul 11 18:12:17 2002 From: csx239@coventry.ac.uk (James Shuttleworth) Date: Thu, 11 Jul 2002 18:12:17 +0100 Subject: [Image-SIG] Low level access In-Reply-To: <200207111505.LAA13763@behemoth.lerc.nasa.gov> References: <200207101605.49647.csx239@coventry.ac.uk> <200207111505.LAA13763@behemoth.lerc.nasa.gov> Message-ID: <200207111812.17671.csx239@coventry.ac.uk> I thought about doing this, but (as far as I know) point only evaluates o= nce=20 for each pixel value, so there's no way to use another image as a source.= =20 Plus the function passed to it can only take one parameter (and I'd need = to=20 know coordinates as well as the value). Ah well. Someone has suggested=20 using numeric, so I'll try that and see what happens. Thanks for replying, James On Thursday 11 Jul 2002 4:07 pm, Robert Klimek wrote: > On Wednesday 10 July 2002 11:05 am, you wrote: > > Hi, > > I've just been playing with the PIL and I'm quite impressed. It's = my > > first use of python, so I've been having lots of fun. I do have a > > question though... > > > > I've been writing a tool that alters an image based on the content of > > another. The first way I tried it, I hust used getpixel and putpixel.= =20 > > This worked fine, but it was very very slow. I speeded things up a > > little (actually, I doubled the speed) by using getdata to retrieve t= he > > pixel info from the two files. What I then wanted to do was to remov= e > > the use of putpixel. First I thought I'd use getdata to get an objec= t of > > the right size and then alter it for the new image, but I can't (it's > > immutable?). Is there any way to quickly manipulate the image data at= the > > pixel level? I've been using the fromstring method to speed things up= a > > little (creating a list and then joining it to create the string rath= er > > than using concatenation), but it's hardly a big improvement. > > > > Am I going about this in the wrong way? Is PIL the right tool for th= e > > job? It's taking around 23s per image pair, which is just too slow.=20 > > Ideally, this is intended for frame by frame compositing of rendered > > movie passes. > > > > Any ideas? > > I'm often frustrated by this as well, where you need to loop through al= l > the pixels of an image and perform some operation, like on a 3x3 > neighborhood. I'm currently looking at a floodfill operation and I'm > running into the speed problem. The one thing in PIL that is very fast = is > the point() function. It may be coupled with lambda such as this simple > threshold operation below: > > def Threshold(image, value=3D128): > # set to 255 if pixel greater than value > t =3D image.point(lambda i, v=3Dvalue: i > v and 255) > return t > > > Maybe you can modify it to suit your requirement? However, there are ma= ny > situations where I don't know how to implement this scheme, such as the= one > you're requesting. > > Hope this helps! > Bob > > > > _______________________________________________ > Image-SIG maillist - Image-SIG@python.org > http://mail.python.org/mailman/listinfo/image-sig From aureli@ipk.fhg.de Fri Jul 12 09:42:26 2002 From: aureli@ipk.fhg.de (Aureli Soria Frisch) Date: Fri, 12 Jul 2002 10:42:26 +0200 Subject: [Image-SIG] Low level access In-Reply-To: <200207111812.17671.csx239@coventry.ac.uk> References: <200207101605.49647.csx239@coventry.ac.uk> <200207111505.LAA13763@behemoth.lerc.nasa.gov> <200207111812.17671.csx239@coventry.ac.uk> Message-ID: Hi, Also in my opinion the way through Numeric is the most appropriate. However with fromstring and tostring methods you will encounter some problems. These functions (I got from the list and modify a bit) can facilitate the work: import Numeric import Image def image2array(im,outputDim=3): if im.mode == "L": a = Numeric.fromstring(im.tostring(), Numeric.UnsignedInt8) bands=1 elif im.mode == "F": a = Numeric.fromstring(im.tostring(), Numeric.Float32) bands=1 elif (im.mode=='RGB')|(im.mode=='YCbCr'): a = Numeric.fromstring(im.tostring(), Numeric.UnsignedInt8) bands=3 elif (im.mode=='RGBA')|(im.mode=='CMYK'): a = Numeric.fromstring(im.tostring(), Numeric.UnsignedInt8) bands=4 else: raise ValueError, im.mode+" mode not considered" #print "array now" #print a if outputDim==3: #bands as vector in the third dimension a.shape=(im.size[1],im.size[0],bands) elif outputDim==2: #for images with 1 band (2D arrays) a=Numeric.reshape(a,(im.size[1],im.size[0])) elif outputDim==1: #for images with 1 band as flat array (1D arrays) a=Numeric.reshape(a,(im.size[1]*im.size[0],)) #print "change shape" #print a return a def array2image(a): #print a.shape if len(a.shape)==3: b=() for i in range(a.shape[2]): #print a[:,:,i].shape b+=(array2image(a[:,:,i]),) #print b[0].size if a.shape[2]==3: #print "here shape 3",b #return b return Image.merge("RGB",b) elif a.shape[2]==1: #print "here shape 1",b return b[0] elif a.typecode() == Numeric.UnsignedInt8: mode = "L" elif a.typecode() == Numeric.Float32: mode = "F" else: raise ValueError, "unsupported image mode" return Image.fromstring(mode, (a.shape[1], a.shape[0]), a.astype(a.typecode()).tostring()) Best regards, Aureli -- ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail: aureli@ipk.fhg.de fon: +49 30 39006-143 fax: +49 30 3917517 web: http://vision.fhg.de/~aureli/web-aureli_en.html ################################# From jtk@yahoo.com Sat Jul 13 01:13:25 2002 From: jtk@yahoo.com (Jeff Kowalczyk) Date: Fri, 12 Jul 2002 20:13:25 -0400 Subject: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Message-ID: I'm using Zope's Photo product, which uses PIL or imagemagik to generate thumbnails for an uploaded image. I like the PIL API, from what I've seen of it so far. I'm using PIL 1.1.3 on Win32 with Zope-Photo, and the resized images don't look nearly as good as ones done in a program like Paint Shop Pro. They're quite jagged. Is this just an area PIL isn't strong in yet, or are there tricks to improve the quality? Speed isn't an issue for me, this is a one-time resizing operation at upload time. Is improved resizing quality available in the development version? Here's the function in Photo that does the work. I use quality=100. def _resize(self, display, width, height, engine='ImageMagick', quality=75): """Resize and resample photo.""" origimg = self._original newimg = StringIO() if engine == 'PIL': # Use PIL img = PIL.Image.open(origimg._PILdata()) fmt = img.format img = img.resize((width, height)) img.save(newimg, fmt, quality=quality) elif engine == 'ImageMagick': # Use ImageMagick ( ... ) newimg.seek(0) return newimg Thanks! From fredrik@pythonware.com Sat Jul 13 16:37:56 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sat, 13 Jul 2002 17:37:56 +0200 Subject: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? References: Message-ID: <023101c22a83$46916010$ced241d5@hagrid> Jeff Kowalczyk wrote (in a message pretending to be a "comp.python.image" newsgroup posting, which caused my mailer to mess up completely): > Is this just an area PIL isn't strong in yet, or are there tricks to improve > the quality? Speed isn't an issue for me, this is a one-time resizing > operation at upload time. Is improved resizing quality available in the > development version? did you look for "resize" options in the 1.1.3 documentation, or in the README or CHANGES documents? (the new ANTIALIAS filter was one of the major features in this release ;-) > Here's the function in Photo that does the work. I use quality=100. > > def _resize(self, display, width, height, engine='ImageMagick', > quality=75): > """Resize and resample photo.""" > origimg = self._original > newimg = StringIO() > if engine == 'PIL': # Use PIL > img = PIL.Image.open(origimg._PILdata()) > fmt = img.format > img = img.resize((width, height)) try this instead: img = img.resize((width, height),Image.ANTIALIAS) > img.save(newimg, fmt, quality=quality) JPEG quality 100 is overkill, btw -- it completely disables JPEG's quantization stage, and "mainly of interest for experimental pur- poses", according to the JPEG library documentation, which continues: "Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality." (full text below): Should probably add something about this to the PIL docs... regards /F ::: from the IJG library documentation: The quality switch lets you trade off compressed file size against quality of the reconstructed image: the higher the quality setting, the larger the JPEG file, and the closer the output image will be to the original input. Normally you want to use the lowest quality setting (smallest file) that decompresses into something visually indistinguishable from the original image. For this purpose the quality setting should be between 50 and 95; the default of 75 is often about right. If you see defects at quality 75, then go up 5 or 10 counts at a time until you are happy with the output image. (The optimal setting will vary from one image to another.) quality 100 will generate a quantization table of all 1's, minimizing loss in the quantization step (but there is still information loss in subsampling, as well as roundoff error). This setting is mainly of interest for experimental purposes. Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality. In the other direction, quality values below 50 will produce very small files of low image quality. Settings around 5 to 10 might be useful in preparing an index of a large image library, for example. Try quality 2 (or so) for some amusing Cubist effects. (Note: quality values below about 25 generate 2-byte quantization tables, which are considered optional in the JPEG standard.) From mailhost@cdc.edu Sat Jul 13 17:32:25 2002 From: mailhost@cdc.edu (Mail System Administrator) Date: Sat, 13 Jul 2002 09:32:25 -0700 Subject: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? References: <023101c22a83$46916010$ced241d5@hagrid> Message-ID: <002801c22a8a$df12cd40$1302a8c0@linkline.com> Fredrik - Great suggestion! Sadly it appears that the Anti-Alias rendering is only in version 1.1.3 which has not been compiled by Secret Labs for us poor windoze folks yet. I am still stuck with 1.1.2. I know you put an installer on your site (effbot.org) that works for python installations, but for zope users it doesn't get past the Enter Python Path screen because the zope installer doesn't create a registry key for the python installation path and the field does not allow manual entry of the path. Would it work to hand enter a registry key for the zope installation? Is there another work-around you can suggest? Thanks, Gary ----- Original Message ----- From: "Fredrik Lundh" To: Cc: "Jeff Kowalczyk" Sent: Saturday, July 13, 2002 8:37 AM Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Jeff Kowalczyk wrote (in a message pretending to be a "comp.python.image" newsgroup posting, which caused my mailer to mess up completely): > Is this just an area PIL isn't strong in yet, or are there tricks to improve > the quality? Speed isn't an issue for me, this is a one-time resizing > operation at upload time. Is improved resizing quality available in the > development version? did you look for "resize" options in the 1.1.3 documentation, or in the README or CHANGES documents? (the new ANTIALIAS filter was one of the major features in this release ;-) > Here's the function in Photo that does the work. I use quality=100. > > def _resize(self, display, width, height, engine='ImageMagick', > quality=75): > """Resize and resample photo.""" > origimg = self._original > newimg = StringIO() > if engine == 'PIL': # Use PIL > img = PIL.Image.open(origimg._PILdata()) > fmt = img.format > img = img.resize((width, height)) try this instead: img = img.resize((width, height),Image.ANTIALIAS) > img.save(newimg, fmt, quality=quality) JPEG quality 100 is overkill, btw -- it completely disables JPEG's quantization stage, and "mainly of interest for experimental pur- poses", according to the JPEG library documentation, which continues: "Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality." (full text below): Should probably add something about this to the PIL docs... regards /F ::: from the IJG library documentation: The quality switch lets you trade off compressed file size against quality of the reconstructed image: the higher the quality setting, the larger the JPEG file, and the closer the output image will be to the original input. Normally you want to use the lowest quality setting (smallest file) that decompresses into something visually indistinguishable from the original image. For this purpose the quality setting should be between 50 and 95; the default of 75 is often about right. If you see defects at quality 75, then go up 5 or 10 counts at a time until you are happy with the output image. (The optimal setting will vary from one image to another.) quality 100 will generate a quantization table of all 1's, minimizing loss in the quantization step (but there is still information loss in subsampling, as well as roundoff error). This setting is mainly of interest for experimental purposes. Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality. In the other direction, quality values below 50 will produce very small files of low image quality. Settings around 5 to 10 might be useful in preparing an index of a large image library, for example. Try quality 2 (or so) for some amusing Cubist effects. (Note: quality values below about 25 generate 2-byte quantization tables, which are considered optional in the JPEG standard.) From gspeer@cortech.org Sat Jul 13 20:08:51 2002 From: gspeer@cortech.org (Gary Speer) Date: Sat, 13 Jul 2002 12:08:51 -0700 Subject: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Message-ID: <004a01c22aa0$b9db82e0$1302a8c0@linkline.com> Hi Fredrik - I'm trying to tackle two issues - 1. The syntax you suggested for the Photo module to use ANTIALIAS is generating errors. I tried the BICUBIC filter so that I could test it on a working?? PIL 1.1.2 installation.. Please see no. 2 as this might be installation related. I tried: img = img.resize((width, height),Image.BICUBIC) which gives an error type AttributeError, error value BICUBIC and img = img.resize((width, height),"BICUBIC") or img = img.resize((width, height),'BICUBIC') patterned after your PIL documentation which gives an error type ValueError, error value: undefined resampling filter The last version gave me some hope that at least the syntax was getting to the module that understands that a filter is being specified. Any suggestions ??? 2. My second challenge may be related to the first in some way. I am trying to install PIL 1.1.3 in a Zope 2.5.1/Python 2.1.3/Win32 environment. I have PIL successfully installed (or at least no errors until this one) by following a how-to that said - Install the PY21 bundle. Copy the PIL directory to c:\Zope\libs\python\PIL, copy the PIL.pth file to that python directory, copy the files _imaging.pyd, tcl83.dll and tk83.dll to the c:\Zope\bin\lib\win32 directory. That seems to have been working. I applied your PIL 113 upgrade on the PY21 installation and simply copied the newer PIL directory and newer _imaging.pyd over their older counterparts. I now appear to be functioning normally again and presume I am successfully upgraded. I noticed in attempting the steps above that in my traceback, the file c:\PY21\PIL\Image.py was being called instead of the copy of that file that is under the python directory in the Zope installation. Apparently the paths are embedded into the compiled files. Would deleting all the pyc files in the PIL directory help or is the issue in the _imaging.pyd? Since the files are being found, I presume this kludge is working, but I would rather simply have a clean install of PIL fully within a clean install of Zope, but that puts me back to the lack of a Python registry key being created when Zope is installed for your PIL installer to read that I described in my last note I don't know if this could be contributing to the error, above. I am struggling because I am not a Python programmer and have learned enough Zope to be damgerous. Nevertheless, after trying to get PIL into Zope for months without replies until two weeks ago, I finally do have a (fully??) functioning photo site via this installation and I would love to enhance it with the ANTIALIAS filter. Knowing PIL as you do, do I have a broken installation and should I start clean and somehow hack the registry values to get your installer to work? My concern is that the Python directory tree is different than zope's and in zope the python executable is in C:\Zope\bin while most of the Python files and products are under C:\Zope\lib\python. I am so close to success with PIL and Photo123! Any and all guidance would be greatly appreciated! Gary By the way - I have been testing the syntax changes by editing the Photo.py file in the Photo product directory using Idle, deleting the photo.pyc file, Killing the Zope server and restarting Start.Bat so that it recompiles photo.pyc as it loads. Is there a faster/easier way to recompile a python product file like photo.pyc on the fly without killing and restarting the server for each iteration? Again. many thanks for any suggestions you can provide. ----- Original Message ----- From: "Mail System Administrator" To: "Fredrik Lundh" ; Cc: "Jeff Kowalczyk" Sent: Saturday, July 13, 2002 9:32 AM Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Fredrik - Great suggestion! Sadly it appears that the Anti-Alias rendering is only in version 1.1.3 which has not been compiled by Secret Labs for us poor windoze folks yet. I am still stuck with 1.1.2. I know you put an installer on your site (effbot.org) that works for python installations, but for zope users it doesn't get past the Enter Python Path screen because the zope installer doesn't create a registry key for the python installation path and the field does not allow manual entry of the path. Would it work to hand enter a registry key for the zope installation? Is there another work-around you can suggest? Thanks, Gary ----- Original Message ----- From: "Fredrik Lundh" To: Cc: "Jeff Kowalczyk" Sent: Saturday, July 13, 2002 8:37 AM Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Jeff Kowalczyk wrote (in a message pretending to be a "comp.python.image" newsgroup posting, which caused my mailer to mess up completely): > Is this just an area PIL isn't strong in yet, or are there tricks to improve > the quality? Speed isn't an issue for me, this is a one-time resizing > operation at upload time. Is improved resizing quality available in the > development version? did you look for "resize" options in the 1.1.3 documentation, or in the README or CHANGES documents? (the new ANTIALIAS filter was one of the major features in this release ;-) > Here's the function in Photo that does the work. I use quality=100. > > def _resize(self, display, width, height, engine='ImageMagick', > quality=75): > """Resize and resample photo.""" > origimg = self._original > newimg = StringIO() > if engine == 'PIL': # Use PIL > img = PIL.Image.open(origimg._PILdata()) > fmt = img.format > img = img.resize((width, height)) try this instead: img = img.resize((width, height),Image.ANTIALIAS) > img.save(newimg, fmt, quality=quality) JPEG quality 100 is overkill, btw -- it completely disables JPEG's quantization stage, and "mainly of interest for experimental pur- poses", according to the JPEG library documentation, which continues: "Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality." (full text below): Should probably add something about this to the PIL docs... regards /F ::: from the IJG library documentation: The quality switch lets you trade off compressed file size against quality of the reconstructed image: the higher the quality setting, the larger the JPEG file, and the closer the output image will be to the original input. Normally you want to use the lowest quality setting (smallest file) that decompresses into something visually indistinguishable from the original image. For this purpose the quality setting should be between 50 and 95; the default of 75 is often about right. If you see defects at quality 75, then go up 5 or 10 counts at a time until you are happy with the output image. (The optimal setting will vary from one image to another.) quality 100 will generate a quantization table of all 1's, minimizing loss in the quantization step (but there is still information loss in subsampling, as well as roundoff error). This setting is mainly of interest for experimental purposes. Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality. In the other direction, quality values below 50 will produce very small files of low image quality. Settings around 5 to 10 might be useful in preparing an index of a large image library, for example. Try quality 2 (or so) for some amusing Cubist effects. (Note: quality values below about 25 generate 2-byte quantization tables, which are considered optional in the JPEG standard.) From fredrik@pythonware.com Sat Jul 13 21:29:39 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sat, 13 Jul 2002 22:29:39 +0200 Subject: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? References: <023101c22a83$46916010$ced241d5@hagrid> <002801c22a8a$df12cd40$1302a8c0@linkline.com> Message-ID: <024f01c22aac$33e2ac70$ced241d5@hagrid> "Mail System Administrator" (?) wrote: > Great suggestion! Sadly it appears that the Anti-Alias rendering is only in > version 1.1.3 which has not been compiled by Secret Labs for us poor windoze > folks yet. I am still stuck with 1.1.2. > > I know you put an installer on your site (effbot.org) that works for python > installations, but for zope users it doesn't get past the Enter Python Path > screen because the zope installer doesn't create a registry key for the > python installation path and the field does not allow manual entry of the > path. > > Would it work to hand enter a registry key for the zope installation? > Is there another work-around you can suggest? I happened to stumble upon this little HOWTO today: http://www.zope.org/Members/SmileyChris/howto/pil_for_windows if I were you, I'd also ask the Zope maintainers to include something similar to the regpy helper described here: http://www.pythonware.com/products/works/articles/regpy20.htm From ilservice@attbi.com Sat Jul 13 18:30:56 2002 From: ilservice@attbi.com (ilservice) Date: Sat, 13 Jul 2002 10:30:56 -0700 Subject: [Image-SIG] Re: Congratulations References: <20020713203336.VDA9157.oe-iw1.bizmailsrvcs.net@Eckvjpp> Message-ID: <3D3063CF.EE089AF@attbi.com> I have not opened you message because my computer has indicated is contains a virus. I do not know who you are. Please do not send me anymore messages. image-sig wrote: From gspeer@cortech.org Sun Jul 14 20:30:39 2002 From: gspeer@cortech.org (Gary Speer) Date: Sun, 14 Jul 2002 12:30:39 -0700 Subject: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Message-ID: <003201c22b6c$f03a2540$1302a8c0@linkline.com> Finally discovered the correct syntax for Fredrik's suggestion at add antialias to the photo123 / photo folders product In photo.py change the line from img = img.resize((width, height)) to: img = img.resize((width, height),PIL.Image.ANTIALIAS) Dramatically improved results on resized photos!!!!!! Fredrik - The HowTo you referred me to was mostly effective. Turns out that tk83.dll also needs to be added to Zope's python path at zope/bin/dll - I sent a note to Chris to update it. Also it seems none of the PIL scripts are compiled until they are actually called for the first time. Whatever makes it work.... Fredrik - any reason not to make anitalias the default filter on a resize? Thanks again, Gary ----- Original Message ----- From: "Gary Speer" To: "Fredrik Lundh" ; Cc: "Jeff Kowalczyk" Sent: Saturday, July 13, 2002 12:08 PM Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Hi Fredrik - I'm trying to tackle two issues - 1. The syntax you suggested for the Photo module to use ANTIALIAS is generating errors. I tried the BICUBIC filter so that I could test it on a working?? PIL 1.1.2 installation.. Please see no. 2 as this might be installation related. I tried: img = img.resize((width, height),Image.BICUBIC) which gives an error type AttributeError, error value BICUBIC and img = img.resize((width, height),"BICUBIC") or img = img.resize((width, height),'BICUBIC') patterned after your PIL documentation which gives an error type ValueError, error value: undefined resampling filter The last version gave me some hope that at least the syntax was getting to the module that understands that a filter is being specified. Any suggestions ??? 2. My second challenge may be related to the first in some way. I am trying to install PIL 1.1.3 in a Zope 2.5.1/Python 2.1.3/Win32 environment. I have PIL successfully installed (or at least no errors until this one) by following a how-to that said - Install the PY21 bundle. Copy the PIL directory to c:\Zope\libs\python\PIL, copy the PIL.pth file to that python directory, copy the files _imaging.pyd, tcl83.dll and tk83.dll to the c:\Zope\bin\lib\win32 directory. That seems to have been working. I applied your PIL 113 upgrade on the PY21 installation and simply copied the newer PIL directory and newer _imaging.pyd over their older counterparts. I now appear to be functioning normally again and presume I am successfully upgraded. I noticed in attempting the steps above that in my traceback, the file c:\PY21\PIL\Image.py was being called instead of the copy of that file that is under the python directory in the Zope installation. Apparently the paths are embedded into the compiled files. Would deleting all the pyc files in the PIL directory help or is the issue in the _imaging.pyd? Since the files are being found, I presume this kludge is working, but I would rather simply have a clean install of PIL fully within a clean install of Zope, but that puts me back to the lack of a Python registry key being created when Zope is installed for your PIL installer to read that I described in my last note I don't know if this could be contributing to the error, above. I am struggling because I am not a Python programmer and have learned enough Zope to be damgerous. Nevertheless, after trying to get PIL into Zope for months without replies until two weeks ago, I finally do have a (fully??) functioning photo site via this installation and I would love to enhance it with the ANTIALIAS filter. Knowing PIL as you do, do I have a broken installation and should I start clean and somehow hack the registry values to get your installer to work? My concern is that the Python directory tree is different than zope's and in zope the python executable is in C:\Zope\bin while most of the Python files and products are under C:\Zope\lib\python. I am so close to success with PIL and Photo123! Any and all guidance would be greatly appreciated! Gary By the way - I have been testing the syntax changes by editing the Photo.py file in the Photo product directory using Idle, deleting the photo.pyc file, Killing the Zope server and restarting Start.Bat so that it recompiles photo.pyc as it loads. Is there a faster/easier way to recompile a python product file like photo.pyc on the fly without killing and restarting the server for each iteration? Again. many thanks for any suggestions you can provide. ----- Original Message ----- From: "Mail System Administrator" To: "Fredrik Lundh" ; Cc: "Jeff Kowalczyk" Sent: Saturday, July 13, 2002 9:32 AM Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Fredrik - Great suggestion! Sadly it appears that the Anti-Alias rendering is only in version 1.1.3 which has not been compiled by Secret Labs for us poor windoze folks yet. I am still stuck with 1.1.2. I know you put an installer on your site (effbot.org) that works for python installations, but for zope users it doesn't get past the Enter Python Path screen because the zope installer doesn't create a registry key for the python installation path and the field does not allow manual entry of the path. Would it work to hand enter a registry key for the zope installation? Is there another work-around you can suggest? Thanks, Gary ----- Original Message ----- From: "Fredrik Lundh" To: Cc: "Jeff Kowalczyk" Sent: Saturday, July 13, 2002 8:37 AM Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough, any workarounds? Jeff Kowalczyk wrote (in a message pretending to be a "comp.python.image" newsgroup posting, which caused my mailer to mess up completely): > Is this just an area PIL isn't strong in yet, or are there tricks to improve > the quality? Speed isn't an issue for me, this is a one-time resizing > operation at upload time. Is improved resizing quality available in the > development version? did you look for "resize" options in the 1.1.3 documentation, or in the README or CHANGES documents? (the new ANTIALIAS filter was one of the major features in this release ;-) > Here's the function in Photo that does the work. I use quality=100. > > def _resize(self, display, width, height, engine='ImageMagick', > quality=75): > """Resize and resample photo.""" > origimg = self._original > newimg = StringIO() > if engine == 'PIL': # Use PIL > img = PIL.Image.open(origimg._PILdata()) > fmt = img.format > img = img.resize((width, height)) try this instead: img = img.resize((width, height),Image.ANTIALIAS) > img.save(newimg, fmt, quality=quality) JPEG quality 100 is overkill, btw -- it completely disables JPEG's quantization stage, and "mainly of interest for experimental pur- poses", according to the JPEG library documentation, which continues: "Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality." (full text below): Should probably add something about this to the PIL docs... regards /F ::: from the IJG library documentation: The quality switch lets you trade off compressed file size against quality of the reconstructed image: the higher the quality setting, the larger the JPEG file, and the closer the output image will be to the original input. Normally you want to use the lowest quality setting (smallest file) that decompresses into something visually indistinguishable from the original image. For this purpose the quality setting should be between 50 and 95; the default of 75 is often about right. If you see defects at quality 75, then go up 5 or 10 counts at a time until you are happy with the output image. (The optimal setting will vary from one image to another.) quality 100 will generate a quantization table of all 1's, minimizing loss in the quantization step (but there is still information loss in subsampling, as well as roundoff error). This setting is mainly of interest for experimental purposes. Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality. In the other direction, quality values below 50 will produce very small files of low image quality. Settings around 5 to 10 might be useful in preparing an index of a large image library, for example. Try quality 2 (or so) for some amusing Cubist effects. (Note: quality values below about 25 generate 2-byte quantization tables, which are considered optional in the JPEG standard.) From Kyler@Lairds.com Mon Jul 15 00:17:37 2002 From: Kyler@Lairds.com (Kyler Laird) Date: Sun, 14 Jul 2002 18:17:37 -0500 Subject: [Image-SIG] bad RGBX conversions Message-ID: <20020714231737.GA4062@jowls.ucnet.net> It appears that RGBX conversions aren't ready to use. I'm not sure if it's of interest to anyone, but I don't have time to debug it and I don't want my explorations to have been a complete waste of time. PIL seems to be able to convert from RGBX to GIF and JPEG. Images converted to GIF are o.k. except red and blue are swapped. This is contrary to the description of "RGBX". 24-bit true colour, stored as (blue, green, red, pad). Conversion to JPEG results in bad/no colors and the image compressed horizontally, leaving black space on the right side. This conversion image_data = image._data['data'] image_data_RGB = '' for y in range(capture_height): for x in range(capture_height): pixel_position = ((y * capture_width) + x) * 4 image_data_RGB += image_data[pixel_position + 2] + image_data[pixel_position + 1] + image_data[pixel_position + 0] makes the image data readable using "RGB" mode, but it takes forever. This is on a Debian unstable system using python2.1-imaging-1.1.3-1-i386. I'm moving on... --kyler From indu@swamicyber.com Mon Jul 15 12:07:33 2002 From: indu@swamicyber.com (Indu) Date: Mon, 15 Jul 2002 16:37:33 +0530 Subject: [Image-SIG] compressed TIFF images Message-ID: <006301c22bef$d6136a90$0503a8c0@ns1.asianet.com> This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C22C1D.EB4E82E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How can we open a compressed TIFF image using PIL? Can anyone help me? Thanks Indu ------=_NextPart_000_0060_01C22C1D.EB4E82E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How can we open a compressed TIFF image = using=20 PIL?
 
Can anyone help me?
 
Thanks
Indu
 
------=_NextPart_000_0060_01C22C1D.EB4E82E0-- From schutte@fel.tno.nl Mon Jul 15 16:05:05 2002 From: schutte@fel.tno.nl (K Schutte) Date: Mon, 15 Jul 2002 17:05:05 +0200 Subject: [Image-SIG] compressed TIFF images References: <006301c22bef$d6136a90$0503a8c0@ns1.asianet.com> Message-ID: <3D32E4A1.21ABF1BA@fel.tno.nl> The Good(TM) method is to add support for the Tiff library to PIL, similar like JPEG support through the JPEG library. I also encountered similar problems using Tiff images (reading 16 bit unsigned Tiff's in my case with packed compression.) The bad things is that our solution is proprietary. Good luck, Klamer > Indu wrote: > > How can we open a compressed TIFF image using PIL? > > Can anyone help me? > > Thanks > Indu > -- Klamer Schutte, E-mail: Schutte@fel.tno.nl Electro-Optical Systems, TNO Physics and Electronics Laboratory Tel: +31-70-3740469 -- Fax: +31-70-3740654 -- Mobile: +31-6-51316671 From frank.derville@wanadoo.fr Tue Jul 16 21:34:04 2002 From: frank.derville@wanadoo.fr (Frank Derville) Date: Tue, 16 Jul 2002 22:34:04 +0200 Subject: [Image-SIG] PIL and JPEG 2000 Message-ID: <000501c22d08$35714840$44c6fea9@Hal> Hello, Is it planned to include JPEG 2000 support to PIL? TIA Frank. From GilmadskilsWilis@aol.com Wed Jul 17 21:34:23 2002 From: GilmadskilsWilis@aol.com (GilmadskilsWilis@aol.com) Date: Wed, 17 Jul 2002 16:34:23 EDT Subject: [Image-SIG] HELP ME !!! Message-ID: <3d.214610f5.2a672ecf@aol.com> --part1_3d.214610f5.2a672ecf_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have all the PIL stuff in my Python22 folder, and I'm having some problems, you'll see: import Image >>> im=Image.open('bobo/logo.gif') >>> im.show() Traceback (most recent call last): File "", line 1, in ? im.show() File "D:\PYTHON22\PIL \Image.py", line 749, in show _showxv(self, title, command) File "D:\PYTHON22\PIL \Image.py", line 1040, in _showxv file = self.convert(base)._dump(format=format) File "D:\PYTHON22\PIL \Image.py", line 427, in convert self.load() File "D:\PYTHON22\PIL \ImageFile.py", line 126, in load self.load_prepare() File "D:\PYTHON22\PIL \ImageFile.py", line 180, in load_prepare self.im = Image.core.new(self.mode, self.size) File "D:\PYTHON22\PIL \Image.py", line 37, in __getattr__ raise ImportError, "The _imaging C module is not installed" ImportError: The _imaging C module is not installed >>> please send help --part1_3d.214610f5.2a672ecf_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have all the PIL stuff in my Python22 folder, and I'm having some problems, you'll see:

import Image
>>> im=Image.open('bobo/logo.gif')
>>> im.show()
Traceback (most recent call last):
  File "<pyshell#9>", line 1, in ?
    im.show()
  File "D:\PYTHON22\PIL \Image.py", line 749, in show
    _showxv(self, title, command)
  File "D:\PYTHON22\PIL \Image.py", line 1040, in _showxv
    file = self.convert(base)._dump(format=format)
  File "D:\PYTHON22\PIL \Image.py", line 427, in convert
    self.load()
  File "D:\PYTHON22\PIL \ImageFile.py", line 126, in load
    self.load_prepare()
  File "D:\PYTHON22\PIL \ImageFile.py", line 180, in load_prepare
    self.im = Image.core.new(self.mode, self.size)
  File "D:\PYTHON22\PIL \Image.py", line 37, in __getattr__
    raise ImportError, "The _imaging C module is not installed"
ImportError: The _imaging C module is not installed
>>>


please send help
 --part1_3d.214610f5.2a672ecf_boundary-- From rmelton@xram.com Wed Jul 17 22:49:24 2002 From: rmelton@xram.com (Robert Melton) Date: Wed, 17 Jul 2002 17:49:24 -0400 Subject: [Image-SIG] Stumped ... ImageEnhance not working at all ... Message-ID: <3D35E664.1070507@xram.com> This is a multi-part message in MIME format. --------------010806080105020707070105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The PIL Library is great, but the ImageEnhance module seems to just "not work" (at least on Microsoft Windows XP [up to date with hotfixes], with ActiveState Python 2.2.1 build 222 and PIL 1.1.3). I would just like to know if anyone else had the problem, or if I am doing something totally wrong. My code is below and attached, and the image my code is using is also attached. Start Code (test.py) ===================================== import Image, ImageFilter, ImageEnhance myImage = Image.open('hawaii.jpg') theEnhancer = ImageEnhance.Brightness(myImage) theEnhancedImage = theEnhancer.enhance(1.5); theEnhancedImage.save('hawaiiEnhanced.jpg') ===================================== End Code --------------010806080105020707070105 Content-Type: image/jpeg; name="hawaii.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="hawaii.jpg" /9j/4AAQSkZJRgABAQEA5gDmAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CADrAWADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDwWkpaSmUFJilooASjFFFIAoopaAEpaSlo AKSiigAooooAKKKKBBRRRQMKKKWgBKQ0tHegBKKMUUCCiiigAooooGGKKKKAClpKKQDl+8Kt r0qmOoq4v3c1Miohj6UhHNONN7VJYlNPpTjTaYCGk70poNAhMUw0+mmmhDaSlxRTEFJS0VRI mKKKKACiiigAopKKACiijvQAUcUUZoAKKM0UAFFJS0AFJS0cUAFFFFABRRRQAUlLSUAFFFFA gooooAKKKKACiiigYo61cXG2qXerisNo5qJlRHe1N70u4etN3CpLuIaQ0vHrSGmIbS0lLQAU xulPpjU0IbSUtFMQUUUVRIlFFFABSUtFACUUUUAFFFFABRRRQAUUUUAFFFA6igAopzoUcrkH B6g5BqSW2kighnYfu5Qdre46j6jj86V0Pllr5ENFFHemIKKKSgQUUYooGFFFFAgooooAKKKK ADmiiigAqcZ2jHpUFXIs+Wv0qZFR3IytIRT3602puXYbjHFKKU0mKYB3pfwpPeloAKY1Ppjd aEIbRRRTESy208LbJYnRh2YYqLvVt7qdovKaRivYE9KS3hW6kCS3CxnszClzNK7NZwpt/u2/ mVKK1H0fynAluI9p+66HcDVSe18h9u9XHqppqaexk4tblakp7Lt70yqJCiiigAooooAKKKKA Ac04JkgZHNNHUVImdwpMaE2YOCwzUi2sj/cwcdaG++K0bABo7kHbyg6x7v4h+VRKTSKSRUAw MHqKRreRo1lY/uixA57048Z74NaVmn/EquHBfJRgQEBGB79qluxRisiKcYJ/Gh0RcYHf1pZe o+tLL2zVkkTqoBwDxTKlkZSpCg9aiqkSwpKWkpiFpKKKBBRRRQMKKKKBBRRRQAVajbEY4qrV qMkQjiplsVDcGOTkU00UdqksD6UlGaTNMVwzTu1N7inUAFMbrT6Y3WhAxufSiijmmItODtqH vVg8r0qvzmgb3FJJXrR/DSdjSr931oENk+6KGglTbvRkD9CwwD+NOcZXFIGkEfll22ZztzxQ UlH7Q57GeOVY3CgtyrbhtP49KikjaKQo4IYdRTwe2aib7xoV+oT5Psr8f+AJRRRVGYUUUUAA 6ipFzuH1qMdavWdmLksPtCRlRuAIJz+VTJpK7KirkEikMNwrV0v5Tchu8XH73Z3H5/SsyfOR /StGwDO8oAY/umJ2qG6c1nPYpLcqujeYwBGMnqa07HyxpU8biLdh8FifTtiqDjEjD39MVoWB b7HOAX/i+6wA+771MnsHQxmYxHorE9yuaVi0XzI33hg8dqbP1XpVmF7NCDexTSR7flEThTn8 R0q27Ba5SmkeTcWbJ4HSoK0dQuLOeOIW1mLd0jVJCGJEhHVuehPHtxWdWkdiGFFFFMkKKKKA CiiigAooooAKKKKACpIieRmo6fH3pPYa3Je9JRnikqTQDR0opDQIB1qQ1GOtPPpQwQYpjdae ajPWhAJRRRTEX8AEgCqzffq02fMOf15qF4pGbKIzfQU3pJjLS2Fu0Ak+2hSR9x4yPyNVXjRO Ek3D6Vdi1W6jt/sxmfZjG1lBA/OpZvD+pR2IvykT2553RzKxH1AORWMZNaTer2Lkt5LYye3r Tn+4KQdCKUj5K0ZPQiPWo2+9U2wsCccConBDU0TJDaKKKokKKKMfWgBKsRSyQOXjdkb1U4NQ hSegJp+DjPbHWkxomm6Lxmr9jtMpDFQDG2CxI5x7VQlGY161d0/JnjUEgspHDBT0Pc1lL4Sy S+eOW8d4YBAhA+RWLAHAyQTzyefxqxpyK0cu5Qx5wDGW7VTmB80gkk4HWrmm42zAkAcfekKj p7VD2GY9x/Diib/VKaW4HAzSS8wKa1XQRA5zuqKpiBlhilAjVWB2sSOCR0qr2JtcgoxmpgjM TgqfbgUgR/4UPocU7i5SLB9DRg1YaJklaJ12sp+Yg5qTyI3j4kKjj73TNTzopQZToqU27+aY 8Lu9j1qLaQMkHFVdMhpoSlpKWmIKKKKACnrwOlMqUcDoKTKQtFJkUmfrUlC5pKQmimK45fvV JUSctUlJjQGoyOaeelR0IGFFFFMRp3CbZyMY/DFRNNNAcxOV+lWb1Ak3BQj/AGCaqTA7c0S1 eoRdloRSyPK25zk+uKQEh8ZP503tR3BFAyQdSKcBlSMZpv8AF9aeABkGpY1sQMOlWII0lQo0 ceSw/eknKj6dDURGVNClOQ5GMepH8qGDRoLHGdTMZntrdcbfMjQmM+5BqxE9tcWT2J+yxzq7 MJfK+/8A8C649OKx1WJiAzopz/FkZoKBHJEqOQM8AkVPL5jutrGut1JeXSvLewQyJGVGYFVS AOAMDGfc1TjQzWc8b3UaEHzdrJnc3TAYcg/pVPKxbXUpJuBBBGcfgacIAbQSGNlOThznDD/E UWt+H4EpR2SLz3DNb2rJfOJreMBVI+6Q2QFI+ueaoTuGnch/MDHOcbc/hSyeSPLKgAbOCrDO feovl3Ak8VUVYHboSv8A6pT0q3YczwYBOWxwu79O9V8qEDRbsA5XcOfxqeGd5rhJZAm4uMgL gdfQdKmWw1uPlGHGB2HbFX9IVjLKF35+U/Lj+Z6VRn4kxwMccEn+dWtLbFw/CngfeQt39KiW w0VVt7SZLj7VdNA6Juiwm4O2QNp544yc+1RpDau6x3Fw0cHeVU3H24qO9By46YY9sfpUbc2o q7eYugsq2i28gXzXnJBVs4ULznI9+KpYq1BGJblIywUNxk9K0U065IhaPyHO8ptC5+YdR70O ahuNQctUYuCAadG+xwcA4zXVXmp2k+g2NpHBCbq0V4iTEFYlm3ZJ746DPPOKyXtYreWN8Qzq ybmXONpz9369/wAaSq3TuinSs9GZfmMO+ec0/eBt3cgj+E9Ae1Wb64gn8vZGylFCjLZAHoPz qOAwtIDIsRUAjaxIHTrkenWqvdXaJtZ2uLOqIQEIyhx6n/CmNKgiVA27cDnI+6c9qfcS+ZBD b7zsiJ2/NwM9cflSvZxJZlhIjSlgVIkH3ccjb65xSTSSuN3voQbCYiRMuBxtPXFSxWcLq265 UEY24GQap4xTo5HidZI2KOpyrA8g1bTtozNSV9UWDDamXCXDAerL/hTHgZcFZEfcSPlNQZOc 96UuxVVLEqv3R6UWfcOZdi7FAbSSOS7tvOhOSY9xHb1FVqRJZEJCuwBGDzQTQk+o7roFHeik piA0lBopiHx0+mx9DT6l7lLYaaZint0qOhAwooo5piNm+weefxNVHG6PqKv3MYMeRn/vnFUQ coRUJ+6mNdUVMdaQ0rDDEUdiOK0ESKzIyOpII5Bqa+vbi7dXuJC7AYDED+lQDlM0NyRxnNSt HcdrjVbCnJp0LKJVZ4hKmeVyf6V0/g22voNXF/b6VLqKQKTJFCG4BHUkA4rN1ry73VprqGH7 JDNJnytxcpnr7mslUUpSj0XXz7Gzg0kyFksrufyrdoIIyMmWZWG0/qak09Le2tZZntxNIQVV t3yj8MUmow6dYzLFpl4l+hQFpnt2iKt6YY/rWfDIxlAkbKZ5yTjFK3NHTbQIy5XruOWS2Dkv bErns1bFvf6U1oYPssjIOQsrhsHuRngfhUd2NKvY7dLG1Nq65EsjPlX54OO1aX2nRrC1s4EX zJ4yDOm3Mc5zkE8n6cYqZ2lbe44SkuiOXmiikm22yFVHdjmriK9lbrH9kglaRd24/McZ/Sma 05i1i6C232QmQnyVG0IPQDJp7SW3/COR4QfbftLb5O5TAwPzBrWa2W6Ig0031GXEc/nlHszb zZwIQhXn6Gp7zTdR0qWJNSspLOR1EiK67Sy9jVP7TcTs0s08kkoPDsxJ/OpWvJruNRPLLK8e QDI+cA+npS16k6E90d0zHOck/wAW7v60ticTNzjKHnJFF0dxDc885OPQelFm2LkYYjKkdcdq noIq3gHmSZ4G49KhYZtsDp71ZuVDyOHYgE9cZquo/wBHwOfbHWrT0AjgmktrpJ4wpdOQCMjN Wppbi5UTsxjeLAyvyjAHGMd6rRFhcIeAVxxnFWpr4yMscvMK9EAxgUS30RUdtRJINUs7G3vi sqWsshaKUEcsDyfr9aqS3AkmlkYGQyA5LnkMTnPHepr2+MshS3RobcDAj3ZFQQQTyuPKiMhJ wFC5JP0ogna8txS3siDBp0UhiYsFRsqVw4yORj86sxR2vkTebvE6jKDOATnGKltbaK/upTNN HaRiNn3BCV3AcLgepwM+9U5rW5PI+hnYpVQswAHWnhDkjB98CtopYiztxabvtTKrPJuICnJB XB49DmidTlHCnzGLHbzSrI0cTusa7nKqSEGcZPoM0zFdJFp15ZQzr9oeBbhAsyDI3r1wfUdD WZELQ3sayGVod4DmMDO3POPelGqpPQc6TgrsZp1naXAuGvLp7dUhZo9se/fJ/Cp9AfXtVTyz u4H0rsTZWlzfJb6LpU7F12xpI2+SQjPzexI7duaoJo8stwzPPCrKNwXqPpnpmpjUlLW2gTjC K31MW6dJvLK28cBVArBCfmPrz3qvXTavBPp+itC1vCI7mYOHKZkBUHgHHA56Cua45q4PoRe+ onek70uRTaoBD0ooNFMklj4WnH1oUYUUcVBohr0ynNTapEsKTmlopgb/AA8PAU8dsmqAGHIP Wr9uxMeGJH+8+P0qlONs3bHtWUNmimveKkoxJTe9TTjgEVD2FWtiRUxgjvTixCDHbvTU4fHr SnhWA60DRo6ffzxcJOULcEKxXP1xVqaaIn95kH/ZPFc+CGcb32j1ApWmOSNzMvYnrWTopu6N 1XsrM6C2sLjWHeHT7RrmRELsFIG1R1PNYjqC21fl56GmxyPnoQvrV6KW3bhwufXNCTgDkqhL qK6N/ZtoLCG+ivVX/SmndWjdu2wAZA+tZglCwGMRqXJ++euK2cp5eIyrD+6wqrNaQ/ZDcGaK ObzNotxu3kYzu6Yx265ohU2TFOn1RIZtbuNERpop59Kt5t+5o/kWRh3bHcDpms64uBOWAjSI ZyI0HArat7vUbiyFmbnFoOTEWO1j2yPWqGorIMKUjCqAAUA7etKE7vlaCVOyuiCKF1h807Sj cDDDP5daZB99hTLf7/1FPhGLgj1FavqYl58lEODyB2/z6UsBxOn1xQBmJeO3p706HiZD/tCs nsNEF3nL9elV0Ja3b1+tXdQJeR9xycdeP6VRg/1Lg4zVrYREpIKkH5qRlZyW5J70IHDIyg5H NPCTOwdWOWz1GM1Q1qrEYRzzjPatnR1lgnWeBGS4QhonRsFX7GobGEtKbecrHtBY5Pp2x61p pcfYTG0Tusg5PybSvPBB7561hVm37qOilBL3mSv4XcxS3OoOlpIHUCFgS7BgTu44A9e/I4rU 03wrYGS486+hmgjhdvMt+GTDhQxVvvA8HaOcH2qiLmW9u3keaR5JGLSO5++x6kmtT+z7drZm baJlGVWIn5v6VzTrSSszohRT1RzN4bYRxx24kVgD5gYjBOe2O2Krm9+y23kFVIYk4CDdzjqe uOBW89lai1mwrtc7l8rAyGHO7PpjjFVLiCSHRPtf2YBfN8t3ZgdzFcrhTz0B5rWDujKWmt7G De6pd6pdJLfTyzFVWNd7dFUYUZ9hxWnoBsLW5FzfsViVwFQHDbj3/CqNukSMHchjjO0rxVyz ktrou7HEg4AAwMGuuCXTY8+pJvVndeJtXstJtNLkjtpFdS09vPDt8wHocv1OK8zm1VmdjAhj U9ixJrU1lfKjtR5u7cCTg5xWHPBL9/YCuOq1MVZu4oJcqZZfVby5tEtZpd8StvGV5zj161Wa RQSrCmQ9aZIcyH61dlc0WkSQ+WelN2Z71FmpE4RjTtYL3AxMPf6U3aQehpwkYe9PV93GKLsL IXBFBNFB6VJRGTk0lKaSqJCkpaKBGpaSuT94067U8N1P1zVW2fbJx/KtGcGSHn8s5rPaZctr mfIuYs9arjpirQyVINRC3lKlwp2+pOBVrTQRF3GKeev1p6W8pXIIUe5pr4jzkq59QaL3DYqk YJoqZFidiZH2+wp88MEcYKTAsf4RzVrUy5tbEcs/moisGwgxy2f/ANVR5Tb0OabS4+lLyKEy fX9aCSe+acwA9PzpoHNAFyyvWtpM8bD1GM1NcX8MykCI88ZrO4qWJNy5NQ4Rvc1VWVuUITiR friph8t0vvUr6TfwWkV69pMttKw8uQodr/Q96jbImRgOh9KL31RG2hfRcoPqe30pyLhgfQ05 F4A96nEfqKyKIL/a0vygj5cHkHJ/Cs235Vwa2LyNw4DqwJH8XpWRbAiSQGnHYSIoopJeUUkL knnHApBcOGOyMAMMYxmiR3ZgWYkgkVoX2iy6fFE7EDcokRweHH+ye/8A9arbXUabWxr6FZSa npN7eQrC72WHmhBAcx85cE9gcDHvViW4hl0ozEQ8t5Z2/wCsUgZBIPb3rlrVnilJj3Bm6AcZ BrZtbUS3UNo8qxmd1WWUjIiU8ZP0rlqU1zHVTqtRECpLKzK5IwD+Na1jdfZoJHvBJ5fknaVb btfopz3x3FVdS0kafdT/AGRmlslm8qOc9HwM/r1qG8muNTt4LNmLpCvy4GMDOeaiylZLY0Uu VN9SdfFNgZz59pLKu3b5iOVK+uB0OfepYLyz1e1aIN86tuVHJ4HTpTYNM8NvoMxubm+XUFfa jRIDHjB69zyP1rFWGKwuY3jmYkdWFbwhB6I4KtWVTRly90lgo8qRWZiQMdsGsqW3nt3OeDnP HFdTp0QuL+GFEd5pmCjAwpB7nPQj+lad34es5gUtZGZgxJU1spJbmOqOCl+0PsYjcpGBV/7J KjfdIGcdOOK686VaL4eS0+ysdSS5Lebnjy9vTH1qjZzO2l34V4pkt1eRo5Dh1yOSuetZ1JKz t0Lg9jhc7ppGx3NVickmp1P7tj61XreJT2CpAMRfU1HUj8BR7U2JDaeg5zTM1InSkxodSMeK WmsaRQyiiimSFJS96SgCbf8ANkAAela1szTRiNAzMeiqOT+ArHEZLdfxrWt9evLG0NrbXRhQ 8N5ChC31bGTWdRN25SlsypJuinZHUowPIYYNQS5LADJp5khkYsxfeepzyfqabJbsF3jIX1Jr RuPNpoSr21BIJnViq/KOpzgCoTxxkGgxuMBuAfU1LHGqkFf3j9scAUARNEyKGYgbugzzTO9a 8Wk+bA1xdXaR/wB1AdzNVKW0e3bLISnY0RfNsS3ZlSipSI88A/nTcgH5V/OmA0jHFLgbehzT jGY8GTjPbvSO4Jwi7V+vJoAZWqmqzQ6L/ZphgNu84mdgg8xiBgLu67epx6ms6MMx4XOOacw4 IPJ9BSe47JrU2tP1q/t7+1fTdQltHU+XHvORHu4Prxz6VQuJrmK7nVZS0m5ld16NzyfxqrGV 53A+2O1aGk2z3F4ArAFSGAIzn8KjlSbdgbtqdX8P9A1nxFfKNIvorO7TLq74JwMcjP1rZk+H vi4eIY9MOmq3mOQ135ZMY9SW6VmWB1rS9WttT0neWDOZWjG0E9xx269K77UPjRfaVFZg28U7 S/fbcRt/CpcXBu8Lp7NafLzJjV5rJM53xB8NtS0e3gu9V1ZGlmTCxtklMDp9BwK8+GjywzSS ebCULEABxmtvx/49vfGGpqpnZLGIDYg+QE9z71w8gTHDH6Zp2urJWKV7tt3JJo9kjK3GGOPe nefPdrHFLM7pFkRqWyEzyQPSmqW37JQWAGMHtV+awu7XToL5oBHbXDFYXyDuI64HWmy15kUJ ELAJ/rDxk84rUF1FYwABS8zHnHWsuP8Acjd/F/KnGUlfespRubJ2GvfXW5lyoDH7pFWF1C4h jeBFj3uPmYA5x6VXYeT++lyGOSi9cVWQu0/mchic5HarUU1sZTkzoLC4EqFJMKw5BHQikvrM xRC48t33HC7VJGfc1QNysSAYBbsRXaaT4rltPDqRxRqwBwEYZy/rVc3IrpXOaUX0M7T45tMi mLAvePGIljY7dpI+Y5+mB+NdLoj2lvaxq1siTSYRxycc+prhXvZJLlnYlsMTuz1Pc1qQ6tIq bsj5RxmoabWpVuh0mqatYpeOlorTyx8SR/dYY7gd657xNNbnRHnSJVlc7AwPOD1pLjXXWAzm ONpghKOVyVrlNT1GW+IMjjLHLKiBVz649aiNNlKyZRPEP1qGpZD8ijNQ10oqQoGTTpD8/wBK RB8/0pCcsTTF0AVKvSogMnFTgYHSkxxCo26089KjpIbCiikpiFpKWkoEXE0+dmCbGLnoi8mt FdKt7RN2o3MduccRgb5D+HQVR/tS5SMpC/lKeuzgn8etU2csSWJJ9SaTUnvoPQkuTb+afswc J6yHk/lTEWWVwiBmbsBSA5471LHM8IO1tueuODT6CSJWsmiIExG/+7np9a09K0i51OYQwRrt 6l3IVF+prHW42vuK7j71u6covUG+6IZuBEvCiom2lvYWiV2SzwWml3Lo229dONyHEYP171Re +MxxOqqOwA4ra1LSPstoJrmaOGAfdLnG76DvXJ3F5vBSMfL2YjmtpUrJTvuY06inotbGvZvo 2mtLc6hp5vyyEQQ+eY1Df3mxyQPTisYXhjVxDFGjN/HjJA9B6VW5JqSOINyzAL3NTd21ZqkR 8nnrTwmBkmpNoC/KOB3NN7Z/U0rlWDOBxkA0nJyR0oyBj+XrRkyMBwB6UDHRbDu3NjA446n0 rU06dYXWQEE46dxSme2t4DBp0edyL51zMoLZ7hf7o/U4rJc5ckHv16VF+bYlq+jO/g8ZSW1r DHHKo8p9ygr7EH+dYGq6qt8pJG0kksR1PFYAlbGG+Ye9TxBHJG7b7NzVcziRDDxTvEibdIQA vQYFOFm5wTjB6YPWtazkv7e2ks7WMf6cqxuNgZmw+VC+mTjp1qtdpc21zLb3ELxzxnbIrrhl PpjtUc0nqtjoUIrR7iRRRQoWchmPYU9JYnliS7naK3UnAA3bB3wPU1XOY1DMfm7D0qpKWc5N K3MV8Opqa/daW+pudDjuUssLtF0QXBxz09+apWlwFlBnXdGOTjrVTBwSelODcEYqowtG25m5 Xdzf1n+xjZ28un3c890wzKroFWMbRwPxz+FYiyuDnApNwGdvT1pGxgURVlZu/wDXkQSDM0yD oCcfSuxt7FntlS3RpGUFI1Rckt/EfwFcfZwSXd5FBF9+RgBjtXq+k6fbTIhiuWia1xFEQcEn +Js+9aJLdmNWTWxzN14eutOkWO4jCsVyMEEYp134Ynh022ubg+VFdDMTZ9yOfToa7BtODXZj DmVV6uepq0fD8V2yXFrqstpeW4CqHYGArknBFUnF72X37eX/AATH20lY8xvrBrawKuxYh9uT 3xXOTf63FegeOJ4nvoyjBpJEEkpwB8x68Djsa8+Y752PvWMXc64tyd2NlPIHoKip78sTTK0R T3HJwrGm0/pGB6mmUCHJyalpkY4p9SylsIxpnanMabTQMSijFFMQUUUUAOpPwoopgGc0lFFA BUsFzLayCSJsOOhxUVPU+tS0mtQH3N3c3kvm3M0kr9Muc4+lRKhNS7R1JpM4GAMCj0BRsIFA 4PJ9BSnrjqfQdKOe/A9KVhtGensP60DHo6qjAqpYj7x7fSq+/wD/AF0hOe9JTSE2OyAPU0nW gL/9YU912EDI9cDtQAvmMY9mfl9KQKSaAM/4VInDD2qdikhyxBhgVct7UEgv8oB5NXFlee2t 4ZtiwWwbywFAJ3HJJPc/X0qOVjNgKu2L271g5t6G6ilqWdO1G4sNSgurA7JLd98bsueR0OKh vbqa7vZ7q6kMszuZJXbqzH1pqyFThCFwOvZRWfdTg/KM7R69T71EYJyukU5WWpFNKXYknNRI rSNtH41PZfZJbhlvZZIoyjbWQZw3bI9Ki89fKEaxgHOd3c+1dK00Rg9dWbKaOqWIee4ijD/M BnJ9qxxFy2CuF7561G0rOeWJpA2Dk0RjJbsiTT2Htj6UzO5ueaHPbiliQu4UdzVkmxozR2Ye 5eVIpHykTOOAfU/yrvLTXbWLT0h05AIpPndJEB2kgH5W69a85MlvNMkRHyrhV54+prQguRbf u04HoKTbta5lOCluem2F9vikLRs25cfLyc/hWe8V1p11BOb0lNwYhvb9K4+PXpra7glQyFYD 5jeXJsfI6YPfHBx7VbvvFX2zTvNkgaOcxbC68iVyeSR2yKiV0tFqZxpO/kY+tam+o6hd3jY3 SyMcAYGM9qwUPzE/jU8xCpgZx0warKQFanGKirI6o9xpo70GlXrViB+oHpTaVjljQoyaAe5K owopaO1Ix4qSxhNFFJTEFFFFMQUUlLQAtJTuppQmOW49qLgMxnpTtuByaXdgccCmEk0AGfSg E54oxTwQnTmgEPXJ44+tHAPH5mtXQrbSmE15rN00dtEPlt4eZZ29B2UerH8Kpt5E90zxp5SF sqgOdo9M1mpp3XYtxatoSppszRRyFCA5+UfxNVy205J32XB8qJATjH3jWzo15ZRzK9xN0GwG tLVP7BtbdLr7Qbi6JysY4jiUev8AeY/kKwVeN+WW/QUoy6bGHq/g9rTQ4NUUmNJjiMOcNLjq Qv8Ad965yO1CjJwzfoP8a6m7uNQ8RzR7vMKABEXvt9vQVBrnh6fT40bBDhRhF5wPetYTnKKj Nq5F4wZy0o2SkDrUeMmrptGVRuXk0R2xLZxx61fOkjRRbII04q5Fbqq75OBUyRIpUttXJxz/ ADrQ1ewsYbi2FrctM4TdNn7qk4wv16k+mQOxrJzTdr2NFG1tCpFC0+12yI+ir3apbpgv7oEG QfePZB6Vp6dBGmmahfteQJNbwYjjdcl3f5VCj1Ayc9sVzb7xGBzt9fWsormd7mt0lYWSZdu0 fdH5k+9Z8rZerEmV69agZRtyetdMEkYTbYwYFNpTQBuIFaGIo5NWJLaSOAPJhc9FPU0xSI3B Tnb0JpsjvNISxJPqaQEZPNWFDQw+Zj5n4X6etXNH06O8vVS5ZktwC0jjqABUl3p89xd4SMxw gAIT0I7GqS5tEQ5K9ijBGUQudp/nUqyY5qRrfyk2A5pPJU4VztyOtJhcsWht5yscxZ4S2XCj 5l46ilkeB7CO2ijBMUpfzScMV7AimJbT6YPta5MRO0OB1OOlRj55JJccHgUnzJ26DSTV0U7o /NioMccGpJ8tIxFQ4NC2L2A0q8AmjPrzRjjg0wG0+MdTTMVMowBQwW4tMY5p2eM0w9alFMKS iimSFFFJTAKWikoAn4ToOajZvzqSTheKh7mhDYUlL2opkhRR2pO9AC5NORsNTKcoBak9hrct SSfugq9KfY/NOhmy0YPIqsfuj3qwCUJC8DFZtaWL66HfWmrw2wEtsUQSYUyEfdHsKzdb8RCe J7S1BKE5LE5Y/U1zKyOEADHGKfBywJ65rkVFRfMxximWYA0g2YJY1N5S26fMMsei1JYErcOw 6iM4rW8K2sF9rB+0xiUBGYBvUdKUpWu3sjpjHRHNPC+/fJ97sKDjqeD7Vf1b/kIzKOBvPArN PJrZaq5DVtC5p1yIZn86NZFKkYbt71XvjH5m+P8ABfSoouHaoT/rfpQo+9cG9CCUHkseT2pn HlnjnNOmOXY96Yo+U1utjF7kRpRwvuTSGl7fjVmQucU8MAgPfPSo+9T26gsuR/EKT2Cx0Olb beBPNgMylhLMgPIiB5FdNqiCDTPKSFDASFjbPIGMj/CsTRGP9qq2eTOIz7qe1b/iVQJUAAA2 9BwKHUSSj1epxTu5nINDlzRqnlPcRbIfLjWNF47sByfzq6FHlE4p1si3Fm4lG4K7Yz9K1guZ 8hTlb3ij94R2geQwKGdgTwCKrMgEROMADNaOANNcgc9M+2azrni1mPvisW7XSOiD5ncxycmk xmj1pe1BsRlcUlSHpTTVITQi8mpKYvBNPpMEIx4plObtTaACjtRQaYgpKU0lABRRR3oEf//Z --------------010806080105020707070105 Content-Type: text/plain; name="test.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test.py" import Image, ImageFilter, ImageEnhance myImage = Image.open('hawaii.jpg') theEnhancer = ImageEnhance.Brightness(myImage) theEnhancedImage = theEnhancer.enhance(1.5); theEnhancedImage.save('hawaiiEnhanced.jpg') --------------010806080105020707070105-- From kevin@cazabon.com Thu Jul 18 01:53:40 2002 From: kevin@cazabon.com (Kevin@Cazabon.com) Date: Wed, 17 Jul 2002 18:53:40 -0600 Subject: [Image-SIG] compressed TIFF images References: <006301c22bef$d6136a90$0503a8c0@ns1.asianet.com> <3D32E4A1.21ABF1BA@fel.tno.nl> Message-ID: <03c801c22df5$8f5401c0$320aa8c0@duallie> While I agree that using lib-tiff directly would be very desirable, the problem mentioned would still exist in most cases. The TIFF format supports a variety of compression methods, however the most common is LZW compression and I assume this is the type he's having problems with. LZW requires licensing, just like GIF does. With PIL being a "free" (as in beer) library on the basic level, you can't include anything that requires a royalty like that. This is also the reason why it can't write GIF files. Fred; do you know if Targa has similar restrictions? TGA format is EASY to write, but PIL only reads it, so I assume this is the case, correct? Kevin. (btw, it's good to see the 'fit' and autocontrast methods in PIL... thanks!) ----- Original Message ----- From: "K Schutte" To: "Indu" Cc: Sent: Monday, July 15, 2002 9:05 AM Subject: Re: [Image-SIG] compressed TIFF images > The Good(TM) method is to add support for the Tiff library to PIL, > similar like JPEG support through the JPEG library. > > I also encountered similar problems using Tiff images (reading 16 bit > unsigned Tiff's in my case with packed compression.) The bad things is > that our solution is proprietary. > > Good luck, > > Klamer > > > Indu wrote: > > > > How can we open a compressed TIFF image using PIL? > > > > Can anyone help me? > > > > Thanks > > Indu > > > > -- > Klamer Schutte, E-mail: Schutte@fel.tno.nl > Electro-Optical Systems, TNO Physics and Electronics Laboratory > Tel: +31-70-3740469 -- Fax: +31-70-3740654 -- Mobile: +31-6-51316671 > > > _______________________________________________ > Image-SIG maillist - Image-SIG@python.org > http://mail.python.org/mailman/listinfo/image-sig > From kevin@cazabon.com Thu Jul 18 01:57:55 2002 From: kevin@cazabon.com (Kevin@Cazabon.com) Date: Wed, 17 Jul 2002 18:57:55 -0600 Subject: [Image-SIG] Low level access References: <200207101605.49647.csx239@coventry.ac.uk> <200207111505.LAA13763@behemoth.lerc.nasa.gov> <200207111812.17671.csx239@coventry.ac.uk> Message-ID: <03d201c22df6$26d60480$320aa8c0@duallie> Ideally I'd love to see the Python Buffer Interface supported for PIL objects... that way you could pass an image to a C/C++ DLL if you wanted pure speed on the raw image data. FRED: PIL must do this internally, is it a tough thing to do externally in a stand-alone DLL? Thanks, Kevin. From a.deuring@satzbau-gmbh.de Thu Jul 18 16:46:59 2002 From: a.deuring@satzbau-gmbh.de (abel deuring) Date: Thu, 18 Jul 2002 17:46:59 +0200 Subject: [Image-SIG] PIL & FH10 eps files Message-ID: <3D36E2F3.49DC208C@satzbau-gmbh.de> Dies ist eine mehrteilige Nachricht im MIME-Format. --------------DA863DCECDE60B2D26FDAE2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi all, it seems that PIL.EpsImagePlugin (version 1.1.3) does not like the headers from EPS files produced by Freehand 10: (1) FH10 writes an empty line after the leading "%!PS-Adobe-2.0 EPSF-1.2", and (2) the line "%ALDOriginalFile:..." raises the exception IOError, "bad EPS header". Neither the regex "split" nor the regex "field" recognize this line. Attached is a fix and an example for FH10 EPS header. Abel --------------DA863DCECDE60B2D26FDAE2B Content-Type: text/plain; charset=us-ascii; name="fh10.eps-header" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fh10.eps-header" %!PS-Adobe-2.0 EPSF-1.2 %%Title: Unbenannt-1 %%Creator: FreeHand 10.0 %%CreationDate: 18.07.2002 16:58 Uhr %%BoundingBox: 0 0 46 28 %%FHPathName:Gans auf Daten eingestellt:Programme:FreeHand 10:German:Unbenannt-1 %ALDOriginalFile:Gans auf Daten eingestellt:Programme:FreeHand 10:German:Unbenannt-1 %ALDBoundingBox: -34 -778 561 63 %%FHPageNum:1 %%DocumentSuppliedResources: procset Altsys_header 4 0 %%ColorUsage: Color %%DocumentProcessColors: Black %%PlateFile: (Black) EPS #98739 100041 %%EndComments --------------DA863DCECDE60B2D26FDAE2B Content-Type: text/plain; charset=us-ascii; name="EpsImagePlugin.py.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="EpsImagePlugin.py.diff" --- EpsImagePlugin.py.orig Sun Mar 10 17:57:39 2002 +++ EpsImagePlugin.py Thu Jul 18 17:16:38 2002 @@ -33,7 +33,7 @@ def o32(i): return chr(i&255) + chr(i>>8&255) + chr(i>>16&255) + chr(i>>24&255) -split = re.compile(r"^%%([^:]*):[ \t]*(.*)[ \t]*$") +split = re.compile(r"^%[%!\w]([^:]*):[ \t]*(.*)[ \t]*$") field = re.compile(r"^%[%!\w]([^:]*)[ \t]*$") def Ghostscript(tile, size, fp): @@ -202,6 +202,10 @@ raise IOError, "bad EPS header" s = fp.readline() + # at leat eps files produced by Freehand 10 may contain empty lines + # in the header: + while len(s) == 1: + s = fp.readline() if s[:1] != "%": break --------------DA863DCECDE60B2D26FDAE2B-- From bh@intevation.de Thu Jul 18 19:18:25 2002 From: bh@intevation.de (Bernhard Herzog) Date: 18 Jul 2002 20:18:25 +0200 Subject: [Image-SIG] PIL & FH10 eps files In-Reply-To: <3D36E2F3.49DC208C@satzbau-gmbh.de> References: <3D36E2F3.49DC208C@satzbau-gmbh.de> Message-ID: <6qfzyg6gsu.fsf@abnoba.intevation.de> abel deuring writes: > hi all, > > it seems that PIL.EpsImagePlugin (version 1.1.3) does not like the > headers from EPS files produced by Freehand 10: (1) FH10 writes an empty > line after the leading "%!PS-Adobe-2.0 EPSF-1.2", and (2) the line > "%ALDOriginalFile:..." raises the exception IOError, "bad EPS header". > Neither the regex "split" nor the regex "field" recognize this line. > Attached is a fix and an example for FH10 EPS header. > > Abel%!PS-Adobe-2.0 EPSF-1.2 > > %%Title: Unbenannt-1 That empty line is part of the output? In that case the EPS file is not really an EPS file because the header doesn't contain the required (for EPS) BoundingBox DSC comment (quoting from the DSC specification): Because header comments are contiguous, any line that does not begin with %X where X is any printable character except space, tab, or newline implicitly denotes the end of the header section. %!PS-Adobe-3.0 %%Title: (Example of Header Comment Termination) ...More header comments... %%DocumentResources: font Sonata %GBDNodeName: smith@atlas.com % This line implicitly denotes the end of the header section. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://www.mapit.de/ From a.deuring@satzbau-gmbh.de Fri Jul 19 11:04:28 2002 From: a.deuring@satzbau-gmbh.de (abel deuring) Date: Fri, 19 Jul 2002 12:04:28 +0200 Subject: [Image-SIG] PIL & FH10 eps files References: <3D36E2F3.49DC208C@satzbau-gmbh.de> <6qfzyg6gsu.fsf@abnoba.intevation.de> Message-ID: <3D37E42C.AD45F61F@satzbau-gmbh.de> Bernhard Herzog wrote: > > abel deuring writes: > > > hi all, > > > > it seems that PIL.EpsImagePlugin (version 1.1.3) does not like the > > headers from EPS files produced by Freehand 10: (1) FH10 writes an empty > > line after the leading "%!PS-Adobe-2.0 EPSF-1.2", and (2) the line > > "%ALDOriginalFile:..." raises the exception IOError, "bad EPS header". > > Neither the regex "split" nor the regex "field" recognize this line. > > Attached is a fix and an example for FH10 EPS header. > > > > Abel%!PS-Adobe-2.0 EPSF-1.2 > > > > %%Title: Unbenannt-1 > > That empty line is part of the output? In that case the EPS file is not yes, it is. At least the Mac version of FH 10 writes such a header. > really an EPS file because the header doesn't contain the required (for > EPS) BoundingBox DSC comment (quoting from the DSC specification): > > Because header comments are contiguous, any line that does not begin > with %X where X is any printable character except space, tab, or > newline implicitly denotes the end of the header section. > > %!PS-Adobe-3.0 > %%Title: (Example of Header Comment Termination) > ...More header comments... > %%DocumentResources: font Sonata > %GBDNodeName: smith@atlas.com > % This line implicitly denotes the end of the header section. Bernhard, you're right. Personally, I would prefer to throw them away, but unfortunately I have to deal with them... So it's perhaps better to write a small filter that fixes the bugs. Abel From lbates@swamisoft.com Fri Jul 19 17:00:49 2002 From: lbates@swamisoft.com (Larry Bates) Date: Fri, 19 Jul 2002 11:00:49 -0500 Subject: [Image-SIG] PIL TIFF to PDF conversion Message-ID: <000a01c22f3d$7673b440$4700a8c0@CC466739A.tsclos01.al.comcast.net> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C22F13.8A7988E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm having problems with a very simple application (see below): #---------------------------- from PIL import Image # # Read in 8.5 x 11 inch TIF invoice scanned at 100 dpi # im=3DImage.open("c:\\test\\invoice.tif") # # Save it in PDF format # im.save("c:\\test\\invoice.pdf","PDF") #---------------------------- The problem is that the PDF that is output by PIL is 11.81 x 15.28 inches in size. If I open the TIF file in PhotoShop it shows 100 dpi, 8.5 x 11 inches. I don't understand what is happening or why. Thanks in advance for any assistance. Regards, Larry Bates ------=_NextPart_000_0007_01C22F13.8A7988E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I'm having problems with a very simple application = (see=20 below):
 
#----------------------------
from PIL import Image
#
# Read in 8.5 x 11 inch TIF invoice scanned at = 100=20 dpi
#
im=3DImage.open("c:\\test\\invoice.tif")
#
# Save it in PDF format
#
im.save("c:\\test\\invoice.pdf","PDF")
#----------------------------
 
The problem is that the PDF that is output by PIL=20 is
11.81 x 15.28 inches in size.  If I open the=20 TIF
file in PhotoShop it shows 100 dpi, 8.5 x 11=20 inches.
 
I don't understand what is happening or = why.
 
Thanks in advance for any assistance.
 
Regards,
Larry Bates
 
 
 
------=_NextPart_000_0007_01C22F13.8A7988E0-- From hancock@ipac.caltech.edu Fri Jul 19 19:33:34 2002 From: hancock@ipac.caltech.edu (Terry Hancock) Date: Fri, 19 Jul 2002 11:33:34 -0700 (PDT) Subject: [Image-SIG] PIL TIFF to PDF conversion In-Reply-To: <000a01c22f3d$7673b440$4700a8c0@CC466739A.tsclos01.al.comcast.net> Message-ID: Evidently PIL is assuming 72 dpi, which is a common default. So it's not preserving the DPI information when you process it. I flipped through the manual just now, but didn't find out if you can set the DPI for saving to PDF. You can use im.resize() to scale to the desired size for 72dpi, but you'll lose some resolution compared to the original. (Hopefully there's a better answer) Terry -- ------------------------------------------------------ * Terry Hancock -- Science Software Support -- IPAC * * http://www.ipac.caltech.edu/ * * hancock@ipac.caltech.edu * ------------------------------------------------------ On Fri, 19 Jul 2002, Larry Bates wrote: > I'm having problems with a very simple application (see below): > > #---------------------------- > from PIL import Image > # > # Read in 8.5 x 11 inch TIF invoice scanned at 100 dpi > # > im=Image.open("c:\\test\\invoice.tif") > # > # Save it in PDF format > # > im.save("c:\\test\\invoice.pdf","PDF") > #---------------------------- > > The problem is that the PDF that is output by PIL is > 11.81 x 15.28 inches in size. If I open the TIF > file in PhotoShop it shows 100 dpi, 8.5 x 11 inches. > > I don't understand what is happening or why. > > Thanks in advance for any assistance. > > Regards, > Larry Bates From b.maryniuk@forbis.lt Mon Jul 22 11:57:49 2002 From: b.maryniuk@forbis.lt (Bo M. Maryniuck) Date: Mon, 22 Jul 2002 12:57:49 +0200 Subject: [Image-SIG] HELP ME !!! In-Reply-To: <3d.214610f5.2a672ecf@aol.com> References: <3d.214610f5.2a672ecf@aol.com> Message-ID: <200207221257.49449.b.maryniuk@forbis.lt> On Wednesday 17 July 2002 22:34, GilmadskilsWilis@aol.com wrote: > File "D:\PYTHON22\PIL \Image.py", line 37, in __getattr__ > raise ImportError, "The _imaging C module is not installed" > ImportError: The _imaging C module is not installed Your PIL is not fully installed (seems to be). Just INSTALL imaging modul= e. --=20 Sincerely yours, Bogdan M. Maryniuck "How should I know if it works? That's what beta testers are for. I onl= y coded it." (Attributed to Linus Torvalds, somewhere in a posting) From joec@mill.co.uk Mon Jul 22 12:50:12 2002 From: joec@mill.co.uk (Joe Connellan) Date: Mon, 22 Jul 2002 12:50:12 +0100 Subject: [Image-SIG] bit decoder - Cineon Message-ID: <3D3BF174.9606CCCE@mill.co.uk> Hi, I'm writting (or trying to) a decoder for the 10bit Cineon file format. I've got it recognising the format and getting width/height, etc from it. Now for the image data. The Cineon format stores the 3 channels (rgb) in 32bits with two bits of waste ie: (R10bits)(G10bits)(B10bits)(2) is it possible to decode this using either the raw or bit decoders? the bit decoder allows for line bit padding but I don't think pixel bit padding (for the 2bits at the end). also if I set up the tile (in cineonImagePlugin.py - the decoder) like so: self.tile = [ ("bit", (0, 0) + self.size, offset, (32, 0, 1, 0, 1)) ] when I try to do a tostring: self.img[0].tostring("bit", 32, 0, 1, 0, 1) I get the following: File "imageViewer.py", line 84, in loadImage self.img[0].tostring("bit", 32, 0, 1, 0, 1) File "C:\Python22\PIL\Image.py", line 351, in tostring self.load() File "C:\Python22\PIL\ImageFile.py", line 140, in load d = Image._getdecoder(self.mode, d, a, self.decoderconfig) File "C:\Python22\PIL\Image.py", line 241, in _getdecoder return apply(decoder, (mode,) + args + extra) ValueError: bad image mode Any ideas? Joe From anders@dahnielson.com Mon Jul 22 13:02:59 2002 From: anders@dahnielson.com (Anders Dahnielson) Date: 22 Jul 2002 14:02:59 +0200 Subject: [Image-SIG] bit decoder - Cineon In-Reply-To: <3D3BF174.9606CCCE@mill.co.uk> References: <3D3BF174.9606CCCE@mill.co.uk> Message-ID: <1027339380.1171.7.camel@linuxbox> > is it possible to decode this using either the raw or bit decoders? Isn't Cineon storing color data logarithmically? That need to be "stretched" out to linear form while decoding to be to any use?? -- Anders Dahnielson From indu@swamicyber.com Wed Jul 24 03:58:32 2002 From: indu@swamicyber.com (Indu) Date: Wed, 24 Jul 2002 08:28:32 +0530 Subject: [Image-SIG] PDF manipulation using PythonMagick Message-ID: <003f01c232be$01417fc0$0503a8c0@ns1.asianet.com> This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C232EC.188BC900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have installed ImageMagick-5.4.8.tar.gz, PythonMagick-0.1e.win32.exe = and ImageMagick-5.4.6-win32libs.zip.=20 When I annotate the image in a pdf file using the draw method the = resulting image is blurred. Can anybody find a solution to it?=20 Please tell me if there is any link to the PythonMagick documentation. Thanks Indu ------=_NextPart_000_0038_01C232EC.188BC900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have installed = ImageMagick-5.4.8.tar.gz,=20 PythonMagick-0.1e.win32.exe and ImageMagick-5.4.6-win32libs.zip.=20
When I annotate the image in a pdf file = using the=20 draw method the resulting image is blurred. Can anybody find a = solution to=20 it?
 
Please tell me if there is any link to the PythonMagick=20 documentation.
 
Thanks
Indu
------=_NextPart_000_0038_01C232EC.188BC900-- From Maik Wojcieszak" (added by mailhost.wobe-team.de) Hi, I'm a beginner to PIL and have some trouble loading a hex encoded image into an image object. The image is an 8bit grayscale hexencoded string. How do I have to set the modes and options to read this data with the fromstring method ? thanks maik From richard-boyd@worldnet.att.net Fri Jul 26 17:13:03 2002 From: richard-boyd@worldnet.att.net (Richard Boyd) Date: Fri, 26 Jul 2002 09:13:03 -0700 Subject: [Image-SIG] urlopen for webpage image file Message-ID: <5.1.0.14.0.20020726085749.00a9c150@postoffice.worldnet.att.net> --=====================_7670769==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I need to dynamically access a webpage and find the largest graphic used on that page, so I tried the following ... ----------------------------- import Image import urllib filename = "http://www.python.org/pics/PythonPoweredSmall.gif" filelocation = urllib.urlopen(filename) img = Image.open(filelocation) img.size ----------------------------- But I got the an error msg ... ------------error msg----------------- Traceback (most recent call last): File "", line 1, in ? File "F:\Dev\Python22\Lib\site-packages\PIL\Image.py", line 955, in open fp.seek(0) AttributeError: addinfourl instance has no attribute 'seek' --------------------------------- I browsed the Python docs and found the following ... --------------------------------- 11.4 urllib -- Open arbitrary resources by URL This module provides a high-level interface for fetching data across the World Wide Web. In particular, the urlopen() function is similar to the built-in function open(), but accepts Universal Resource Locators (URLs) instead of filenames. Some restrictions apply -- it can only open URLs for reading, and no seek operations are available. ....... (It is not a built-in file object, however, so it can not be used at those few places where a true built-in file object is required.) --------------------------------- I then noticed that in the PIL Manual it says for Image.open() that, "You can use either a string (giving the filename) or a file object. In the latter case, the file object must implement read, seek, and tell methods, and be opened in binary mode." Since urllib.urlopen() does not provide a seek operation ... I get the error msg above. Is there a way to use PIL image functions to access the size info of a web graphic image file ... without downloading (too time consuming) the whole image? Thanx. -richard- P.S. What I had to do was switch to REBOL [www.rebol.com]. It is very simple in REBOL ... print size? http://www.python.org/pics/PythonPoweredSmall.gif returns the size ... 361 --=====================_7670769==_.ALT Content-Type: text/html; charset="us-ascii" I need to dynamically access a webpage and find the largest graphic used on that page, so I tried the following ...
-----------------------------
import Image
import urllib

filename = "http://www.python.org/pics/PythonPoweredSmall.gif"
filelocation = urllib.urlopen(filename)
img = Image.open(filelocation)
img.size
-----------------------------


But I got the an error msg ...
------------error msg-----------------
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "F:\Dev\Python22\Lib\site-packages\PIL\Image.py", line 955, in open
fp.seek(0)
AttributeError: addinfourl instance has no attribute 'seek'
---------------------------------


I browsed the Python docs and found the following ...
---------------------------------
11.4 urllib -- Open arbitrary resources by URL

This module provides a high-level interface for fetching data across the World Wide Web.
In particular, the urlopen() function is similar to the built-in function open(),
but accepts Universal Resource Locators (URLs) instead of filenames.
Some restrictions apply -- it can only open URLs for reading, and no seek operations
are available.
.......
(It is not a built-in file object, however, so it can not be used at those few places
where a true built-in file object is required.)
---------------------------------


I then noticed that in the PIL Manual it says for Image.open() that, "You can use either a string (giving the filename) or a file object. In the latter case, the file object must implement read, seek, and tell methods, and be opened in binary mode."

Since urllib.urlopen() does not provide a seek operation ... I get the error msg above.

Is there a way to use PIL image functions to access the size info of a web graphic image file ... without downloading (too time consuming) the whole image?

Thanx.

-richard-


P.S.    What I had to do was switch to REBOL [www.rebol.com]. It is very simple in REBOL ...
        print size? http://www.python.org/pics/PythonPoweredSmall.gif

returns the size ...
        361
--=====================_7670769==_.ALT-- From lbates@syscononline.com Fri Jul 26 22:43:45 2002 From: lbates@syscononline.com (Larry Bates) Date: Fri, 26 Jul 2002 16:43:45 -0500 Subject: [Image-SIG] PIL and multi-page images Message-ID: <2C1A673A677CD311988E00902773A6DD35C98E@qbert.syscon-computers.com> I have some multi-page .DCX files coming from network fax (Castelle Faxpress) that I would like to convert to .TIF and process. Can PIL handle multi-page .DCX or .TIF images? I just can't seem to find anything in the documentation that tells how to handle these files. Thanks in advance, Larry Bates From fredrik@pythonware.com Sat Jul 27 13:10:12 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sat, 27 Jul 2002 14:10:12 +0200 Subject: [Image-SIG] urlopen for webpage image file References: <5.1.0.14.0.20020726085749.00a9c150@postoffice.worldnet.att.net> Message-ID: <008801c23566$93083480$ced241d5@hagrid> Richard Boyd wrote: > I need to dynamically access a webpage and find the largest > graphic used on that page, so I tried the following ... largest as in "number of pixels", or "number of bytes"? if you want to get the size in bytes, you don't need to decode the image at all; just grab the data, and use the len() function to get the number of bytes. file = urllib.urlopen(url) print len(file.read()) if you don't want to load the entire image, check the header instead: file = urllib.urlopen(uri) print file.headers.get("content-length") file.close() urllib always uses the HTTP GET method; to be a bit nicer, you can use the HTTP HEAD method instead. this helper shows you how to do that: import httplib, urlparse def getsize(uri): # check the uri scheme, host, path, params, query, fragment = urlparse.urlparse(uri) if scheme != "http": raise ValueError("only supports HTTP requests") if not path: path = "/" if params: path = path + ";" + params if query: path = path + "?" + query # make a http HEAD request h = httplib.HTTP(host) h.putrequest("HEAD", path) h.putheader("Host", host) h.endheaders() status, reason, headers = h.getreply() h.close() return headers.get("content-length") print getsize("http://www.pythonware.com/images/small-yoyo.gif") ::: if you want to get the size in pixels, use the ImageFile.Parser or ImageFileIO modules (or read the whole thing, and wrap it in a StringIO object). the following helper returns both the size of the file, and the size of the image, usually without loading more than 1k or so. import urllib import ImageFile def getsizes(uri): # get file size *and* image size (None if not known) file = urllib.urlopen(uri) size = file.headers.get("content-length") if size: size = int(size) p = ImageFile.Parser() while 1: data = file.read(1024) if not data: break p.feed(data) if p.image: return size, p.image.size break file.close() return size, None print getsizes("http://www.pythonware.com/images/small-yoyo.gif") > What I had to do was switch to REBOL [www.rebol.com]. It is very > simple in REBOL ... > > print size? http://www.python.org/pics/PythonPoweredSmall.gif > > returns the size ... > 361 oh, you meant bytes. why didn't you say so from the start? ;-) (are you sure that size? doesn't load the whole thing, btw?) From fredrik@pythonware.com Sat Jul 27 13:18:54 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sat, 27 Jul 2002 14:18:54 +0200 Subject: [Image-SIG] PIL and multi-page images References: <2C1A673A677CD311988E00902773A6DD35C98E@qbert.syscon-computers.com> Message-ID: <008e01c23567$c95b6970$ced241d5@hagrid> Larry Bates wrote: > I have some multi-page .DCX files coming from network > fax (Castelle Faxpress) that I would like to convert > to .TIF and process. > > Can PIL handle multi-page .DCX or .TIF images? I just > can't seem to find anything in the documentation that > tells how to handle these files. the DCX decoder implements the seek() method, so in theory, all you have to do is to loop over the image object until you get an EOFError (or IndexError?) exception: page = 0 try: while 1: im.seek(page) do something with im page = page + 1 except EOFError: pass (note that seek mutates the image; if "do something" involves e.g. appending the page image to a list, make sure you to do im.copy() instead of appending the im object itself) (also note that I haven't seen a DCX file in ages. if you can create a multipage sample, it would be a welcome addition to the set of PIL test images...) creating multipage TIFF files is a bit harder; there's no good support for that out of the box. if you're on Linux/Unix, you can use PIL to split the DCX into sub pages, and use tiffcp to merge them into a multipage TIFF. From lbates@syscononline.com Mon Jul 29 22:44:03 2002 From: lbates@syscononline.com (Larry Bates) Date: Mon, 29 Jul 2002 16:44:03 -0500 Subject: [Image-SIG] Python, PIL and barcode recognition Message-ID: <2C1A673A677CD311988E00902773A6DD35C9A2@qbert.syscon-computers.com> Has anyone used Python and PIL for barcode recognition? I have a project where I must take pages that have been scanned, extract a barcode from the first page of each document and extract the code from the barcode. Program will then use this information to file the document into an appropriate folder. Thanks in advance for any advice. Regards, Larry Bates