Auto adjust image improvements: Overexposure reduction and removes UI thread block

[moschmdt]

Description

The issue is already described extensively in #568.
Additionally, the auto adjust for multiple images has been put in a thread not blocking the UI and includes a progress indicator now.

Type of Change

• Bug fix
• Code refactoring
• UI/UX improvement

Changes Made

• Add blacks/whites to the AutoAdjust structure to counter high exposure
• Reduce the scaling variables
• Name the scaling variables, so in the future something like custom configs could be possible for auto adjust.

Screenshots/Videos

Previous behavior see #568.

Testing

• I have tested these changes locally and confirmed that they work as expected without issues

Test Configuration:

• OS: macOS Tahoe
• Hardware: M1 Pro

Checklist

• My code follows the project's code style
• I haven't added unnecessary AI-generated code comments
• My changes generate no new warnings or errors

Additional Notes

AI Disclaimer:

Please state the involvement of AI in this PR:

• This PR is entirely AI-generated
• This PR is AI-generated but guided by a human
• This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
• This PR contains only blood, sweat, and coffee (AI-free)

[CyberTimon]

Thanks for your PR. Can you please just commit the backend changes, as the UI side will follow a different design?

[moschmdt]

Done! Thank you for creating this project!

[CyberTimon]

@moschmdt Thanks so much for the quick change! Very nice. Can you please lastly remove the AI code comments or keep them to a very minimum (just the ones absolutely needed) and fix the merge conflict? In the last version, I've already moved the processing to a seperate thread, so probably just the improved auto adjust algorithm is needed. Thanks!

[moschmdt]

I will have a look at it!

What do you think about exposing the variables for the auto-adjust algorithm via settings to the user to fit the user’s expectation more precisely/ make experimentation easier without recompile?

[moschmdt]

@CyberTimon all the changes are there you requested. I also fixed an issue where the brightness was not included in the auto edit.

I have two more questions/ requests that would be reasonable to add I guess:

1. The perform_auto_analysis currently takes approximately 4 seconds per image (M1 Pro). A lot of time (99 % according to profiling) is used on loading the image with load_base_image_from_bytes() with the use_fast_raw_dev=False. If this would be turned to true the process would take approximately 500 ms per image. I think this would be a reasonable step, since the image is scaled down to ANALYSIS_MAX_DIM=1024 afterwards anyway. I checked with some images and the changes appear to be minimal, if noticeable at all.
2. apply_auto_adjustments_to_paths is in a separate thread but does not make use of the Rayon thread pool. Should I add it?
3. I added a binary to time the process for multiple images in a temporary folder (not synced with git). Developers would need to add there own set of images to test this. Do you want this in the main repo for future testing?
4. I do not see an option in the UI to cancel the auto adjustment process?

[CyberTimon]

Hi @moschmdt

Thanks for your update! Looks very good to me.

To get to your questions:

1. Yes, feel free to add this :). Just double check that the adjustments don't degrade a lot (because f32 highlights values from the fast demosaiced image differ a lot from the original (this is a seperate bug))

2. Definitely, feel free to add this too.

3. How big of a change is this / how would that look like?

4. Right, there is nothing to cancel this yet. To keep it consistent with other batch operations (e.g. batch denoising, batch negative conversion etc.), we shouldn't add this here yet, but add a global and consistant batch operation stopper at some point.

Thanks a lot for your work!

Timon

[moschmdt]

1. Done

2. I missed the double par_iter() that already makes use of rayon, so no changes there. Instead, what kept it slow is the two `par_iter loops: one for image loading and adjustments and one for thumbnail generation. Now they are combined. Computing and applying auto adjustment to 85 RAW images now takes approximately 12 seconds :)

3. It's a separate rust file built as binary with ~ 150 lines of code + 5 lines in cargo.toml. Can also easily be generated by AI if the need arises in the future, so I think leaving it out for now is better. I will push it to a branch in my fork if you are interested, see fix-multiple-auto-adjust-performance for the rough idea.

4. Okay

[moschmdt]

@CyberTimon ready to merge from my side when you do not have any other requests. :)

[CyberTimon]

Amazing! Looks good to me, will merge now. The results are much better now! 💯