An interactive map of a series, with the height clipped on the colour bar, to find the phase transitions migrated

I08 · an idea of the seed-place, on its way to the module.

The idea

While reading the maps of the ESRF ID22 series of sample 400_4 (the esrf-datuak-irene project, 23 October 2026): a kind of map, but interactive, so that the exploration of the map is made easier for finding the phase transitions. It should have the option to select in the height, done on the colour-map legend at the right: the idea is to be able, so to say, to get rid of the big-height peaks and "go down" to the details.

Said again the same day, the features not finished: it should also offer the option to zoom in the temperature against 2\(\theta\) plane, to focus on the temperature \(\times 2\)\(\theta\) region the user wants. And, interestingly, the CLI should open a window, without the need of being inside the app (with the app open) to work on it; if possible, it could take the user to the browser, or perhaps there is a better option: propose, innovate.

Assessment

Plots' Map view already draws the core's matrix (plots::map, PL4) with the colour range the core gives (PL9), and the Surface view (step 15, L402) the same matrix in three dimensions. What is asked is a control on the colour bar itself: drag its upper bound (and the lower) so that the range shown is a slice of the intensities, everything above it saturated, and the weak bands (broad maxima of a poorly crystalline stage, 100 counts over a 500-count background beside 2600-count reflections, in the ID22 series) come up as the strong peaks are clipped; the same for the Surface's height. The square-root and log scales (PL27's map_scale) help but do not replace it: a clip is local to what the eye is looking for. The core's part is small (a range is a pair of numbers; the matrix does not change); the module's part is the handle on the legend, the redraw, and the range kept in the plot set file so that a figure made through Publish shows the same slice (its caption saying the range and that values above it are saturated).

The zoom in the T–2\(\theta\) plane. A rectangle dragged on the map zooms both axes together (the design's linked zoom, DESIGN.md §3); the wheel over an axis zooms that axis alone; a double-click returns. What is new is that the clip follows the zoom when asked: a "range from the view" switch sets the colour range to the intensities inside the rectangle, so that a weak band in a corner of the plane gets the whole colour scale. The rectangle is a window in 2\(\theta\) (the set's windows, PL5) times a range of the variable, and can be saved as such: a named region the user comes back to, and the one a Publish map draws (F3's windows = [...] plus a variable_range). The core gives the matrix once; a zoom reads a sub-block of it (plots::map on the window's columns and the rows in range), so nothing is recomputed on a drag.

A window from the CLI, without the app. Three ways, from the cheapest:

• *The app launched onto the set*: drs plots show <set.drv> runs open -a diff-ref-struct <set.drv>; the app already opens a .drv by double-click into Plots (the manual's "a launch file"), so one flag (--view map) lands the user on the Map view. It needs the app installed, and the whole app comes up.
• *The browser*: drs plots show <set.drv> --browser writes one self-contained HTML file beside the set (the core's matrix, edges and colour range as JSON inside it, plus the viewer script) and opens it in the default browser. No server, no app, works on a machine with the core alone and travels by mail; the sand-emissivity site's spectrum explorer (data-viewer.js) is the family's precedent of such a page.
• *A window of the core's own*: a small Tauri window shipped with drs (drs-view), the same web view as the app's without the app around it. The best feel and the most to maintain; not first. The one rule that makes the three one thing: the viewer is a single component (the Map view's canvas, clip, zoom, cursors, readout) hosted three ways, by the app's Plots module, by the standalone page, by drs-view; it draws the core's numbers and computes none (L139), so the standalone page is not a second map but the app's map in a browser. A .drv written by the CLI or by hand is its input everywhere.

Proposal

• Step 1, Plots. Two draggable marks on the colour bar (upper and lower bound of the range shown), the numbers typed too; values beyond them saturated at the end colours; the range per view (map, difference map, surface), on the scale shown (linear, √, log); a double-click resets to the core's range. Saved in the set file (map_range = { from, to }, PL27's family), so that a set reopens as it was left.
• Step 2, Publish. F3's map and difference map take the set's map_range; the caption says the range and the saturation; the colour bar's ticks still anchored at its ends (W5, G2).
• Step 3, finding transitions. A row cursor on the map (one scan) with that scan's pattern drawn below it, and a column cursor (one 2\(\theta\)) with the intensity against T beside it, both following the pointer: the two sections through the map that make a transition visible as a kink.
• Step 4, the zoom. A rectangle on the map zooms both axes; the wheel over an axis, that axis; "range from the view" clips to the rectangle's intensities; a region is saved by name (a 2\(\theta\) window plus a range of the variable) in the set file, and Publish's F3 map takes it.
• Step 5, the window from the CLI. drs plots show <set.drv> [--view map|projection] [--browser]: the app launched onto the set when it is installed, else (or on --browser) a self-contained HTML page written beside the set and opened in the browser, the Map view's component inside it with the core's matrix as data. The component is factored out of app/ui/modules/plots/ so that both hosts load the same file (the module's guard, PL14, keeps it free of calculation).
• Step 6, later. drs-view, the core's own window, if the browser page is found wanting.

For Josu to decide

• Whether the clip is a view (never changes the data: proposed) or an operation.
• Whether the range is kept per set file, so that Publish's figures show it.
• Which host comes first for the CLI window: the app launched onto the set (cheapest), or the browser page (works without the app; proposed first, since Josu asked for a window without the app).
• Whether a saved region (2\(\theta\) window × variable range) becomes a kind of window of the set file, beside PL5's.

The idea's log

• 2026-10-23 · said

  Said by Josu while reading the maps of the ESRF ID22 series (esrf-datuak-irene, L012 there): an interactive map with the height selectable on the colour-map legend, to get rid of the big peaks and go down to the details, for finding the phase transitions. L403

• 2026-10-23 · said

  Said again by Josu, the features not finished: a zoom in the temperature against 2\(\theta\) plane, to focus on the region wanted; and a window opened from the CLI without the app, the browser or a better option. Assessed: zoom with the clip following it and regions saved in the set file; one viewer component hosted by the app, by a self-contained browser page written by drs, and later by a window of the core's own. L404

• 2026-10-23 · decision

  Green, the same day: Josu said to start, with the merging session as the orchestrator. Requirement R33 appended; the Plots stream takes it in three steps (16: the clip on the colour bar and the row and column cursors; 17: the zoom in the T–2\(\theta\) plane and the saved regions; 18: the viewer factored out for the CLI's page), the core takes PL37 (the set file keeps the clip and the regions) and, after step 18, drs plots show. The asks answered as proposed unless Josu says otherwise: the clip is a view; the range is kept in the set file; the browser page is the first host without the app (the app launched onto the set costs one line and comes with it); a region is a table of its own in the set file, [[regions]], not one of PL5's windows. L405

• 2026-10-24 · work

  Plots' step 16 merged (L406): the clip on the colour bar, the same on the Surface's height, the row and column cursors, the clip kept in the tab until the core had it. Core 0.76.0 (L407): the set file keeps map_range, difference_range and [[regions]] (with the quantity a region was drawn in), plots::map_region gives a region's block of the map and its range, drs plots describe and drs plots region. Next: Plots' step 17, the zoom in the T–2\(\theta\) plane and the regions on 0.76.0. L407

• 2026-10-24 · work

  Plots' steps 17 and 18 merged (L408, L412): the zoom in the T–2\(\theta\) plane, range from the view, the regions saved in the set file; the Map viewer factored out as one module and bundled as a generated asset of the core (L409). Core 0.77.0 (L413): plots::page_data and drs plots show, the map's page without the app, written beside the set and opened in the browser. Left of the idea: PL39 (the app launched onto a .drv with --view, the app stream) and PL40 (Publish's F3 taking the clip and a region). L414

• 2026-10-24 · work

  PL39 met by the app stream (the app launched onto a .drv with --view) and PL40 by drs-publish 0.36.0 (F3 takes the clip and a named region), both merged (L417). Every step of the idea is built; the app release that carries them, app 0.53.0 on core 0.77.0, is the merging session's next and last step before the idea migrates. One correction found by Publish follows (P65: a region's own range says which map it is on). L417

• 2026-10-24 · migration

  Migrated: app 0.53.0 on core 0.77.0 and drs-publish 0.36.0 built from main e73e5b89, self-checked under PL36 (151 OK, 0 FAIL; relaunch 146 OK, 0 FAIL; Josu's files unchanged) and installed on Josu's Mac, 0.52.1 to the Trash. The interactive map is in his app from the colour bar to the paper and the browser. P65 (a region's range per view) follows as a correction of the core and the module. L418