phatch-dev team mailing list archive

[Erich Heine <sophacles@xxxxxxxxx>]

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. This
does add a small performance hit, and it does add to ram use. 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.  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.

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.

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.

So those are my thoughts on this matter.

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
>