[BUG] MRXS reads are not deterministic: overlapping camera tiles are painted from parallel tasks
Maintainers usually reply within 3 days
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- backend, performance
Research direction
Start with MrxsTileExecutor::ExecutePlan and the canvas coverage logic in rgb_blit.cpp and bilinear_blit_hwy.cpp; compare the existing BifTileExecutor handling of overlapping tiles. Reproduce with the named MRXS test slide and repeat read_region calls. Done means overlapping tile reads return identical pixels across runs while retaining parallel decoding; an open linked pull request indicates work is already underway.
Written by the indexing model from the issue text.
Description
Problem
MRXS reads are not deterministic: the same read_region returns different pixels from one call to the next, even from a single thread.
Reading one 512×512 region at level 4 of a MRXS slide (Mirax2.2-4-BMP.mrxs, OpenSlide test data) 20 times in a row, without a cache:
- 19 of 19 repeat reads differ from the first;
- up to 29 220 of 262 144 pixels differ (11 %), by up to 140 levels (histogram from 1 to 140, so whole overlap bands switch between camera tiles, not rounding).
On a tile-by-tile scan of the slide (973 tiles at ~4 mpp and ~0.5 mpp), 145 tiles change between two runs.
Cause
MRXS camera tiles overlap. MrxsTileExecutor::ExecutePlan paints the operations of a read from parallel pool tasks (submit_sequence over plan.operations). The canvas resolves overlaps with its coverage map, first writer wins (rgb_blit.cpp, bilinear_blit_hwy.cpp skip already-covered pixels). The first writer is whichever task finishes decoding first, so the visible camera tile in an overlap changes from read to read.
Running the operations serially on one thread makes the output deterministic: 0 of 973 tiles change between runs, and 0 of 19 repeat reads differ.
Proposal
Do what BifTileExecutor already does for its overlapping tiles: decode the tiles of a read in parallel (phase 1), then paint them serially in a fixed order (phase 2), e.g. plan order, or the order that matches OpenSlide's MRXS rendering. That keeps the parallel decode and makes the output a function of the request only.
- Dominant language
- C++
- Stars
- 56
- Forks
- 4
- Avg merge
- 5d 3h
- Merged PRs (30d)
- 7
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NKI-AI/fastslide
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
NKI-AI/fastslide#76 · 1 comment ·
Maintainers usually reply within 3 days
-
[BUG] Every cache miss copies the decoded tile into the cache, and evicted tiles are freed under the cache lockPossibly taken @AzHicham claimed this 25 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Maintainers usually reply within 3 days
-
Concurrent reads decode the same stored tile several times (no single-flight on cache misses)Possibly taken @AzHicham claimed this 25 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Maintainers usually reply within 3 days
-
Every read hands its tile operations to the shared pool; costly for servers with concurrent readsPossibly taken @AzHicham claimed this 25 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
NKI-AI/fastslide#68 · 6 comments ·
Maintainers usually reply within 3 days
All issues in NKI-AI/fastslide
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
-
area:qmc bug
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
Maintainers usually reply within 3 days
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ASGC-Game-Jam/asgc-gamejam-2026#563 ·
Maintainers usually reply within 1 day
-
area/ysql kind/bug priority/medium status/awaiting-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
yugabyte/yugabyte-db#37523 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100