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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
