Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lighttable : unexpected behavior of selective paste (all) in overwrite mode #17217

Open
cjose38 opened this issue Jul 28, 2024 · 17 comments
Open
Labels
no-issue-activity scope: DAM managing files, collections, archiving, metadata, etc.

Comments

@cjose38
Copy link

cjose38 commented Jul 28, 2024

Describe the bug

without knowing the origin, after several random uses, selective copy/paste in crush mode switches to stack mode (while leaving crush mode on display).
I use this mode a lot, copying everything and pasting everything to have the masks drawn and modified.
if you cycle from overwrite to stack and back again, it resets but then switches again.
I also had this reaction before the new version.

Steps to reproduce

  1. do a development.
  2. copy selectively, selecting all modules.
  3. paste selectively, selecting all modules. overwrite mode.
  4. check and compare the number of modules used in the photo.
  5. if the résult is good, delete the development en try again (delete opération make the bug for me).

Expected behavior

crush instead of stack

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.8.1

What OS are you using?

Windows

What is the version of your OS?

w10 pro

Describe your system?

No response

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

vokoscreenNG-2024-07-28_09-09-52.zip

@MStraeten
Copy link
Collaborator

What exactly is the issue? Where’s the switch to enable a global ‚crush‘ mode?

@pehar1
Copy link

pehar1 commented Jul 28, 2024

I suspect OS means lighttable -> history stack -> mode overwrite ?
Anyway, checked with fresh install of current master, for me selective copy in overwrite mode works. Or I don't understand the issue of OS ?

@victoryforce
Copy link
Collaborator

My understanding is that "selective pasting in overwrite mode changes to append mode after several uses".

@pehar1 BTW, what does "OS" mean in your comment?

@pehar1
Copy link

pehar1 commented Jul 28, 2024

Double typo, OP (original poster) is meant of course.

Edit:
checked again with fresh install of current master, imported four images, edited image 1

  1. lighttable -> history stack -> mode overwrite
  2. select first image, history-stack -> selective copy -> select all -> ok
  3. select image 2 - 4, history stack -> selective paste -> select all -> ok
  4. keep image 2 - 4 selected, history stack -> discard history

repeated steps 2-4 several times -> no issue. Tried the same (steps 2-4) in append mode -> no issue.

@ralfbrown ralfbrown added the scope: DAM managing files, collections, archiving, metadata, etc. label Jul 28, 2024
@ralfbrown ralfbrown changed the title light table, selective gluing with crush reacts to stacking after several uses. lighttable: selective paste in overwrite mode reverts to append after several uses. Jul 28, 2024
@cjose38
Copy link
Author

cjose38 commented Jul 28, 2024

sorry for my English, I use deepl for the translation which is not exact and brings misunderstanding.

I've just tested on my laptop with w11 family and version 4.9.0+75~g753a3cd62d and I get the same behavior.
I'm attaching a video.

vokoscreenNG-2024-07-28_20-00-45.zip

@pehar1
Copy link

pehar1 commented Jul 29, 2024

Watched your video several times and tried to reproduce with a completely fresh current master, no initial XMP sidecar files for the imported test images, but I can't.

  • Did you take the video with a fresh install? I suspect not.
  • Do you have auto applied presets active possibly causing the issue ?

To try a fresh install (without any presets) yourself you could lauch darktable from the command line

/path/to/your/darktable --library /path/to/empty/librarydir/ --configdir /path/to/empty/configdir/ --cachedir /path/to/empty/cachedir/

@cjose38
Copy link
Author

cjose38 commented Jul 29, 2024

yes, the video with the night-time version is indeed a new installation. my laptop is new and i took the opportunity to install a night-time version. the one i'm working with is on a fixed workstation.
yes, i have presets applied to the opening. i've attached a style file so you can see which ones. for sharpness, i use a drawn mask (without a drawn mask and just with an initial level on the sharpness level), then i have instances with different settings that use this same mask in “raster”.
If, indeed, it's difficult to reproduce, chances are it's due to this configuration.

initial setup 1.zip

I'm going to run the test on my laptop anyway.

@MStraeten
Copy link
Collaborator

could not reproduce with my local windows 4.8.1 build.
just the mandatory moduels (even if not selected) + selected items are present in the new history stack

@pehar1
Copy link

pehar1 commented Jul 29, 2024

new installation

Yes, a new installation of the binaries, but using your previous configuration files in ~/.config/darktable ? Otherwise you would not have the presets available stored in ~/.config/data.db.
Can you check if the issue is still present if you

  • start dt without your data.db (rename it or move it to another location)
  • or better : rename the folder ~/.config/darktable to force dt to create a complete fresh configuration
  • or use the command (adapted to your system) from my previous comment to do this.

If the issue does not persist with a fresh config the cause for your problem is located in your personal config.

Edit:

attached a style file

I meant auto applied presets (for specific modules) not a style which is not applied automatically but on demand.

@cjose38
Copy link
Author

cjose38 commented Jul 29, 2024

I've renamed the database directory, I've got the standard modules applied. I've modified the filmic module and the exposure. I've compressed the history. I've selectively copied all the history. I've copied in overwrite mode and I've got a result in stack mode.
I wonder if this isn't linked to the custom module names.

see screenshots.

the style file sent earlier corresponds to the modules that apply when the image is opened in the darkroom. i didn't know how else to send them.
copied
pasted

@pehar1
Copy link

pehar1 commented Jul 30, 2024

OK, I think I got it.

  • you have two (or more) nearly identical images
  • you develop one image
  • you want to make the other images look the same (have the same history stack)
  • use copy / paste in overwrite mode (not selective) in this case

Selective copy / paste (even in overwrite mode) works different. It is designed to selectively copy parts of the history stack. In this case stack entries of the source overwrite stack entries of the destination only, if their descriptions match, otherwise they are appended. This makes it possible to work with several instances of a module, for example

  • exposure (defaults)
  • exposure
  • exposure (brighten sky with mask)

where exposure would never overwrite one of the others and vice versa. Selective copy should only be used if you really want to do a selective copy and the entries to be copied should be selected well-considered. If you blindly copy "all" this is a "misuse" of this function and you might get unexpected results.

So in my opinion the behaviour you described is as designed. If this explanation is satisfactory for your problem, you can consider closing this issue. BTW, it might be useful to change the title again, it is misleading. The overwrite mode does not revert to append.

@cjose38
Copy link
Author

cjose38 commented Jul 30, 2024

Yes, that's the way I do it.
I use copy with selection because it also copies masks drawn as paths, circles, ... which global copy/paste doesn't do.
if it's a bird on a branch with a complex shape, i move the mask, adjust a few points and it's ok, ... i don't have to redraw the whole thing. ditto for an eye to which i often add sharpness with a circle, i just have to move it.
depending on the type of photo, I may not need to copy the cropping, retouching, etc. module.
I use the function in stack mode when I come back to a group of photos already developed and only change the white balance (for example) and this only modifies the result linked to this module without touching the others.
but if that's not what I'm aiming for, I'll adapt: compressing the history removes all redundant lines.
I'll let you change the title as I don't master the subtleties of English (with DeepL).
I'll close the topic after modification because I don't know, if I do it now, if it will be possible to modify the title.

Translated with DeepL.com (free version)

@pehar1
Copy link

pehar1 commented Jul 30, 2024

Using selective copy is absolutely ok, just don't copy all modules, but only the ones you really need.
You can change the title by editing your original post. Go to the first post, select the ... icon (top right), select edit. I have not the permissions to do it for you. New title might be

Lighttable : unexpected behavior of selective paste (all) in overwrite mode

Title can be changed even if the issue has been closed, it stays available in section "closed", can be reopened if needed.

@cjose38 cjose38 changed the title lighttable: selective paste in overwrite mode reverts to append after several uses. Lighttable : unexpected behavior of selective paste (all) in overwrite mode Jul 30, 2024
@MStraeten
Copy link
Collaborator

i think i get an idea on the issue:

the behaviour of selective copy / paste (i.e. ctrl+shift+c / ctrl+shift+v) within darkroom depends on the mode setting of 'history stack' module in lighttable which is not expected, as you can't see the setting when doing copy paste in darkroom

if in lighttable view that mode is set to "overwrite" then selective paste also overwrites the whole history stack also in darkroom instead of just pasting the selected module on top of the history stack.

So to be able to copy paste selected modules from one edit to another you need to check the mode setting in lighttable view first.

better customer experience: within darkroom view the mode setting of lighttable view is ignored

@cjose38
Copy link
Author

cjose38 commented Aug 1, 2024

i think i get an idea on the issue:

the behaviour of selective copy / paste (i.e. ctrl+shift+c / ctrl+shift+v) within darkroom depends on the mode setting of 'history stack' module in lighttable which is not expected, as you can't see the setting when doing copy paste in darkroom

if in lighttable view that mode is set to "overwrite" then selective paste also overwrites the whole history stack also in darkroom instead of just pasting the selected module on top of the history stack.

So to be able to copy paste selected modules from one edit to another you need to check the mode setting in lighttable view first.

better customer experience: within darkroom view the mode setting of lighttable view is ignored

I'm not sure I understand, but I don't use keyboard shortcuts.

@pehar1
Copy link

pehar1 commented Aug 1, 2024

@MStraeten within darkroom

Hmm, I'm not sure. @cjose38 explicitely mentions lighttable in his title, even in the first version before it has been modified two times. And he also explicitely mentions (point three of original post) that he uses overwrite mode.

As I understand it, the problem is different:

  • he has applied a larger number of presets for different modules
  • he changes setting(s) of one or more of these modules

As a result, there are now two (or more) entries for these modified modules in the history stack with different names:

  • module x
  • module x (auto applied defaults)

Now this stack is copied selectively (all). As a result, there are now two entries for module x in the stack of the target image, while OP expects module x to overwrite module x (auto applied defaults).

This also remains valid if the stack of the source image is compressed before copying. In this case, only

  • module x

would remain and be copied, but module x does not overwrite the auto applied module x (auto applied defaults) of the target image in this case either.

@cjose38 I'll adapt: compressing the history removes all redundant lines.

I think this is the correct solution of this "issue".

Copy link

github-actions bot commented Oct 1, 2024

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-issue-activity scope: DAM managing files, collections, archiving, metadata, etc.
Projects
None yet
Development

No branches or pull requests

5 participants