phatch-dev team mailing list archive

[Juho Vepsäläinen <bebraw@xxxxxxxxx>]

Hi,

2009/6/15 Stani <spe.stani.be@xxxxxxxxx>:
> Juho wrote:
>>> I hope my initial comments were not too harsh. I still have some in
>>> store (ie. proper preview and co.). :)
> Good you mention preview. In that sense I also have more comments ;-)
> I think it is important to do a step back first and look to the big
> picture of the future of Phatch. There are many dreams for Phatch
> which are not implemented due to a lack of manpower:
> - multiple backends besides pil (especially imagemagick and also
> necessary command line tools such as dcraw, ...)
> - layer support for compositing
> - life preview (preview update as you slide)
> - jQuery interface (for desktop with webkit like gwibber and for
> server as web application)
> - interaction with the best graphics software (Blender, inkscape, ufraw, ...)
> - multiprocessing (luckily Ido volunteered for this)
> - installers for windows and mac (increase market share drastically)
>
> ... and once Phatch is perfect for images:
> - general purpose batch processor, not just for images, but for
> text/xml/yaml/processing/video encoding/...
>
> Some of these will requires a new pipeline structure, so that multiple
> command line actions (eg imagemagick and friends) can be efficiently
> chained after each other or layers can be handled properly. To tell
> you the truth, I would prefer to concentrate first all refactoring
> efforts there. These are things which really will push Phatch, which
> is an end user program, forward and turn into something huge. As the
> current system might be not perfect or leave room for improvement,
> that is not what IMO our users are for waiting first. Seeing how much
> energy you have Juho, I really would prefer if you would join us to
> work on these major features first. Life preview is connected to if we
> switch to jquery+webkit. I really would like to do it, if we could get
> some jquery manpower on board. It would allow me as an architect and
> visual artist to develop the dream interface for Phatch and it would
> make more suitable for servers. For every new release we should see
> what is realistic with the current manpower and limit ourselves so we
> could have a half year cycle release ideally.

Okay. I find especially the "multiple backends" goal interesting
because if designed properly this might be something to use in other
projects. :) I see it as a separate, lower layer on the architecture
which the actions can then call directly. This layer might also handle
possible fallbacks (ie. if module is not found).

So in architectural terms it would be just an adapter. All current
actions would work on generic images instead of PIL ones. The image
manipulator layer would handle all conversions/grunt work needed.
Perhaps "- interaction with the best graphics software (Blender,
inkscape, ufraw, ...)" would fit into this layer as well.

Another interesting one from my point of view is the preview. As
phatch is a batch processing program, at best you can use preview as a
tool to help previsualize partial results (ie. using perspective
action is kind of tough now). Perhaps it could be integrated as a tool
just like "Image Inspector". So to use it you would go to Tools ->
Image Preview in the menu (or hit alt-space?).

After this it would create a little window (around 200x200 pixels?)
for previewing purposes. It should be possible to load an image to the
preview (similar functionality to "Image Inspector" perhaps they
should share the image data?). The preview could show ~before~ and
~after~ images based on the currently selected action. As far as I can
see there are two different preview cases you want to handle:
1. evaluate action list till selection (default preview option)
2. evaluate only the selected action

I consider preview much simpler task than image manipulation arch. So
if you want I can try to poke around to see if I can come up with
something. It ~ought~ to be quite straightforward to write.

>
> I did a poll once before:
> http://ubuntuforums.org/showthread.php?t=726547
> At the end I decided to start with exif as that was half implemented
> as read only and it felt more natural to implement write support. Also
> the fact that Robin joined the team, pushed this forward ;-) It is
> often good to implement a feature already slightly, as the feedback
> from the exif use was necessary to make the write support step now.
> That is why I wanted the 'Geek" action (the command line one) as this
> will give new feedback when we want to integrate command line tools
> such as imagemagick properly.
>
> The refactoring of the UI internals (with or without YAML) seems less
> a priority for me compared to these major features. I'm not saying it
> is not good or not important, but less important. Everyone should work
> on what is fun for him and what has more priority. If that is YAML for
> you, let's look at it together and than you can go for it. But just to
> seduce you, imagemagick support would be wonderful as this was
> designed for batch processing from the beginning, and it fills many
> painly holes that PIL has. Just to give one example: gaussian blur.
> The blur in the shadow option is really a pain as with PIL the maximum
> is a blur with 3px. So the only way to make it more blurry is to
> iterate. That takes a lot of ressources and time and besides it will
> never be able to achieve blurs with higher radius. Next to the fact
> that imagemagick provides basic needed functionality, it can also do
> some very cool stuff:
> http://www.imagemagick.org/Usage/
> http://www.imagemagick.org/Usage/advanced/
> http://www.imagemagick.org/Usage/transform/
>
> (I would prefer to use imagemagick rather than pythonmagick as these
> bindings are not complete and hard to find for Windows & Mac, unless
> this has changed.)

I will put the YAML thing in the freezer for a while (I have the
"tough" code implemented already) and see how things go. I consider it
post-0.2 feature now. :)

By the way there's a fork of imagemagick, graphicsmagick
(http://www.graphicsmagick.org/) which you might find interesting.
It's supposedly a bit faster. Perhaps that's worth looking into? In
any case should a proper image manipulation layer be implemented,
these kind of things become less important.

Sincerely,
Juho Vepsäläinen

>
> Best regards,
>
> Stani
>
> _______________________________________________
> 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
>