[Radiance-general] Re: pcomb photometrically correct

[Gregory J. Ward]

Hi Axel,

> From: "Axel Jacobs" <a.jacobs at londonmet.ac.uk>
> 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