v0.2.3
pictkura 0.2.3 is the release where the Mac build stops being a shell of the Windows one:
HEIC photos and videos get real thumbnails, the first launch stops quoting Windows at you,
and a library that comes up empty now says why instead of showing a bare 0.
What's new
HEIC and HEIF decode on macOS. Every HEIC sat in the grid as an empty frame, because
the macOS build had no HEIF decoder wired up at all — and the notice beside it told Mac
users to go buy a Windows Store extension. pictkura now decodes them through ImageIO, the
system's own decoder, on every HEIF entry point in the code — the photo, the viewer, the
embedded thumbnail, the HEVC preview inside a CR3, and the check for whether a decoder is
there at all. The picture is drawn into an sRGB bitmap so CoreGraphics does the colour
conversion, which is what the Windows path has always done, so both platforms come out of
the decoder in the same format.
Measured on Apple Silicon: a 24MP main image from an iPhone takes 330–357ms where before
there was no decoder, and its embedded thumbnail about 15ms. RAW coverage on the CC0
sample set went from 9 of 10 to 10 of 10.
Videos get thumbnails on macOS. They were all empty frames. pictkura now pulls the
first frame through AVFoundation, so mp4 and mov show a picture — measured at about
80–104ms for the first tile in a grid and about 10ms for every one after it, since only
the first pays AVFoundation's start-up cost. Rotation is left to the framework
(appliesPreferredTrackTransform), so a portrait clip should come out upright, though
that has not been checked against a clip from a real phone.
.avi still shows an empty frame on macOS, and it is the one container we know cannot be
reached: QuickLook hangs on it (45 seconds, had to be killed) and Spotlight returns
nothing for it either. Containers other than mp4, mov and .avi have not been
measured either way.
The Mac's first launch stops quoting Windows. Three things were written for Windows and
shown to everyone: the drive list said Macintosh HD () with an empty label, offered
/System/Volumes/Data as a place to browse, and the "add a folder" hint suggested
D:\Pictures. The label keeps the mount point, browsable disks are now decided by the flag
macOS itself sets (MNT_DONTBROWSE) rather than by matching path text, and the hint is
per-platform. Drives holding a DCIM folder sort to the top of the list.
The two codec notices split three ways as well: Windows still offers the Store extensions
because there is genuinely something to install, macOS says the decoder ships with the
system, and anything else says a decoder may be missing without claiming either way.
An empty library says why it is empty. On a Mac's first launch ~/Pictures usually
holds nothing but the Photos app's own library, and pictkura does not read inside that —
so the scan was correct, the exclusion was correct, and the screen said 0 with no
explanation, which reads as broken. It now answers, in order: no folder is configured yet;
a configured folder is not there, naming it, which is usually an external drive that is
unplugged; a folder exists but could not be read, naming it, which on macOS is usually
the permission prompt that was declined; the folder holds a Photos, iPhoto or Aperture
library, with wording that matches which one, since only the Photos library keeps most
originals in iCloud; everything found was excluded; or the folder genuinely has no photos
in it.
It also stops speaking with more confidence than it has. A folder that never answers — a
network share that stopped answering mid-session, with the connection still up, is the
case this was measured against — is now reported as exactly that, with the place named,
rather than as "still looking". Each folder is checked on its own, so one wedged share no
longer takes the healthy folders down with it, and a share that never answers is not
touched again until it comes back or is
removed. A scan that failed no longer reports itself as finished, and the panel asking you
to press Rescan takes itself down once a rescan works.
A RAW with no usable preview keeps its date, size and camera. Extracting the preview
and reading the metadata are two jobs, and a failure in the first was throwing away the
second, which had already succeeded. A Canon CR3 shot in 2024 was filed under the day it
was copied, and had dropped out of the camera filter. It now records the size, capture
date and camera even while the thumbnail is still reported as a failure.
Libraries reached through a symlink stop losing favourites. On macOS the file watcher
reports resolved paths — /var comes back as /private/var, and letter case is corrected
to whatever is on disk — which did not match the spelling in your settings. The database
treated them as two different photos, swept the original, and recreated it under a new id,
taking the favourite and the cull mark with it. Watcher paths are put back into the
configured spelling before they reach the database. A plain ~/Pictures was never
affected.
Downloads
| You want | File |
|---|---|
| Windows 10/11, the usual case | pictkura_0.2.3_x64-setup.exe — no administrator rights |
| Windows, machine-wide install (for administrators) | pictkura_0.2.3_x64_ja-JP.msi / _en-US.msi |
| Windows, no installer | pictkura_0.2.3_x64-portable.zip |
| macOS 11+ (Apple Silicon) | pictkura_0.2.3_arm64.zip |
Neither build is code-signed, so Windows shows SmartScreen and macOS shows Gatekeeper on
first launch. The README walks through
both, including the extra steps macOS 15 needs.
Upgrading from 0.2.2
On Windows, run the installer over the top of the old one. On macOS, unzip the new
pictkura.app and replace the old one where you keep it — the Gatekeeper steps in the
README apply again, because the app you
just downloaded is a new file as far as macOS is concerned.
Either way, your library, settings, favourites and picks stay where they are.
Known gaps
Video thumbnails go only as far as the operating system can open the container: on Windows
they come from the Shell, on macOS from AVFoundation, where mp4 and mov were measured
working with H.264 and with HEVC (hvc1) samples, .avi measured returning nothing. The
frame taken is always the first one, so a video that fades in from black gets a black
tile. Linux has no route wired up for any of this, and there is no Linux build. .m2ts
and .avi appear in the
grid but do not play inside the app. There is still no sort order for search results
(newest capture date first), no UI to rebuild the search index, and imports cannot be
cancelled once started. The full list is in the README.
日本語
pictkura 0.2.3 は、Mac 版が Windows 版の抜け殻でなくなる更新です。HEIC の写真と動画に
サムネイルが出るようになり、初回起動の画面が Windows の言葉を並べるのをやめ、
ライブラリが空のときは 0 件 とだけ出さずに理由を言うようになりました。
新しくなったところ
macOS で HEIC / HEIF の絵が出ます。 これまで HEIC は一覧に枠だけが並んでいました
——Mac 版には HEIF のデコーダが1つも繋がっていなかったからです。しかも横の案内は、
Mac の人に向かって Windows ストアの拡張機能を買うように言っていました。いまは macOS 自身の
ImageIO で展開します。HEIF に行き着く入口——写真・ビューア・埋め込みサムネイル・
CR3 の中に HEVC で入っているプレビュー・そもそもデコーダがあるかの判定——の
すべてに入れてあります。取り出した絵はいったん sRGB のビットマップに描き直して
CoreGraphics に色を変換させます——Windows 側が前からやっていることと同じで、
両方のOSでデコーダの出口が揃います。
Apple Silicon で測りました。実物の iPhone の 24MP の写真そのものが
330〜357ミリ秒（それまでは「デコーダが無い」でした）、その埋め込みサムネイルは
15ミリ秒ほどです。CC0 の見本の RAW は10件中9件だったのが10件中10件になりました。
macOS で動画にサムネイルが出ます。 これまでは全部が枠だけでした。いまは
AVFoundation で先頭のコマを取り出すので、mp4 と mov に絵が出ます。一覧の
1枚目が約80〜104ミリ秒、2枚目以降は約10ミリ秒——AVFoundation の初回読み込みを
払うのが最初の1枚だけだからです。向きは AVFoundation 任せ
（appliesPreferredTrackTransform）なので、縦位置の動画も正しく出るはずですが、
実物のスマートフォンの動画では確かめていません。
.avi は macOS では枠だけのままです。しかもこれは、どの道からも届かないことが
分かっている唯一のコンテナです——QuickLook は45秒返らず（強制終了しました）、
Spotlight も何も返しません。mp4・mov・.avi 以外のコンテナは、出るとも出ないとも
測っていません。
Mac の初回起動が Windows の言葉を並べるのをやめました。 Windows 向けに書いたものを
そのまま全員に見せていた箇所が3つありました——ドライブの一覧が Macintosh HD () と
名前を空にしていたこと、/System/Volumes/Data を「開けるディスク」として並べていたこと、
フォルダを足すときの例が 例: D:\Pictures だったことです。名前はマウント先をそのまま
使うようにし、一覧に出すかどうかは macOS 自身が立てる印（MNT_DONTBROWSE）で決めるように
しました——パスの文字を見て当てるのをやめています。例文はOSごとに分けました。ついでに、
DCIM フォルダを持つドライブが一覧の先頭に来ます。
コーデックの案内も3つに分かれました。Windows には本当に入れるものがあるので
これまでどおり案内し、macOS には「OSに入っています」と伝え、それ以外のOSには
「無いかもしれません」とだけ言います——あるともないとも決めつけません。
ライブラリが空のとき、その理由を言います。 Mac の初回起動では、~/Pictures の中身が
写真アプリのライブラリだけ、ということがよくあります。pictkura はその中を読まないので、
スキャンも除外も正しく動いた結果として 0 件 だけが出ていました。これは壊れているように
見えます。いまは順に答えます——フォルダをまだ設定していない／設定したフォルダがそこに無い
（名前を出します。たいていは繋いでいない外付けドライブです）／フォルダはあるのに読めない
（名前を出します。macOS では権限の確認を断ったときがほとんどです）／中身が写真アプリ・
iPhoto・Aperture のライブラリである（どれに当たったかで文面を変えます。原本がiCloudに
あるのは写真アプリだけなので）／見つかったものが全部除外された／本当に写真が1枚も無い。
分かっていないことを分かったように言うのもやめました。 返事をしないフォルダ
——接続は生きたまま返事だけ来なくなったネットワーク共有で実測しました——は
「まだ探しています」ではなく、
場所を名指しで「返事がありません」と出します。フォルダは1つずつ別々に調べるので、
固まった共有が1つあっても、他の健全なフォルダを道連れにしません。返事をしない共有は、
戻ってくるか設定から外すまで二度と触りません。途中で落ちたスキャンが「終わりました」と
名乗ることもなくなり、「再スキャンしてください」の案内は、再スキャンが通れば自分で下がります。
使えるプレビューが無い RAW でも、日付・寸法・カメラは残ります。 プレビューの取り出しと
メタデータの読み取りは別の仕事なのに、前者が失敗するとすでに成功していた後者まで
捨てていました。2024年に撮った Canon の CR3 が、コピーした日のフォルダに並び、カメラの
絞り込みからも消えていました。いまはサムネイルを失敗として報告しながら、寸法・撮影日時・
カメラは控えます。
シンボリックリンク越しのライブラリで、お気に入りが消えなくなりました。 macOS の
ファイル監視は解決済みのパスを返します——/var は /private/var になり、大文字小文字も
ディスク上の綴りに直されます。これが設定の綴りと一致しないため、データベースは別の写真として
扱い、元の行を掃除して新しいidで作り直していました。お気に入りと選別の印はそこで道連れに
なっていました。監視から来たパスは、データベースに届く前に設定の綴りへ揃えます。
ふつうの ~/Pictures は元から影響を受けていません。
配布物について
| 用途 | ファイル |
|---|---|
| Windows 10/11・ふつうはこれ | pictkura_0.2.3_x64-setup.exe（管理者権限は不要） |
| Windows・PC全体に入れる（企業などの管理者向け） | pictkura_0.2.3_x64_ja-JP.msi / _en-US.msi |
| Windows・インストール不要 | pictkura_0.2.3_x64-portable.zip |
| macOS 11以降（Apple Silicon） | pictkura_0.2.3_arm64.zip |
どちらも署名していないので、初回に Windows は SmartScreen、macOS は Gatekeeper の
警告が出ます。進め方は
README に
書いてあります（macOS 15 で手順が変わった件も含みます）。
0.2.2 からの更新
Windows はインストーラをそのまま上書きで実行してください。macOS は ZIP を展開して、
置いてある pictkura.app を新しいものに置き換えてください——Gatekeeper の手順は
もう一度必要です（macOS から見ると、落としてきたのは別のファイルだからです）。
手順は README に
あります。
どちらの場合も、ライブラリ・設定・お気に入り・選別の印はそのまま残ります。
まだ出来ないこと
動画のサムネイルは、OSがコンテナを開ける範囲までです——Windows はシェルから、macOS は
AVFoundation から借りています。mp4 と mov は H.264 と HEVC（hvc1）の見本で出ること、
.avi は何も返らないことを実測しています。取り出すコマは常に先頭なので、黒からフェード
インする動画は黒いタイルになります。Linux は経路そのものが無く、配布物も出していません。
.m2ts と .avi は一覧には出ますが、アプリ内で再生できません。検索結果の並び替え
（撮影日の新しい順で固定）、検索索引の再構築UI、取り込みの中断はありません。全部は
README にまとめてあります。