I'm not a programmer of any sort so take what I say with a grain of salt. When I compress the history, I like it to be clean so sometimes, there is/are module(s) with "(off)" in the compressed history. So what do I do? I enable them, then turn them off again so that they appear at the top of the list (visibly) with "(off)", then I click on the top module that doesn't have "(off)", compress the history again and the "(off)" modules disappear from the compressed history.
It sounds like, from above: para...@paraf.in (2019-Jun-10, excerpt): > I think we still have default-on modules not recorded in history > stack (highlight reconstruction and white balance), so removing all > “off” steps might modify the image. that what I've done might modify the image. I haven't noticed any changes and really, there shouldn't be any changes: if a module has been used, modified and then turned off, any effect the module might apply with the modifications made within it, no effects should happen when it is off. Isn't that what we do to see if we like what the changes we've made to a module will do to an image, turn it on and off and if we don't like it, we either modify it or just keep it turned off? Surely, we can't turn off a module yet have some residual effect on the image? What I'm saying is that if a module appears in the compressed history with "(off)", this "flag" should be all that's required to remove it. Jules On Mon, Jun 10, 2019 at 11:30 AM <dt-l...@stefan-klinger.de> wrote: > para...@paraf.in (2019-Jun-10, excerpt): > > I think we still have default-on modules not recorded in history > > stack (highlight reconstruction and white balance), so removing all > > “off” steps might modify the image. > > Hmmm. So if I understand you correctly, the problem is that removing > all unused modules would be a problem for some "special" modules which > are not recorded on the stack but are on by default, and have then > been disabled by the user. I observe this with "white balance": > > * disable "white balance" > > * compress history stack with removing unused modules > > * => white balance is automagically enabled again, changing the > image. > > Correct? I do not see any other problem. > > I could easily work around that by simply changing the query to > something like (yes, ugly) > > DELETE FROM main.history > WHERE imgid = ?1 > AND enabled == 0 > AND module != <you need to tell me> > AND module != <you need to tell me> > AND module != <you need to tell me> > AND module != <you need to tell me> > > But that would add technological debt in order to get around a funny > design choice (or: Why are these modules not recorded on the stack?) > > > Best approach would be to record all applied iops to history, but > > it’s a little tricky due to backwards compatibility > > I agree. > > Basically I see the question as this: Are these modules special (then > I must work around them, or they must not have the ability to be > disabled) or they are not (then they must be recorded to the history). > > For the backwards compatibility: I have not checked, but I hope that > there is versioning informaton in the XMPs. If so, new stacks should > have white balance added, and old stacks could be recognised and > migrated by adding the default white balance to their stacks. > > > -- > http://stefan-klinger.de o/X > I prefer receiving plain text messages, not exceeding 32kB. /\/ > \ > ___________________________________________________________________________ > 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
