phatch-dev team mailing list archive

[Stani <spe.stani.be@xxxxxxxxx>]

On Tue, Jun 2, 2009 at 5:23 PM, Erich Heine <sophacles@xxxxxxxxx> 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 <spe.stani.be@xxxxxxxxx> wrote:
>>
>> On Tue, Jun 2, 2009 at 1:16 PM, Nadia Alramli <nadiana@xxxxxxxxx> 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     : phatch-dev@xxxxxxxxxxxxxxxxxxx
>> 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