(respond to myself)
After some discussion on irc with LebedevRI and houz, let's try to resume :
- This approach is overkilled, totally wrong, bad... so let's forget it
for now ;) (no problem, that's the goal of proposals)
- There is a problem with c&r (for devs, not for the user)
- It would be better for quality to reduce the place where we
interpolate pixels. (currently : ashift, c&r and lensfun)
1 : Do nothing. Let c&r as it is now... but it may cause problem hard to
fix sooner or later and that means that it will probably not evolve.
2 : Deprecate c&r, and rewrite their features in different iop(s) :
2.a : merge rotation and perspective inside lensfun () and do a special
iop for cropping only. It has the advantage to concentrate all
interpolation inside lensfun iop, we lost the actual c&r ui, which works
quite well from an user pov
2.b : merge perspective into ashift, adding a "manual" mode. and rewrite
a new c&r iop with just crop and rotate like in the old days. but it
will complexify the ashift code, and it will not reduce the number of
interpolate iops
2.c : rewrite c&r with perspective, rotation and cropping. But I really
doubt that it will solve anything, we'll still have the really messy mix
of all that different distortions and canvas elements.
I personally prefer the 2.a approach...
Thanks
AlicVB
Le 27/03/2016 18:13, AlicVB a écrit :
Hi all,
As many of us , I'm tired of the "instability" of the clipping iop.
Each change is prone to a cascade of small other errors and/or subtle
change to the output... But that's not a secret for every dev who has
hack this file :D
So I thought about how to solve this situation. I came to the
conclusion that even with a full rewrite, we'll still get a mess,
because there's too many functionalities which don't work well
together, especially when we speak about distortions and canvas elements.
Hence my idea to split clipping in 3 new iops : manual perspective,
rotation, and cropping. Those iop will be really simpler to
maintain/understand/enhance.
*but* the problem is that ATM this is not possible. Here's is a
*proposal* for adding "iop replacement" possibility to our iop api :
info can be found here :
https://github.com/AlicVB/darktable/blob/cr_replace2/doc/iop_replacement.txt
but, to summarize :
- iop API :
- Add "int accept_external_params(struct dt_iop_module_t *self,
char *iop_name, int params_version)" to iop api (optional, return 0 if
not implemented)
- Add "int handle_external_params(struct dt_iop_module_t *self,
char *iop_name, void *previous_params, void *extern_params, void
*new_params)" to iop api (optional, return 0 if not implemented)
- Add a new module flag "IOP_FLAGS_REPLACED"
- history stack loading :
- Once we have have load the history stack, we go through all
history entries, and replace those with IOP_FLAGS_REPLACED by calling
accept_external_params and handle_external_params fct.
I've done an experimentation here :
*DISCLAIMER* : this *will* destroy your history stacks so test it with
something like --library :memory: and import test images only !
(especially this will *remove* all flip/clipping entries without
replacing all their features)
now that you are warned :
https://github.com/AlicVB/darktable/tree/cr_replace2
What is done : implement a new 'rotate' iop, which replace flip iop
and clipping iop. This is just a quick hack to be sure the design
works, not a "full feature" code ! (clipping iop is not fully replaced
(perspective and cropping), not "hidden", rotate iop is not in
iop_dependency, and so on...)
Please have a look, and comment.
Once we agree (or not), I'll do (or not) the rest of the
implementation. Again it's just a *proposal* ...
Thanks for your review.
AlicVB
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to
darktable-dev+unsubscr...@lists.darktable.org
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
