PS Mobile

PSD and PSB viewer for Android. Opens 800 MB, 198-megapixel Photoshop documents in a fraction of a second via a scanline index and tiled rendering.

A mobile Photoshop document viewer for Android, written in Kotlin. It opens PSD and PSB files, renders them, and registers itself as a system handler for both extensions.

The current milestone is opening and rendering. Editing is not implemented; "New document" creates a real, valid canvas so that the surrounding machinery is in place for it.

Opens PSD and PSB of any size the formats allow — verified on an 812 MB, 800 × 247 517 px (198 megapixel) PSB with 155 layers, which parses in 117 ms. Registers as a file handler for .psd/.psb by MIME type, extension and file:// path, so the app appears in "Open with" from any file manager or share sheet. In-app file browser that lists only Photoshop documents, previews them, and can search the whole device in one pass. The system picker is still available as a fallback. Recent documents with rendered thumbnails, dimensions, layer counts and sizes. New document — Photoshop's dialog pared down: presets, size, resolution, colour mode and background. Layers panel with the real group hierarchy, per-layer previews, blend modes, opacity and colour labels. Layers can be shown and hidden, and tapping one takes the canvas to it. Document properties — format, canvas, megapixels, bit depth, channels, resolution. Settings — language, canvas surround, opening zoom, smoothing, zoomed-out quality, file search and preview behaviour. Format support Supported Containers PSD (v1), PSB (v2) Bit depths 1, 8, 16, 32 Colour modes RGB, Grayscale, CMYK, Lab, Indexed, Bitmap, Duotone, Multichannel Compression Raw, RLE (PackBits), ZIP, ZIP with prediction Structure Image resources, layer records, groups, masks, unicode names, colour labels, blend modes, adjustment and text layer detection Files saved without "Maximize Compatibility" have no flattened preview; those are composited from their layers instead, with the separable blend modes implemented.

How it renders a 198-megapixel canvas A single Android Bitmap for that document would be 792 MB, and no GPU will accept a texture 247 517 pixels tall. Nothing in the app ever holds the image as a whole.

1. Scanline index. RLE-compressed image data is preceded by a table of per-scanline byte counts. Reading that table once turns it into absolute file offsets, after which any row of any channel is a single positioned read — no matter how deep into the file it lives. For the test PSB the table is 2.97 MB and the resulting index 5.9 MB, built in a fraction of the 117 ms open. This is what makes the whole design work.

2. Tile pyramid. The canvas is addressed as 512 px tiles across levels; level n samples every 2ⁿ-th pixel, and the top level fits in one tile. The 800 × 247 517 document becomes ten levels, from 2 × 484 tiles at full resolution down to a single tile.

3. On-demand decoding. The viewer works out which tiles cover the viewport at the level matching the current zoom, and asks for those. Tiles are decoded on a small pool of worker threads — each with its own scanline buffers and a sliding read-ahead window — into a byte-budgeted LRU. The coarsest level is pinned, so there is always something to paint under a pending tile rather than a hole; finer tiles overpaint coarser ones as they arrive.

Result: a 198-megapixel document and a 2-megapixel one cost the same to draw, and full-resolution crops from the middle of the file decode in tens of milliseconds.

4. Live compositing when visibility changes. The flattened preview can only ever show the state the document was saved in, so hiding or showing a layer moves rendering onto the layer compositor — same tile interface, same pyramid, blended on demand. Undoing every change moves it back to the fast path. The previous coarse level is kept on screen while the new one decodes, so the canvas sharpens in place instead of blanking.