Commit Graph

2 Commits

Author SHA1 Message Date
3dtours d1e9425b9c web: read a frame's white off its pile, not off its largest sample
sensorWhite hung its nine counts of window off the plane's largest sample. A
hot pixel sits hundreds of counts above the level the sensor stops at, so on a
frame that carries one the window held the stray alone, found no pile in it, and
handed the develop the factor two instead of the frame's own level.

Measured on a Panasonic DMC-LX10 RW2: one sample at 15993 and one at 14665 over
a pile of 9,594,544 at 13855. The frame's level is 1.75x the fall-back, so the
develop opened 0.81 of a stop bright, clipped the sky the sensor had held to
flat, and the fit to the camera's preview could only pull the exposure back
after the highlight detail was gone. Against the camera's own JPEG of the shot,
mean |dL| 23.48 and dRGB +8.57,+0.90,+4.90 became 19.14 and +5.32,+1.89,+2.04,
and the level itself 7908 (gain 8.2872) became 13874 (gain 4.7236) against the
13855 the plane piled at — 0.14%, 0.002 of a stop.

The level is now the highest count the plane piled at, off a whole-plane
histogram: `floor` counts is a pile, and the same cliff rule as before still has
to hold over the count below it, so a smooth bright sky is left alone and a
frame that has not clipped still falls back on the factor two.

The same stray was in four of the ten bodies to hand. A Nikon _GDN0447.NEF read
the fall-back 8190 where its plane piles at 13806 (gain 8.0018 -> 4.6022, 0.79
of a stop), a Fujifilm RAF 29696 where the documented level is 30993, and a Sony
ARW 31742 against the 2.002x the body's ratio was measured at. Six were
untouched, and a Canon CR2 develops byte-identical through the change — the
window moves only on a frame whose largest sample is not its highest pile.

scripts/white-level-check.mjs keeps the LX10 shape: a plane piled at 30995 with
a stray above it has to answer 30995.
2026-09-28 15:55:04 +07:00
3dtours 224ff0b935 web: open a RAW at the resolution of its sensor, not at the quarter of it
LibRaw's half-size demosaic was on. The Ricoh GR's own DNG (D0004128.DNG)
developed to 3010x2012 while the JPEG written beside it in the same second is
6000x4000, and the Fuji's RAF to 3008x2007 against its own 6000x4000 -- the
quarter was the flag, not the file. With `halfSize: false` the same develop
returns 6020x4024 and it is the sensor's frame on every body tried:

  D0004128.DNG  6020x4024   IMGP6916.DNG        6028x4024
  DSCF1701.RAF  6016x4014   _DSC0009.ARW        6024x4024
  AFXT2721.RAF  6246x4170   Nikon-D850 NEF      6216x4136
  _GDN0447.NEF  4284x2844   P1010607.RW2        3472x3472
  5G4A9396.CR2  2880x1920

Nine files, 27s to 155s a develop on one core. Checked through the app
itself, not only through LibRaw: photo-dims 6020x4024 on the DNG against
6000x4000 on the JPEG, both err none.

The colour it opens with is now fitted per file to the preview the camera wrote
into it (previewMatch.ts): a 3x3 over a block grid of the develop against the
same grid of that preview, then one cubic a channel for what the 3x3 leaves.
The offline per-body table this replaces (cameraMatch.ts) stopped matching the
moment the path under it changed -- its rows no longer summed to 1 once the
highlight knee landed ahead of it -- and a body with a row opened with a cast
one without did not. The file's own preview does not age.

The white level the gain carries is the frame's own plateau rather than
`maximum` (sensorWhite.ts), a factor of 1.89 to 2.00 out; without it every
frame opened a stop bright and a body that sat lower (X-Trans, 1.892) never
reached the highlight desaturation at all.

The desaturation gate reads the gain-lifted levels as well as the sensor's,
which is the whole of the magenta: on a body whose cam_mul lifts red and blue
(the GR's [2.64, 1, 1.73]) a blown sky crosses the white level at 0.38 of the
raw range in red while green crosses at 1.0, so a gate read on the sensor's
levels alone stayed shut across it. Measured in the app against the camera's
own JPEG, mean dRGB over a 16x16 block grid: +1.20, -5.95, -6.11 with the
sensor's clip alone, +0.21, +0.24, +0.47 with both, mean |dL| 21.5 against
10.3. The same grid on the Fuji comes back balanced (+4.7, +5.0, +3.6) and best
aligned at offset 0,0.

-HL is recovery and +HL is a lift, so they are different moves now: recovery is
the doc's soft knee in linear light over the top half, which is the only term
in the tone shader that is not a shift and the only one that can put detail
back into a blown sky rather than merely darken it.

The four checks pin the develop down where it can only run in a browser:
raw-develop-check, preview-match-check, white-level-check, highlight-knee-check.
2026-09-28 15:24:37 +07:00