phatch-dev team mailing list archive

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

2009/6/14 Juho Vepsäläinen <bebraw@xxxxxxxxx>:
> Hi,
>
> While developing the EXIF related patches I noticed it modifies the
> metadata of input image(s) in any case (ie. even if "Save" action is
> present). Is this by purpose? Modifying image data is non-destructive
> so it kind of contradicts with that. I have not worked with
> EXIF/metadata related things before so it's all new to me. :)
Yes this by design. I've explained the principle before with the
geotag action as that one was the first one manipulating the metadata:
https://lists.launchpad.net/phatch-dev/msg00102.html

Basically the save action now saves the pil image to disc. In the
current state it would be not wanted that if you want to add metadata
(such as geodata or authorship) to a jpeg image that it is opened and
saved by pil, as this is not a lossless operation. You basically want
to to open only the metadata and save it. As such in the current
implementation every metadata action is a save action. However they
are buffered and written at once. So that is why you can have an
action list with only a metadata action or why you have to place the
metadata action *after* the save action, as this won't change the
source image. If a metadata action after the save action modifies the
source image it is a bug.

That said,  I agree that, although this design is consequent and
predictable, it is counter-intuitive in Phatchs workflow. In Phatch
0.1 saving metadata was a testing feature and therefore not enabled by
default. Exiv2 is not perfect and has its own bugs. Therefore I wanted
to get only bug reports of people who enabled this conciously. For
Phatch 0.2 I hope we have fixed these issues as good as we can, but
not completely. (Eg no option to add or update exif thumbnails.) To
put the "Copy metadata" as a checkbox in the execution dialog box, was
also for me a temporary solution, as I didn't dare to put it in the
save action yet. Moreover as there was no system for conditional
showing/hiding options the save list would become too long.

So now we have dealt with most exiv2 issues (which means even
disabling where exiv2 fails, eg for tuple values) and have conditional
parameters at our disposal, we can design a better way how to
integrate the metadata workflow in Phatch. There a different solution
possible:
- we could add image_dirty or pyexiv2_dirty attribute to actions.
(Dirty means changed.) Whatever which is dirty is saved by the save
action. Disadvantage here is that the save options such as quality and
so on ... are not taken in consideration when only the metadata is
dirty. So if you want to save with manipulated metadata and another
compression there is no way to do so.
- a proposal could be to add a ChoiceField to the save action which
let's you choose between saving image, metadata or both. This has the
advantage that the user is in full control and that optionally the
right parameters can be shown or hidden.
- ...
I'm curious to hear your proposals, as there should be more.
>
> Is there some specific place where I should put my tests? Do you
> prefer to use some specific testing suite (ie. unittest/doctest/some
> other?)?
Look to core/lib/formField.py I started implementing doctests there
already as an example. However I had not yet the time to finish it
yet. So always use doctests, unless it doesn't make sense. The
unittests will be run by nose.
>
> I have used "get_relevant_field_labels" for conditional fields (ie.
> fields depending on state of others). The system works, yes. But I
> find it a bit suboptimal.
Suboptimal in which way? Can you clarify?
> Is there some specific reason why not to
> determine the relationships between different fields in "interface"? I
> think it might be more straightforward this way.
This is about relations in between fields, so I am curious how you can
define these inside the fields themselves. Please give an example. The
only thing I know of are xforms (from where I took the relevance
concept), but it would be overkill to work with xforms here. Also
having it defined in one python function gives you a lot of
flexibility without being complex.
Actually I am quite happy with this method. But in case you have
something better in your mind please propose an alternative so we can
compare and evaluate.
>
> In addition it might be interesting to construct the object hierarchy
> based on higher level definition (ie. YAML). Here's an example (ported
> "reflection" action to YAML syntax):
> ui = '''
> PixelField:
>    -name: Depth
>    -width: 50% # I suppose original 50% meant width. anyway as you
> can see it's reader friendly too
>    -choices: self.PIXELS[:-1]
> PixelField:
>    -name: Gap
>    -width: 0
>    -choices: ['0', '1', '2', '5']
> SliderField:
>    -name: Opacity
>    -value: 60
>    -min: 0
>    -max: 100
> BooleanField:
>    -name: Scale Reflection
>    -value: False
>    -children:
>        ImageResampleField:
>            -name: Scale Method
>            -method: antialias
> ColorField:
>    -name: Background Color
>    -color: black # I prefer to use a library
> (http://code.google.com/p/grapefruit/) handling the conversion
> SliderField:
>    -name: Background Opacity
>    -value: 100
>    -min: 0
>    -max: 100
>
> I'm not 100% sure that it's valid YAML. It should be right enough to
> convey the idea though. Basically keys refer to class names and their
> attributes to the attributes of the classes. It's a piece of cake to
> convert this into a real object hierarchy if needed.
Hmmm... how this system deals with gettext with extracting
information? One of the rules I used in Phatch development to use
python for everything: so no xml, ... Actionlists are dictionaries and
the settings are even pickled dictionaries. As Phatch started as one
mans project this has saved a lot of time and complexity. If more
people are willing to put their time in these issues, we can revaluate
that and maybe get to something better.
Until now I have no regrets. I really like that actions are one file
as it makes it easy to handle. From the moment you start with multiple
files (like an xml/yaml for user interface, pil function in py file
and icon seperately), you need to manage. Do you put each action in a
separate folder or zip or ...? So I took the KISS approach.
So I am open for new systems if it can do everything as the current
system and better. In fact there are some parts where I consciously
had to take a shortcut and I know there are better solutions. For
example in action lists the english label fields are used as an ID.
This is really bad as this means that if for example you correct a
spelling mistake in a label it breaks a previous saved action list. So
there is still a lot of place for improvement.
>
> Note that everything needed by interface and get_relevant_field_labels
> methods can be generated based on this. So if wanted, this system can
> fit on top of the current one instead of replacing it. I think the
> system would pretty much pay off for itself in more complex cases (ie.
> hierarchies going past two level). Furthermore it could be used to
> bring cohesion and consistency to the system.
I'm afraid we need more power for the relevancy. (Check out Xforms.
Inkscape is going to use that.) For example for the varborder action,
I wanted to implement the opacity is only shown if the values for
left, top, bottom and right are negative. How would you do that with
YAML? I like a relevance method as it is dynamic and very flexible,
while YAML looks static. The current proposal looks 'suboptimal' to
me, but prove me wrong ;-)

>
> I suppose many actions have some sort of background color and opacity
> defined in them. It would be possible to refer to generic properties
> such as this in the structure itself. In this case you would subclass
> ColorField and SliderField and end up with something like this:
> BackgroundColor
> BackgroundOpacity
>
> Of course sometimes you might want to this partially (ie. Opacity):
> Opacity: # subclass of SliderField
>    -name: just some opacity
>    -value: 55 # i'm not happy with the default so let's set it to 55 :)
>
> Anyway those were some initial thoughts after two days of development.
> It has been pretty easy to work with phatch so far. :)
Well many features are implemented in a few hours or less, so you see:
two days of development is already plenty enough to give feedback.
Just take in account that besides features, the transition from Phatch
0.1 to 0.2 is also from an one person project to a multiple persons
project. I feel still too much load on my shoulders, but with so much
energy I hope that can diminish ;-)

Probably for these kind discussions IRC is a better medium (#phatch on
freenode). I'll be there monday.

Best regards,

Stani

-- 
Phatch Photo Batch Processor - http://photobatch.stani.be
SPE Python IDE - http://pythonide.stani.be