phatch-dev team mailing list archive

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

2009/6/15 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.
Indeed and the golden rule is that conversions should be only done
when needed. It also is related to multilayer. I see it possible that
all layers are not in the same format, so they don't have necessarily
to be converted together. For example one layer could even be a text
file which can be converted to an image later on in the process. This
will be even more so if Phatch will support other formats than images.
In that case we will need feedback for every step in the action list,
as maybe two actions can't follow after each other as eg a text can't
manipulate an image. Or the add dialog should be able  to decide which
actions are possible after the current selected action. So when
developing the generic image, it would be good to have already to
evaluate if we can implement the basics already of generic layered
data instead of a generic layered image. Maybe it is too complicated
and we limit ourselves to images first. For example now in Phatch the
photo object has already a layer structure although it is not exposed
in the UI. I like it, as it shows what still has to be done.
>
> 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
Well, I am plenty of ideas for preview. I have been thinking of this
for a long time. Another option is to show three little previews next
to each other:
source - current step - final result
The preview is not just about image, it is also about filename and
exif data, so this should get there a place too. Another related issue
is the open option. Now it is hidden in the execute dialog, but that
is not ideal. It should be or available as an action or be available
in the user interface. So that the preview can immediately pick the
right ones.
https://blueprints.launchpad.net/phatch/+spec/open-folder

Another issue is that it would be nice to show easily previews of
multiple images. This would fit better with Phatch as it is a batch
program, rather than an image editor such as Gimp. Virtual list
controls in wxpython are ideal for this, as they will only generate
the preview on demand. So if you have a folder with hundreds of
images, it will only generate the five images which are on display. As
they have a small size it should be fast enough. (The add action
dialog is an example of highly customized virtual list control.)

For that we have to cache the image for every step, so regenerating
the steps after can start from there.
>
> 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.
It is easy to write, for sure in wxpython. Again just a matter of
time. Also I was wanting to limit the work on the GUI, as it would be
wasted if we go to eg jquery. If we don't care about that, we should
write the specification for it, listing the different options, discuss
about it and choose one.
https://blueprints.launchpad.net/phatch/+spec/live-preview
>
>>
>> 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. :)
OK. So lets focus now on getting Phatch 0.2 ready.
>
> 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?
Why not? It only should be available on Mac and Windows. Also if it is
a fork, we should compare the development activity, as it is a
nightmare to end up with a dead project. But if they use exactly the
same command line interface, it should be easy to switch.

> 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
>>
>
> _______________________________________________
> 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