pcomb photometrically correct

Dear all,

I'm trying to process an HDR image to pick out the light source. The image
was taken with hdrgen:
RGBE: http://luminance.londonmet.ac.uk/pickup/004.hdr
falsecolor: http://luminance.londonmet.ac.uk/pickup/004_fc.jpg
Header:
$ head -10 004.hdr
#?RADIANCE
CAMERA= NIKON E990 version E990v1.1
hdrgen created HDR image from '0129_012.jpg' '0129_011.jpg' '0129_010.jpg'
'0129_009.jpg' '0129_008.jpg' '0129_007.jpg' '0129_006.jpg' '0129_005.jpg'
'0129_004.jpg' '0129_003.jpg' '0129_002.jpg' '0129_001.jpg'
Removed lens flare
EXPOSURE=4.175030e-01
CAPDATE= 2007:01:29 17:33:57
PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
FORMAT=32-bit_rle_rgbe
-Y 768 +X 1024

What I'm after is to black out all pixels below a certain threshold, and
leave all others, i.e. the ones that are part of the light source
untouched.

Firstly, a quick test-run to warm up:
$ pcomb -e 'lo=li(1)' -o 004.hdr > test.pic ; ximage test.pic &
This does nothing but show the brightness. The -o ensures I get
photometric units.

Fine so far. BUT: If I run the same command straight into ximage, the
picture looks the same, but hitting 'L' displays a luminance of 0.0 for
all pixels (the square light source should have a luminance of just under
500 cd/m2):
$ pcomb -e 'lo=li(1)' -o 004.hdr |ximage
This is the first thing that I don't understand.

Second question: To set the threshold to 400 cd/m2 like described above, I
run:
$ pcomb -e 'lo=if(li(1)-400/WE,li(1),0)' -o 004.hdr > test.pic ; ximage
test.pic &
WE is the white efficacy, which seems to be read-only: Setting WE=2000
doesn't do anything.
URL: http://luminance.londonmet.ac.uk/pickup/400.png (the light only --
rest is black)

From pcomb(1):

"... WE gives the white efficacy (lumens/brightness) for pixel values,
which may be used with the -o option or the le(n) values to convert to
absolute photometric units (see below)"

The exposure value le(n) is the same for the entire picture (in my case
just over 0.4), so is it correct to say that I only have to worry about it
when combining multiple images? And that WE is equally useful with li(n),
not just li(n) and -o?

So combining multiple images with different exposures would be done like so:
$ pcomb -e 'lo=li(1)/le(1)+li(2)/le(2)' -o 004.hdr 006.hdr > test.pic
Right?

Thanks for shedding some light on the issue.

Cheers

Axel

Hi Axel,

If you want to derive light sources from an HDR you should take a look at mksource, this will evaluate the scene and then output as set of illum sources.

-Jack

Axel Jacobs wrote:

ยทยทยท

Dear all,

I'm trying to process an HDR image to pick out the light source. The image
was taken with hdrgen:
RGBE: http://luminance.londonmet.ac.uk/pickup/004.hdr
falsecolor: http://luminance.londonmet.ac.uk/pickup/004_fc.jpg
Header:
$ head -10 004.hdr
#?RADIANCE
CAMERA= NIKON E990 version E990v1.1
hdrgen created HDR image from '0129_012.jpg' '0129_011.jpg' '0129_010.jpg'
'0129_009.jpg' '0129_008.jpg' '0129_007.jpg' '0129_006.jpg' '0129_005.jpg'
'0129_004.jpg' '0129_003.jpg' '0129_002.jpg' '0129_001.jpg'
Removed lens flare
EXPOSURE=4.175030e-01
CAPDATE= 2007:01:29 17:33:57
PRIMARIES= 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.3127 0.3290
FORMAT=32-bit_rle_rgbe
-Y 768 +X 1024

What I'm after is to black out all pixels below a certain threshold, and
leave all others, i.e. the ones that are part of the light source
untouched.

Firstly, a quick test-run to warm up:
$ pcomb -e 'lo=li(1)' -o 004.hdr > test.pic ; ximage test.pic &
This does nothing but show the brightness. The -o ensures I get
photometric units.

Fine so far. BUT: If I run the same command straight into ximage, the
picture looks the same, but hitting 'L' displays a luminance of 0.0 for
all pixels (the square light source should have a luminance of just under
500 cd/m2):
$ pcomb -e 'lo=li(1)' -o 004.hdr |ximage
This is the first thing that I don't understand.

Second question: To set the threshold to 400 cd/m2 like described above, I
run:
$ pcomb -e 'lo=if(li(1)-400/WE,li(1),0)' -o 004.hdr > test.pic ; ximage
test.pic &
WE is the white efficacy, which seems to be read-only: Setting WE=2000
doesn't do anything.
URL: http://luminance.londonmet.ac.uk/pickup/400.png (the light only --
rest is black)

>From pcomb(1):
"... WE gives the white efficacy (lumens/brightness) for pixel values,
which may be used with the -o option or the le(n) values to convert to
absolute photometric units (see below)"

The exposure value le(n) is the same for the entire picture (in my case
just over 0.4), so is it correct to say that I only have to worry about it
when combining multiple images? And that WE is equally useful with li(n),
not just li(n) and -o?

So combining multiple images with different exposures would be done like so:
$ pcomb -e 'lo=li(1)/le(1)+li(2)/le(2)' -o 004.hdr 006.hdr > test.pic
Right?

Thanks for shedding some light on the issue.

Cheers

Axel

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

Hi Axel,

I'm glad Jack answered you, first. I wouldn't have thought through to your purpose to suggest mksource.

Even so, I'd hate to leave your other questions unanswered, so here goes...

From: "Axel Jacobs" <[email protected]>
Date: February 1, 2007 7:17:53 AM PST
...

Firstly, a quick test-run to warm up:
$ pcomb -e 'lo=li(1)' -o 004.hdr > test.pic ; ximage test.pic &
This does nothing but show the brightness. The -o ensures I get
photometric units.

Fine so far. BUT: If I run the same command straight into ximage, the
picture looks the same, but hitting 'L' displays a luminance of 0.0 for
all pixels (the square light source should have a luminance of just under
500 cd/m2):
$ pcomb -e 'lo=li(1)' -o 004.hdr |ximage
This is the first thing that I don't understand.

Ximage doesn't load the original HDR pixels into memory, instead relying on the file's presence to query specific values. If you don't give it the file, it disables its query function.

Second question: To set the threshold to 400 cd/m2 like described above, I
run:
$ pcomb -e 'lo=if(li(1)-400/WE,li(1),0)' -o 004.hdr > test.pic ; ximage
test.pic &
WE is the white efficacy, which seems to be read-only: Setting WE=2000
doesn't do anything.
URL: http://luminance.londonmet.ac.uk/pickup/400.png (the light only --
rest is black)

From pcomb(1):

"... WE gives the white efficacy (lumens/brightness) for pixel values,
which may be used with the -o option or the le(n) values to convert to
absolute photometric units (see below)"

The exposure value le(n) is the same for the entire picture (in my case
just over 0.4), so is it correct to say that I only have to worry about it
when combining multiple images? And that WE is equally useful with li(n),
not just li(n) and -o?

You should EITHER use the -o option (once for each input file), OR use le(n) to adjust the exposure, not both. If the -o option is applied to an input image, values you get will already have been divided by the associated expousre.

So combining multiple images with different exposures would be done like so:
$ pcomb -e 'lo=li(1)/le(1)+li(2)/le(2)' -o 004.hdr 006.hdr > test.pic
Right?

Given what I just said, you would either use:

$ pcomb -e 'lo=li(1)/le(1)+li(2)/le(2)' 004.hdr 006.hdr > test.pic

or:

$ pcomb -e 'lo=li(1)+li(2))' -o 004.hdr -o 006.hdr > test.pic

If you felt like it, you could get the same result from:

$ pcomb -e 'lo=li(1)+li(2)/le(2)' -o 004.hdr 006.hdr > test.pic

but that would be a little twisted...

-Greg

Thanks for the quick reply,

Jack

If you want to derive light sources from an HDR you should take a look
at mksource, this will evaluate the scene and then output as set of
illum sources.

I'm actually trying to quantify the vignetting and angular response of my
fisheye lens, so mksource (which I did think about using) isn't quite what
I want.

Greg

Ximage doesn't load the original HDR pixels into memory, instead
relying on the file's presence to query specific values. If you
don't give it the file, it disables its query function.

Since this is the most puzzling Radiance feature yet, allow me to get back
to it.

Are you saying that ximage reads the file into memory to display it, but
then relies on additional file reads for 'L'?
If so, then would not -f make sure that all 'L's are read from the
in-memory copy, rather than from the file (which it doesn't)? Or would in
a networked-X scenario the application still pull the pixel luminance over
the network, if called with a file name?

In other words: There are two distinct parts to ximage: the display part,
and the query part, and the two don't know anything about one another?

I've experimented with the -o options ('T'-key), and the results are the
same: zero when input to ximage comes through a pipe, expected value when
read from file:
$ pcomb -e 'lo=li(1)' -o 004.hdr | ximage -ov

If you don't give it the file, it disables its query function.

So some of the ximage features can not be used when input is STDIN? Is
there a particular reason for implementing it this way?

Given what I just said, you would either use:
$ pcomb -e 'lo=li(1)/le(1)+li(2)/le(2)' 004.hdr 006.hdr > test.pic
or:
$ pcomb -e 'lo=li(1)+li(2))' -o 004.hdr -o 006.hdr > test.pic
If you felt like it, you could get the same result from:
$ pcomb -e 'lo=li(1)+li(2)/le(2)' -o 004.hdr 006.hdr > test.pic

Aha! This makes it crystal-clear now. Thanks 1000!

Axel

Hi Axel,

From: "Axel Jacobs" <[email protected]>
Date: February 2, 2007 4:09:56 AM PST
...

Ximage doesn't load the original HDR pixels into memory, instead
relying on the file's presence to query specific values. If you
don't give it the file, it disables its query function.

Since this is the most puzzling Radiance feature yet, allow me to get back
to it.

Are you saying that ximage reads the file into memory to display it, but
then relies on additional file reads for 'L'?
If so, then would not -f make sure that all 'L's are read from the
in-memory copy, rather than from the file (which it doesn't)? Or would in
a networked-X scenario the application still pull the pixel luminance over
the network, if called with a file name?

In other words: There are two distinct parts to ximage: the display part,
and the query part, and the two don't know anything about one another?

I've experimented with the -o options ('T'-key), and the results are the
same: zero when input to ximage comes through a pipe, expected value when
read from file:
$ pcomb -e 'lo=li(1)' -o 004.hdr | ximage -ov

Back in the day when memory was not quite so cheap as it is now, keeping an entire floating-point buffer for an image, as would be required for luminance queries off the standard input, seemed unreasonable. I could copy the standard input to a file and read back from that, but it seemed rather too much trouble for a feature that may or may not be used in a particular invocation.

In other words, ximage tone-maps the floating-point (RGBE) input data into an (at most) 24-bit/pixel buffer to be used for display. Storing the original image as well would take more than twice the memory, and as I said, it was not so cheap when ximage was written.

I hope this clarifies matters. A lot of what is in Radiance is showing its age in terms of the trade-offs made. On the positive side, I did not encode many limits, so cheap memory has meant larger and larger models we can render. Being stingy has its rewards, too.

-Greg