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

Dynamic Profile Rules application when picture is selected in File Browser #6803

Draft
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

Bezierr
Copy link
Contributor

@Bezierr Bezierr commented Jul 27, 2023

This proposal refers to my question in the forum https://discuss.pixls.us/t/dynamic-profile-rules-application-in-file-browser/38529

The idea is to evaluate Dynamic Profile Rules whenever a picture is selected in File Browser for the first time.

Code is motivated by function "rankingRequested" in rtgui/filebrowser.cc because I noticed that this evaluation is done whenever I change the star rating of a picture.

What I'm unsure about: Function "rankingRequested" contains calls to "beginBatchPParamsChange" and "endBatchPParamsChange". It's not clear to me what exactly these calls do, and if something similar might be needed here. It seems to work without, but ...

As always with my unsolicited potential contributions, feel free to reject if this is not something you'd like to have in general RawTherapee

@Lawrence37
Copy link
Collaborator

The dynamic profile should ideally be applied when the image is first edited by any means (opened in editor, batch editor used, partial profile pasted/applied, etc.). Doing it upon selection is unintuitive in my opinion.

@Bezierr
Copy link
Contributor Author

Bezierr commented Aug 21, 2023

Hi @Lawrence37,

Thank you for your feedback. I've thought about and played with it, and see the following options ("initialize" refers to first application of dynamic profile when using batch editor):

  • (1) Initialize when, and only when, some value is changed in batch editor.
    This, however, results in a very bad user interface:
    -- How am I to know which values to batch edit if I don't see what the picture will actually look like? I ended up just pulling any slider only to initialize. Which, of course, is not the idea.
    -- First batch editing may show confusing behavior. For example, moving "exposure" to the left may actually result in brightening the image if dynamic profile contains a curve (it does, in my case).
    -- The right panel may change as a consequence of initialization, leaving your mouse not where you intended it to be.

  • (2) Initialize whenever it is possible that some value will be changed in batch editor. Effectively, this would mean: Whenever some pictures are selected and right panel is then switched to batch editor, or whenever batch editor is selected in right panel and subsequently some pictures are selected.
    -- Advantage: RT behavior is the same as today for those who never use batch editor.
    -- Disadvantage: For someone unaware of the underlying mechanism, the behavior may be confusing because sometimes for no apparent reason some pictures are initialized, and sometimes they aren't.
    -- (I have not checked how feasible it would be to implement this.)

  • (3) Initialize whenever a picture is selected.
    -- Advantage: Consistent behavior.
    -- Disadvantage: Change to current behavior.

  • (4) Initialize whenever pictures are "loaded" into RT, i.e. you switch to a different folder in file browser.
    This would be similar to Lightroom's preview creation right after image import. However, in Lightroom this only affects database entries which can be set to be automatically deleted after some time. In RT, over time, this would lead to thousands of .pp3 files that you neither want nor need, scattered all over the place. So I think it's not a good idea.

  • (5) Don't change RT code but use "reset to defaults" workaround before batch editing is to be done.
    -- Advantage: Why fix a problem that apparently noone but me has encountered?
    -- Disadvantage: Manual step involved that is likely to be forgotten; loss of work if manual step is applied at the wrong time.

Do you have any other ideas? What is your proposal?

(In case you opt for (5) I'd continue to use (3) in my local copy of RT because it best suits my personal use case. May be quite different for other users, of course.)

@Lawrence37
Copy link
Collaborator

I've been thinking about this and here's my reasoning.

Let's start with the goal which is to apply the dynamic profile. The question that comes to mind is when does it get applied. It must be either when explicitly requested or automatically at some other time. If the second one, it should not take the user by surprise. Doing it after the thumbnails have been loaded fails the criteria, or at least I can't think of any way to do this. Imagine having an image change suddenly without requesting it to. Doing it before the thumbnails are loaded doesn't make sense either. Unlike darktable, RawTherapee doesn't have libraries/collections so RawTherapee would have to crawl the entire file system. Not good. That leaves applying the profiles while generating the thumbnails. Some users may want this. I'm OK with having this as an option. Not everyone will want it and it can make opening a folder slower, so it should be an opt-in option. The default behavior is to only apply the profile upon request.

If manually changing the parameters, as you pointed out, it's ideal to give the user enough information to understand what adjustments to make. The two parts to this are the parameters and the preview of the starting point. For the parameters, we'll just load the correct dynamic profile instead of the neutral profile as we do now. For the preview, I think it should be all or nothing for consistency. Either show the preview for all images, or show the embedded thumbnail. Half of the first option already exists. There's an setting to show the raw data instead of the embedded thumbnail. The only thing missing is applying the dynamic profile to generate the preview instead of the neutral profile. If the file browser is configured to show the embedded preview, there's no reason to show the dynamic profile unless requested by the user. You're right it's weird to have to move a slider to see the update, but this can be remedied by adding an easily accessible button to apply the dynamic profile to the selected image(s).

For this approach, the necessary changes are:

  • Add option to apply dynamic profile upon opening a folder (Actually, this part is not strictly necessary, just nice to have)
  • When the user selects a picture, load the dynamic profile values into the tool panel instead of the neutral profile
  • When generating a thumbnail from the raw image and no pp3 exists, use the dynamic profile instead of neutral
  • Add a button for applying the dynamic profile

@Beep6581 Beep6581 marked this pull request as draft August 28, 2023 19:55
@Bezierr
Copy link
Contributor Author

Bezierr commented Oct 13, 2023

Again, thanks for your comments and sorry for the delay on my side.

Your bullets #2 and #3: Not sure I understand. Do you distinguish between "loading dynamic profile values into tool panel" and "use dynamic profile for creating a thumbnail"? Shouldn't that happen at the same time? And what should be that time -- when a user selects a picture (bullet 2), or when thumbnails are first created (bullet 3), i.e. when a directory is opened? Or some misunderstanding on my side?

Your bullet #4: If dynamic profile is applied when (a) user selects a picture and/or (b) generating a thumbnail, what situations would remain for using this button?

Anyway, the code I provided in this pull request is incomplete. There is a new version, in case you are interested. Approach is the same as before: In file browser, when selecting a picture for which no .pp3 exists, dynamic profile is applied and tools in batch editor are set. Works well for me -- but then, this is just me. Not sure in how far this matches what you have in mind with your bullets 2 and 3.

@Lawrence37
Copy link
Collaborator

Points 2 and 3 are distinct. Consider the current behavior if Show embedded JPEG is deselected. On opening a directory, any new raw image will get their thumbnail created using the Neutral profile. No pp3 file is created yet. On selecting the image, the batch edit tab loads the Neutral profile values because there is no pp3. The thumbnail generation and batch editor tool panel value loading happen at different times. Points 2 and 3 simply update the current behavior to use the dynamic profile instead of the Neutral profile.

Point 4 applies if Show embedded JPEG is selected. You won't see how the dynamic profile looks like on the image until you start making adjustments. The button applies the profile so you see the starting point and lets you figure out what adjustments you want to make.

The four points are the only changes needed in my opinion. No need to apply the dynamic profile when selecting an image because the four points cover all the cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants