Post Deflicker (deflick.mo)

[a1ex]

Audionut refactored the post deflicker feature as a module, with the help from nanomad (will be in next nightly). Please let me know if it works on all cameras (there should be no change in functionality).

An interesting trick: Marsu42 is using it not for timelapse, but for photo shooting (exposure normalization). Can you share some more details about this workflow?

Tutorial: http://www.magiclantern.fm/forum/index.php?topic=5705

Alternatives:
- For timelapse, deflickering is best done when postprocessing (try dmilligan's deflicker script, based on the same algorithm, but requires proprietary software).
- For regular photo shooting (exposure normalization, including natural-looking HDR), you can try my script: uniform_exposure.py (based on enfuse and ufraw). Don't try it for timelapse.

Once we'll have a fully open source post-processing tool that uses this algorithm, I believe this feature can be removed completely from ML (and free the resources for things that can't be done in post).

[Marsu42]

An interesting trick: Marsu42 is using it not for timelapse, but for photo shooting (exposure normalization). Can you share some more details about this workflow?

It works fine for my with shooting wildlife in different zoom positions and a bit changing lighting, via the xmp I can then get a common exposure base in Lightroom and batch-edit it to where I want all files to be. If this fails, nothing is lost and I can just reset the exposure to zero.

As I already wrote in a bug ticket, sometimes the xmp overflows to max. +exposure on 6d, please give feedback if this also happens to you and you have a clue what the cause is.

[Audionut]

Can you be a little more specific of when it overflows?  edit:  Nevermind, I should check the bug report 

For me, This needs to delete the xmp when the image has been deleted.  I do a lot of test shots to check for exposure and it's a pita to have unneeded xmp files everywhere.  I like keeping my file structure clean.

This would be another option where toggling would be useful.  Hold button - disable xmp.

I ported this for the simple reason that it looked like the easiest thing to try my hand at. 

[a1ex]

Tip: before deleting files from Canon menu, restart the camera. It will delete all the sidecars too.

[Marsu42]

I ported this for the simple reason that it looked like the easiest thing to try my hand at. 

If you're looking for a useful occupation, try to refactor focus stacking & rack focus into a module - these code parts are rather independent, and either people will use them all the time or not at all, so a module should be ideal. Plus I have some additions for focus stacking in mind, but no doubt patching the core is more of a hassle to merge than modifying a module.

[Audionut]

I had a look at bracketing and such, but that all looks to be to deeply integrated into too many source files.  I need to work out how to do all this branch stuff, then I'll take a look.  Somewhere along the line I'd like to get the documentation up to scratch, and I'd like to do a massive post/guide on exposure/ettr/dual_iso etc (how ML helps photography), but I'm not a machine like a1ex, trying to do to many things at once leads to confusion.


Ideally I would like to port almost all features into modules.
This way the source files get trimmed to core functionality, bin size reduced, memory usage reduced, menu only contains features enabled by the user (clean).  And probably most importantly, as you mentioned, it should be easier for users to patch modules then source files.

Those are a few advantages I can see off the top of my head.

[Marsu42]

Ideally I would like to port almost all features into modules.

Ah, you're trying to refactor Linux into a micro-kernel system like GNU Herd - and we all know what became of that :-p ...

... I also had the same idea, but as you just I discovered it is very difficult to get these things apart, or you'll end up with too many inter-module dependencies and shoot tasks all over the place. I even created a thread some time ago asking for a schedule what code parts are easy to separate, but nobody answered back then, feel free to attempt it again.

That's why I gave you the hint with stacking/rack, it's worthwile since it's a huge chunk of code, but rather easy to do because unlike hdr it's mostly independent and stuffed in 1-2 source files.

Last not least remember we still don't have array variables in modules, so you cannot refactor these (yet) - and hdr is one of which require these.

[Audionut]

or you'll end up with too many inter-module dependencies and shoot tasks all over the place.

I don't understand how this is any different to what we have now.  ie:  There's to many dependencies.

It seems easier (to me) to have the each module define it's dependencies. 

[Marsu42]

It seems easier (to me) to have the each module define it's dependencies.

Easier in theory, yes, but a clean room software engineering approach is not necessarily the most adequate solution for a real world problem.

It needs a lot of time to get these components apart and define dependencies, and if you are at it you'll want to really refactor a lot for clean interfaces. The alternative is just to cherry-pick huge, rather independent chunks and put these into modules for improved core maintenance- and spend the rest of the time developing new features, test or improve them.

Ultimately it's about using the camera and shooting/videographing and not to have the most over-engineered software hack :-o ... but it's your time and if you chose to invest it like it's of course it's also beneficial to the project.

[Audionut]

Ultimately it's about using the camera and shooting/videographing and not to have the most over-engineered software hack :-o ... but it's your time and if you chose to invest it like it's of course it's also beneficial to the project.

Heh, the only reason why ML is what it is, is because someone (a1ex and co), choose to invest time into making it what it is 

And time/effort is the only way ML will continue to expand.

http://www.x264.nl/developers/Dark_Shikari/loren.html

<pengvado> making an alpha product into final is easy
<pengvado> the hard part is adding features so that it stays alpha

Make no mistake, I am not in a position to port everything to modules and refactor all of the code necessary to do so.  But there is only one way to learn, and that's to dive in and try and break things

[LebedevRI]

Once we'll have a fully open source post-processing tool that uses this algorithm, I believe this feature can be removed completely from ML (and free the resources for things that can't be done in post).

As of this moment, this feature has been ported into darktable, and avaliable in exposure module

Commit: f0a71c60b08291395bbdc6a9f31d243cf3605d05
Merged pull request: https://github.com/darktable-org/darktable/pull/433

[a1ex]

Nice! Need to try this one

[rwh]

From a quick discussion of this on the darktable IRC, a simple workflow would be:

• edit a single raw in the darkroom, open the exposure module and check the Deflicker box and choose Percentile and Target level
• return to lighttable, and use the history stack module to copy just the exposure item to all other images in the series
• return to the darkroom and use the <space> key to advance through all of the files

The reason for the last step is that the deflicker algo needs the histogram to be evaluated, which only happens when the file is loaded in the darkroom.  If you don't do this step, then all images will get the same exposure change as the image you copied the history stack item from.

[LebedevRI]

darktable 2.0 was just released.
This is the first darktable release, in which deflicker is available, (in exposure module) and can be used.
(it got pulled out of 1.6 for some internal reasons.)

[DeafEyeJedi]

Thanks for the heads up @LebedevRI!

[LebedevRI]

Some explanation on how to use it:

(from 8m10s to 11m17s)

IMPORTANT: only available for raw (not even SRAW!) files, i.e. .CR2, .NEF, etc; NOT FOR ANYTHING ELSE (ldr/hdr - jpg, tiff, png, etc)