Hi tobias,
Great !
It seems for me also that point 1/ is the first step to start this project.
The ideal approach would be to give as input 2 xmp files (start and end)
but it could be done after.
The modules you mentionned are a good starting point also. (Bare minimum is
exposure module)
For information, i think that if you manage to do 1/ i could do 4/ (for
deflickering).
I've already done this in a script with octave and convert.
Let me know for the next steps :-)
Alex
Le 26 août 2013 14:03, "Tobias Ellinghaus" <h...@gmx.de> a écrit :
> WARNING: long mail ahead!
>
> Am Sonntag, 25. August 2013, 16:44:47 schrieb Alexandre Jullien:
> > I've got the feeling that I could find a quick answer to my need by
> > combining exiv2 with a little part of code of exif.cc
>
> Well, let me say it like this: it should be quite simple to code something
> that "just works". However, that will hard code a lot of things and needs
> changes to the code whenever anything in the parameter layout of any (used)
> iop changes. For personal "in house" use that would be probably ok,
> however I
> wouldn't feel comfortable to release such a tool to the public since it
> implies eternal maintenance.
>
> > I've found that in exif.cc, it seems to be the encoding/decoding rules of
> > XMP blend operations params
>
> No, the blend params are for blending, what you want are the general
> params.
> In XMP the interesting parts are:
>
> darktable:history_modversion
> darktable:history_enabled
> darktable:history_operation
> darktable:history_params
>
> And maybe also multi instance:
>
> darktable:multi_priority
> darktable:multi_name
>
> Of course the blending could be supported, too:
>
> darktable:blendop_params
> darktable:blendop_version
>
> [snippet from exif.cc]
>
> This is just general code to convert any binary data blob into a printable
> string and to convert it back. So yes, this is a needed tool, but not too
> interesting.
>
> > Furthermore, exiv2 can directly reads the XMP data of XMP file:
> >
> > exiv2 -p x myPicture.xmp
> > => gives me all data I need (filter + blenop_params encoded in sort of
> > hexa).
>
> I would keep everything in C and not start mixing shell and compiled C
> code.
>
> > Somebody to support me and indicate me if I'm going in the right
> direction ?
>
> With what I said above there are several ways your program work:
>
> 1) Only make use of a subset of our modules that are most useful (e.g.
> exposure, white balance, shadow&highlights, crop&rotate, levels, ...) and
> only
> use a subset of the parameters for each of them. For these the user can
> provide a ramp to be applied for a given set of images. The application
> then
> generates an XMP file for every image with a history stack that represents
> the
> wanted settings.
>
> 2) Same as above but allow access to all parameters of maybe all modules.
>
> 3) Allow to specify a set of images and an XMP for the first and last of
> the
> sequence. This can be generated by manually developing the two images
> inside
> darktable. The application then reads these two XMP files and interpolates
> between the settings used in darktable and generates new XMP files for the
> other pictures of the sequence.
>
> 4) Don't limit the application to generate ramps but also to do deflicker
> on a
> per-image basis.
>
> Now, let's evaluate these 4 approaches. The difficulty rises from 1) to 4).
>
> 1) is quite easy to do and would even be future proof with regard to
> changes
> inside darktable since the module versions would help a lot.
>
> 2) has the same benefits as 1) but would need a user interface that is way
> more
> complex.. It would also require to add new modules as they get added to
> darktable.
>
> 3) would already be quite hard. You would have to keep track of module
> versions, make sure to do something like our legacy_params function. The
> best
> idea I have for this is to use the actual modules installed by darktable,
> feed
> the parameters you find to their legacy_params callback and only handle the
> latest version. However, this still needs you to keep track of changes to
> this
> latest version. Quite messy. And long term support is needed. It also
> implies
> that things like multi instance and blending are supported, otherwise the
> results might not be as expected.
>
> 4) is a completely different beast than 1)-3). While 3) is already hard
> compared to 1) and 2), it's a stroll in the park compared to 4). While the
> others ONLY have to deal with XMP files and the module parameters inside
> (so
> basically just a bunch of number that need to be interpolated once you have
> figured the format out) the de-flickering would have to access the actual
> image,
> do fancy computations and analysis on them and then try to come up with a
> history stack that fixes whatever problems the algorithm found.
>
> Conclusion:
> Forget about 4). Sorry, but that is a project for someone who know about
> computational image processing and has probably months of free time.
>
> For now I would start with 1). Something like that should be relatively
> easy
> to code, give you basic ramping support and will work for a long time. The
> user interface could be made simple to quickly get results, probably by
> developing the first and last frame inside darktable, write down the
> settings
> and enter them in the external application. In the future the ramping
> could be
> made more sophisticated, but all of that could be based in the same
> concept.
> Over time this could even be enhanced to become 2).
>
> So, if you are still interested and if the approach described in 1) would
> be
> enough for you: tell me. I might be willing to get my hands dirty. :)
>
> > Thanks !
> >
> > Alexandre
>
> Tobias
>
> >
> > 2013/8/25 Alexandre Jullien <alex.jull...@gmail.com>
> >
> > > I agree that doing this in the code is not wanted for the first step.
> > >
> > > As I wrote, my basic need is to have standalone executable *translating
> > > darktable XMP files* in clear operations parameters in both ways.
> > >
> > > The interpolation is clearly the final goal, but is not hard if you can
> > > translate easily modules parameters in XMP file.
> > > I've write some scripts using bash and octave doing this kind of job on
> > > luminosity to deflicker my timelpase but on JPG only...
> > >
> > > Thanks for your answers, I hope that somebody with development skill
> could
> > > helm me to do this external tool based on src/iop :-)
> > >
> > > Alexandre
> > >
> > >
> > > 2013/8/25 Tobias Ellinghaus <h...@gmx.de>
> > >
> > >> Am Sonntag, 25. August 2013, 12:51:53 schrieb Alexandre Jullien:
> > >> > Hello everybody,
> > >>
> > >> Hi.
> > >>
> > >> [modifying iop params from outside the module]
> > >>
> > >> this is something I wanted to do for quite some time, however it
> requires
> > >> some
> > >> means of introspection to make sense of the module params. This would
> > >> probably
> > >> require some new API so that modules could decode their binary params
> > >> blob.
> > >> Doing it directly in code would be quite messy and prone to break
> > >> whenever
> > >> anything gets changed. It would also require us to invent some data
> > >> format to
> > >> convert the params to/from.
> > >>
> > >> My hope is that some day™ LUA will be able to access the parameters of
> > >> modules. Then we could write small scripts (maybe some day even with a
> > >> GUI)
> > >> that can interpolate between the parameters of two images over a whole
> > >> set.
> > >> But until that happens the only hope would be to write a small
> external
> > >> tool
> > >> that directly uses the struct definitions from the files in src/iop/*
> and
> > >> breaks
> > >> whenever these are changed.
> > >>
> > >> TL;DR: would be nice but is hardly possible.
> > >>
> > >> > Alexandre (Toulouse (31) / France)
> > >>
> > >> Tobias
> > >>
> > >>
> -------------------------------------------------------------------------
> > >> ----- Introducing Performance Central, a new site from SourceForge and
> > >> AppDynamics. Performance Central is your source for news, insights,
> > >> analysis and resources for efficient Application Performance
> Management.
> > >> Visit us today!
> > >>
> > >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clkt
> > >> rk
> > >> _______________________________________________
> > >> darktable-devel mailing list
> > >> darktable-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>
>
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
