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.

Sign up for GitHub

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

Jump to bottom

jp2 files and faststone #18394

Open
1 task done
MichelNieuw opened this issue Feb 10, 2025 · 9 comments
Open
1 task done

jp2 files and faststone #18394

MichelNieuw opened this issue Feb 10, 2025 · 9 comments
Labels
scope: image processing correcting pixels

Comments

@MichelNieuw
Copy link

Is there an existing issue for this?

  • I checked and did not find my issue in the already reported ones

Describe the bug

When I export a file as JP2000 JP2 file, faststone seems to read it but the picture is far too bright. I have no possibility to find if it is a problem from darktable or from faststone

Steps to reproduce

open a ARW file (in my case)
do processing
save as JP2 file
open this file in faststone

Expected behavior

export correctly

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

darktable.org / GitHub release

darktable version

5.0.0

What OS are you using?

Windows

What is the version of your OS?

Windows 11

Describe your system

No response

Are you using OpenCL GPU in darktable?

I dont know

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

No response
@victoryforce
Copy link
Collaborator

Describe the bug

When I export a file as JP2000 JP2 file, faststone seems to read it but the picture is far too bright. I have no possibility to find if it is a problem from darktable or from faststone

You can import the exported file into darktable, this will show you whether there is a problem with faststone or not.

Steps to reproduce

open a ARW file (in my case) do processing save as JP2 file open this file in faststone

It's not reproducible here. It's likely that this effect was caused by some specific processing, such as the effect of some processing module. So, in order for us to understand what is the matter, we need an image on which you observe the described behavior and the corresponding xmp sidecar file.

@ralfbrown ralfbrown added the scope: image processing correcting pixels label Feb 12, 2025
@MichelNieuw
Copy link
Author

MichelNieuw commented Feb 19, 2025 via email

@victoryforce
Copy link
Collaborator

I cannot send you the complete output file from Darktable. So I cropped it a little (sample1DT_cropped.jp2)

You didn't actually send anything. You probably weren't aware, but GitHub doesn't support receiving attachments via email replies to comments. So please provide the required images via the web interface.

@MichelNieuw
Copy link
Author

  1. open a jp2 sample file from the internet in faststone and darktable:
  2. opens OK in both and looks OK
  3. Now in Darktable save the sample file without any changes as jp2 file with the settings as in the attachment.
  4. Open the saved sample file again in faststone or darktable: The result is a picture with far too much brightness
    Conclusion: Sonething wrong with saving the jp2 file by Darktable

Image

SINCE I CAN NOT ATTACH A JP2 FILE FOR SOME REASON YOU CAN FIND THE SAMPLE FILE HERE:
https://sample-files-online.com/samples/jp2

@kmilos
Copy link
Contributor

kmilos commented Feb 28, 2025 •
edited
Loading

You're exporting w/ an HDR PQ transfer curve (dt's 1.0 = 10000nits in the current implementation since it is an absolute curve). As dt doesn't have a sophisticated HDR workflow yet, you'll need to manually pull the image exposure down by extra 5-6 EVs just before exporting to any PQ based profile, then restore exposure back.

Basically, this is the inverse of #18197

@kmilos
Copy link
Contributor

kmilos commented Feb 28, 2025 •
edited
Loading

@victoryforce Also, I don't see anywhere in the dt JPEG 2000 writer code that an output profile is actually set, so one shouldn't really use it w/ anything other than sRGB...? I.e. forget the 5-6 EV compensation comment above, you're probably just seeing the difference between PQ and sRGB curves.

@MichelNieuw
Copy link
Author

MichelNieuw commented Mar 1, 2025 via email

@kmilos
Copy link
Contributor

kmilos commented Mar 1, 2025

Ok, let me try to simplify it: currently it is not possible (i.e. it is broken) to export jp2 to anything else than the sRGB output profile, so you shouldn't set it to anything else in the export settings (PQ P3 like you did).

Thanks for uncovering this limitation though!

@TurboGit
Copy link
Member

TurboGit commented Mar 1, 2025

What is incomprehensible to me is that:

Default settings should just work ok.

But you've changed the default sRGB profile to use PQ P3 and you're still accusing darktable to be the cause of your problem.

@kmilos kmilos mentioned this issue Mar 1, 2025
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
scope: image processing correcting pixels
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@TurboGit @kmilos @ralfbrown @victoryforce @MichelNieuw