[Radiance-general] Re: pcomb photometrically correct

[Axel Jacobs]

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