pmxbot IRC Log Viewer

[13:48:03] <aclark> wiredfool: ok we need an ideas list for GSOC… please add yours here: https://github.com/python-imaging/Pillow/wiki/GSOC-Ideas

[13:52:50] <aclark> wiredfool: also can you create a user profile so I can add you as the backup administrator in the organization application? http://www.google-melange.com/gsoc/homepage/google/gsoc2014

[15:21:50] <mikehelmick> Hey guys,

[15:22:34] <mikehelmick> I wanted to be able to handle ICOs in my thumb script. — I see Pillow offers ICO compatability, but I can't figure out what to import so ICOs are handled correctly

[15:22:36] <mikehelmick> :(

[18:33:30] <WillIAM_> Test

[18:33:46] <WillIAM_> I just downloaded Pil

[18:34:23] <WillIAM_> my goals is to make a program that analyzes face pictures and organizes based on common features

[18:42:32] <wiredfool> WillIAM69_: openCV may be helpful

[18:51:29] <matt__> Hey all, I was wondering if there is a quick way to draw multiple transparent polygons.

[18:51:52] <matt__> Right now I am drawing multiple 'layers' and compositing them down into one.

[18:52:02] <matt__> This works, but it is reallllyyyy slow.

[18:52:42] <wiredfool> well, the draw code isn't well optimized

[18:53:14] <wiredfool> (in that it's essentially pixel by pixel drawing)

[18:53:48] <wiredfool> you could draw multiple polygons into one image

[18:54:14] <wiredfool> offhand though, I'm not sure that there's anything better than just drawing them.

[18:55:02] <matt__> They problem with that is drawing a semi-transparent yellow square over a red triangle will just leave the square.

[18:55:17] <matt__> Rather than a sqaure with and orange triangle in it.

[18:55:38] <wiredfool> ah. right, since it's just blitting in the color

[18:56:42] <matt__> Exactly, I was looking into it and through it would be possible for it to 'mix' colors when there is an alpha channel.

[18:57:36] <matt__> I am not against implementing something like that, I was just not sure if something for doing that already existed.

[18:57:47] <wiredfool> There might be something.

[18:58:04] <wiredfool> But I think ultimately it would wind up being compositing

[18:58:22] <wiredfool> transform or paste with a mask

[19:00:20] <wiredfool> right, composite is essentially paste

[19:00:37] <wiredfool> with a full image copy

[19:01:41] <wiredfool> there's also alpha_composite

[19:02:40] <matt__> Yeah, I am using alpha_composite. It looks like composites and pasting are very similar under the hood.

[19:02:50] <matt__> Not sure if that would be much faster.

[19:03:41] <matt__> Aplha compositing 50 or so polygons starts to get really slow.

[19:03:43] <wiredfool> minor speed up might be to extract the bounding box of the poly that you're compositing in

[19:03:54] <wiredfool> then do the operations on that subset, and paste it in.

[19:04:17] <wiredfool> but that's an optimization on a non-optimal algorithim.

[19:06:02] <matt__> Yeah. I might dig around the drawing code, see if I cannot hack something in.

[19:06:08] <wiredfool> I can think of a few ways that lots of work could speed this up.

[19:06:43] <wiredfool> 1) smid

[19:06:52] <wiredfool> 2) opencl

[19:07:05] <wiredfool> 3) general gpu based rendering

[19:07:25] <wiredfool> 4) better api

[19:15:19] <matt__> I was looking into dropping down to gpu/openGL/CL. I am hopping even a naive approach to anding it to the draw API will be enough.

[19:15:51] <wiredfool> simd/opencl has been in the back of my mind lately

[19:16:01] <wiredfool> you just managed to hit a use for it

[19:16:46] <wiredfool> I'd think draw with a blend would be an appropriate way to do it

[19:17:27] <wiredfool> though, the pixel level draw stuff is somewhat icky right now. There are off by n errors (for n>1) in the results of some operations

[19:25:28] <matt__> Hahaha, oh noes. Is the code mostly in _imaging.c?

[19:28:21] <wiredfool> aclark: profile made (I think, ui is somewhat unclear)

[19:28:55] <wiredfool> matt__: There's that, and libImaging.*

[19:29:08] <wiredfool> AlphaComposite.c

[19:29:21] <wiredfool> Draw.c

[19:30:13] <wiredfool> everything in libImaging is python independent

[19:30:59] <wiredfool> looks like there's rgba on rgb blending in Draw.c

[19:33:21] <matt__> Cool, thanks! I will take a look, and may even accomplish something.

[19:34:59] <aclark> wiredfool: username?

[19:35:08] <aclark> (thanks)

[19:37:31] <wiredfool> aclark: username is wiredfool

[19:38:39] <aclark> k

[19:57:49] <wiredfool> two new ideas added

[20:00:47] <wiredfool> so, don't we have a book of documentation?

[20:03:34] <matt__> Two new ideas?

[20:04:24] <wiredfool> matt__: google soc wiki

[20:04:35] <wiredfool> only half related to our conversation

[20:05:01] <matt__> Ahh, okay.

[20:05:08] <aclark> wiredfool: we do have the PIL book, IIRC

[20:05:16] <wiredfool> Pil Handbook

[20:05:25] <aclark> wiredfool: not the best idea, but I'm sure there is other stuff

[20:05:26] <wiredfool> and it's actually being somewhat updated

[20:06:03] <wiredfool> I'd love to play with opencl, but my workstation is only barely capable. 8 cuda cores

[20:08:03] <aclark> heh

[20:08:21] <wiredfool> it's possible that I've got more processor than gpu

[20:08:43] <wiredfool> incidentally, I've got a patch here that does the tests in parallel

[20:08:58] <wiredfool> I want to do something similar for builds

[20:11:17] <wiredfool> also, random question, do we have docs on how to do a dev build of pillow for windows? like which distributions of the various libraries and known working compilers and such?

[22:34:43] <matt__> Okay, I did not poking around. It looks like hline32rgba is not called when drawing polygons with an alph channel

[22:36:39] <wiredfool> interesting.

[22:37:51] <matt__> It looks like `op` is always 0 in:

[22:37:52] <matt__> https://github.com/python-imaging/Pillow/blob/master/libImaging/Draw.c#L745

[22:38:30] <matt__> I hard coded `op = 1` at the top of that function and that seemed to make it work.

[22:39:00] <matt__> Now I just need to find what calls that.

[22:39:17] <wiredfool> _imaging.c:_draw_polygon

[22:39:18] <matt__> I think.

[22:39:25] <wiredfool> l 26654

[22:39:30] <wiredfool> l #2665

[22:39:46] <wiredfool> looks like self->blend

[22:40:29] <wiredfool> which in turn is from PIL/ImageDraw.py

[22:40:55] <matt__> Haha, cool. You know this code base much better than I.

[22:41:01] <wiredfool> looks like if you pass in the mode, and it's RGBA on RGB it blends

[22:41:09] <wiredfool> no, I've got emacs and M-x grep

[22:41:15] <wiredfool> well, I do that too

[22:42:20] <wiredfool> tho, I think there's a bug in that you can't blend two rgba images

[22:42:24] <wiredfool> which seems wrong to me

[22:42:40] <wiredfool> ImageDraw.py:69

[22:44:04] <matt__> Yeah... That does not look right.

[22:53:54] <matt__> I am not sure where self->blend is coming from.

[23:02:26] <wiredfool> It's the blend in this line:

[23:02:31] <wiredfool> self.draw = Image.core.draw(self.im, blend)

[23:02:40] <wiredfool> ImageDraw.py:79

[23:06:16] <matt__> Yeah, thought that was it. I hard coded that to 1 and it did not seem to have an effect.

[23:07:51] <wiredfool> That should be it. It's passed to _imaging.c:_draw_new, and that's put in self->blend

[23:08:53] <wiredfool> then it's sent through the methods like _draw_polygon

[23:09:00] <wiredfool> and _draw_outline

[23:09:16] <matt__> Wow, sorry. Yeah that is it. I had two copies of the some file opening. I was editing one and compiling the other.

[23:09:31] <matt__> Okay, yeah. I think that fixes it.

[23:09:42] <wiredfool> ah

[23:10:59] <wiredfool> ah, that's why it's not doing blend on rgba+rgba

[23:11:15] <wiredfool> it's implicitly assuming that the initial alpha is 255

[23:11:23] <matt__> Yep yep.

[23:11:42] <wiredfool> since it's original * (255-mask) + new * mask

[23:13:02] <wiredfool> I'd love to bench those muldiv macros against current compilers

[23:14:24] <wiredfool> There's also a RGBa mode, premultiplied alpha, which is only used in a couple small places.

[23:14:53] <wiredfool> This might be one application for it.

[23:15:20] <matt__> I would assume now days it will optimize maths like that. I generally trust compilers to be smart.

[23:15:26] <matt__> For those macros.

[23:16:16] <wiredfool> yeah. I generally trust compilers to be better than I am at optimizing

[23:24:07] <matt__> But yeah, its the two rgba not being blended together. Like you said.

[23:25:05] <matt__> Drawing semi-transparent polygons on an "RBG" image works as expected.

[23:26:02] <wiredfool> I think rgba on rgba is somewhat more complicated

[23:26:49] <wiredfool> such as, what is the alpha when 25% is overwritten on 25%, or 75% on 75%

[23:28:15] <matt__> Yeah, I agree. I think there should be a note of that in the docs.

[23:28:18] <matt__> Maybe?

[23:28:32] <wiredfool> documentation is good

[23:30:04] <matt__> Haha, indeed

[23:58:59] <matt__> Cool, thing works. Thanks for all your help!

Log file Viewer

Help | Karma | Search:

#pil logs for Thursday the 13th of February, 2014