how to calculate pu_metrics

[Carrotor116]

The paper of NHDRRNet provided pu_metrics, ei. pu_ssim and pu_psnr. While I am confuse how to calculate that metrics.

I find the source code about pu_metrics in their website.

However, their code use absolute luminance values to calculate metrics, as their comment.

% I1, I2 - two HDR images. They must contain absolute luminance values.

the predict HDR result of NHDRRNet before tonemap maybe in '.hdr' format (Radiance HDR (.pic, .hdr) file format).

So how can I calculate pu_psnr metric use their matlab code? Derictly read .hdr data and call qm_pu2_psnr seem not be correct. as follow

a = hdrread('ref.hdr');
b = hdrread('pred.hdr');
psnr = qm_pu2_psnr(a, b);

Please help me. Thank a lot.

[tuvovan]

Hi, Thank you for your concern.

As you may see, in the test.py file, you can find line 39

The value rs[0] is the output in luminance domain. I later use a Tonemapping algorithm to transform it to LDR and save it.

So I think you could save that value instead of out.

Hope that helps!

[Carrotor116]

The value rs[0] is the output in luminance domain. I wonder whether it's absolute luminance values or not. The save result in test.py is after applied tonemapping algorithm. Then metric PSNR-PU in paper is calculated using results tonemapped by cv2.createTonemapReinhard ?

Pseudocode:

tonemap = cv2.createTonemapReinhard()

ref = cv2.imread('ref.hdr')
ref = tonemap .process(ref)

rs = model.predict(SDR)
pred = tonemap.process(rs[0])

psnr_pu = psnr = qm_pu2_psnr(a, b)

[tuvovan]

I would say rs[0] is in the range of 0 and 1

So if I want to calculate psnr_pu I will do as follow:

ref = cv2.imread('ref.hdr')

rs = model.predict(SDR)

psnr_pu = psnr = qm_pu2_psnr(ref, rs[0])

My intention was not to compute any PSNR value, my intention was to see how the algorithm works in terms of ghost removing ability.

Then my suggestion might not be correct. Let me know your opinion, I will be very appreciated!

[Tx000]

I have the same question with you. Have you solved this problem yet? HDR-VDP-2 is also evaluated on the absolute luminance values. How to calculate HDR-VDP-2? The authors of HDR-VDP-2 claim that to transform images to absolute units, the RGB values can be multiplied by an appropriate constant. Such constant will depend on an application and the brightness at which the scenes or images are going to be seen. (http://hdrvdp.sourceforge.net/wiki/index.php/Frequently_Asked_Questions) So in my implementation, I adopt a luminance range typical for HDR displays (up to 3000 cd/m2) to show the display quality of generated HDR images, i. e., Ia = 2999 * Ir + 1, to transform relative luminance map Ir to an absolute luminance map Ia with 3000 cd/m^2 peak luminance and 1 cd/m^2 black level. The image values correspond to the luminance emitted from the target HDR display. Then I use these images to compute PSNR-PU, SSIM-PU, and HDR-VDP-2. The readme file of PSNR-PU also claims that PSNR-PU and SSIM-PU are display-referred metrics(those metrics expect that the values in images correspond to the luminance emitted from the HDR display). However, in this way, computed results are different from those in the paper. I don't know if this is right. Welcome to discuss.

[tuvovan]

I believe that the author didn't do such ways you have mentioned.

I worked for 2 different projects which related to HDR before. One is deghosting the other is tonemapping.

The former one they don't really care about the target display so I assume that they used the range of 0 and 1 to calculate. The latter one they did the experiment directly on the displays, that is why they cared about the maximum luminance value of the display and from there calculate ting the HDR-VDP with considering the max-lum.

I suppose that (not sure) it depends on the problem you want to solve. And in this problem which is deghosting, the maximum value of the display may not be considered.

Lets chat!

[Tx000]

Thank you for your response. In my opinion, directly using the normalized HDR values to compute HDR-VDP-2 is not right. In the code of HDR-VDP-2, the color_encoding (one parameter of HDR-VDP-2) can be 'luma-display' or 'sRGB-display', which requires standard (tonemapped) images that range from 0 to 1. The other options require absolute luminance values and will check the input values. If the images contain very low physical values(below 1 cd/m^2), it will warn that "The passed values are most probably not scaled in absolute units, as required for this color encoding". So I believe directly using the normalized HDR values to compute HDR-VDP-2 is not right except that you tonemap HDR images to LDR images first and then compute HDR-VDP-2. However, I agree with you that the authors in the papers of deghosting used the range of 0 and 1 to calculate. It's very confusing to me.

[tuvovan]

yeah makes sense. I think if the author uses the tonemapped version to calculate then it will answer all of our question right? Correct me if I'm wrong I remember that they mentioned some tonemapping functions in the paper, not sure to show the results or even used them to calculate. anyway this is a good idea for the deghosting problem, isn't it?

[Tx000]

I don't think so. Even you take the tonemapped version as input and choose "sRGB-display" as color_encoding, HDR-VDP-2 will use inverse gamma correction function to map input images to linear domain and then scale the values to 1~100cd/m^2. Therefore, it's no need to tonemap input images.