Viewer luminance map uses a different palette from falsecolor

[adulbrich]

Non-blocking. Nothing in the WebAssembly port (#227) depends on this. Filed because it surfaced while porting falsecolor and is easy to lose.

The situation

The image viewer's luminance map and the pipeline's _fc.hdr both present luminance as colour, and they do not agree on the colours.

They already agree on the luminance: falsecolor-luminance-webgpu.ts uses Radiance's brightness weights (0.265074126 R, 0.670114631 G, 0.064811243 B) and the same 179 multiplier. That part is right.

Where they diverge is the mapping from luminance to colour:

	viewer	_fc.hdr
Source	FALSECOLOR_GRADIENT in heatmap-texture.ts	def_redp/def_grnp/def_blup in pc0.cal
Shape	9 hand-written stops, interpolated linearly	three 23-entry tables, interpolated by interp_arr
Ramp	black-blue -> blue -> cyan -> green -> yellow -> red -> dark red	Radiance's def palette
Gamma	none	^ gamma with gamma = 2.2 for several palettes

So the same picture is one set of colours on screen and a different set in the file the user exports. Someone comparing the viewer against _fc.hdr side by side will see two different images of the same data.

Why it is worth a decision rather than a fix

The viewer's ramp is a perfectly reasonable heatmap, and it may well have been chosen deliberately for on-screen legibility. Radiance's def palette is what the field expects and what every other Radiance tool produces, which matters for anything that ends up in a paper or a report.

There is also a naming problem regardless of which way it goes: the constant is called FALSECOLOR_GRADIENT and the module falsecolor-luminance-webgpu.ts, both of which imply it is falsecolor's palette. It is not. Whatever is decided, those names should stop claiming otherwise.

Options

1. Match def. Port the three 23-entry tables and interp_arr, apply the same gamma. The viewer then previews exactly what _fc.hdr will contain. Most work, best consistency.
2. Offer both. A palette selector, defaulting to def. Radiance itself ships six palettes (def, spec, pm3d, hot, eco, tbo) and -pal selects among them, so this is not an invention.
3. Keep the current ramp, rename it. Cheapest. Accepts that the viewer is an exploratory tool and the exported picture is the deliverable, and stops the names implying otherwise.

I would lean to 1 or 2: the tables are already in the repo at
src/lib/pipeline/__fixtures__/falsecolor-pc0.cal, extracted verbatim from
falsecolor.pl, so porting them is transcription-free.

Worth checking first

Whether anyone actually reads the viewer's colours quantitatively, or only uses the hover readout and the statistics. If the colours are purely a navigation aid, option 3 is the honest answer and the other two are wasted effort.

Pointers

• src/app/image-viewer/view/heatmap-texture.ts -- the gradient and its interpolation
• src/app/image-viewer/view/falsecolor-luminance-webgpu.ts -- the luminance computation, which is already correct
• src/app/image-viewer/view/page.tsx:161-169 -- the legend, drawn as a canvas gradient from the same stops
• src/lib/pipeline/__fixtures__/falsecolor-pc0.cal -- the def tables, if they are wanted