Falsecolor of hdr ubuntu, ubuntu(WSL), windows, mac

hdri
1

Hi Experts,
we are assisting on a student’s sky luminance project.

We are using a surveillance fisheye camera to observe the sky.
We managed to get the device capturing the 6 images series. (from a Ubuntu machine)

We are now stuck in falsecoloring this test.hdr on ubuntu, ubuntu(WSL), windows; we succeeded only on MacOS.

Thank you for help on this?
Best regards Robert and Johannes.

Case A)
on the Windows machine, ./hdrgen64bit -o test.hdr -a -x -r response_800.rsp ?.jpg
The header of the test.hdr:
#?RADIANCE
CAMERA= a common brand
./hdrgen64bit created HDR image from ‘snapshot_2024-10-07_08-58-45_2560.jpg’ ‘snapshot_2024-10-07_08-58-42_1280.jpg’ ‘snapshot_2024-10-07_08-58-39_640.jpg’ ‘snapshot_2024-10-07_08-58-36_320.jpg’ ‘snapshot_2024-10-07_08-58-33_160.jpg’ ‘snapshot_2024-10-07_08-58-31_80.jpg’
EXPOSURE=1.388793e-02
CAPDATE= 2024:10:07 06:58:45
PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
FORMAT=32-bit_rle_rgbe

-Y 960 +X 1280

then falsecolor -i test.hdr > test_fc.hdr works with error BUT the image is NOT openable in Photoshop, nor is it further processible
The header of the test-fc.hdr (with legend, so it is wider than the original)
#?RADIANCE
CAPDATE= 2024:10:07 09:23:37
GMT= 2024:10:07 07:23:37
falsecolor -i test.hdr
FORMAT=32-bit_rle_rgbe

-Y 960 +X 1380

trying to convert this test_fc.hdr on the UBUNTU 22.04 machine by "convert -gamma 2.2 test_fc.hdr test_fc_converted.png throws an error:

convert-im6.q16: improper image header test_fc.hdr' @ error/hdr.c/ReadHDRImage/383. convert-im6.q16: no images defined test_fc_converted.png’ @ error/convert.c/ConvertImageCommand/3229.

##############
Case B)
on a Ubuntu 22.04.4(WSL) we get ./hdrgen64bit -o test_1-6.hdr -a -x -r response_800.rsp ?.jpg the hdr.
The header of the test_1-6.hdr:
#?RADIANCE
CAMERA= Mobotix Q26 version MX-V5.2.6.7
./hdrgen64bit created HDR image from ‘6.jpg’ ‘5.jpg’ ‘4.jpg’ ‘3.jpg’ ‘2.jpg’ ‘1.jpg’
EXPOSURE=1.388793e-02
CAPDATE= 2024:10:07 06:58:45
PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
FORMAT=32-bit_rle_rgbe

-Y 960 +X 1280
and so on

Then trying to falsecolor this hdr to a fc_hdr breaks on “Bad Header” error:$ falsecolor -i test_1-6.hdr > test_1-6_fc.hdr
cannot find font file “helvet.fnt”
/tmp/KxZqHqLd4Y/slabT.hdr: bad picture size
/tmp/KxZqHqLd4Y/slab.hdr: bad picture size
/tmp/KxZqHqLd4Y/slabinv.hdr: bad picture size
Bad header!

The header of the test_1-6_fc.hdr, bear in mind, that the falsecolor CLI interaction throws the “bad header” error.
#?RADIANCE
CAPDATE= 2024:10:07 10:53:48
GMT= 2024:10:07 08:53:48

#################
Case C)
on a MacOS (Macbook Pro M2) it works all fine, we get the falsecolor of our sky-luminance distribution.

2

I believe this is the clue to your falsecolor error, at least on UBUNTU. This file needs to exist somewhere in your $RAYPATH list of folders. Perhaps it didn’t get installed by the default installer, which could be our problem. Or, it was installed but $RAYPATH is not being set properly in your “$HOME/.bashrc” file or whatever initializes your shell. I believe the file may be found in the auxiliary file archive posted here.

Regarding the Windows issue, say that “falsecolor works with error” but that just means it didn’t work. What was the error?

Best,
-Greg

3

Hi Greg,

Regarding to our Windows problem, we actually meant “falsecolor works without error”. Sorry for the misunderstanding. So it generates the falsecolor image without an error, but when you try to open it on a photoediting program like Photoshop, this error shows up:
image
It simply means, that Photoshop could not interpret the image format.

We used the latest version of the Radiance software.

Thank you for your help and your time.

Best regards,
-Johannes

4

Hi Johannes,

can you view your HDR image with ximage or convert it e.g. using ra_tiff? Just to check if it is related to the image itself or to Photoshop not being able to read it.

Best,
David

5

Hello David,

No, i cannot convert it into a .tif. If I use following command: “.\ra_tiff -w test_fc.hdr test_fc.tiff” → it says “Bad Radiance Picture”

image
image1088×68 3.77 KB

But it generates a .tif image, it is just not accesable. It only has 1KB so there’s nothing there to see. The original hdr image is 2461KB big and the corrupted falsecolor image is 1172KB big.

If I use my original .hdr image (test.hdr), everything works fine. So there must be something with the conversion to the falsecolor image itself.

And there is no ximage.exe in my Radiance folder. So i cannot use that.

Thank you for your help.

Best,
Johannes

6

Hi Johannes,

can you upload the original test.hdr as well as the test_fc.hdr somewhere that we can have a look at it?

Best,
David

7

Hi David,

Yeah of course. You can use following Google Drive Link below to get to the images:
https://drive.google.com/drive/folders/1o1GuGO1JEUBA5S_4cevNNHM9nEHpw0Ok?usp=sharing

Best regards,
Johannes

8

OK, I didn’t expect to see this, but it seems test_fc.hdr is some kind of non-ASCII 16-bit encoding. I am not familiar with this type of file, but it’s clearly a function of your operating system. Is there some system setting in Windows that affects the file output types? I think the output is being set to UTF-16, somehow.

Cheers,
-Greg

9

Hi @SchettJohannes ,

If you are using Windows Power Shell, please consider using Windows Command Prompt instead.

1 Like
10

Just looked at the file; the header is UTF-16, as is sometimes default on Windows. @Robert_Weitlaner , what version of Windows are you using?

11

Hello @Nathaniel_Jones,

I did not expect that, but that solved the problem for me. I did not really pay attention for that. Thank you very much.

12

Dear all,

in fact I experienced a similar problem with BSDF files once. I think they had been generated by genBSDF on a Windows installation, and I had to convert to UTF8 before being able to use them.

I found some weird documentation mentioning a messy re-interpretation of format strings by Microsoft (they label it an “extension”), flipping the meaning of formatting characters depending on wether they are used with printf() or wprintf(): Link to documentation “Type conversion specifier”. Is this the culprit?

Best, Lars.

13

Hi @Lars_Grobe ,

Your suggestion seems possible. As this page explains, PowerShell uses UTF-16 encoding by default (while the command prompt apparently does not), and this behavior can be changed from within PowerShell.

My solution is not to use PowerShell, but that is difficult to enforce.

1 Like