[Digikam-devel] Adjusting filters to be deterministic

[Marcel Wiesweg]

> JulienN raised a good idea in comments under my blogpost. Rewrite the
> filters to be deterministic and thus fully reproducible. This would help a
> lot for non-destruct. editng. I would go with leaving the random init part,
> but alter the filters in such way, that we can store the output values and
> reuse it later with those exact same values to get an exact same output.
> 
> The benefits would be quite big for NDE as now the concept is such, that
> with using any non-reproducible filter, new file must be created to
> preserve this exact output and also, any edit you did prior that will be
> unremovable without losing this output. Example: you use brightness,
> contrast and raindrops and then some other filters. Now you see that the
> initial brightness is not very good so you want to change/remove it. But
> if you do so, you must reapply all the filters in the stack which are
> after
> brightness. But since you can't reapply the raindrops, you need to lose
> this and that means you will lose any other edits you did after raindrops
> too.
> 
> What do you think? Would it be possible to alter all the filters so they
> could be reproduced to get the exact same output? I don't have very good
> code knowledge of them.

Yes, it's a very interesting point.

1) Which filters are affected? A search for rand reveals:
- BlurFX
- DistortionFX
- Filmgrain
- Raindrop
- localcontrast
- in the CImg library

I would separate out one group of filters: Those depending on very complex, 
possibly externally develop algorithms like CImg. For these, the algorithm can 
change with library updates, we dont have full control anyway.
I am not sure which other plugins fall into this group; localcontrast? Gilles 
knows more about that.

So lets talk about the four of BlurFX, DistortionFX, Filmgrain, Raindrop:

2) Possible approaches to make the random values deterministic
a) store every single randomly generated value. This breaks when a large 
number of values is generated, like one value per pixel. It works if only a 
few dozen values are involved.
b) When now a random value is generated per pixel, devise a solution to reduce 
this randomness to fewer calls to rand(). Problem: This changes the core of 
the algorithm, feasibility unknown for each single case.
c) Store the random seed of the pseudo-random generator. With a real pseudo-
random generator, the random values would then be determined.
Problem: Depends on the underlying rand() implementation provided, and 
differing, by the platform.
d) Use a defined pseudo-random generator, and store the seed, or the random 
number generator seed (available in binary form). The GSL provides a number of 
such algorithms:
http://www.gnu.org/software/gsl/manual/html_node/Random-Number-Generation.html
Now using the GSL directly is not a good choice, it is GPLv3 only (sigh...) 
and would be a big dependency. Ripping out one selected algorithm, be it from 
glibc, BSD, or GSL 1.9 (GPLv2), should be feasible, if someone sits down with 
patience and finds the right source files.

More ideas are welcome ;-)