On Tue, Jun 2, 2009 at 5:23 PM, Erich Heine <[email protected]> wrote: > Hi all, > Sorry for the late reply to this thread, but most of the discussion took > place while i was sleeping. My opinion on the matter is this: > I would like to see a consistent internal representation for phatch. If you mean that Phatch should convert by default any file for any action list, I disagree. Let's say you scanned multiple images as tiff g4, which is one bit, and you want to mass rotate them. Converting them to RGBA is overkill. See for example the 35 megapixel file posted by a Phatch user in this bug report (imagine the size after converting it from 35megapixel 1-bit to RGBA): https://bugs.launchpad.net/phatch/+bug/234788
Also the approach of converting to RGBA would work fine if Phatch limits itself for its only backend, but in the future I'd like to add other backends such as imagemagick, dcraw, ... If we'll use RGBA as the default representation this will inflate the interprocess communication and make Phatch considerably slower. In a very far future when Phatch is the king of image batch processing, it would be nice to expand Phatch to any kind of batch processing (not just for images), like what automator does for the mac. > This > does add a small performance hit, and it does add to ram use. Next to being a developer of Phatch, I am also a very heavy user. For example for the coin, I was working on very high resolution 1bit images which I was processing with Phatch. In case they would be converted to RGBA, Phatch would not be able to handle it. Of course I wouldn't want to abandon Phatch for my own work as there is no alternative ;-) > It also gives > us a major advantage: all actions can be written without concerns for 'P' vs > 'L' vs 'RGB' etc. In the long run I believe this aspect to be more > beneficial than the tradeoffs. This might ask for a different code design and some work on the api. It could be possible that an action can define its requested input format and its output format. For a rotation function this will be completely open. For actions including transparency, they could specify that they need RGBA. The action would not need to write the conversion code itself but this would be handled on a global level by Phatch. This is similar to caps negotiation for video pipelines in gstreamer: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-negotiation.html http://www.cin.ufpe.br/~cinlug/wiki/index.php/Introducing_GStreamer We can also have a look at GEGL, which implements a pipeline for images. > Based on the points made in previous emails > I will just make a few points myself: > 1. I strongly suspect that phatch will be I/O bound in many of the cases it > is being used. I have no real data to back this up, it is just a hunch. > Further, except for large actionlists, taking advantage of the > multiprocessing module in 2.6+ may make it easy to turn this into an I/O > problem. We also need to consider this in the light when in one action lists image data has to be passed through pipes or temporary files between different processes in a future version of Phatch, which supports multiple backends. > 2. Complicated workflows which involve pasting or other operations involving > transparency effects will already need RGBA conversions, and the performance > hit in these cases will be terrible since many conversions need to be made. The conversion is only done *once* (not many times): in the first action which requires RGBA. I agree that the responsability of an action should not go further than requesting a certain image mode and the core of Phatch should do the dirty work. Unfortunately there is not such framework yet present in Phatch. It needs to be designed with multiple backends and maybe layers in consideration. Nadia also proposed to have a nicer API. > 3. The above mentioned developer ease. Another side effect of this is > debugging ease. > 4. As a user of image editing software: I don't mind how the image is > internally represented, I only care about the results I can acheive. Me too. When I am working on location, I use my first-generation Asus Eee PC and the only memory concern I have is that Phatch can handle it. At this moment I'd like to refrain from a whole rewrite of the Phatch api. Many features have been added and a lot of work has been done which is ready to be released. I'd like to stick for Phatch 0.2 to the current state, so we can release it as soon as possible. It has many features which users like to start using now. Let's open the discussion for Phatch 0.3, in which I like to include imagemagick support as this will be able to fill some gaps of PIL (like gaussian blur) and many effects. So for Phatch 0.3 we can also look how to implement properly the conversion negotiation and multiple layers. It would be nice to to start different blueprints on the different topics so we can make clear design decisions before coding them. > So those are my thoughts on this matter. Thanks for sharing them! Both Nadia and you are experienced with twisted and some very large scale python projects. So I'm really open to optimize Phatch for your experience (like you mentioned multiprocessing). Stani > Regards, > Erich > On Tue, Jun 2, 2009 at 6:44 AM, Stani <[email protected]> wrote: >> >> On Tue, Jun 2, 2009 at 1:16 PM, Nadia Alramli <[email protected]> wrote: >> > Hey, >> > >> >> >> >> > I agree we should only convert when we have to. And only convert back >> >> > to >> >> > 'P' >> >> > if absolutely necessary. In this case the border action can convert >> >> > to >> >> > 'RGBA' if the border is negative >> >> I agree >> >> > or if the image was mode 'p' with >> >> > transparency. >> >> As I didn't dive as deep in the subject as you, maybe I am forgetting >> >> something. Let's consider the case where the image has mode 'P' and >> >> transparency set. I thought it could be possible to keep the >> >> transparency color index (stored inside photo.info['transparency']) >> >> and add the border color to the palette (in case it was not part of it >> >> already). This will only fail if the palette has 255 colors (+1 for >> >> transparency) already, in which case a conversion to RGBA is needed by >> >> a lack of colors in the palette, but not by transparency. (Note that >> >> this would also be case for non transparent P images which have >> >> already 256 colors and to which e.g. the variable border action wants >> >> to add a color.) >> > >> > That would have been the right way to do it if PIL created palettes with >> > the >> > right size. I'm not an expert in this. But from playing around with >> > convert. >> > It seems that getpalette always return a 256 colors palette no mater >> > what >> > the image is actually using. We can't use palette.palette size to >> > determine >> > unused colors because of the mentioned PIL bug. You can tell unused >> > colors >> > in other ways. But then to make this work you need to do the following >> > (or >> > something similar) >> > >> > palette = im.getpalette() >> > size = len(im.palette.mode) >> > unused_color_index = getUnUsedColor(im) >> > if unused_color_index >= 0: >> > palette[unused_color_index*size: unused_color_index * size + size] = >> > color >> > newimg = Image.new('P', size, unused_color_index) >> > newimg.putpalette(palette) >> > else: >> > # No unused color was found convert to 'RGBA' >> > >> > I don't have access to PIL to test this pseudo code, but I think it >> > should >> > work. However, it seems overly complicated to me. >> I agree, so converting to RGBA in that case is fine too. However I >> think it would be good if you or Erich report this issue on the PIL >> mailing list. PIL 1.1.7 rc will come out soon and maybe this bug can >> be fixed for this new release of PIL. >> >> Thanks for clarifying, >> >> Stani >> >> -- >> Phatch Photo Batch Processor - http://photobatch.stani.be >> SPE Python IDE - http://pythonide.stani.be >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~phatch-dev >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~phatch-dev >> More help : https://help.launchpad.net/ListHelp > > -- Phatch Photo Batch Processor - http://photobatch.stani.be SPE Python IDE - http://pythonide.stani.be _______________________________________________ Mailing list: https://launchpad.net/~phatch-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~phatch-dev More help : https://help.launchpad.net/ListHelp
