web: the frame under the preview says where it was shot and what it was shot with
A negative is opened to be looked at, and the two things a photographer reads
off it first are the numbers the camera wrote and where it stood when it wrote
them. The stage gave the name, the folder, the date and the weight of the file,
which is what the catalogue knows; the rest was a trip into the studio.
Both are now under the picture. The numbers are the camera's own — ISO, focal
length, aperture, shutter, frame size — printed in the order a photographer
says them, and every one the file does not carry is left out rather than stood
in for: a Fuji RAF gets no line at all, a Panasonic RW2 gets the glass and the
shutter and no ISO, and a JPEG gets the lot. Where the frame was shot is the
GPS it carries, named by the geocoder when one answers and left as the
coordinates it holds when none does — a naming is a network round trip on a PRO
account, and the numbers do not wait for it, so a refusal or a miss costs the
reader nothing.
What this costs is one read of the frame's first few hundred kilobytes, the
same head a scan hands the parser, and only the frame that is up pays it: the
strip walks past a hundred negatives without reading one of them. The read is
held by the read itself and not by the frame object under it, because the
catalogue is read back on a timer while a scan runs, which hands the screen a
fresh object every few hundred milliseconds — a screen that went by the object
would read the same file again and again for as long as the scan lasts.
The check's stand-in folder had no frame of its own with a GPS tag on it, and
none of the samples carries one, so the check writes one: an APP1 segment
holding a GPS IFD and nothing else, spliced in right after the frame's SOI. It
is deliberately the first APP1 — a JPEG carries one EXIF segment and the
catalogue reads the first, so a file that has a place is a file that spent its
EXIF on the coordinates. That is also what makes the RAW the frame that shows a
spec line, and the two frames now check the two halves of the same feature.
The run counts what a reading costs, and a head is not what it counted before:
it counts the whole file a lane develops apart from the head a parser is handed,
because "the RAW was read" is a claim about the scan and the preview legitimately
reads the same file's head.
Verified:
library-check.mjs — 47 steps, all passed, two of them new. The JPEG off the
check's server carries a GPS tag and the page keeps 16.0544, 108.2022 under
the frame, with no geocoder behind it to name them; the RAW prints
"26.4mm · f/2.8 · 1/320s" — the glass and the shutter it has, no ISO and no
frame size it does not. Every earlier step still holds, including the one
that says a scan does not read a RAW whose size and write time have not
moved: whole reads {}, heads {"P1010256.RW2":1,"P1010256.JPG":2}, the one
RAW head being the frame that is up.
scan-nav-check.mjs, roll-walk-check.mjs — all passed. frontend tsc --noEmit
clean, vite build clean.
ponytail: the place is named by the API's geocoder and nothing else — no map, no
picker, no place a reader can type. The coordinates are what the file carries,
and a file that carries none shows no line, which is the honest answer and the
common case for a phone frame with location off. The line is read for the raised
frame only; a grid of hundreds is a list of names, and a row of ISO numbers
under each tile is not what it is for.
Co-authored-by: PenguinHarness <noreply@penguin.local>
This commit is contained in:
@@ -166,6 +166,68 @@ export async function readCapturedAt(bytes: Uint8Array): Promise<number | null>
|
||||
return null;
|
||||
}
|
||||
|
||||
// What the camera recorded about the shutter, the glass and the frame itself —
|
||||
// the numbers a photographer reads first. All of them sit in the EXIF segment at
|
||||
// the front of the file, so this costs the same few hundred kilobytes the date
|
||||
// does. Each one is null where the file does not carry it, which is what a
|
||||
// screenshot, a scan or a Fuji RAF answers: `exifr` reads the formats it knows
|
||||
// and nothing about a file it does not know is invented here.
|
||||
export interface ShotSpecs {
|
||||
iso: number | null;
|
||||
// A focal length in millimetres, an f-number, and an exposure in seconds.
|
||||
focal: number | null;
|
||||
aperture: number | null;
|
||||
exposure: number | null;
|
||||
// The frame's own size, which only a JPEG states outright. A RAW leaves it to
|
||||
// the decoder, and half a number is worse than none.
|
||||
width: number | null;
|
||||
height: number | null;
|
||||
}
|
||||
|
||||
export async function readSpecs(bytes: Uint8Array): Promise<ShotSpecs | null> {
|
||||
try {
|
||||
const tags = (await exifr.parse(bytes, {
|
||||
pick: ['ISO', 'ISOSpeedRatings', 'FocalLength', 'FNumber', 'ExposureTime', 'ExifImageWidth', 'ExifImageHeight'],
|
||||
})) as Record<string, unknown> | undefined;
|
||||
if (!tags) return null;
|
||||
const num = (v: unknown): number | null => {
|
||||
const n = Number(Array.isArray(v) ? v[0] : v);
|
||||
return Number.isFinite(n) && n > 0 ? n : null;
|
||||
};
|
||||
return {
|
||||
iso: num(tags.ISO ?? tags.ISOSpeedRatings),
|
||||
focal: num(tags.FocalLength),
|
||||
aperture: num(tags.FNumber),
|
||||
exposure: num(tags.ExposureTime),
|
||||
// Null together: a frame with one edge and not the other has no size.
|
||||
width: tags.ExifImageWidth && tags.ExifImageHeight ? num(tags.ExifImageWidth) : null,
|
||||
height: tags.ExifImageWidth && tags.ExifImageHeight ? num(tags.ExifImageHeight) : null,
|
||||
};
|
||||
} catch {
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
// The rounded number as it is printed: one decimal, and none where there is
|
||||
// none — `f/2.8` rather than `f/2.8000000000000003`.
|
||||
const round = (n: number) => String(Math.round(n * 10) / 10);
|
||||
|
||||
// Those numbers as the line under a frame. A shutter faster than a second is the
|
||||
// fraction a camera prints (`1/320s`), and everything the file does not have is
|
||||
// left out rather than stood in for — an empty line is what a file with no EXIF
|
||||
// gets, and the caller prints nothing.
|
||||
export function specsLine(specs: ShotSpecs | null): string {
|
||||
if (!specs) return '';
|
||||
const parts = [
|
||||
specs.iso ? `ISO ${Math.round(specs.iso)}` : '',
|
||||
specs.focal ? `${round(specs.focal)}mm` : '',
|
||||
specs.aperture ? `f/${round(specs.aperture)}` : '',
|
||||
specs.exposure ? (specs.exposure < 1 ? `1/${Math.round(1 / specs.exposure)}s` : `${round(specs.exposure)}s`) : '',
|
||||
specs.width && specs.height ? `${specs.width}×${specs.height}` : '',
|
||||
];
|
||||
return parts.filter(Boolean).join(' · ');
|
||||
}
|
||||
|
||||
// EXIF GPS of the loaded photo, in the shape the renderer + EXIF writer expect.
|
||||
// Returns null when the photo has none — the caller then offers manual entry.
|
||||
export async function readGps(bytes: Uint8Array): Promise<GPSInfo | null> {
|
||||
|
||||
Reference in New Issue
Block a user