Lift the 1540px vision ceiling by rebuilding the Pixtral RoPE table; map its limits

Follow-up on the four review questions: better settings, a newer model, a
hidden resolution knob. The useful answer is the third.

The 1540px ceiling is soft, not hard. Last week's file called it a hard
architectural limit. The vision tower precomputes a 110x110 RoPE table
(image_size//patch_size = 1540//14) and a larger image indexes past it and
asserts -- but the table is analytic and can be rebuilt for any image_size
with no retraining. Wired in as run_lightonocr.py --rope-rebuild (acts only
when --longest > 1540; the module lives at
model.vision_encoder.patch_positional_embedding and its buffers need an
explicit .to(device)). At 2464 (176 patches/side) it runs clean, VRAM 4.2
-> 5.1 GB, and on the feasibility probe the duplicate-line fraction on the
most starved poster fell 0.30 -> 0.09.

But bigger is not uniformly better, because extrapolating the grid past the
trained 110 band has its own cost. Full corpus at 2464-rebuild vs 1540:
rField 0.765 -> 0.731 overall, but split by native DPI the picture is clear
-- already-fine posters (>=40 DPI) degrade -0.075 (they gain no detail, only
untrained positions), while starved posters (<40 DPI) are a wash on average
(-0.009) yet swing hard per poster: 42 +0.234 (rField to 0.99), gasimova
-0.167 (its banner was already 1.00 at 1540). Two dense posters truncated at
2464 for want of token budget. So the lever is real but "render bigger" is
wrong: the follow-up is adaptive per-poster resolution -- scale toward ~80-100
DPI, cap near 2464 to stay in safe extrapolation, never upscale a poster
already above target -- plus a higher token cap. RESOLUTION.md and
rope_crossover.py carry the full per-poster table.

Two dead ends confirmed, one a retraction. Generation settings do NOT fix
the isporeu loop: greedy, the card's temp0.2/top_p0.9, and greedy+rep_penalty
all loop identically (dup 0.42-0.43). I implied last week that running greedy
was our bug; it was not. The loop begins exactly at a <th>Treatment</th> HTML
table cell -- the model degenerates transcribing a dense results table, a
model limitation, not a decoding artifact. And no newer or higher-res model
exists: LightOnOCR-2 is the current flagship, the sibling checkpoints
(-ocr-soup, -bbox) are all 1B/1540px, and 0.9B-32k is a pruned vocabulary not
a bigger context.

Adds probe scripts (probe_combined.py, probe_rope2.py), the crossover
analysis, and the 2464 raw outputs so the per-poster claims are reproducible
without a GPU.

Author: jimnoneill

calibration/vlm/FINDINGS.md

@@ -61,6 +61,11 @@ merge, no marker parsing. It also returns wrapped titles in one piece.
 
 ## Resolution: the ceiling is architectural, and posters fall off it
 
+> UPDATE 2026-07-24: "architectural" was too strong. The 1540px ceiling
+> is SOFT -- the Pixtral vision RoPE table can be rebuilt for a larger
+> image_size with no retraining (run_lightonocr.py --rope-rebuild). It
+> helps the worst-starved posters but not for free. See RESOLUTION.md.
+
 **1540px is not a setting.** `PixtralVisionConfig.image_size = 1540`,
 `patch_size = 14`, so the vision tower's 2D RoPE table holds 110 patch
 positions per axis. Hand it a bigger image and it indexes off the end:

calibration/vlm/RESOLUTION.md

@@ -0,0 +1,100 @@
+# Resolution and settings follow-up (2026-07-24)
+
+Four questions from the review: better generation settings? a newer model? a
+hidden resolution knob in the config? The answers, in order of usefulness.
+
+## 1. The 1540px ceiling is soft: the vision RoPE table can be rebuilt
+
+This is the real finding. Last week's file called 1540px a "hard architectural
+ceiling". It is not. The vision tower precomputes a
+`max_patches_per_side x max_patches_per_side` RoPE table where
+`max_patches_per_side = image_size // patch_size = 1540 // 14 = 110`
+(`PixtralRotaryEmbedding.compute_default_rope_parameters`). A larger image
+indexes past 110 and asserts -- but the table is analytic, so it can be rebuilt
+for any `image_size`:
+
+    enc = model.model.vision_encoder
+    c = enc.patch_positional_embedding.config
+    c.image_size = 2464                       # 176 patches/side
+    emb = PixtralRotaryEmbedding(c).to(dev)   # buffers need explicit .to(dev)
+    emb.inv_freq = emb.inv_freq.to(dev)
+    emb.original_inv_freq = emb.original_inv_freq.to(dev)
+    enc.patch_positional_embedding = emb
+
+No retraining. Wired into the runner as `--rope-rebuild` (only acts when
+`--longest > 1540`). At 2464 it runs clean -- coherent text, VRAM 4.2 -> 5.1 GB,
+and on the feasibility probe the duplicate-line fraction on the most starved
+poster actually FELL (0.30 -> 0.09). NTK theta-scaling on top gave nothing extra
+and 3080 began to degrade, so plain table-rebuild at ~1.6x is the sweet spot.
+
+## 2. But more resolution is not a blanket win, because extrapolation has a cost
+
+Scored full corpus at 2464-rebuild vs 1540 (`rope_crossover.py`). Corpus rField
+went DOWN, 0.765 -> 0.731, head-to-head 8 wins / 11 losses. The per-poster split
+by native effective DPI:
+
+    already-fine (>=40 DPI at 1540)  n=5   mean d rField -0.075   clearly worse
+    starved      (<40 DPI)           n=13  mean d rField -0.009   a wash
+
+The already-fine posters degrade cleanly (6724771 0.98 -> 0.80, 4560930
+0.65 -> 0.53): they are small, already at or above native resolution, so 2464
+only pushes their patch grid into the never-trained 110-176 band for no added
+detail. That is the cost of extrapolation, and it is real.
+
+The starved posters are a genuine mixed bag, not the uniform win the DPI theory
+predicted:
+
+    42        (32 DPI)  rField 0.76 -> 0.99   +0.234   <- huge
+    aysaekanger(33)     0.69 -> 0.76   +0.073
+    8228476   (33)      0.50 -> 0.56   +0.052
+    gasimova  (33)      0.90 -> 0.74   -0.167   <- its banner was already 1.00
+    AISec     (33)      0.84 -> 0.74   -0.093
+    10890106  (28)      truncated at 2464 (more pixels -> more tokens)
+    5128504   (35)      truncated at 2464
+
+So added detail helps some starved posters a lot and destabilizes others whose
+banner was already perfect at 1540. The extrapolation cost competes with the
+detail gain, and which wins is per-poster.
+
+**Conclusion:** RoPE rebuild is a real, working lever, but "just render bigger"
+is wrong. The right design is ADAPTIVE per-poster resolution -- scale each
+poster toward a target effective DPI (~80-100), CAP at ~1.6x the trained grid
+(≈2464) to stay in the safe extrapolation band, and never upscale a poster
+already above target. Plus a higher token budget, since more pixels truncated
+two dense posters at 6144. That is the follow-up worth running; a fixed edge is
+not it.
+
+## 3. Generation settings do NOT fix the failures (retraction of "we ran it wrong")
+
+I noted last week that we used greedy while the shipped `generation_config.json`
+is `do_sample=true, temperature=0.2, top_p=0.9`, and implied that was our bug.
+Tested on isporeu2023, the poster that loops (`probe_combined.py`):
+
+    greedy (what we ran)       3072tok dup=0.43  LOOP
+    card: temp0.2 top_p0.9     3072tok dup=0.43  LOOP
+    greedy + rep_penalty1.15   3072tok dup=0.42  LOOP
+
+All three loop identically. Honoring the config is more correct and we should do
+it, but it changes nothing on the hard cases. The isporeu loop is not a decoding
+artifact: it begins exactly at `<th>Treatment</th>` (line 105, first repeat of
+line 75) -- the model degenerates trying to transcribe a dense
+cost-effectiveness RESULTS TABLE as HTML. That is a known VLM-OCR failure mode
+and a model limitation, not a setting. The banner and prose above it are clean.
+
+## 4. No newer or higher-res model exists
+
+LightOnOCR-2 (Jan 2026) is current and is the flagship. Checked the org: the
+only other checkpoints are same-size variants -- `-base`, `-ocr-soup` (weight
+average), `-bbox` (adds bounding boxes) -- all 1B, all 1540px vision. There is
+no 2B, no larger, no higher-resolution model. The `LightOnOCR-0.9B-32k` "32k" is
+a pruned VOCABULARY (European-language speedup), not context length or
+resolution. `-bbox` is worth a look ONLY if we later want layout coordinates;
+it does not change the resolution story.
+
+## Net
+
+The banner win from last week stands (VLM reads author/affiliation structure far
+better than xy_cut). The resolution ceiling is liftable and helps the worst
+posters, but not for free, so the next experiment is adaptive resolution + token
+budget, not a bigger fixed render. Settings and model-shopping are dead ends:
+the config is already optimal and there is nothing newer to buy.

calibration/vlm/out_rope2464/10890106.md

@@ -0,0 +1,95 @@
+# OPTIMIZATION AND VALIDATION OF A BIOCHEMICAL FRET ASSAY FOR THE EXONUCLEASE ACTIVITY OF SARS COV-2 NSP14-NSP10 COMPLEX
+
+Laura Dettori$^{1,2}$, Paolo Malune$^{2}$, Marta Maria Cara$^{1,2}$, Salvatore Nieddu$^{2}$, Enzo Tramontano$^{2}$ and Francesca Esposito$^{2}$
+
+$^{1}$National PhD Programme in One Health approaches to infectious diseases and life science research, Department of Public Health, Experimental and Forensic Medicine, University of Pavia, Pavia, 27100, Italy.
+
+$^{2}$Department of Life and Environmental Sciences, University of Cagliari, 09042, Monserrato, Italy.
+
+---
+
+## INTRODUCTION
+
+SARS-CoV-2, the virus responsible for COVID-19, has one of the longest RNA genomes among RNA viruses. To correct replication errors, it uses a unique proofreading mechanism involving the nsp14 protein, which has 3'-5' exonuclease activity, assisted by the cofactor nsp10. Currently, there are no drugs targeting this function. To support antiviral research, nsp14 and nsp10 were expressed and purified in E. Coli cells, and a FRET-based biochemical assay was developed to study their exonuclease activity, as previously mentioned in the literature [1]. This system lays the groundwork for identifying future inhibitors of the nsp14-nsp10 complex.
+
+---
+
+## WORKFLOW
+
+![image](image_1.png)
+
+---
+
+## RESULTS
+
+### 1. Size-exclusion chromatography (SEC)
+
+![image](image_2.png)
+
+nsp14
+
+nsp10
+
+### 2. pH dose-dependent
+
+![image](image_3.png)
+
+pH 7.5
+
+### 3. MgCl$_2$ dose-dependent
+
+![image](image_4.png)
+
+[MgCl$_2$]
+
+MgCl$_2$ 4 mM
+
+### 4. Enzymatic activity curve
+
+![image](image_5.png)
+
+nsp14 250 nM + nsp10 750 nM
+
+### 5. Substrate concentration curve
+
+![image](image_6.png)
+
+Substrate concentration 1 µM
+
+### 6. Inhibition Dynasore NO-Cat curve
+
+![image](image_7.png)
+
+IC$_{50}$ = 3.3 µM ± 0.4
+
+---
+
+## CONCLUSIONS
+
+Optimization of the biochemical assay of the enzyme nsp14-10 allowed the development of a sensitive, reproducible, and effective method to study the activity of this enzyme complex. A compound known in the literature as an inhibitor of the nsp14-10 complex was used [2]. This result represents an important step in furthering the biochemical characterization of nsp14-10 and facilitating future screening activities for potential inhibitors, with possible implications in the development of new antiviral strategies.
+
+---
+
+## ACKNOWLEDGMENTS
+
+This research was supported by EU funding within the NextGenerationEU-MUR PNRR Extended Partnership initiative on Emerging Infectious Diseases (Project no. PE00000007, INF-ACT), spoke 5. AVITHRAPID: Antiviral Therapeutics for Rapid Response Against Pandemic Infectious Diseases” project n. 101137192 - HORIZON-HLTH-2023-DISEASE-03, finanziato nell’ambito del programma HORIZON EUROPE - CUP F23C23000820006.
+
+---
+
+## REFERENCES
+
+[1] Rona G, Zeke A et al. The NSP14/NSP10 RNA repair complex as a Pan-coronavirus therapeutic target. Cell Death Differ. 2022 Feb;29(2):285-292. [2] Asthana, A.; Corona, A.; et al. Analogs of the Catechol Derivative Dynasore Inhibit HIV-1 Ribonuclease H, SARS-CoV-2 nsp14 Exoribonuclease, and Virus Replication. *Viruses* 2023, 15, 1539.
+
+---
+
+![image](image_8.png)
+
+Finanziato dall'Unione europea NextGenerationEU
+
+Ministero dell'Università e della Ricerca
+
+Italiadomani
+
+Fondazione INF-ACT
+
+AVITHRAPID PROJECT