Sorry for being contrary, but... wouldn't that be an odd kind of reset? After all, as I understand reset, it's supposed to reset values back to the original, as if this module is entered for the first time with that image, isn't it?
Cheers, Richard In message <5130fe08.7080...@frontier.com> on Fri, 01 Mar 2013 11:14:16 -0800, David Vincent-Jones <davi...@frontier.com> said: davidvj> Something annoying that I have noticed working with this module: davidvj> The 'reset' button not only puts all of the sliders back to central position but it also forces davidvj> the aspect back to 'image'. Would it be possible to leave both the aspect and guides as previously davidvj> set? davidvj> davidvj> David davidvj> On 13-03-01 06:03 AM, Richard Levitte wrote: davidvj> davidvj> Hi, davidvj> davidvj> I just had a closer look, and summary of it all: I like! davidvj> davidvj> I have found one thing that differs from before... not sure if this davidvj> is something you care about or not, but... before your changes, the davidvj> code would adapt the aspect ratio to the original picture format. For davidvj> example, if I chose 5:4 and the picture is vertical (portrait), the davidvj> aspect ratio would automagically be auto-flipped to 4:5. This isn't davidvj> happening in your branch. It's really a small thing, I'm not even davidvj> sure if I'd be annoyed... davidvj> davidvj> Also, while speaking of flipping the aspect ratio, I've always davidvj> wondered if the aspect flipping shouldn't be saved... from looking at davidvj> your code, all the needed changes would be in aspect_presets_changed, davidvj> all that's needed is to care about the sign of d and p->ratio_d, davidvj> wouldn't it? davidvj> davidvj> Last comment, from the pure code management point of view; I noticed davidvj> that the aspect ratio data exists in three places in the code. My gut davidvj> feeling says that this can be a source of errors (inconsistent updates davidvj> of numbers). I'd suggest having those numbers in a constant array, davidvj> ratios[RATIO_COUNT][2] or something like that and use those... davidvj> davidvj> The way I see it, this does replace PR 159. I'll simply delete the davidvj> corresponding branch. davidvj> davidvj> Cheers, davidvj> Richard davidvj> davidvj> In message <512d2421.9090...@gmail.com> on Tue, 26 Feb 2013 22:07:45 +0100, AlicVB <alic...@gmail.com> said: davidvj> davidvj> alic.vb> Hi all, davidvj> alic.vb> I finally let the mask in paused for 1 or 2 days and work on correcting davidvj> alic.vb> bug in C&R. davidvj> alic.vb> I've created a new branch on main repo for that : CR_fixes davidvj> alic.vb> Currently here's what has been done : davidvj> alic.vb> 1- save changes done with cropping area even if the pipe is still davidvj> alic.vb> working (bug #9245) davidvj> alic.vb> 2- save ratio in image params (should close lot of bugs/feature request davidvj> alic.vb> like #9151 or #9143 and replace somehow PR #159) davidvj> alic.vb> 3- avoid cropping area to "jump" when C&R module get focus davidvj> alic.vb> 4- exported image now respect exactly the ratio (partially fix #9148) davidvj> alic.vb> 5- different little other fixes davidvj> alic.vb> davidvj> alic.vb> The main "tricky" point is 4 : davidvj> alic.vb> this indeed correct a "bug", but the weird effect is that it will change davidvj> alic.vb> the exported size of all already processing pictures. The change is not davidvj> alic.vb> really big (max 6 pixels) but... davidvj> alic.vb> And I don't think it's possible to handle that in legacy_params, because davidvj> alic.vb> we would need to access the whole pipe, or at least all other distort davidvj> alic.vb> modules to do that (the size change is dependent of the size of the davidvj> alic.vb> image just before C&R is applied, so after all previous iop have been davidvj> alic.vb> applied) davidvj> alic.vb> davidvj> alic.vb> If some of you have other bugs to fix - in C&r, I mean ;) - please try davidvj> alic.vb> the branch to see if it's still present and report it. If you are lucky, davidvj> alic.vb> I'll be able to correct it ! davidvj> alic.vb> davidvj> alic.vb> Oh, and as usual : backup _everything_ before testing. I've upgraded C&R davidvj> alic.vb> params. The upgrade should be handle properly, but not the downgrade ;) davidvj> alic.vb> davidvj> alic.vb> Thanks for your comments and tests. davidvj> alic.vb> Aldric davidvj> alic.vb> davidvj> alic.vb> ------------------------------------------------------------------------------ davidvj> alic.vb> Everyone hates slow websites. So do we. davidvj> alic.vb> Make your web apps faster with AppDynamics davidvj> alic.vb> Download AppDynamics Lite for free today: davidvj> alic.vb> http://p.sf.net/sfu/appdyn_d2d_feb davidvj> alic.vb> _______________________________________________ davidvj> alic.vb> darktable-devel mailing list davidvj> alic.vb> darktable-devel@lists.sourceforge.net davidvj> alic.vb> https://lists.sourceforge.net/lists/listinfo/darktable-devel davidvj> davidvj> ------------------------------------------------------------------------------ davidvj> Everyone hates slow websites. So do we. davidvj> Make your web apps faster with AppDynamics davidvj> Download AppDynamics Lite for free today: davidvj> http://p.sf.net/sfu/appdyn_d2d_feb davidvj> _______________________________________________ davidvj> darktable-devel mailing list davidvj> darktable-devel@lists.sourceforge.net davidvj> https://lists.sourceforge.net/lists/listinfo/darktable-devel davidvj> ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel
