1Requirements
| Item | Detail |
|---|---|
| Windows | Windows 10 / 11 (x64). Needs the WebView2 runtime, already present on Windows 11 and on up-to-date Windows 10 |
| macOS | macOS 11 or later (Apple Silicon). There is no Intel build |
| Linux | No build is published (Tauri v2 could target it) |
| OS components | HEIC / HEVC pixels are decoded by the OS. On Windows that means "HEIF Image Extensions" (free) and "HEVC Video Extensions" (paid) |
| Languages | English and Japanese. Follows the OS language; can be overridden in settings |
2What it does
Import from USB / SD cards
Sorted into folders by capture date — nine presets, or a pattern you write
Add folders as they are
Photos are never moved into a catalogue of its own. They stay where you keep them
Grid by capture date, plus a calendar
The year scrubber crosses tens of thousands of photos in one drag
Search and filter
File name, folder, camera, capture date, kind (photo / RAW / video), ★ and ⚑. All conditions are ANDed
Viewer and culling
⚑ to pick, ✕ to reject, ★ to favourite. Capture info (aperture, shutter, ISO, GPS) too
Bulk actions
Star a selection, copy or move it to a folder, or send all of it to the recycle bin
Slideshow and video playback
Containers the engine cannot play are handed to your default player
AutoPlay entry (Windows)
Appears as a choice when a card is inserted. It never launches on its own
Ctrl+K, then adding a year on top. Conditions stack with AND, taking 30,000 photos down to 1,200. The recordings on this site show the Japanese interface; the app itself is in English as well.3What it does not do
Features omitted by design and features not yet implemented, listed separately.
| Not available | Why / current state |
|---|---|
| RAW development | Deliberate. The camera's embedded display JPEG is used instead |
| Editing or exporting photos | No rotation, no cropping. It is a tool for looking |
| AI culling or face detection | Deliberate. The person who took the photo decides |
| Tags and keywords | None. There are exactly two marks, ★ and ⚑ |
| Changing the sort order | Newest capture date first, with no way to change it |
| Cancelling an import | Once started, an import runs to completion |
| Video thumbnails (macOS, some containers) | Only what AVFoundation can open is shown: mp4 and mov confirmed working with H.264 and HEVC (hvc1) samples, .avi confirmed empty, other containers untested. Windows borrows from the Shell instead, which has its own limits — .m2ts was never checked there, and a container the OS has no codec for comes back empty |
Duration and dimensions on macOS outside mp4 m4v mov 3gp | Those four are read from the container header. The rest depend on the Windows Shell, so macOS shows no duration or dimensions, and the capture date falls back to the file name or the modification time |
Playing .m2ts / .avi in-app | The browser engine cannot handle those containers. They still appear in the grid |
| A size for a RAW that declares none | Dimensions come from the file's own declaration, from the sensor borders in Panasonic's own RAW formats (rw2 raw rwl), or from the embedded preview. A RAW with none of those — the Blackmagic CinemaDNG we tested — shows no size. On Windows a file that only exists in the cloud is the exception: the Shell supplies its dimensions without downloading it |
| Rebuilding the index from the UI | Delete pictkura.db in the settings folder and it is rebuilt |
| Right-to-left layout | Not supported |
4Supported formats
Grid and full view Limited — Not supported
4.1 Photos
| Extension | Grid | View | Notes |
|---|---|---|---|
| jpg jpeg | Decoded while downscaling, so large photos stay quick | ||
| png webp | |||
| avif | Decoder bundled (rav1d); no OS extension required | ||
| heic heif hif | iPhone's default. Pixels are decoded by the OS | ||
| bmp gif tif tiff | tiff is re-wrapped as JPEG because browsers cannot draw it | ||
| svg | Drawn from the original, so it stays sharp at any zoom |
4.2 RAW — no demosaicing
| Extension | Grid | View | Notes |
|---|---|---|---|
| cr2 cr3 nef nrw arw raf orf rw2 pef srw dng rwl 3fr x3f kdc | The camera's own display JPEG, at or near full resolution. Includes Apple ProRAW (which is DNG) | ||
| crw srf sr2 mrw erf dcr iiq mos | Older bodies embed only a small preview (160×120 to 640×480 on the files we tested), so a full-screen view is soft | ||
| raw | The two we tested (Panasonic DMC-LX1, DMC-FZ8) carry no preview at all, so only a frame appears. The size is read from the sensor borders and the date and camera from EXIF, so they still sort by date and show up in the camera filter | ||
| fff | Hasselblad. The H5D-40 file we tested carries no preview at all, so only a frame appears | ||
| ptx | ? | ? | Pentax. Recognised, but we could not obtain a real file to check |
| Blackmagic CinemaDNG | Contains no preview at all |
Checked on 2026-08-20 against 28 real files from 16 makers (samples from photographyblog.com and the CC0 set at raw.pixls.us): the display JPEG comes out, portrait shots come out upright, and the shot date and camera name are read. The rows above that say a file carries no preview at all are the exception: there is no display JPEG to take, so only a frame appears.
4.3 Video
| Extension | Grid | Plays in app | Notes |
|---|---|---|---|
| mp4 m4v mov webm | Codec support comes from the OS (HEVC needs the extension above) | ||
| avi mts m2ts mkv 3gp wmv mpg mpeg | — | Playback opens your default player |
Appearing in the grid is the same on every platform; what changes is whether a picture comes with it. The grid column above is what was checked on Windows, and even there the picture is the OS's answer rather than ours. Video thumbnails are borrowed from the OS, so a container is covered exactly as far as the OS can open it: on Windows through the Shell (.avi and HEVC .mov confirmed, .m2ts never checked, anything the OS has no codec for comes back empty), on macOS through AVFoundation (mp4 and mov confirmed with H.264 and HEVC (hvc1) samples, .avi confirmed empty, the rest untested). Duration, dimensions and capture time are read from the container header for mp4, m4v, mov and 3gp (not a single pixel is decoded); other containers depend on the Windows Shell.
5Network and privacy
| Item | Detail |
|---|---|
| Outbound connections | One update check at startup, automatic at most once a day. All it sends is "pictkura version X is asking" |
| Never sent | Photos, file names, folder paths, usage. There is no analytics or telemetry of any kind |
| Turning it off | Settings → About pictkura → "Check for updates at startup". With it off, the app never reaches the network |
| Cloud-only files | Never fetched on their own. The real file is pulled only when you actually look at that photo |
| Deleting | Always through the recycle bin. pictkura never removes a file outright |
The same ground is covered as a formal document in the privacy policy.
6Where data lives
| What | Where |
|---|---|
| Settings (Windows) | %APPDATA%\dev.harusame.pictkura\pictkura.toml |
| Settings (macOS) | ~/Library/Application Support/dev.harusame.pictkura/ |
| Index | pictkura.db, in the same folder |
| Thumbnails | thumbs\, in the same folder |
| The photos themselves | Untouched, in whatever folder you added |
The settings file can be edited by hand. Options that have no UI — folder patterns to skip while scanning, which sidecar extensions travel with a photo — are documented in the manual.
7Measured numbers
All figures below were measured on the machine described here. Items that take longer are listed in the same tables.
| Item | Detail |
|---|---|
| CPU | AMD Ryzen 7 5700X (8 cores / 16 threads) |
| Memory | 32GB |
| Location of the files | NVMe SSD (KIOXIA EXCERIA G2) |
| OS | Windows 11 Home |
| Method | Release build. Other processes stopped; the second run is used, with the OS file cache warm |
7.1 Producing the full-size image
The time pictkura takes to produce the full-size image when one is opened in the viewer. The WebView draws it afterwards: a 24MP JPEG takes a further 130ms to decode, or 0.0–0.5ms when the prefetch already holds it.
| Format | Time | Notes |
|---|---|---|
| JPEG | 6ms | No re-encode is required; the bytes are sent as they are |
| RAW, landscape (Canon EOS R8, CR3, 24MP) | 17.1ms | Not developed. The display JPEG embedded by the camera is extracted |
| RAW, portrait (Nikon Df, NEF, 16MP) | 218.5ms | The preview is rotated and re-encoded, which takes about 13× the landscape case. The file has fewer megapixels than the landscape example, so most of the difference is the rotation and re-encode |
| AVIF (4032×3024) | 40–53ms | Decoded by the bundled decoder (rav1d). Scaling and colour conversion are combined, +1–2ms |
| TIFF | about 300ms | The WebView cannot draw it, so it is converted to JPEG first |
| HEIC (iPhone, 24.5MP) | 0.6–1 second | The slowest format in this table. Broken down below |
For RAW, the landscape figure comes from a real Canon EOS R8 file and the portrait figure from a CC0 sample on raw.pixls.us (Nikon Df; a 4928×3280 preview rotated to 3280×4928). The two portrait files measured 216.3ms and 220.7ms.
Where one HEIC goes (average of 20 files):
| Step | Time | Notes |
|---|---|---|
| Decoded by the Windows decoder | 522ms | Performed by the OS; it cannot be shortened here |
| Alpha flattened to white | 10ms | |
| Re-encoded as JPEG | 79ms | The pure-Rust implementation took 496ms, so mozjpeg is used instead |
Reducing the re-encode from 496ms to 79ms still leaves about a second per file, as the decode dominates. The viewer therefore limits prefetch to the single adjacent file and shows the grid thumbnail beneath it until the full-size image arrives.
7.2 Building the library
| What was measured | Time | Notes |
|---|---|---|
| Indexing 3,166 photos that exist only in the cloud | 20 seconds | No network traffic at all. The capture date and dimensions come from what Windows already knows |
| Thumbnail from a JPEG (19MP, average of 40) | 92ms → 40ms | Decoding at full size was replaced by decoding at 1/8 scale |
| Pulling the preview out of a RAW file | 100–350ms | Some formats require the whole file to be read |
| Reading the dimensions of a HEIF | 0.2ms | Header only; no image is decoded |
7.3 Search (30,000 rows, 15,000 matching)
Measured 2026-08-17. Two implementations were compared; the left one shipped.
| Operation | Shipped | Not shipped |
|---|---|---|
| Select a range (151 files) | 6.7ms | 636.8ms |
| Select a range (everything) | 9.2ms | 26.1 seconds |
| Confirm a selection (500 files) | 8.4ms | 529.1ms |
| Confirm a selection (15,000 files) | 295.5ms | 26.7 seconds |
On the query plan alone the right-hand form is the simpler of the two, but measurement put it orders of magnitude behind, so the left one shipped. The other form remains in the code so the comparison can be repeated.
7.4 Bulk operations
| What was measured | Time | Notes |
|---|---|---|
| 500 photos to the recycle bin (2MB each) | about 4.9 seconds | The Windows recycle-bin API costs a median of 20ms per file and 215ms at most |
| The same 500 split into batches (1MB each) | no split 3,675ms 5 batches 4,848ms 10 batches 5,406ms | Splitting increases the total time, but allows progress to be shown from the start |
Measured 2026-08-19. The estimate beforehand was 2.3 seconds; the real machine took 4.9. That is long enough to warrant feedback, so the work is split into batches and progress is reported. The split adds about a second in total; the first batch is small and each subsequent one doubles, which keeps the overhead at that level. Selections of 25 or fewer are not split.
These figures were taken during development and vary with the machine, the files and the version. The tool used to produce them is in the repository (cargo run --release --bin bench; it is not part of the app that ships).