assign hdr metadata and display hdr images

afternoon !

here are all the test renders which can highlight the interpretation differences between these differents files and their respective embeded metadata by [‘microsoft photos’, ‘hdr + wcg image viewer’] :
onedrive

here is a list of all the images displaying as intended equally to the original :
obs.jxr
shadowplay.jxr
xboxgamebar.jxr

here is a list of all the images not displaying as intended no where near the original [dull, completely washed out] :
resolveexport.exr
resolveexport.png
resolveexport.tif
obs_jxrdecappconvert.tif

obs_jxrdecappconvert.tif :
screenshot from obs converted with jxrlib with : jxrdecapp.exe -i 'obs.jxr' -o 'obs_jxrdecappconvert.tif'
obs.jxr : screenshot from obs
shadowplay.jxr : screenshot from shadowplay
xboxgamebar.jxr : screenshot from xbox gamebar

resolveexport.exr : export from davinci resolve from the deliver tab [‘exr’, ‘rgb float’]
resolveexport.png : export from davinci resolve from the deliver tab [‘png’, ‘rgb 16 bits’]
resolveexport.tif : export from davinci resolve from the deliver tab [‘tif’, ‘rgb 16 bits’]

strange thing is comparing 2 images :
1 that do display as intended equally as the original :
magick identify -verbose 'obs_jxrdecappconvert.tif'
and 2 that does not display as the original :
magick identify -verbose 'resolveexport.tif'
, with ‘imagemagick’, the ‘color space’ appears to be the same ‘srgb’ and the transfert function ‘rendering intent: perceptual’|‘gamma: 0.454545’ appears to be the same, while 1 is clearly displaying as rec 2100 pq (perceptual quantizer) and 2 as rec 709|srgb.

there is a difference of interpretation based on the metadata in the files that gives the viewer the ‘color space’ and ‘transfert function’ to use when displaying the image !
but how to identify (with what software) this different information ?

where is located this different information in the metadata ?
how to edit this information ?
how to edit this information ?

You can use exiftool or exiv2 to find out where the metadata is in your files.

thank for answering !
tried with exiftool, here is the output :

ExifTool Version Number         : 12.71
File Name                       : obs.jxr
Directory                       : <path>/investigation_hdr still/new batch
File Size                       : 19 MB
File Modification Date/Time     : 2023:12:26 16:53:02+01:00
File Access Date/Time           : 2023:12:27 01:55:57+01:00
File Creation Date/Time         : 2023:12:26 16:53:15+01:00
File Permissions                : -rw-rw-rw-
File Type                       : JXR
File Type Extension             : jxr
MIME Type                       : image/jxr
Exif Byte Order                 : Little-endian (Intel, II)
Pixel Format                    : 64-bit RGBA Half
Transformation                  : Horizontal (normal)
Image Type                      : (none)
Image Width                     : 3840
Image Height                    : 2160
Width Resolution                : 72
Height Resolution               : 72
Image Offset                    : 162
Image Byte Count                : 18510186
Alpha Offset                    : 18510348
Alpha Byte Count                : 18684
Image Size                      : 3840x2160
Megapixels                      : 8.3
-- press ENTER --

does not appear to give on the precise color space or .icc color profile used.

concerning exiv2 : how do you use it ? do you have any specific command ?
because nothing appears to output the metadata in the documention.

For exiftool, looks like you need to press enter to see more…

it exits windows terminal

in simple terms, why the obs.jxr displays as hdr and why the resolveexport.tif does not in ‘microsoft photos’ for instance ?
is it the embded color space, .icc color profile ?
where is it ? how to find the one use in obs.jxr or usually by hdr images, is it bt.2020 with bt.2100 pq transfert function ?
how to assign such a color space ? where to to download such a .icc color profile for ‘microsoft photos’ to interpret the hdr color correctly as intended ?

does someone manage to display hdr still images using rec. 2100 color space and st. 2084 pq transfert function once out of .jxr ?

I’m sorry, I don’t understand the question. What kind of processing is involved in darktable and in gimp?

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).

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?

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.

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.

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.

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.

I use ExifToolGUI.

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

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.

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.:

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

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.

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

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