semantic_joint_ctxmix (0.148)

[adpena]

Submission name

semantic_joint_ctxmix

Upload zipped archive.zip

Attached to this pull request via my fork's release: archive.zip. Verify after download:

• SHA-256: cbb8d928a8ccdd3f5103da1d4a8d38d0662a5e5615266b923b5f8350d405bf25
• Size: 180,002 bytes (one stored member p, 179,902 bytes)

report.txt

=== Evaluation results over 600 samples ===

Average PoseNet Distortion: 0.00000637

Average SegNet Distortion: 0.00020139

Submission file size: 180002 bytes

Original uncompressed size: 37545489 bytes

Compression Rate: 0.00479424

Final score: 100*segnet_dist + √(10*posenet_dist) + 25*rate = 0.15

Verbatim from the evaluator (device: cuda, num_threads: 2), Tesla T4, Linux x86_64, all 600 samples. The final line displays two decimals; recomputed from the report's own printed components the score is 0.14797617125559104.

Does your submission require GPU for evaluation (inflation)?

Yes. Measured on T4: 532.3 s inflation + 40.6 s evaluation ≈ 573 s. CPU inflation exceeded the wallclock budget, so GPU is required.

Did you include the compression script? And want it to be merged?

Yes. compress.py in the submission directory replays the five lossless coding stages that produced this archive from its pinned base and refuses unless the rebuilt archive matches its pinned SHA-256 exactly. The pinned base archive is an input rather than part of the packet, so compress.py refuses without it. Usage and environment pins are described in README.md.

Note: the training, segmentation edit solve, and pose re-solve stages (described below) did not run on CUDA. I ran them on my local Apple-silicon machine using this project's MLX/Metal ports of the contest's frozen scoring networks, with every accepted change verified against the standard CPU PyTorch scorers. Re-running those stages takes days of compute and would not reproduce the exact bytes on different hardware, so compress.py does not attempt it at this time. The code, configs, and logs for all of it are in my research repository: https://github.com/adpena/comma-lab (evaluated commit 1c9fbbf5).

TODO (planned after this submission):

• A --device flag so the solve stages can run on CUDA as well as on the Apple-silicon stack.
• A full-pipeline mode that starts from the raw video, runs the credited PR semantic-pose-HPAC_CPR1 #130/semantic-pose-HPAC_CPR1_polished (0.162) #135 training scripts, then applies the solve and packaging stages. Because neural training is not bit-for-bit reproducible across GPUs, the resulting archive's score and quality would need fresh measurement.
• Generalizing the pipeline so it can be pointed at any video by turning the per-video constants (frame count, resolution, pair structure) into automatically measured configuration.

Is this submission competitive or innovative? Explain why

Competitive: 0.14797617125559104 [contest-CUDA T4, n600] versus the public PR #135 result of 0.162 on the same axis (author-reported unrounded 0.16226842169958583).

Inherited: The learned semantic renderer and pose-carrier vehicle come from PR #130 (Fesal Fayed, @fesalfayed) and PR #135 (Shreyan Mohanty, @codexblack). PR #135 in turn builds on PR #133 (@JasonMo123), which refined PR #130's vehicle. Credits are in README.md beside the source, and the full mechanism-level accounting is in my research repository.

Innovative: The decision and lossless-representation layer built on top of that vehicle is a campaign of pointer-moving improvements, each accepted only after re-scoring the rebuilt archive:

• Joint edit admission (the submission's namesake): candidate segmentation edits of the semantic tokens are proposed per pair and priced against their exact pose cost through the frozen PoseNet, then admitted through a Lagrange-multiplier waterfill (455 of 573 proposed edits admitted). The pose carrier is then re-solved (damped Gauss–Newton) against the edited renders. This is the largest single move and produced the sub-0.15 crossing.
• In-compile pose compensation: a frame-0 compensation solved inside the compile so segmentation edits carry approximately zero pose tax. Pose distortion landed below the unedited base on its proof row.
• A zero-byte pose re-solve of the stored carrier coefficients against the frozen scorer on the shipped renders.
• A lossless representation chain on the coder and container: fixed-point integer log-odds context mixing, group-conditioned token contexts, an address-free tile-conditioned re-encode, an exact receiver-assembly identity check, and container transforms. After the previous packet was frozen, five further changes shaved another 454 bytes off the archive while decoding to exactly the same output.

Independent concurrent development: Some of the inherited ideas were in my tree before the PRs that published them. A stored PoseNet-target sidecar conditioning the decoder on ground-truth pose targets was committed April 11, 2026, before PR #130's semantic-pose carrier. A direct-partition coding stack (region adjacency, contour coding, margin-based region merging) was committed June 10, 2026, before PR #130's dense semantic-token vehicle. PR #130/#135 shipped working public vehicles first and this submission builds on their shipped form.

Additional comments

What did not work:

• Lossy quantization of the learned tensors: worse at every depth I measured. The render amplifies weight error faster than the byte credit pays.
• Distilling the renderer into a smaller network: the smaller model's pose error cost tens of times more than the weight bytes it saved.
• Replacing the dense lane tokens with parametric lane curves: every version, including a trained lane predictor, came out larger than the tokens it replaced once the needed corrections were counted (1.7× at best, several times in most versions).
• Swapping or re-tuning the entropy coder: on the measured shipped-family bodies, 25 Brotli/LZMA configurations found no saving on the frozen model sections, and generic recoding added 5 bytes on the then-current token stream. These fixed-probability coder swaps lost; changing the context model is a different axis.
• Reordering the token stream before coding: within the shipped fixed model's only lossless reorder class, a full-n600 seeded within-group permutation changed the stream bytes but not its length (113,777 bytes to 113,777 bytes). Cross-group ordering would require training a different context model.
• Storing explicit "fix this pixel/token" corrections: the addresses cost more than the corrections were worth. The address-free tile-conditioned re-encode in this submission is what replaced that idea.
• Small fitted pose-correction layers: in a stratified n64 local CPU screen, the 43-byte, 247-byte, and 997-byte variants were modeled-positive but held-out pose-negative or neutral, so none passed the gate to compile or exact contest evaluation.

I used coding agents (Claude as orchestrator of Codex subagents) extensively as research and engineering tools for the work behind this submission. The linked repository contains the resulting prompts, implementation history, experiment receipts, and provenance records.

[github-actions]

Thanks for the submission @adpena! 🤏

A maintainer will review your PR shortly.

To run the evaluation, a maintainer will trigger the eval workflow with your PR number.