Skip to content

fix(color): use the sRGB exponent when linearising linear-raw files - #1633

Open
pluja wants to merge 1 commit into
CyberTimon:mainfrom
pluja:fix/srgb-exponent-linear-raw
Open

fix(color): use the sRGB exponent when linearising linear-raw files#1633
pluja wants to merge 1 commit into
CyberTimon:mainfrom
pluja:fix/srgb-exponent-linear-raw

Conversation

@pluja

@pluja pluja commented Aug 29, 2026

Copy link
Copy Markdown

srgb_to_linear in src-tauri/src/raw_processing.rs raises to the power of 3.0. The inverse sRGB transfer function uses 2.4:

C_linear = ((C_srgb + 0.055) / 1.055) ^ 2.4

sRGB is: a linear segment below 0.04045 and this power curve above it. The two have to meet at that threshold. With 2.4 they do. With 3.0 the curve jumps 76% at the join. The constants already in the function (0.055, 1.055, 12.92, 0.04045) come from the sRGB definition and only produce a continuous curve with exponent 2.4.

The rest of the codebase already uses 2.4. Same formula, same constants:

  • src-tauri/src/image_loader.rs:60
  • src-tauri/src/image_processing.rs:1215

Only raw_processing.rs differs.

This only affects files where is_linear_raw_format() is true (RawPhotometricInterpretation::LinearRaw) and apply_ungamma is set, so the gamma and gamma_skip_calib values of the linear_raw_mode setting. Bayer and X-Trans files never reach this branch.

Note: This was introduced in f00ea84, which added the linearisation step rather than tuning an existing one, so the exponent looks like a slip rather than a deliberate curve.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Performance improvement
  • Code refactoring
  • Documentation update
  • UI/UX improvement
  • Build/CI or Dependency update

Changes Made

One line in src-tauri/src/raw_processing.rs:

-        ((value + 0.055) / 1.055).powf(3.0)
+        ((value + 0.055) / 1.055).powf(2.4)

Screenshots/Videos

Not applicable, no UI change.

Testing

  • These changes were tested locally by a human and confirmed to work.
  • I haven't added any automated tests to the code because the codebase currently lacks a test suite.

cargo check --no-default-features --all-targets passes with no new warnings.

I could not verify this against a real LinearRaw file, since I do not have one. The change is a correction to a published constant rather than a behavioural guess, but someone with a LinearRaw source should confirm it before merging.

Test Configuration:

  • OS: Arch Linux
  • Hardware: N/A

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

AI Disclaimer:

Please state the involvement of AI in this PR:

  • This PR is created by an AI agent
  • This PR is mostly AI-generated but edited/merged together 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)

Claude found the incorrect exponent and made the change. I reviewed it, verified it builds, and am submitting it.

The inverse sRGB transfer function raises to 2.4, not 3.0, so LinearRaw files
were being decoded with a curve far darker than the one their data was
encoded with.
@pluja
pluja requested a review from CyberTimon as a code owner August 29, 2026 15:46
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.

1 participant