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 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
Re: [Image-SIG] resizing an image with alphachannel: dirty edges
On Thu, Nov 12, 2009 at 3:59 PM, Ivan Elchin 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
[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 Marquardt 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] 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] Patch: Better compression of png-images
On Wed, Jul 22, 2009 at 1:34 PM, Flynn Marquardt 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] Suggestion to use tcl stubs when building PIL
On Tue, Jul 14, 2009 at 11:48 PM, Sridhar
Ratnakumar 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] 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
Re: [Image-SIG] Announcing my PIL repository
On Sun, Sep 7, 2008 at 5:42 PM, Pander <[EMAIL PROTECTED]> wrote: > Thanks for your work. Did you get any replies from the original authors? Well, It's just that nobody replied to my patch emails. They went to the list completely silently, and that felt a little bit odd. :-/ > Attached you will find a contribution from my side. I hope it can find > its way into PIL. Please review the code and report back any issues you > might encounter. I'm afraid you might have misunderstood me. I don't have anything to do with PythonWare or Secret Labs AB, so I absolutely can't decide what goes and what doesn't go into PIL. :-/ As for the review I see at least some problems with your code: 1) It's too specialized. I would recommend, if possible, splitting image generation and caching code into different functions, so that one returns unsaved images and the other checks file cache and in case of a cache-miss uses the first one and saves it on disk. 2) You hard-code text to be str in utf-8 encoding. Even worse, different functions expect different things (for example, getWidth[Height] expects a ascii/unicode string, but generateLabel expects utf-8 string), you even make the mistake of incorrectly calling them in your own code. Just make users call your functions with ascii/unicode strings and convert to unicode if you really need to, don't special-case on utf-8 or any other encoding. ~ Alexey ___ 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] problem about color about some jpeg
Just in case, attaching Kevin's patch as unified diff:
Index: JpegImagePlugin.py
===
--- JpegImagePlugin.py (revision 207)
+++ JpegImagePlugin.py (revision 208)
@@ -32,7 +32,7 @@
__version__ = "0.5"
import array, string
-import Image, ImageFile
+import Image, ImageFile, ImageChops
def i16(c,o=0):
return ord(c[o+1]) + (ord(c[o])<<8)
@@ -270,8 +270,11 @@
handler(self, i)
if i == 0xFFDA: # start of scan
rawmode = self.mode
-if self.mode == "CMYK":
-rawmode = "CMYK;I"
+# patch by Kevin Cazabon to comment this out -
nobody should be using Photoshop 2.5 any more (and it breaks newer
versions)
+# CMYK images are still inverted, we'll fix that
just before returning.
+#if self.mode == "CMYK" and self.info.has_key("adobe"):
+#rawmode = "CMYK;I" # Photoshop 2.5 is broken!
+
self.tile = [("jpeg", (0,0) + self.size, 0, (rawmode, ""))]
# self.__offset = self.fp.tell()
break
@@ -282,6 +285,10 @@
else:
raise SyntaxError("no marker found")
+# patch by Kevin Cazabon to re-invert CMYK JPEG files
+if self.mode == "CMYK":
+self.im = ImageChops.invert(self).im
+
def draft(self, mode, size):
if len(self.tile) != 1:
@@ -378,7 +385,7 @@
"RGB": "RGB",
"RGBA": "RGB",
"RGBX": "RGB",
-"CMYK": "CMYK;I",
+"CMYK": "CMYK",
"YCbCr": "YCbCr",
}
@@ -406,6 +413,10 @@
dpi[0], dpi[1]
)
+if im.mode == "CMYK":
+# invert it so it's handled correctly in Photoshop/etc. -
Kevin Cazabon.
+im = ImageChops.invert(im)
+
ImageFile._save(im, fp, [("jpeg", (0,0)+im.size, 0, rawmode)])
def _save_cjpeg(im, fp, filename):
Best regards,
Alexey.
JpegImagePlugin-kevin-cmyk.patch
Description: Binary data
___
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] PIL ImageGrab clipboard block
On 4/14/07, Ole Trenner <[EMAIL PROTECTED]> wrote:
> Hi List,
>
> I'm currently using the ImageGrab module of PIL for a small image upload
> client. I've noticed that the ImageGrab.grabclipboard() method seems to
> somehow block the clipboard.
This is a bug, you can use this patch to fix that:
diff -ruN Imaging-1.1.6-orig/display.c Imaging-1.1.6/display.c
--- Imaging-1.1.6-orig/display.cSun Dec 3 14:51:25 2006
+++ Imaging-1.1.6/display.c Sat Apr 14 20:54:37 2007
@@ -496,6 +496,7 @@
if (!handle) {
/* FIXME: add CF_HDROP support to allow cut-and-paste from
the explorer */
+CloseClipboard();
Py_INCREF(Py_None);
return Py_None;
}
Best regards,
Alexey.
___
Image-SIG maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/image-sig
Re: [Image-SIG] Help with PIL, Imagemagick Composite function in PIL?
On 4/11/07, Douglas Bagnall <[EMAIL PROTECTED]> wrote:
> Alexey, I think you are completely right about the problem, but the
> solution can be quite a bit simpler:
>
> dtop = Image.open("dtop.png")
> frame = Image.open("frame.png")
>
> dtop.paste(frame.convert('RGB'), (0,0), frame)
> dtop.save("test.png")
Hmm... The good part I see in this solution is that when image is
converted from RGBA to RGB it just so happens that its pixelsize is
still 4 but 4th byte is filled with 255. Then paste_mask_RGBA kicks
in, and if dtop has alpha channel it will composite its alpha channel
with 255, decreasing dtop transparency where frame is not completely
transparent. To be honest I'm not sure what is generally expected in
this situation, though looking at the way antigrain does rgba blending
I see that it essentially has this formula:
a = a * (1 - alpha) + 1 * alpha
Which is just the way it works in the code above (and absolutely not
the way it'd worked in my code). So if this behavior is expected my
example wouldn't even work as it should, thanks for showing that. :)
Best regards,
Alexey.
___
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
Re: [Image-SIG] install of PIL under cygwin fails
Hi Mark, I've just updated my cygwin and tried building it on WinXP. At first it failed (with fork issues), but after following steps in /usr/share/doc/Cygwin/python-2.5.README (that explained how to rebaseall), it was almost the same as in your case: $ python setup.py build_ext running build_ext building '_imaging' extension creating build creating build/temp.cygwin-1.5.24-i686-2.5 creating build/temp.cygwin-1.5.24-i686-2.5/libImaging gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DHAVE_LIBJPEG -DHAVE_LIBZ -I /usr/include/freetype2 -IlibImaging -I/usr/include -I/usr/include/python2.5 -c _imaging.c -o bui ld/temp.cygwin-1.5.24-i686-2.5/_imaging.o Assembler messages: FATAL: can't create build/temp.cygwin-1.5.24-i686-2.5/_imaging.o: Permission denied Note that the last line happened only once, other times it was just hanging silently. Looks like cygwin issue. Best regards, Alexey. On 3/27/07, Mark Wendell <[EMAIL PROTECTED]> wrote: > Hello - I'm trying to install PIL in cygwin under windows vista. I'm > running the latest cygwin-setup-installed python 2.5. I've tried two > ways: > > a) Grab the install files manually, unzip and untar them, and run > "python setup.py install" from the resulting folder. > b) Just run "easy_install -f http://www.pythonware.com/products/pil Imaging". > > With method a), here's the output I get before it hangs indefinitely: > running install > running build > running build_py > running build_ext > building '_imaging' extension > gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes > -DHAVE_LIBZ -IlibImaging -I/usr/include -I/usr/include/python2.5 -c > encode.c -o build/temp.cygwin-1.5.24-i686-2.5/encode.o > gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes > -DHAVE_LIBZ -IlibImaging -I/usr/include -I/usr/include/python2.5 -c > map.c -o build/temp.cygwin-1.5.24-i686-2.5/map.o > > With method b), it writes out a temporary .s file, and then just hangs. > > Anyone else see this? Any ideas how it get past this and get a good > install of PIL under cygwin? > > Note that the PIL windows installer works just fine on the same > machine, and I can use the Image module when using the > windows-installed python. > > thanks in advance, > Mark > > > -- > Mark Wendell > ___ > 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] Correct raw mode for 16-bit .bmp files
Hi everyone,
Today I stumbled upon a 16-bit .bmp file that when opened with PIL had
very-very wrong colors. While looking for the cause I finally read
MSDN documentation on BITMAPINFOHEADER, where it says that by default
(i.e. when BI_BITFIELDS is not specified in biCompression field)
16-bit bitmaps have 5-bits for each color band, thus in
BmpImagePlugin.py it should be:
-16: ("RGB", "BGR;16"),
+16: ("RGB", "BGR;15"),
I wonder if there's any collision with OS/2 16-bit bitmaps though?
(don't even know where to start looking for information on them) If
not it would be good if it could be fixed on trunk.
Thanks,
Alexey.
___
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
[Image-SIG] Patch for saving .tga files
Reposting with plain text: -- Forwarded message -- From: Alexey Borzenkov <[EMAIL PROTECTED]> Date: Feb 3, 2007 4:55 PM Subject: Patch for saving .tga files To: image-sig@python.org Hi everyone, Another patch from me, this time to save .tga files. You can grab it here: http://snaury.googlepages.com/Imaging-1.1.6-df-tga.patch However I must note that for saving RGBA images you will need my another patch I posted earlier today: http://snaury.googlepages.com/Imaging-1.1.6-df-bgr.patch The .tga saving I did is the very minimal that *seems* to work for me (I based it on code that saves .bmp files), however I'm really not sure about whether I'm saving palette information correctly or not. The main concern is that I don't know how to determine whether image's palette is RGB or RGBA, and thus it's possible to lose alpha information when loading .tga file with BGRA palette and then saving it back (because palette will be saved as BGR). But I hope it'd help others nonetheless. ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
[Image-SIG] Inconsistency with BGR packing
Reposting in plain text:
-- Forwarded message --
From: Alexey Borzenkov <[EMAIL PROTECTED]>
Date: Feb 3, 2007 2:08 PM
Subject: Inconsistency with BGR packing
To: image-sig@python.org
Hi everyone,
Yesterday I've tried using PIL to load and save .bmp files that
contain alpha channel. Well, loading was easy to do without even
modifying the library:
from PIL import BmpImagePlugin
BmpImagePlugin.BIT2MODE [32] = ("RGBA", "BGRA")
BmpImagePlugin.SAVE["RGBA"] = ("BGRA", 32, 0)
However when I tried to save bitmap after loading it I suddenly found
that packing into BGRA is not supported. I wonder if this was decided
some time ago as "the right thing", or if this was just accidentally
left out? (as it seems inconsistent to me that it can unpack
BGRA/ABGR, but can't pack it back) Fix for this is pretty trivial, but
as it contains tabulation characters in addition to seeing it below
you can download it here:
http://snaury.googlepages.com/Imaging-1.1.6-df-bgr.patch
I hope here is the right place to submit a patch, as PIL site told to
do so. And if what's done below is in any way wrong, I'd like to hear
your reasons.
diff -druN Imaging-1.1.6-orig/libImaging/Pack.c Imaging-1.1.6/libImaging/Pack.c
--- Imaging-1.1.6-orig/libImaging/Pack.cSun Dec 3 14:37:25 2006
+++ Imaging-1.1.6/libImaging/Pack.cSat Feb 3 09:56:20 2007
@@ -287,6 +287,34 @@
}
}
+void
+ImagingPackBGRA(UINT8* out, const UINT8* in, int pixels)
+{
+int i;
+/* BGRX, reversed bytes with right padding */
+for (i = 0; i < pixels; i++) {
+out[0] = in[B];
+out[1] = in[G];
+out[2] = in[R];
+out[3] = in[A];
+out += 4; in += 4;
+}
+}
+
+void
+ImagingPackABGR(UINT8* out, const UINT8* in, int pixels)
+{
+int i;
+/* XBGR, reversed bytes with left padding */
+for (i = 0; i < pixels; i++) {
+out[0] = in[A];
+out[1] = in[B];
+out[2] = in[G];
+out[3] = in[R];
+out += 4; in += 4;
+}
+}
+
static void
packRGBL(UINT8* out, const UINT8* in, int pixels)
{
@@ -460,6 +488,9 @@
{"RGBA","RGBA",32,copy4},
{"RGBA","RGBA;L",32,packRGBXL},
{"RGBA","RGB",24,ImagingPackRGB},
+{"RGBA","BGR",24,ImagingPackBGR},
+{"RGBA","BGRA",32,ImagingPackBGRA},
+{"RGBA","ABGR",32,ImagingPackABGR},
{"RGBA", "R",8, band0},
{"RGBA", "G",8, band1},
{"RGBA", "B",8, band2},
@@ -469,6 +500,9 @@
{"RGBX","RGBX",32,copy4},
{"RGBX","RGBX;L",32,packRGBXL},
{"RGBX","RGB",32,ImagingPackRGB},
+{"RGBX","BGR",32,ImagingPackBGR},
+{"RGBX","BGRX",32,ImagingPackBGRX},
+{"RGBX","XBGR",32,ImagingPackXBGR},
{"RGBX", "R",8, band0},
{"RGBX", "G",8, band1},
{"RGBX", "B",8, band2},
___
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
[Image-SIG] Patch for loading .tga files
Hi everyone, As a follow up I found a really small bug with loading .tga files where loader didn't accept 1-bit depth black&white files. See the patch below, but I've also appended it to patch at http://snaury.googlepages.com/Imaging-1.1.6-df-tga.patch (which requires http://snaury.googlepages.com/Imaging-1.1.6-df-bgr.patch) P.S. I wonder why my previous two letters didn't get thru to the mailing list... x_x diff -druN Imaging-1.1.6-orig/PIL/TgaImagePlugin.py Imaging-1.1.6/PIL/TgaImagePlugin.py --- Imaging-1.1.6-orig/PIL/TgaImagePlugin.pySun Dec 3 14:37:15 2006 +++ Imaging-1.1.6/PIL/TgaImagePlugin.py Sat Feb 3 17:10:04 2007 @@ -70,7 +70,7 @@ # validate header fields if id != 0 or colormaptype not in (0, 1) or\ self.size[0] <= 0 or self.size[1] <= 0 or\ - depth not in (8, 16, 24, 32): + depth not in (1, 8, 16, 24, 32): raise SyntaxError, "not a TGA file" # image mode ___ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
