Re: [Image-SIG] resizing an image with alphachannel: dirty edges
On Thu, Nov 12, 2009 at 3:59 PM, Ivan Elchin ivanger...@gmail.com wrote:
I have a problem, when i resizing an image with alphachannel.
You can try converting your image to RGBa (premultiplied alpha),
resizing it, then converting back to RGBA. The problem here is that
there are dirty pixels with 0 alpha, and they get interpolated like
everything else. On my PIL this works:
from PIL import Image
im = Image.open(sega.png)
im = im.convert(RGBa)
cur_width, cur_height = im.size
new_width, new_height = (200, 200)
if not new_width == 0 and not new_height == 0:
ratio = min(float(new_width)/cur_width,
float(new_height)/cur_height)
else:
if new_width == 0:
ratio = float(new_height)/cur_height
else:
ratio = float(new_width)/cur_width
new_dimensions = (int(round(cur_width*ratio)),
int(round(cur_height*ratio)))
new_im = im.resize(new_dimensions, Image.ANTIALIAS)
new_im = new_im.convert(RGBA)
new_im.save('rez.png')
Though my PIL has many modifications, I'm not sure if RGBA-RGBa-RGBA
is implemented in vanilla 1.1.6. (after checking) Ah, yes, it's not.
Though you can try recompiling PIL with this patch:
http://git.kitsu.ru/patched/pil.git?a=commitdiff;h=b8f1c572430b06b5d4294fb2bf29327275120554
___
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] PIL 1.1.6 ImageFile.Parser destroys data for PngImagePlugin
Hi Fredrik, On Wed, Nov 4, 2009 at 6:43 PM, Fredrik Lundh fred...@pythonware.com wrote: Thanks for the detailed analysis. The fix in 1.1.7 is slightly different from the one you propose: http://hg.effbot.org/pil-2009-raclette/changeset/fe4688f15fed/ Not sure why the code considers it important to close the file at that point; I'll take another look at a look at the code and the history of that file when I find the time. I looked at your changeset, and wonder why do you call image.load() in finally? If Image.open fails, then self.image.load will also fail, masking the original exception with attribute error. I don't remember what I posted back then, but my patch was a little different: http://git.kitsu.ru/patched/pil.git?a=commitdiff;h=943d371a903bf2af8ebc6b3be908bcdd6f8d0964 ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
[Image-SIG] ImageFile._ParserFile
Hi all, I've been looking at ImageFile._ParserFile (used by ImageFile.Parser), and suddenly thought that all it does is reimplement reading part of StringIO. Why is it needed? Of course using StringIO.StringIO wouldn't make much sense in terms of performance/etc, but cStringIO.StringIO (with the usual try/except) might make sense. What do you think? ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Patch: Better compression of png-images
On Tue, Jul 28, 2009 at 2:16 PM, Flynn Marquardtp...@flynnux.de wrote: I never got corrupt images, but I applied the attached patch anyway. Well, it seemed that the bigger the image, the bigger the chance for corruption. In my case (with images 800x600 and the like in size) it was something like 2 corrupted images out of 20. I didn't even attribute it to Z_NO_FLUSH at first, thinking there was strange problems in my conversion logic, until I saw that ACDSee was saying corrupt image in the status bar. P.S.: There is another size bloating feature in PIL: all palettes are stored full size (usually 256 entries) instead only storing the real used colors. This especially is a problem with pictures with only a few colors, where then the palette is much bigger than the compressed data. Do you see any chance to fix this? I took alook, but it seems not so easy. Well, it certainly doesn't affect me. :) 1.1.6 doesn't seem to support partial palettes anyway, you can only assign all 256 colors, and remapping colors would be crazy (since I use PIL for game localizations mostly, I often need the *exact* palette [which is often separate and shared among several images in the game], and wouldn't want PIL to do anything fancy with it). Besides, that's under 1k anyway, you should definitely use pngcrush if sizes like that matter to you. ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Suggestion to use tcl stubs when building PIL
On Tue, Jul 14, 2009 at 11:48 PM, Sridhar
Ratnakumarsridh...@activestate.com wrote:
Jeff Hobbs pointed out that using tcl stubs is the correct thing to do in
order to ensure compatibility with different versions of Tcl/Tk libraries
installed. Since this is not an issue with python.org's Python (whose 2.5
version comes with Tcl/Tk 8.4), I do not consider this a severe issue,
however, having this fixed will at least make PIL work against some of the
custom Python installations (of which ActivePython is just one of them).
Actually, good idea. Here's a patch:
http://git.kitsu.ru/patched/pil.git?a=commitdiff;h=34b332238afbdd22a27f9e66905df60f8856e74c
(just ignore setup-df-mingw.py and setup-df.py)
Or here, if gmail doesn't screw it up:
diff --git a/Tk/tkImaging.c b/Tk/tkImaging.c
index 5e37d05..3ddace5 100644
--- a/Tk/tkImaging.c
+++ b/Tk/tkImaging.c
@@ -240,6 +240,12 @@ PyImagingPhotoGet(ClientData clientdata,
Tcl_Interp* interp,
void
TkImaging_Init(Tcl_Interp* interp)
{
+#ifdef USE_TCL_STUBS
+Tcl_InitStubs(interp, TCL_VERSION, 0);
+#endif
+#ifdef USE_TK_STUBS
+Tk_InitStubs(interp, TK_VERSION, 0);
+#endif
Tcl_CreateCommand(interp, PyImagingPhoto, PyImagingPhotoPut,
(ClientData) 0, (Tcl_CmdDeleteProc*) NULL);
Tcl_CreateCommand(interp, PyImagingPhotoGet, PyImagingPhotoGet,
diff --git a/setup.py b/setup.py
index aee3d2d..2a64576 100644
--- a/setup.py
+++ b/setup.py
@@ -211,6 +211,7 @@ class pil_build_ext(build_ext):
class feature:
zlib = jpeg = tiff = freetype = tcl = tk = None
+tclstub = tkstub = False
feature = feature()
if find_library_file(self, z):
@@ -250,11 +251,23 @@ class pil_build_ext(build_ext):
if _tkinter:
# the library names may vary somewhat (e.g. tcl84 or tcl8.4)
version = TCL_VERSION[0] + TCL_VERSION[2]
-if find_library_file(self, tcl + version):
+if find_library_file(self, tclstub + version):
+feature.tcl = tclstub + version
+feature.tclstub = True
+elif find_library_file(self, tclstub + TCL_VERSION):
+feature.tcl = tclstub + TCL_VERSION
+feature.tclstub = True
+elif find_library_file(self, tcl + version):
feature.tcl = tcl + version
elif find_library_file(self, tcl + TCL_VERSION):
feature.tcl = tcl + TCL_VERSION
-if find_library_file(self, tk + version):
+if find_library_file(self, tkstub + version):
+feature.tk = tkstub + version
+feature.tkstub = True
+elif find_library_file(self, tkstub + TCL_VERSION):
+feature.tk = tkstub + TCL_VERSION
+feature.tkstub = True
+elif find_library_file(self, tk + version):
feature.tk = tk + version
elif find_library_file(self, tk + TCL_VERSION):
feature.tk = tk + TCL_VERSION
@@ -326,9 +339,15 @@ class pil_build_ext(build_ext):
))
feature.tcl = feature.tk = 1 # mark as present
elif feature.tcl and feature.tk:
+tkdefs = []
+if feature.tclstub:
+tkdefs.append((USE_TCL_STUBS,None))
+if feature.tkstub:
+tkdefs.append((USE_TK_STUBS,None))
exts.append(Extension(
_imagingtk, [_imagingtk.c, Tk/tkImaging.c],
-libraries=[feature.tcl, feature.tk]
+libraries=[feature.tcl, feature.tk],
+define_macros=tkdefs
))
if os.path.isfile(_imagingmath.c):
___
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Patch: Better compression of png-images
On Wed, Jul 22, 2009 at 1:34 PM, Flynn Marquardtp...@flynnux.de wrote: Reverting this to: err = deflate(context-z_stream, Z_NO_FLUSH); /* FIXME: temporary workaround for problem with recent versions of zlib -- 990709/fl */ // err = deflate(context-z_stream, Z_SYNC_FLUSH); improves the compression (close) to the desired optimum. I think the mentioned bug in zlib is fixed, it is ten years ago. No, it appears it is not. I tried working with PIL compiled with Z_NO_FLUSH and several hours later I found that it rarely generates corrupt png images. And this is with zlib 1.2.3, so it appears it is either not fixed, or there is something else going on... ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Patch: Better compression of png-images
Hi again,
I found what was the real problem with Z_NO_FLUSH. The code was only
checking that it ran out of output buffer, but when it does it can
usually mean that not all input was deflated. However, when it enters
ZipEncode next time, the data that was not deflated in the previous
round is forgotten and discarded (by overwriting next_in), thus it was
making holes in dicompressed data, which turned into corrupt png
images. The following patch (I hope) fixes it properly:
http://git.kitsu.ru/patched/pil.git?a=commitdiff;h=3f199f00ec63237ad3bf2d8895a2e16605c8c08a
diff --git a/libImaging/ZipEncode.c b/libImaging/ZipEncode.c
index 11e000c..e2480d3 100644
--- a/libImaging/ZipEncode.c
+++ b/libImaging/ZipEncode.c
@@ -69,6 +69,8 @@ ImagingZipEncode(Imaging im, ImagingCodecState
state, UINT8* buf, int bytes)
context-z_stream.zalloc = (alloc_func)0;
context-z_stream.zfree = (free_func)0;
context-z_stream.opaque = (voidpf)0;
+ context-z_stream.next_in = 0;
+ context-z_stream.avail_in = 0;
err = deflateInit2(context-z_stream,
/* compression level */
@@ -103,6 +105,27 @@ ImagingZipEncode(Imaging im, ImagingCodecState
state, UINT8* buf, int bytes)
/* Setup the destination buffer */
context-z_stream.next_out = buf;
context-z_stream.avail_out = bytes;
+if (context-z_stream.next_in context-z_stream.avail_in 0) {
+ /* We have some data from previous round, deflate it first */
+ err = deflate(context-z_stream, Z_NO_FLUSH);
+
+ if (err 0) {
+ /* Something went wrong inside the compression library */
+ if (err == Z_DATA_ERROR)
+ state-errcode = IMAGING_CODEC_BROKEN;
+ else if (err == Z_MEM_ERROR)
+ state-errcode = IMAGING_CODEC_MEMORY;
+ else
+ state-errcode = IMAGING_CODEC_CONFIG;
+ free(context-paeth);
+ free(context-average);
+ free(context-up);
+ free(context-prior);
+ free(context-previous);
+ deflateEnd(context-z_stream);
+ return -1;
+ }
+}
for (;;) {
@@ -237,12 +260,7 @@ ImagingZipEncode(Imaging im, ImagingCodecState
state, UINT8* buf, int bytes)
context-z_stream.next_in = context-output;
context-z_stream.avail_in = state-bytes+1;
- /* err = deflate(context-z_stream, Z_NO_FLUSH); */
-
-/* FIXME: temporary workaround for problem with recent
- versions of zlib -- 990709/fl */
-
- err = deflate(context-z_stream, Z_SYNC_FLUSH);
+ err = deflate(context-z_stream, Z_NO_FLUSH);
if (err 0) {
/* Something went wrong inside the compression library */
___
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Announcing my PIL repository
On Mon, Sep 8, 2008 at 5:28 PM, Kent Tenney [EMAIL PROTECTED] wrote: Ah, I found what you are talking about. There is a patch by Lowell Alleman, who posted it to this list on 23 February 2007, and it's a pure-python patch. So, no, this was not my patch. :) +1 to preserving PngInfo by default. Why would you want to do so by default? If you want to have text chunks (or any other chunks) you can use PngInfo yourself: pnginfo = PngInfo() pnginfo.add_text(blah, some value) pnginfo.add_text(another, some other value, zip=1) im.save(filename.png, pnginfo=pnginfo) Other than that text chunks are currently exposed via im_info dictionary, which cannot be used for generating tEXt chunks as it is (this dictionary has other keys that have nothing to do with text chunks, and any backwards compatible solution would have to either be guesswork, which is -1 by me, or a separate set/dictionary containing a set of keys that are text chunks, and maybe a flag whether it was tEXt or zTXt, which is not ideal either). In what situations do you find it useful so preserve text tags by default? ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
[Image-SIG] Announcing my PIL repository
Hello, fellow Image-SIG subscribers, PIL 1.1.6 has been released almost two years ago. And as some of you may remember, I have sent several patches to this list since then, but there hasn't been any reply to my emails from developers for some reason, and I don't even know if my patches are accepted or not, if they require any work, etc. Anyway, previously my PIL branch was part of a bigger repository that I couldn't open to everyone, but now I have found a way to split it into a separate repository (using bzr-svn), so everyone can look at it if they want to: svn://kitsu.ru/pil/trunk Many revisions wouldn't be of any interest to anybody (they just fiddle with setup scripts), but there are some features (I haven't sent to this list yet) that might be interesting to some of you who do raw image data processing and use Image.fromstring and Image.tostring heavily: - Add P;4R raw type, where high and low 4-bits are swapped. - Added RGB to RGBa dummy conversion, plus added BGR;15 and BGR;16 packing code. - Added a very simple RGBa-RGBA conversion And of course it includes all the patches I sent to this list. Binaries for Python 2.4 and Python 2.5 on Windows are also available: http://kitsu.ru/pil The are built using mingw (gcc 4.3.0) and are linked against jpeg-6b, tiff-3.8.2, freetype-2.3.7 and ActiveTcl 8.4.19.1. P.S. Please let me know if there is anything else missing. P.P.S. And I hope that PIL is not dead and we will see some releases in the future. Almost two years without any new release and without any public repository to watch for is very tough. :( ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] DDS support
Hi Philippe, I personally use NVidia's readdxt and nvdxt to convert to/from .tga and then use PIL to open the image and do further processing. You can download it here: http://developer.nvidia.com/object/nv_texture_tools.html Best regards, Alexey. On 7/25/07, Philippe Deschamps [EMAIL PROTECTED] wrote: Is there any plans for DDS support in the foreseeable future or is there any tool or hack out there to handle DDS images with python? Thank you. -- Quemadmodum gladius neminem occidit, occidentis telum est. ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
[Image-SIG] Support for writing tga images of different orientations
Hi everyone, Another patch (against my tga saving patch) that I'm not sure anyone needs or appreciates: Index: PIL/TgaImagePlugin.py === --- PIL/TgaImagePlugin.py (revision 284) +++ PIL/TgaImagePlugin.py (revision 331) @@ -100,6 +100,8 @@ else: raise SyntaxError, unknown TGA orientation +self.info[orientation] = orientation + if imagetype 8: self.info[compression] = tga_rle @@ -163,6 +165,15 @@ else: colormapfirst, colormaplength, colormapentry = 0, 0, 0 +if im.mode == RGBA: +flags = 8 +else: +flags = 0 + +orientation = im.info.get(orientation, -1) +if orientation 0: +flags = flags | 0x20 + fp.write(\000 + chr(colormaptype) + chr(imagetype) + @@ -174,12 +185,12 @@ o16(im.size[0]) + o16(im.size[1]) + chr(bits) + - chr(0x20)) + chr(flags)) if colormaptype: fp.write(im.im.getpalette(RGB, BGR)) -ImageFile._save(im, fp, [(raw, (0,0)+im.size, 0, (rawmode, 0, 1))]) +ImageFile._save(im, fp, [(raw, (0,0)+im.size, 0, (rawmode, 0, orientation))]) # # ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
[Image-SIG] Problem with rgb-bgr15 convertion
Hi all, I had to save images in BGR;15 format and suddenly found that image quality unexpectedly and quickly degraded during convertions. Here's the patch that fixes this problem: Index: libImaging/Convert.c === --- libImaging/Convert.c(revision 277) +++ libImaging/Convert.c(working copy) @@ -208,7 +208,7 @@ UINT16* out = (UINT16*) out_; for (x = 0; x xsize; x++, in += 4) *out++ = -UINT16)in[0])8)0x7c00) + +UINT16)in[0])7)0x7c00) + UINT16)in[1])2)0x03e0) + UINT16)in[2])3)0x001f); } ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Installing PIL1.1.x With Python 2.5 In FreeBSD6.2 Failture.
Hi bbenyu, I haven't been working with unixes for a while, but I suspect your problem might be that you build shared version of libjpeg and /usr/local/jpeg-6b/lib is not on your LDPATH (or whatever variable is there for dynamic libraries search path). Try configuring libjpeg with --disable-shared --enable-static. On 5/7/07, bbenyu [EMAIL PROTECTED] wrote: HI all: Can you tell me what error with my installation ? I order following steps install my PIL , but final it was failture. 1、download and install the jpegsrc-6b.tar.gz from ijg.org fetch ... tar -zxf jpegsrc-6b.tar.gz cd jpeg-6b ./confgiure --prefix=/usr/local/jpeg-6b make make install ( In fact i make bin, man, man1 directoies manually) 2、download and install the PIL1.1.6 from http://www.pythonware.com/products/pil/index.htm fetch... tar -zxf Imaging-1.1.6.tar.gz cd Imaging-1.1.6 vi setup.py and change the jpeg_root value to /usr/local/jpeg-6b running python setup.py build_ext -i that shows have supported the jpeg tip. went on running python setup.py install All steps was successfuly not got any errors. When i upload the JPEG fromat picture into Django 0.96 admin ,i got the error: decoder jpeg not available /usr/local/python/lib/python2.5/site-packages/PIL/Image.py in _getdecoder, line 375 my system environment is: Freebsd 6.2 , python2.5, Django0.96 Thanks ! bbenyu 2007-05-07 ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Help with PIL, Imagemagick Composite function in PIL?
On 4/10/07, César Pérez [EMAIL PROTECTED] wrote: Hi, I am new to this list but and i have a small problem with PIL. I am looking for a function that works like composite does in imagemagick. [..snip..] from PIL import Image dtop = Image.open(dtop.png) frame = Image.open(frame.png) dtop.paste(frame,(0,0),frame) dtop.save(test.png) I tried every form of paste but I always get this result or worst. The problem you have happens because alpha channel of images *also* gets composited using the mask you specified. To do it right you actually need to split image, save target image alpha channel and after compositing merge it back using original alpha channel: from PIL import Image dtop = Image.open(dtop.png) frame = Image.open(frame.png) assert dtop.mode == RGBA r,g,b,a = dtop.split() dtop = Image.merge(RGB, (r,g,b)) dtop.paste(frame,(0,0),frame) r,g,b = dtop.split() dtop = Image.merge(RGBA, (r,g,b,a)) dtop.save(test.png) Best regards, Alexey. ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
