assign hdr metadata and display hdr images

Processing
, ,
9

the kind of processing involved by gimp or darktable reside in the relation there is between the 2 softwares and their respective ability to process the image during the encoding of this image into any type of container metadata or directly binarized, including .jxr, .tif, .exr, .hdr.
as respectively raster image editor tool and developping tool, they have the ability to register and encode the color space and the eotf (transfert function) at export necessary for any viewer on any os in order to display the outputted image as originally intended.
also gimp has a non functional extension for .jxr and darktable being a developper tool has some option to change the imput color space and transfert function.
however, no matter the setting selected in these cases (no settings in gimp except inexistant .icc color profiles for hdr, non functional imput profile rec. 2020 in darktable), none of these 2 software manage to export|process an image to be display correctly by any viewer on any os for target hdr 16 bpc rec. 2100 color range st. 2084 pq transfert function, becasue no matter the container used for export (.tif 16, .exr 16, .hdr 16, .png 16), the image still appears completely washed out and dull.

moreover, and completely independently from these 2 softwares, the issue is still a processing issue category when the question is basically about :
how to do hdr imagery in still photography ?
meaning how to export hdr 16 bpc rec. 2100 color range st. 2084 pq transfert function for it to be interpreted as intended by any viewer for instance [‘microsoft photos’, ‘hdr + wcg image viewer’] ?
which software to use ?
is there a way using gimp ? darktable ?
what other software can you use to export usable image to display in hdr ? any existing one or affinity photo is the only one able to do it ?
does someone knows a way to do hdr still imagery and display it at 16 bpc rec. 2100 color range st. 2084 pq transfert function ?
also and the big question is :
how do you process hdr .jxr images to other editable format without lossing the color space and eo transfert function information to later be display as hdr ? and not a completely washed out, dull, colorless srgb mock up ?
even imagemagick does not -identify the rec. 2100 color space and st. 2084 pq eotf when it s actually there and displayed correctly by microsoft photo : it -identify srgb while it s absolutely not the case, and concerning the original .jxr screenshots, impossible for imagemagick even with the recommended jxrlib in the environment variable path as recommended on the official website…

hence the previously presented tags : gimp, darktabe (in the maybe category), processing (obvious relation).

10

I’m afraid I don’t understand what you are saying.

You have hdr input files and want to process them, tonemap them and produce e.g. sRGB output?

Phrasing like

to process the image during the encoding of this image into any type of container metadata or directly binarized

or

no settings in gimp except inexistant .icc color profiles for hdr, non functional imput profile rec. 2020 in darktable)

confuse me.

During the years, many HDR images (including photos, demo and synthetic images as well) have been posted in the darktable category to help with development of its tone mapping features.

You say the images don’t look good when exported; do they look OK in the editor? In what colour space do you export? What colour space is your input? What processing do you perform? Can you share your darktable xmp sidecar files on OneDrive?

11

you have hdr input files and want to process them,

the input files are hdr screenshots in .jxr format so the color space is rec. 2100 and the eotf is st. 2084 pq.

tonemap them and produce e.g. sRGB output?

do not want to tonemap, just want to output in .exr, .hdr without loosing the embded hdr metadata by producing a rec. 2100, st. 2084 pq output.

to process the image during the encoding of this image into any type of container metadata or directly binarized

means that the objective is to process the image basically by remuxing it s binary information from 1 container [.jxr] to another for instance [.exr, .hdr]

no settings in gimp except inexistant .icc color profiles for hdr, non functional imput profile rec. 2020 in darktable)

to help get rid of your confusion involved by this phrasing you can try this :
-take an .hdr screenshot with the [xbox gamebar, nvidia shadowplay, obs, special k]
#you can use the ‘obs.jxr’ present in the onedrive link
the resulting image will be encoded in a .jxr container
_open it in gimp with the non functional extension
_export in [.exr, .hdr]
_open your 1st .jxr screenshot with microsoft photos and the [.exr, .hdr] with hdr + wcg image viewer
_notice the difference, the exported [.exr, .hdr] are totally blown out, washed out dull, colorless because they did not retain the hdr metadata.

_now, repeat step 1 but this time with a mono color bucket fill
_open it again
_notice how the color is not displaying in hdr

concerning darktable, there is a way to keep the hdr metadata while exporting in .jxr

During the years, many HDR images (including photos, demo and synthetic images as well) have been posted in the darktable category to help with development of its tone mapping features.

interesting ! can you send some links ?

You say the images don’t look good when exported; do they look OK in the editor?

gimp and darktable does not report hdr to windows so they appear all washed out and dull

In what colour space do you export?

tried to export in rec. 2020 pq, but the result was nonesensical, tried to export in standard srgb and the resulting image displays as intended in hdr : it s like when you impose it another color space it looses the original hdr metadata (which is still a mystery on where it s located and how to detect it by the way).

What colour space is your input?

impossible to know exctly, exiftool and imagemagick reports ‘srgb’ wich is ridiculously incorrect, the image is hdr so it has to be rec. 2100

What processing do you perform?

the type of processing performed here is called a remux, alternatively called a container swap wich is the processing involving the transfert of the binary data in a file from a container to another without rencoding.

Can you share your darktable xmp sidecar files on OneDrive?

for darktable already found the capabilities and the limitations of the software : only able to export hdr content in .exr.

12

Does TIFF have the ability to signal that an image is HDR? (I think that you’d need to convince Adobe to add it)

You may be better off with PNG - it’s new editors draft includes the signalling required for HLG or PQ HDR. Some software has already included the new signalling.

13

Please search the forum, there have been discussions about HDR output from dt already. You might have best luck w/ AVIF.

For PQ output profiles (either 2020 or P3), you might want to drop exposure by approx 6EV just before export.

14

Most JPEG XR files I’ve seen are linearly encoded with sRGB gamut (Microsoft calls it scRGB - more detail on why in the next paragraph). Many viewers might assume that and behave badly if presented anything else. Note that if a viewer assumes linear data and you feed it something that is gamma or log-encoded it will appear EXTREMELY washed out - kind of the opposite of what happens when you misinterpret linear data as being gamma or log-encoded (extremely dark)

Before you say that sRGB gamut is too narrow - since JPEG XR encodes floating point values, it can encode out-of-gamut colors using negative values for R, G, or B. This is why MS calls it scRGB ( scRGB - Wikipedia ) - although in JXR, usage of float32 eliminates even the scRGB limitations discussed in that article - no practical limits on magnitude of negative or positive values.

JXR is used extremely rarely around here - the limit of my experience/knowledge with JXR is from JPEG XR (*.jxr) file format support · Issue #6612 · Beep6581/RawTherapee · GitHub and Python image conversion scripts - intended primarily for RawTherapee input but useful otherwise

Wrong, see above regarding scRGB with float representation

EXR is the same - nearly every EXR example I’ve found is linearly encoded using sRGB primaries, which again is NOT a gamut limitation in any float-based format that can encode negative values for color components.

Rec.2020 gamut + PQ or HLG transfer function is almost never used with float encoding, because the whole point of those is to work well with formats that rely on unsigned integers to represent everything (typically 10-bit unsigned integers). I would not be surprised if many JXR viewers assume sRGB primaries and linear encoding regardless of metadata, just like many JPEG viewers without proper color management assume sRGB primaries and sRGB transfer function.

JXR was designed to be easily viewable on sRGB displays - clamp all floats to [0,1], apply sRGB transfer function to the result, done. Yeah you clip highlights and clip gamut instead of a more appropriate tonemapping, but 95%+ of the population won’t notice. Especially since a lot of game developers tend to minimize their gamut/luminance excursions outside of the sRGB space since there’s such wide variety of HDR display capabilities right now.

15

I use ExifToolGUI.

If present, the .icc profile information is shown under the tab ‘All’

16

I use ExifToolGUI.

If present, the .icc profile information is shown under the tab ‘All’

sure !

but tried it ! as already presented confer supra : it does display completely incorrect informations, tagging an hdr .jxr screenshot, or an [.exr, .hdr] hdr image as srgb which is absolutely not the case.
exiftool is unable to detect and identify the rec. 2100 st. 2084 pq information that allows the viewer [microsoft photos, hdr + wcg image viewer] to display the image as intended in hdr.
try exiftool on the obs.jxr in the onedrive link, and try to identify where the hdr metadata is kept.
if there was no difference why [microsoft photos, hdr + wcg image viewer] would display the image as hdr while another image with the same 16 bpc would display completely washed out, dull, colorless ?
it s because there is an embeded information somewhere in the file wether hidden in the metadata where exiftool or imagemagick cannot detect it or even directly binarized in the image data, holding the [rec. 2100, st. 2084] information.

17

Again, this assertion is WRONG for a format that stores high-precision floating point data like EXR and JXR do, and have supported HDR and WCG since LONG before the Rec. 2100 or Rec. 2020 standards existed.

scRGB - published in 2003
JPEG XR - published in 2009 - which again effectively extends scRGB further by eliminating the -0.5/+7.5 limits by supporting float32 (EDIT: And float16, which is what the files you have provided are using)
Rec. 2020 - published in 2012
Rec. 2100 - published in 2016

Standard/typical encoding for JXR is linear transfer function and sRGB primaries, since floating point allows you to use negative numbers to represent out-of-gamut colors, and PQ/HLG transfer functions only make sense for low-bit-depth integer encoding.

EVERY JXR file I’ve ever seen was linear scRGB.

Both obs.jxr and xboxgamebar.jxr that you provided are linearly encoded scRGB (note since this is a high contrast scene the preview in this screenshot is pretty aggressively tonemapped - RT’s DRC tool, etc.:

image
image2050×1156 400 KB

Both obs.jxr and xboxgamebar.jxr are HDR (maximum value in each is 1.94, anything greater than 1.0 is outside of the normal sRGB transfer function), but do not contain any out-of-gamut information for sRGB (most negative number is -1.78881393e-06, which is practically zero)

1 Like
18

Sorry, I failed to understand most of your original post, it seems. And I didn’t really understand the above because I don’t shoot HDR either.

For my Sigma cameras there is a utility which extracts ALL the meta-data, not just the EXIF.

Perhaps there is such a utility for your camera model by which you may find the information you seek.

19

Feel free to comb through the JPEG XR spec and let us know where and how the colour space information is supposed to be encoded.

Being proprietary software, there’s no way to know what Microsoft’s image viewers support and implement for each format. (And seeing that they are pushing JPEG XR, they could be treating in a special way.)

As for the (linear) sRGB assumption, @Entropy512 just explained why it is a valid one for floating point EXRs and JXRs. Just to back this up, in the absence of explicit colour primaries, OpenEXR indeed assumes sRGB/Rec709 ones by default: https://github.com/AcademySoftwareFoundation/openexr/blob/6258740337bf3859ed8abcf8d99a1671b2cdd06d/src/lib/OpenEXR/ImfChromaticities.h#L36-L50

2 Likes
20

This is where you went wrong. You say it’s nonfunctional - so why did you use it?

Per that link:
“Almost all pixel formats supported by JPEG XR can be loaded. Incompatible formats, however, will first be converted to a representation that GIMP understands (this means you’ll loose HDR data, for example). All RGB pixel formats are converted to 24bpp RGB, all RGBA formats to 32bpp BGRA, and all grayscale formats to 8bpp Gray. Black-white images are imported as indexed images.”

Note that it didn’t say you lost HDR metadata - it says (as is expected when trying to cram float16 into an int8) that you will lose data

If you really want to create a Rec. 2100 encoded 10bpp image from a JXR, you can start with the Python tool I linked, but it’ll need quite a bit of work since doing that was unnecessary for the original purposes of that script - it was designed to generate TIFFs that could be ingested into RawTherapee, so it doesn’t alter the data at all and tags it as linear with sRGB primaries, which matches every JXR file I’ve ever seen. You will need to:

  • Calculate the appropriate matrix for converting an image encoded with sRGB primaries to Rec.2020 primaries, I’d suggest https://www.colour-science.org/ for that
  • Apply that matrix to the float32 numpy array representing your image data after the script loaded an image
  • At this point you should not have any negative numbers - if you do, you probably made a math error because it’s extremely unlikely (but possible) that the image contains colors outside of the Rec. 2020 colorspace. (negative float16/float32 numbers are a signal of either a bug or out-of-gamut colors)
  • Take your image data that is now floating point linear with rec. 2020 primaries, and apply the HLG or PQ transfer functions
  • Export as HEIC/HEIF with appropriate metadata - I can’t help you here. Or export as int16 linear Rec2020 TIFF then feed that to ffmpeg to create a video clip, see Experimenting with HLG and HDR10 for still images - #22 by Entropy512 for an example
2 Likes
21

@xpatUSA, no issue thank for answering as well !
@kmilos, thank for the link !

@Entropy512, thank for this excellent and very informative answer !

copy, about the details involvintg the floating point encoding, the relation between the the standard and the creation of the format, right.

ok copy ! so it s linear with negative numbers ! that explains everything !

This is where you went wrong. You say it’s nonfunctional - so why did you use it?

tried it at the begining of these investigations and now that you explain why you loose the metadat based on the description, it a lot clearer.

but it’ll need quite a bit of work since doing that was unnecessary

then do you know a usable format that supports it natively ?

so you are saying that the tiff are holding the out of range data in negative numbers bu the viewer does not find it as it finds it in [.jxr, .exr, .hdr] ?
is there a way to display .tif in hdr like the obs.jxr ?
what would you use to display and create .hdr images ?

so does it means that if you fill an image in blue max value, you export it as .exr, .hdr, will this image once displayed in microsoft photos, hdr + wcg image viewer be in hdr ? will the value coded to 255 blue will be the max value that the display can output in hdr ?

do you know editing software that reoorts hdr in the swachain besides affinity photo ?
do you know other softwares than windows photos, hdr + wcg image viewer that displays [.jxr, .exr, .hdr] in hdr ?

22

No. Again, this is proprietary software, we can’t know what it does. If it supports floating point JPEG XR in some special way, it does not mean it will support floating point EXR and TIFF the same way.

1 Like
23

no. again, not talking about .jxr here, talking about [.exr, .hdr], if you fill it with full blue, will the color be at max luminance value ?
because tried it appears like it but is it really the case digiatlly ?
.jxr and windows photos are proprietary, but hdr + wcg image viewer is not so if you want to only use non proprietary software, do you know other hdr image viewer by the way ?

24

Hi,
Since this now seems to be not darktable-specific anymore, from my limited investigations, I found out that:

  • Google Chrome on Mac os should be able to display avif HDR images (with rec.2100 PQ at least)

  • maybe this works on windows too? I don’t know because I don’t use windows, but there’s a chance it might if you configure HDR output properly (which I don’t know how to do)

  • chrome on Linux will at least tonemap the HDR avif to sdr, so that it looks reasonable on a standard sdr display

  • on my TV, I can successfully trigger hdr output when using heif with either hlg or pq encoding (still rec.2100)

  • for both avif and heif, you need to tag the files properly. that means no ICC profiles, and use of the nclx box instead to specify the primaries and transfer function

HTH

1 Like
25

Try:

26

@agriggio and @kofa thank for the detailled suggestions !
definitely giving it a try !

27

There’s also

I have no experience with any of these, as I don’t do HDR.

There’s this thread, and the first comment references another:

28

Nice. On mine, I cannot - At least until 2-3 years ago, the only reliable content distribution format for HDR stills was to encode it to an HLG or PQ + Rec. 2020 10-bit H.265 video. (I linked to how I did that in one of my other posts)

At least in theory it might now be possible to create an HDR image viewer that works in full screen with gamescope on Linux (right now the only userspace that has HDR support…), but that’s extremely niche.

In general, HDR stills are a sh*tshow as far as support and compatibility. Float JXR works well in Windows, but on any other OS your best bet is to convert it to float TIF - and even then, that’s really only valid for feeding it to darktable, ART, or RT to tonemap it down to SDR, there are no HDR image viewers. MacOS seems to have the best support for HDR stills in the more well known/standardized formats (AVIF, HEIF/HEIC, etc)