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

camera whitebalance reference value changed to 25000 K #14498

Closed
MStraeten opened this issue May 13, 2023 · 9 comments · Fixed by #14515
Closed

camera whitebalance reference value changed to 25000 K #14498

MStraeten opened this issue May 13, 2023 · 9 comments · Fixed by #14515
Assignees
Labels
bug: pending someone needs to start working on that priority: medium core features are degraded in a way that is still mostly usable, software stutters reproduce: confirmed a way to make the bug re-appear 99% of times has been found
Milestone

Comments

@MStraeten
Copy link
Collaborator

Describe the bug

the camera reference value changed from 6502 to 25000
current master:
image
last build 6.5. (darktable-4.3.0+2172~ga4a48485bc):
image

Steps to reproduce

  1. expand whitebalance module
  2. check camera reference setting

Expected behavior

No response

Logfile | Screenshot | Screencast

No response

Commit

tbd: darktable-4.3.0+2172~ga4a48485bc (6.5.)

Where did you install darktable from?

self compiled

darktable version

darktable-4.3.0+2254~g09d99ce81f

What OS are you using?

Mac

What is the version of your OS?

MacOS Ventura

Describe your system?

No response

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

not relevant

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

No response

@Nilvus
Copy link
Contributor

Nilvus commented May 13, 2023

With 4.3.0+2236~g46414573f2, I still have 6502k on white balance. And commit just after is Rawspeed module update (last commit of may, 10th). I can't test by now commits after but maybe there's something about that, or something camera specific.

@kmilos
Copy link
Contributor

kmilos commented May 13, 2023

IIRC, this is common on Sonys?

@gi-man
Copy link
Contributor

gi-man commented May 13, 2023

I'm seeing the same. Olympus ORF, Fedora 37, 4.3.0~git2266.004b30d0

edit: The image looks correctly. Older edits also show the 25k.

@Nilvus
Copy link
Contributor

Nilvus commented May 14, 2023

I can reproduce after updating from 4.3.0+2236~g46414573f2 to latest master. With 4.3.0+2236, I still have 6502K (I'm using a Panasonic G9) and now, with latest master, I also see 25000K. So there's an issue on a recent update (Rawspeed one?).

@Nilvus Nilvus added priority: medium core features are degraded in a way that is still mostly usable, software stutters reproduce: confirmed a way to make the bug re-appear 99% of times has been found bug: pending someone needs to start working on that labels May 14, 2023
@Nilvus
Copy link
Contributor

Nilvus commented May 14, 2023

Just an add: seems to be a display infos issue. If I click on pen icon, I still have 25000k value but image become black. If I come back to bulb icon, 25000k is still displayed but image come back to correct and wanted display. So real value is probably still 6502K when on bulb icon but UI display 25000K).

@Nilvus Nilvus added this to the 4.4 milestone May 14, 2023
@Nilvus
Copy link
Contributor

Nilvus commented May 14, 2023

I've done some bisect and seems that issue come from #14143 PR. @ralfbrown, as it's yours, do you have any idea about that issue?

@ralfbrown
Copy link
Collaborator

Not yet, other than that it seems something is not being initialized anymore - switching from camera ref to user-defined by clicking on the pencil icon gets 0/0/0 wb coefficients.

@sg456
Copy link

sg456 commented May 16, 2023

I noticed that it's not only the camera reference value that is affected, but all other wb presets as well. I use legacy WB often, so that was how I noticed it.

@ralfbrown
Copy link
Collaborator

Yes, there's something broken in how the slider values transfer among each other - changing the channel multipliers doesn't change the displayed temperature or tint and vice versa.

But once the display goes black after manually changing temp/tint, it can be restored by changing the values of all three channel coefficients, in either direction....

Commit 8df1fb1 is definitely the culprit, but it doesn't modify anything in src/iop/temperature.c, and most definitely not anything GUI-related. So I will have to dig in to see what broke.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug: pending someone needs to start working on that priority: medium core features are degraded in a way that is still mostly usable, software stutters reproduce: confirmed a way to make the bug re-appear 99% of times has been found
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants