Neatbo.

Preserve camera views and container provenance

A camera container can hold multiple compressed images and legitimate gaps; preserve source evidence before interpreting stereo meaning.

The first displayed image is not the whole camera container

The original 3DS recovery request sought separate JPEGs using existing hardware; another author found that ordinary viewers only show one stored capture. The useful deliverable is each original compressed view, rather than another resize or crop of the first raster.

T326 is one workflow for all supported MP entries. Source offsets and index order determine filenames; another eye, color setting or endian variant does not create an independent tool.

A byte between views can be provenance

Both actual Nintendo3DS specimens contain a one-byte inter-view gap. Requiring contiguous streams would wrongly reject them. Each indexed range is checked, overlaps refused and every gap/trailing byte retained in original.mpo with full offset/length/SHA evidence.

Standalone JPEGs remove only cross-file MPF APP2 references. Exact indexed streams also travel in the ZIP, making every removal auditable.

Tie claims to artifacts
ClaimEvidenceLimit
Source preservedoriginal.mpo and source SHANo interpretation of every unindexed byte
All indexed views deliveredOriginal stream and standalone JPEG with offsets/hashesUnsupported or malformed framing refuses atomically
Metadata retainedComplete EXIF/APP1 outside removed MPFNot anonymization or complete EXIF validity assurance
No pixel reencodingCompressed bytes retained after controlled MPF removalCompressed entropy is not decoded by this tool

Interpret meaning after recovering bytes

Index order, raw MP type and dependent references do not automatically label left/right or depth. Review each exported JPEG before stereo alignment or GIF editing. GPS and other camera metadata can survive; consider that retention when sharing.

  • Keep original and complete report beside downstream edits.
  • Compare source and standalone hashes to distinguish extraction from later processing.
  • Treat arbitrary damaged entropy, every camera variant and iPhone behavior as separate compatibility questions.

Require actual workload evidence without universal promises

The typed production report has a genuine 8 MiB exact witness: legal raw TIFF aliases expand into full JSON/CSV. One extra source-name character produces the first-excess atomic refusal. Full serialized evidence, not source size alone, controls that boundary.

A real 1000-view Worker is canceled at positive incomplete progress and recovers the same original with byte-identical complete ZIP. That is native evidence. Actual browser interaction has a separate acceptance channel; specimen decoding and structural recovery do not certify all CIPA camera semantics.

References

Tools in this category

Expand a tool to see its steps, options and supported formats, then open its workspace.

Extract MPO imagesRecover every indexed JPEG view from a local MPO, preserving compressed originals, EXIF and full offset/SHA evidence.

Select one MPO or JPEG carrying an MP index. Recover every stored view in index order, without pixel reencoding. Download one ZIP with the exact original, standalone JPEGs, original streams and complete inventory.

Steps

  1. Select one original MPO or MP-indexed JPEG and keep a separate copy.
  2. Run and inspect the view count, dimensions, order and unindexed byte count.
  3. Download mpo-views.zip; open every standalone JPEG you need.
  4. Use the complete inventory and original streams to audit offsets, metadata and SHA256.

Capabilities and limits

  • One file up to 50 MiB and a filename up to 512 UTF-16 units. JPEG MP version 0100, II/MM TIFF, 2–1000 in-bounds nonoverlapping indexed views; physical order may differ from index order.
  • 8-bit baseline/progressive JPEG with one or three components. SOF, SOS, selectors, sampling, DQT, Huffman shape, lengths and EOI are checked. Compressed entropy is preserved without decoding or full validity assurance; broken JPEG repair is outside scope.
  • All TIFF types 1–12 and bounded next-IFD chains are reported as typed raw values. Sorted unique tags and bounded exact/partial value aliases are supported; directory/header storage overlaps are refused. This does not interpret every camera attribute or certify full CIPA compliance.
  • At most 1024 tags per IFD, 20000 total MPF tags, 2048 total IFDs, 64 chain levels and 20000 indexed JPEG structural segments. Complete compact JSON plus CSV must fit 8 MiB. Every budget applies simultaneously; an excess or malformed file creates no archive.
  • The ZIP contains original.mpo, every view-NNNN-original-stream.bin, every view-NNNN.jpg, mpo-inventory.json and mpo-tags.csv. A 1000-view file has 2003 controlled members. The 170 MiB ZIP ceiling is a dominated allocation guard, not an independently reachable output promise.
  • Standalone JPEGs remove only MPF APP2 segments to eliminate stale cross-file index pointers. Compressed pixels, EXIF/GPS and other permitted metadata remain. The original container and indexed streams are byte exact. Gaps/trailing bytes remain in the original and receive offset, length and SHA records.
  • All view rows appear in the table. Complete offsets, dependency references, raw TIFF fields, removed spans and hashes are in downloads. Eye assignment and depth are not inferred; no stereo alignment or GIF assembly is performed.
  • Browser-local byte processing. No URL fetch, metadata execution, upload, camera/filesystem scan or cloud service. This is view recovery, not anonymization; sharing the output can retain GPS and other camera metadata.
Open Extract MPO images →