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, German, Spanish (Spain and Latin America), Simplified and Traditional Chinese, Japanese — seven interface languages to choose from. 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 catalog 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 favorite. File details and capture info (camera, lens, aperture, shutter, ISO, focal length, GPS) too
Take out the picture you are looking at
📋 copies it to the clipboard, 💾 saves it to a file (Ctrl+C / Ctrl+S). The manual has the details
Bulk actions
Star or pick (⚑) a selection, copy or move it to a folder, print it (up to 9 per page), or send all of it to the recycle bin
Right-click actions
Rotate a JPEG (and put its orientation back), print, copy to the clipboard, file details. On Windows, the File Explorer menu opens from there too
Slideshow and video playback
Containers the engine cannot play are handed to your default player
Outgoing
Every import lines up what you want to hand to a photo service in an Outgoing folder. For RAW+JPEG pairs only the JPEG goes in. Off by default. Guide
AutoPlay entry (Windows)
Installed with the installer or from the Microsoft Store, it appears as a choice when a card is inserted (the portable build does not offer it). 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 available in 7 languages.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 photos | No cropping or raw development. It is a tool for looking and choosing (saving the picture on screen, and copying or moving files, are there). A JPEG can be rotated, except photos on a camera card, photos only in the cloud, and JPEGs with no orientation information; when another reason stops it, a message says why |
| 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 (★, ⚑, the records that let a rotation be undone and the record of what was placed in Outgoing or is waiting to be placed again are lost) |
| 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
Whether there is a display JPEG to take is the camera's decision, and bodies writing the same extension disagree with each other — so this is counts from real files, not checkmarks. Full size means the preview's longest edge reaches 1600px, where a full-screen view stops looking soft. None means only a frame appears; the file still sorts by date and still shows up in the camera filter, because the size and the EXIF are read separately from the picture. The same measurement broken down by camera body is here — 923 bodies from 56 makers.
| Ext | Files | A picture | Full size | Small | None | Notes |
|---|---|---|---|---|---|---|
| rw2 | 363 | 363 | 363 | — | — | Panasonic, and the Leicas built on those bodies |
| cr3 | 110 | 110 | 110 | — | — | Canon |
| pef | 40 | 40 | 40 | — | — | Pentax |
| srw | 24 | 24 | 24 | — | — | Samsung |
| rwl | 20 | 20 | 20 | — | — | Leica |
| x3f | 14 | 14 | 14 | — | — | Sigma |
| nrw | 8 | 8 | 8 | — | — | Nikon compacts |
| ori | 19 | 19 | 19 | — | — | OM System. The second of the three files a High Res shot writes (.ORF, .ORI, .JPG) |
| arw | 197 | 197 | 193 | 4 | — | Sony |
| nef | 273 | 273 | 264 | 9 | — | Nikon |
| raf | 143 | 143 | 136 | 7 | — | Fujifilm |
| orf | 85 | 85 | 77 | 8 | — | Olympus and OM System |
| kdc | 5 | 5 | 4 | 1 | — | Kodak |
| cr2 | 134 | 131 | 127 | 4 | 3 | Canon |
| 3fr | 9 | 9 | 5 | 4 | — | Hasselblad. Five at full size, four small |
| iiq | 35 | 35 | 2 | 33 | — | Phase One. A picture from every one, but 33 of 35 are below 1600px |
| erf | 3 | 3 | — | 3 | — | Epson. All three are 160px |
| mos | 3 | 3 | — | 3 | — | Leaf. All three are around 330px |
| srf | 1 | 1 | — | 1 | — | Sony, first generation. 640px |
| sr2 | 1 | 1 | — | 1 | — | Sony, second generation. 640px |
| arq | 1 | 1 | 1 | — | — | Sony. Not written by a camera — Imaging Edge builds it on a PC from 4 or 16 ARWs |
| dng | 257 | 166 | 75 | 91 | 91 | The most split format there is. Apple ProRAW is DNG and comes out at full size; Blackmagic CinemaDNG is DNG and carries nothing. Of the 91 that give no picture, 50 are phones; one of those 91 with no picture is the 383MB Light L16, where the scan stopped short rather than finding nothing; of the 91 small, 38 are 128px thumbnails from Canon compacts |
| fff | 11 | 7 | 1 | 6 | 4 | Hasselblad. Four of eleven give no picture, and only one of the rest reaches full size. One of those four (H6D-100c, 134MB) is past 128MB, so the brute-force scan stopped at 16MB — we cannot say it has none |
| crw | 33 | 12 | 7 | 5 | 21 | Canon, before CR2. Twenty-one of 33 carry no preview |
| mrw | 8 | 2 | — | 2 | 6 | Minolta. Six of eight carry no preview |
| raw | 29 | 7 | 5 | 2 | 22 | Panasonic, before RW2. Twenty-two of 29 carry no preview |
| dcr | 5 | 1 | — | 1 | 4 | Kodak. Four of five carry no preview |
| ptx | 0 | — | — | — | — | Pentax. Recognized, but we could not obtain a real file to check — it is not in the CC0 set, and we did not find one outside it |
Measured on 2026-09-04 against 1,870 real files — every CC0 sample at raw.pixls.us — 816 on macOS and 1,054 on Windows, with no crashes. The 1,831 counted above are the ones whose extension is scanned as RAW; the other 39 are not. Every picture counted here was decoded, not measured from a JPEG header. Two of the extensions above, ori and arq, are measured through the forced-RAW path: they joined the scan list in 0.2.7, after this sweep had run.
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 comes from the OS, not from pictkura. 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 → "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, copy or move it to a folder, or copy it to the clipboard or print it |
| Deleting | Always through the recycle bin. pictkura never removes a file outright, except what it placed in the Outgoing folder |
| Log | The things that did not work, what pictkura did in the Outgoing folders (creating one, removing from it, placing what could not be placed earlier), and what pictkura put right on its own (a file left half-rotated, AutoPlay entries an older version registered, a window that ended up off screen or did not fit the display) are appended to pictkura.log (lines can contain file names and folder paths). Nothing sends it anywhere — open it from Settings to read it, and delete it whenever you like |
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 |
| Log | pictkura.log, in the same folder — written only for what section 5 lists under “Log”, and never sent anywhere |
| Microsoft Store version | If another build of pictkura was used with this Windows account, the same places as above. If only the Store version is used, %LOCALAPPDATA%\Packages\<package name>\LocalCache\Roaming\dev.harusame.pictkura\, which is deleted when you uninstall it |
| The photos themselves | Kept in whatever folder you added. Only rotating from the right-click menu writes to one: it changes a JPEG's orientation tag and its modification time (“Restore original orientation” puts both back) |
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 color 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).