Releases: Harusame64/pictkura
Release list
v0.2.5
pictkura 0.2.5 is a small follow-up to 0.2.4, about a RAW that keeps its picture past the
first 16 MiB of the file. The two Sigma bodies that do this stop showing an empty frame in
the grid, and stop sitting under the day you copied them.
What's new
A RAW that hides its picture past the first 16 MiB now shows one in the grid. The grid
asks for a picture with a 512-pixel long edge and stops as soon as it is holding one. The
viewer asks for 1600, and when the first 16 MiB of the file holds nothing that big it goes
on to read the whole file. Sigma's sd Quattro and sd Quattro H write no JPEG at all inside
that first window — their display picture sits at 44.00 MiB and 48.45 MiB — so the viewer
opened those photos while the grid came back with nothing.
That is only half of what went wrong. An X3F carries neither its capture time nor its
camera name in the container: both live inside that same picture. So the two files sat in
the grid as empty frames, under the day they were copied, and were missing from the camera
filter entirely.
| File | Before | Now |
|---|---|---|
sd Quattro .X3F |
empty frame, no date, no camera | 5424x3616, 2023-08-14, SIGMA sd Quattro |
sd Quattro H .X3F |
empty frame, no date, no camera | 6192x4128, 2018-04-09, SIGMA sd Quattro H |
The grid now reads the whole file as well — but only when nothing at all was found, not
when a smaller picture was. That distinction is the fix. The makers whose RAW yields only a
small picture, and only from a later step — Hasselblad 3fr and fff, Phase One iiq,
Minolta mrw, Kodak dcr, Leica dng, Epson erf, Leaf mos, Canon crw — are already
holding one by the time the question is asked, and are left alone. Measured on Windows over
exactly those eleven files, six runs each: 645–762 ms before, 631–768 ms after. Overlapping
ranges, which is what "left alone" looks like.
What the fix costs is a first pass that reads those files through. On the Windows machine,
108 files (68 RAW and 40 JPEG) went from 5509–6113 ms to 5853–6534 ms — about 6 % — and it
is paid once per file: a picture found leaves a thumbnail behind. The pinned 60-file
sample set comes out with no file changing at all, and on the Windows machine the viewer's
own path was unchanged across all 68 RAW it was run over. Reading a whole file also means
holding it, so no more than two of those reads run at a time; the peak memory of the whole
application over the same 108 files measured 463 MB before and 473 MB after.
The spec page already listed x3f as fully supported. For these two bodies that was not
true, and now it is.
A RAW with no picture anywhere is remembered as such. Until now, a RAW that carries no
display picture was searched again every time its tile came into view. With the search now
willing to read the whole file, that would have meant reading tens of megabytes, repeatedly,
to find the same nothing. So when the search has read a file through and found nothing, the
row is marked, and from then on the picture is not looked for again — while the capture date
and the camera name are still re-read, and still corrected, exactly as before.
The mark is only written when the file really was read through. A read that failed partway —
a file half-synced, a lock held by something else — does not earn it. Neither does a picture
that is there but could not be decoded: Canon's HDR PQ .CR3 writes its preview in HEVC, so
on a machine with no HEVC decoder those files stay unmarked and installing the Windows HEVC
extension later still brings their pictures in. Three files in the sample set are marked as
having no picture: the Blackmagic CinemaDNG, and the two old Panasonic .RAW.
Downloads
| You want | File |
|---|---|
| Windows 10/11, the usual case | pictkura_0.2.5_x64-setup.exe — no administrator rights |
| Windows, machine-wide install (for administrators) | pictkura_0.2.5_x64_ja-JP.msi / _en-US.msi |
| Windows, no installer | pictkura_0.2.5_x64-portable.zip |
| macOS 11+ (Apple Silicon) | pictkura_0.2.5_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.4
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.
Photos already in your library come right on the next startup, on their own. A photo
with no size recorded is asked again at every startup, and these two had none: the size, the
date and the camera all live in the picture that was never found. That pass now finds it and
writes all three, and builds the tile at the same time. This was run against a library of
30,178 files rather than reasoned about. Nothing else starts being re-read because of this
release: the rows asked again at startup are the same ones as before, and a photo that
already has its size is not among them.
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 and .avi measured returning nothing
there — on Windows the Shell does produce a thumbnail for .avi. 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. A RAW that declares nothing anywhere — the Blackmagic CinemaDNG in the sample set
is the one left — still shows no size.
New with this release: a RAW whose picture sits past the first 16 MiB, and whose bytes live
only in the cloud, is fetched in full when its tile is built. This was not measured —
every RAW measured for this release was a local file. The 16 MiB read that came before it
would very likely have fetched the whole file anyway, but that is reasoning, not a
measurement, and it is written here as such. The full list of gaps is in the README.
日本語
pictkura 0.2.5 は 0.2.4 の続きで、絵をファイルの先頭16MiBより後ろに置くRAWについての
小さな更新です。そうする Sigma の2機種が、一覧で枠だけになるのをやめ、コピーした日に
並ぶのもやめました。
新しくなったところ
先頭16MiBより後ろに絵を隠しているRAWでも、一覧に絵が出ます。 一覧は「長辺512の絵」を
探し、1枚掴んだ時点でやめます。ビューアは1600を求め、先頭16MiBにそれだけの絵が無ければ
ファイルを最後まで読みます。Sigma の sd Quattro と sd Quattro H は、その先頭の窓の中に
JPEGを1枚も置いていません——表示用の絵があるのは 44.00MiB と 48.45MiB の位置です。
だからビューアでは開けるのに、一覧は何も掴めないという形になっていました。
狂っていたのはそれだけではありません。 X3F は撮影日時もカメラ名もコンテナに持たず、
どちらもその絵の中にあります。ですから2枚は、一覧では枠だけで、コピーした日に並び、
カメラの絞り込みからも消えていました。
| ファイル | これまで | いま |
|---|---|---|
sd Quattro .X3F |
枠だけ・日付なし・カメラなし | 5424x3616・2023-08-14・SIGMA sd Quattro |
sd Quattro H .X3F |
枠だけ・日付なし・カメラなし | 6192x4128・2018-04-09・SIGMA sd Quattro H |
一覧もファイルを最後まで読むようになりました——ただし 1枚も掴めなかったときだけで、
「小さい絵しか無い」ときではありません。この線引きが直しの本体です。 小さい絵しか持たず、
しかも後の段でしかそれが出ない社——Hasselblad の 3fr・fff、Phase One の iiq、
Minolta mrw、Kodak dcr、Leica dng、Epson erf、Leaf mos、Canon crw——は、
その時点で既に1枚持っているので、今までどおり素通りします。Windows の実機でこの11件
だけを各6回測って、前 645〜762ms／後 631〜768ms。範囲が重なっているのが「素通り」の姿です。
代わりに払うのは、そのファイルを最後まで読む最初の1回です。Windows の実機で108件
（RAW 68件＋JPEG 40枚）を通して 5509〜6113ms → 5853〜6534ms（約6%）。1ファイルに
つき一度きりで、絵が出ればサムネイルが残ります。固定の60ファイルの見本では変わった
ファイルは1件もなく、Windows の実機で流したビューア側の道も、68件すべてで結果が
同じでした。丸ごと読むことは
丸ごと抱えることでもあるので、同時に走らせるのは2本までにしてあります——同じ108件で
アプリ全体の最大使用量を測って、前 463MB／後 473MB でした。
仕様の頁は以前から x3f を「対応」と書いていました。この2機種についてはそれが嘘で、
いま本当になりました。
どこにも絵を持たないRAWを、そう覚えるようになりました。 これまでは、表示用の絵を
持たないRAWでも、タイルが見えるたびに探し直していました。最後まで読むようになった以上、
それは「同じ無いものを見つけるために、毎回数十MBを読む」ことを意味します。そこで、
最後まで読んで1枚も無かったときはその行に印を付け、以後は絵を探しません——
撮影日時とカメラ名は、これまでどおり読み直して直します。
印を付けるのは、本当に最後まで読めたときだけです。途中で読めなくなったとき——同期の
途中、他のものがロックを握っているとき——には付けません。絵はあるのに起こせなかった
ときも付けません: Canon の HDR PQ の .CR3 はプレビューを HEVC で書くので、デコーダの
無い機械ではそのまま印を付けずに残り、あとから Windows の HEVC 拡張機能を入れれば
絵が出ます。見本の中で印が付くのは、Blackmagic の CinemaDNG と、古い Panasonic の
.RAW 2枚の計3件です。
配布物について
| 用途 | ファイル |
|---|---|
| Windows 10/11・ふつうはこれ | pictkura_0.2.5_x64-setup.exe（管理者権限は不要） |
| Windows・PC全体に入れる（企業などの管理者向け） | pictkura_0.2.5_x64_ja-JP.msi / _en-US.msi |
| Windows・インストール不要 | pictkura_0.2.5_x64-portable.zip |
| macOS 11以降（Apple Silicon） | pictkura_0.2.5_arm64.zip |
どちらも署名していないので、初回に Windows は SmartScreen、macOS は Gatekeeper の警告が
出ます。進め方は
README に書いてあります
（macOS 15 で手順が変わった件も含みます）。
0.2.4 からの更新
Windows はインストーラをそのまま上書きで実行してください。macOS は ZIP を展開して、
置いてある pictkura.app を新しいものに置き換えてください——Gatekeeper の手順は
もう一度必要です（macOS から見ると、落としてきたのは別のファイルだからです）。手順は
README にあります。
どちらの場合も、ライブラリ・設定・お気に入り・選別の印はそのまま残ります。
すでにライブラリに入っている写真は、次の起動で自分から直ります。 寸法が記録されて
いない写真は起動のたびにもう一度調べ直されます。この2枚はまさにそれで、寸法も撮影日時も
カメラ名も、見つからなかったあの絵の中にありました。その回にいまは絵が見つかるので、
3つとも書き込まれ、タイルも同時にできます。これは理屈ではなく、30,178件のライブラリで
実際に確かめました。このリリースのせいで読み直しが増えることはありません——起動時に
聞き直される行はこれまでと同じ顔ぶれで、寸法が既に入っている写真はそこに入りません。
まだ出来ないこと
動画のサムネイルは、OSがコンテナを開ける範囲までです——Windows はシェルから、macOS は
AVFoundation から借りています。mp4 と mov は H.264 と HEVC（hvc1）の見本で出ること、
.avi は macOS では何も返らないことを実測しています——Windows のシェルは .avi の
サムネイルを返します。取り出すコマは常に先頭なので、黒からフェードインする動画は黒い
タイルになります。Linux は経路そのものが無く、配布物も出していません。.m2ts と .avi は
一覧には出ますが、アプリ内で再生できません。検索結果の並び...
v0.2.4
pictkura 0.2.4 is a small follow-up to 0.2.3, about the RAW files that carry no picture
inside them: they stop sitting in the grid under the day you copied them, and the ones
that do write their size — somewhere pictkura was not looking — finally get one.
What's new
A RAW that declares no size keeps its date and camera. 0.2.3 fixed half of this — a
failure to extract the preview was throwing away metadata that had already been read
successfully. The other half was the file that also declares no pixel dimensions: the
record path gave up on everything, including the capture date and the camera name it was
already holding. The pair of old Panasonic .RAW files in the sample set (DMC-LX1,
DMC-FZ8) has no preview, declares no PixelXDimension, and does carry a maker, a model
and a capture time; both sat in the grid under the day they were copied and had dropped
out of the camera filter. They now read 2018-06-19 and 2018-01-26, and both cameras
register. The import itself was never confused: it reads the date straight from the file
when it picks a destination folder. What was wrong is the date pictkura kept afterwards.
Those two do not even give up their size any more — the third item below finds it
elsewhere in the file. What is left for this branch is the RAW that declares its size
nowhere at all, and there the size, and only the size, is given up: writing a zero would
erase what the operating system had lent us.
A date already read is no longer replaced by a worse guess. A file that ends up with
no size at all is asked again on every startup — which, until this release, included the
two Panasonic RAWs above. If the first pass got a real capture date and a later pass read
nothing — EXIF empty, the Windows Shell quiet partway through a sync — the fallback to the
file's modification time overwrote the good date and moved the photo back under the day it
was copied. The guess taken from the file name could do the same.
The order is now: EXIF, then the OS properties, then the date already recorded for that
file, then the file name, then the modification time. The recorded date is consulted only
when it is not itself the modification time, so a photo still sitting on that fallback can
still be corrected by its name, as before. This chain belongs to the path taken when no
picture could be made, whether or not the file declares a size. A photo whose thumbnail
was made goes through a different chain, and so do videos; this release touches neither,
so one of those, processed again later — the thumbnail cache evicting its tile and
rebuilding it is the way that happens — can still have a good date replaced this way. A
rescan cannot: it clears the recorded date along with the size and reads the file afresh. After this release the files that
keep coming back are the RAW that declares its size nowhere, and videos with no
dimensions.
Panasonic and Leica RAW record the size of the original. Panasonic does declare the
size — just not in the tag we were reading. It writes the sensor borders into its own
tags, and the picture is what lies inside them. Those tags are in the EXIF pictkura
already parses, so nothing extra is read from disk.
Measured on the pinned 60-file sample set:
| File | Before | Now |
|---|---|---|
DMC-LX1 .raw |
no size, no date | 3840x2160, 2018-06-19 |
DMC-FZ8 .raw |
no size, no date | 3072x2304, 2018-01-26 |
Leica D-LUX 5 .rwl |
1920x1440 | 3648x2736 |
The D-LUX 5 line is the one worth reading twice: 1920x1440 was the size of the embedded
preview, standing in for the original because nothing declared one. The DC-GH7 and
DC-S5M2 come out unchanged, and that is what the borders were checked against — both of
those carry a full-size preview, and the size derived from their borders matches it
exactly, pixel for pixel.
The borders are consulted only for rw2, raw and rwl, only when nothing declares a
size, and only when all six tags agree on a positive area inside the sensor. What they
give is then held to the same guard as any other declared size wherever a preview was
extracted: on that path anything smaller than the preview is not believed, which is what
leaves the DMC-LX7 alone. Where no preview could be extracted there is nothing to compare
against, and the borders are taken as they are. They are read on the path that patches
Panasonic's non-standard TIFF header, which is how every Panasonic RAW in the sample set
is read. The DMC-LX7 .rw2 in the sample set is the one that
guard rejects — borders of 1824x1368 against a 1920x1440 preview — so its size is
unchanged. That sample is a small-format file to begin with: its own tags put the whole
sensor at 1904x1384, so the borders are right for it and the preview is simply the larger
of the two. Leica's Digilux and D-LUX are Panasonic-built and write the same structure
under their own name, so none of this is decided by the maker's name.
Downloads
| You want | File |
|---|---|
| Windows 10/11, the usual case | pictkura_0.2.4_x64-setup.exe — no administrator rights |
| Windows, machine-wide install (for administrators) | pictkura_0.2.4_x64_ja-JP.msi / _en-US.msi |
| Windows, no installer | pictkura_0.2.4_x64-portable.zip |
| macOS 11+ (Apple Silicon) | pictkura_0.2.4_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.3
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.
Photos already in your library come right on their own, at two different speeds.
A photo with no size at all — the two Panasonic .RAW files above — is asked again on
the next startup, and that pass now writes the size, the date and the camera together.
Those have no picture pictkura can make, so there is no thumbnail of theirs to rebuild;
the startup pass is the only route they have, and it is enough.
A photo that already carries a size taken from its preview — the Leica .rwl — is a
different case, because nothing is looking for it: the pass that fills in sizes after the
fact takes only rows with no preview size recorded, which any photo imported by 0.2.2 or
later already has. Its corrected size is written the next time that photo is processed at
all: a fresh import, a rescan after the file itself changed, or the thumbnail cache
evicting its tile and rebuilding it. On a library older than 0.2.2 the after-the-fact pass
does have it, and corrects it there.
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 and .avi measured returning nothing
there — on Windows the Shell does produce a thumbnail for .avi. 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. A RAW that declares nothing anywhere — the
Blackmagic CinemaDNG in the sample set is the one left — still shows no size. The full
list is in the README.
日本語
pictkura 0.2.4 は 0.2.3 の続きで、中に絵を持たない RAW についての小さな更新です。
一覧でコピーした日に並んでしまうのをやめ、寸法を書いてはいたもの
——こちらが見ていない場所に書いていただけのもの——に寸法が入るようになりました。
新しくなったところ
寸法を申告しない RAW でも、撮影日時とカメラ名は残ります。 0.2.3 で直したのは
半分でした——プレビューの取り出しに失敗すると、すでに読めていたメタデータまで
捨てていた件です。残る半分は、寸法の申告も無いファイルでした。この場合は
記録の道が丸ごと諦めていたので、手元に持っていた撮影日時とカメラ名まで一緒に
落ちていました。見本にある古い Panasonic の .RAW 2枚（DMC-LX1・DMC-FZ8）が
まさにこれで、プレビューが無く PixelXDimension も書いていない代わりに、
メーカー名・機種名・撮影日時は持っています。2枚とも一覧ではコピーした日に並び、
カメラの絞り込みからも消えていました。取り込み自体は間違えていません
——行き先のフォルダを決めるときはファイルから直に日付を読みます。
狂っていたのは pictkura が控えたほうの日付です。いまは 2018-06-19 と 2018-01-26 と読め、
カメラも登録されます。
この2枚は、もう寸法すら諦めません——下の3つめが、同じファイルの別の場所から
見つけるからです。この枝に残るのは「どこにも寸法を申告していない RAW」で、そこでは
寸法だけを諦めます。ここに 0 を書くと、OSが貸してくれていた値を
消してしまうためです。
一度読めた撮影日時が、あとの当てずっぽうに上書きされなくなりました。
寸法がまったく入らないファイルは、起動のたびにもう一度調べ直されます
——このリリースまでは、上の Panasonic の2枚もそこに入っていました。1回目に本当の
撮影日時が読めていても、2回目にたまたま何も読めなければ——EXIF が空、同期の途中で
Windows のシェルが黙る——ファイルの更新日時への切り替えが働いて、正しい日付を
取り込んだ日に書き換えていました。ファイル名からの推測も同じことができました。
順番はこうなりました: EXIF → OSのプロパティ → そのファイルについて既に記録して
ある日付 → ファイル名 → ファイルの更新日時。記録してある日付を見るのは、それが
更新日時そのものでないときだけです——更新日時のまま止まっている写真は、
これまでどおりファイル名で直せます。この連鎖は絵を作れなかったときに通る道のもので、
寸法を申告するかどうかは問いません。サムネイルが作れたファイルは別の連鎖を通り、
動画もまた別です。どちらもこのリリースでは触っていませんので、あとから
作り直される写真——サムネイルの置き場から追い出されて作り直されたとき——は、
いまも同じ形で日付を書き換えられることがあります。再スキャンでは起きません
——あちらは記録してある日付も寸法もいったん消して、ファイルを読み直すからです。
このリリースのあとで何度も戻ってくるのは、どこにも寸法を申告していないRAWと、
寸法の出ない動画です。
Panasonic と Leica の RAW が、原本の寸法を記録します。 Panasonic は寸法を
申告していました——こちらが読んでいたタグと違う場所に、です。センサーの縁を自社の
タグに書いていて、絵になるのはその内側です。このタグは pictkura が既に読んでいる
EXIF の中にあるので、ファイルを読み直しません。
固定の60ファイルの見本で測りました:
| ファイル | これまで | いま |
|---|---|---|
DMC-LX1 .raw |
寸法なし・日付なし | 3840x2160・2018-06-19 |
DMC-FZ8 .raw |
寸法なし・日付なし | 3072x2304・2018-01-26 |
Leica D-LUX 5 .rwl |
1920x1440 | 3648x2736 |
D-LUX 5 の行が要点です。1920x1440 は埋め込みプレビューの寸法で、申告が無いために
原本の寸法の代わりに入っていたものでした。DC-GH7 と DC-S5M2 は変わりません——
そして、縁の読み方を確かめたのがこの2台です。どちらも原寸のプレビューを持っていて、
縁から出した寸法が1画素も違わずに一致しました。
縁を見るのは rw2・raw・rwl のときだけ、しかも寸法の申告がどこにも無く、6つの
タグが揃ってセンサーの内側で正の面積になるときだけです。そのうえで、プレビューを取り出せた道では
他の申告と同じ関門を通ります——プレビューより小...
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](https://githu...
v0.2.2
pictkura 0.2.2 is a small release about RAW files: Canon's HDR PQ shots get a thumbnail at
last, and a RAW that declares the sensor's own size now has it recorded.
What's new
Thumbnails for Canon's HDR PQ RAW files. A CR3 shot in HDR PQ carries its preview as
HEVC rather than JPEG — 10-bit PQ will not fit in a JPEG — and there is no usable JPEG
anywhere else in the file. Those files used to sit in the grid as an empty frame. pictkura
now lifts the HEVC preview out of the file, wraps it as a minimal HEIF, and hands it to the
same decoder it already uses for HEIC, so the picture appears.
Getting one of these out of the file costs about a quarter to four tenths of a second on
this machine, slower on some, where the same job on the other RAW files at hand took 2.6 to
104 milliseconds. So it only happens when nothing found earlier in the file is big enough
for the size being asked for. Ordinary CR3 files are untouched and just as fast as before.
The viewer goes down the same road, so these files open as well, not just show a tile.
This one is Windows only for now, and it needs the same OS components as HEIC: "HEIF Image
Extensions" (free) for the container and "HEVC Video Extensions" (paid) for the pixels.
Without them the file keeps its empty frame, and nothing points you at the cause — the
notice inside the app that offers to install them counts HEIC photos, not RAW. On macOS these
files still show an empty frame too, because the HEIF decoder there is not wired up yet.
A RAW that declares the sensor's size gets it recorded. width/height for a RAW used
to hold the size of the embedded preview — 1620x1080 for an HDR PQ CR3 — while the sensor's
own 6000x4000 went unrecorded. Both are kept now, read from what the file itself declares.
Where that is written differs by maker, and plenty of them do not put it within reach.
Canon writes it in the CR3's CMT1 box and in the CR2's Exif IFD; Sony, Samsung, Phase One
and Apple write it in the Exif IFD as well. Nikon, Fujifilm, Panasonic, Olympus, Sigma,
Leica and others keep it inside a SubIFD this reader does not open, so those files carry the
preview's size as before. Of 24 sample files from raw.pixls.us, 8 declared a size
and 5 of those differed from the preview. For those, the grid draws the tile at the sensor's
aspect ratio, which is close to the preview's but not always equal.
Existing libraries correct themselves once, quietly in the background, on the first launch
after the update. Nothing needs to be rescanned and no thumbnail is rebuilt — this pass
never decodes a picture. It does read the file, though: for CR2, NEF, ARW, DNG and other
TIFF-shaped RAW the reader takes in the whole file to find the declaration, so a library
with many RAW files will have the disk busy for a while that first time. It happens once,
and files on a drive that is not connected, or that live only in the cloud, are left alone
until the day they can be read.
Downloads
| You want | File |
|---|---|
| Windows 10/11, the usual case | pictkura_0.2.2_x64-setup.exe — no administrator rights |
| Windows, machine-wide install (for administrators) | pictkura_0.2.2_x64_ja-JP.msi / _en-US.msi |
| Windows, no installer | pictkura_0.2.2_x64-portable.zip |
| macOS 11+ (Apple Silicon) | pictkura_0.2.2_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.1
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
The HDR PQ preview above is decoded by the operating system, so it needs Windows and the
two extensions named above. Video thumbnails are Windows-only for the same reason. .m2ts
and .avi appear in the grid but do not play in the app. There is 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.2 は小さな更新で、中身はRAWの話が2つです。Canon の HDR PQ で撮った RAW に
サムネイルが出るようになり、原本（センサー）の寸法を申告している RAW は、その寸法も
控えるようになりました。
新しくなったところ
Canon の HDR PQ で撮った RAW にサムネイルが出ます。 HDR PQ で撮った CR3 は、
プレビューを JPEG ではなく HEVC で書きます——10ビットの PQ は JPEG では表せません——
そして、そのファイルには使える JPEG が1枚も入っていません。これまでは一覧に枠だけが
並んでいました。pictkura はこの HEVC のプレビューをファイルから取り出し、最小の HEIF に
包み直して、HEIC で既に使っているデコーダに渡すようにしました。絵が出ます。
取り出しは1枚あたり0.25〜0.4秒ほどかかります（この機械での値で、機械によっては
もう少しかかります。同じ取り出しを手元の他のRAWでやると 2.6〜104ミリ秒でした）。
そのため、それまでに見つかった絵が、求められた大きさに届かなかったときだけ
この道を通ります。ふつうの CR3 はこれまでどおりの速さです。
ビューアも同じ道を通るので、一覧に出るだけでなく開いても絵が出ます。
いまのところ Windows のみで、HEIC と同じOSの部品が要ります——コンテナのための
「HEIF Image Extensions」（無料）と、画素の展開に「HEVC Video Extensions」（有料・
数百円）です。入っていなければ枠だけのままで、しかも理由を指してくれるものが
ありません——アプリの中で導入を勧める帯が数えているのは HEIC の写真で、RAW は
数に入らないからです。macOS では HEIF のデコーダをまだ繋いでいないので、こちらも
枠だけになります。
原寸を申告している RAW は、その寸法も控えます。 これまで RAW の width/height
に入っていたのは埋め込みプレビューの寸法で（HDR PQ の CR3 なら 1620x1080）、
センサーの 6000x4000 はどこにも残っていませんでした。いまは両方を持ちます。値は
ファイル自身の申告から読みます。
どこに書いてあるかは社ごとに違い、手の届かない所に置く社も多くあります。
Canon は CR3 なら CMT1 の箱、CR2 なら Exif IFD に書きます。Sony・Samsung・
Phase One・Apple も Exif IFD です。Nikon・Fujifilm・Panasonic・Olympus・Sigma・
Leica などは SubIFD の中に置いており、いまの読み手では届かないので、これまでどおり
プレビューの寸法のままです。raw.pixls.us のサンプル24件では、
申告を持つのが8件、そのうち実際にプレビューと違ったのが5件でした。その5件では、
一覧の枠が原本の縦横比で描かれます——プレビューとほぼ同じですが、常に同じとは限りません。
すでにあるライブラリは、更新後の初回起動で一度だけ、背景で静かに直ります。取り込み直しは
要りませんし、サムネイルも作り直しません（絵は1枚も起こしません）。ただしファイルは
読みます——CR2・NEF・ARW・DNG のようなTIFFの形をしたRAWでは、申告を探すのに
1枚まるごと読むので、RAWの多いライブラリでは初回だけディスクがしばらく動きます。
走るのは一度きりです。繋いでいないドライブの中や、クラウドにしか実体が無いファイルは、
読める日が来るまで触りません。
配布物について
| 用途 | ファイル |
|---|---|
| Windows 10/11・ふつうはこれ | pictkura_0.2.2_x64-setup.exe（管理者権限は不要） |
| Windows・PC全体に入れる（企業などの管理者向け） | pictkura_0.2.2_x64_ja-JP.msi / _en-US.msi |
| Windows・インストール不要 | pictkura_0.2.2_x64-portable.zip |
| macOS 11以降（Apple Silicon） | pictkura_0.2.2_arm64.zip |
どちらも署名していないので、初回に Windows は SmartScreen、macOS は Gatekeeper の
警告が出ます。進め方は
README に
書いてあります（macOS 15 で手順が変わった件も含みます）。
0.2.1 からの更新
Windows はインストーラをそのまま上書きで実行してください。macOS は ZIP を展開して、
置いてある pictkura.app を新しいものに置き換えてください——Gatekeeper の手順は
もう一度必要です（macOS から見ると、落としてきたのは別のファイルだからです）。
手順は README に
あります。
どちらの場合も、ライブラリ・設定・お気に入り・選別の印はそのまま残ります。
まだ出来ないこと
上の HDR PQ のプレビューはOSのデコーダで開くので、Windows と、上に書いた2つの
拡張機能が要ります。動画のサムネイルも同じ理由で Windows のみです。.m2ts と
.avi は一覧には出ますが、アプリ内で再生できません。検索結果の並び替え（撮影日の
新しい順で固定）、検索索引の再構築UI、取り込みの中断はありません。全部はREADMEに
まとめてあります。
v0.2.1
pictkura 0.2.1 is a small release: a filter for the kind of file you are looking at, two
fixes in the viewer, and a change to where the update notice takes you.
What's new
Filter by kind. The left pane has a new "Kind" section — Photos, RAW, Videos. Press one
to narrow the timeline, press it again to clear it. It is a separate axis from ★ and ⚑, so
the two stack: with ★ and Videos both on you get the videos you starred. The camera list and
the search box stack the same way, so "the RAW files from the EOS R8" is two clicks. You can
also type kind:raw (or type:video, 種類:動画) in the search box.
The filter reads the extension, so it costs nothing to apply: the kind is stored next to each
file when it is indexed. Existing libraries fill this in once, on the first launch after the
update, and nothing needs to be rescanned.
Fixes
The video controls can be reached again. The filmstrip along the bottom of the viewer sat
on top of the player's own control bar, so the volume slider and the position bar were covered
and could not be clicked. While a video is showing, the filmstrip now folds away. Which file
you are on stays in the caption, and ← → still step to the next one.
Full screen no longer sticks. Going full screen in the viewer and then clicking outside the
photo closed the viewer but left the window with no frame — and no way back, because the only
two ways out (the toolbar button and F11) belong to the viewer. Closing the viewer now leaves
full screen as well.
The update notice opens the download page. It used to open the list of releases on GitHub,
which shows all five files and leaves you to pick. It now opens the download page on the site,
which offers the one file for the machine you are reading it on.
Downloads
| You want | File |
|---|---|
| Windows 10/11, the usual case | pictkura_0.2.1_x64-setup.exe — no administrator rights |
| Windows, machine-wide install (for administrators) | pictkura_0.2.1_x64_ja-JP.msi / _en-US.msi |
| Windows, no installer | pictkura_0.2.1_x64-portable.zip |
| macOS 11+ (Apple Silicon) | pictkura_0.2.1_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.0
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 are Windows-only. .m2ts and .avi appear in the grid but do not play
in the app. There is 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.1 は小さな更新です。ファイルの種類での絞り込みを足し、ビューアの不具合を
2つ直して、新しいバージョンのお知らせが開く先を変えました。
新しくなったところ
種類で絞り込めます。 画面左に「種類」の節が増えました——画像・RAW・動画。押すと
その種類だけになり、もう一度押すと戻ります。★ や ⚑ とは別の軸なので重ねて効きます。
★と動画を両方押せば「お気に入りに入れた動画」です。カメラの一覧や検索語とも重なるので、
「EOS R8 で撮った RAW」はクリック2回で出ます。検索ボックスに kind:raw
（type:video や 種類:動画 でも可）と打っても同じです。
判定に使うのは拡張子だけなので、絞り込みに時間はかかりません。種類はファイルを
索引に載せるときに一緒に控えます。すでにあるライブラリは、更新後の初回起動で一度だけ
埋まります。取り込み直しは要りません。
直したところ
動画の操作バーに手が届くようになりました。 ビューアの下に並ぶフィルムストリップが
プレイヤーの操作バーに重なっていて、音量つまみと再生位置が隠れて押せませんでした。
動画を見ているあいだは、この帯を畳むようにしました。何枚目かは字幕に出たままで、
← → での送りもそのままです。
全画面から出られなくなることがなくなりました。 ビューアで全画面にしたあと、
写真の外をクリックするとビューアは閉じますが、枠の無い窓だけが残っていました。
全画面の切り替えはビューアの道具バーと F11 にしかないので、そこから出る手が
無くなります。ビューアを閉じたときに全画面も解くようにしました。
新しいバージョンのお知らせが、ダウンロードの頁を開きます。 これまでは GitHub の
リリース一覧を開いていて、5つ並んだファイルから選ぶ必要がありました。いまは紹介サイトの
ダウンロードの頁を開き、見ている機械に合う1つを出します。
配布物について
| 用途 | ファイル |
|---|---|
| Windows 10/11・ふつうはこれ | pictkura_0.2.1_x64-setup.exe（管理者権限は不要） |
| Windows・PC全体に入れる（企業などの管理者向け） | pictkura_0.2.1_x64_ja-JP.msi / _en-US.msi |
| Windows・インストール不要 | pictkura_0.2.1_x64-portable.zip |
| macOS 11以降（Apple Silicon） | pictkura_0.2.1_arm64.zip |
どちらも署名していないので、初回に Windows は SmartScreen、macOS は Gatekeeper の
警告が出ます。進め方は
README に
書いてあります（macOS 15 で手順が変わった件も含みます）。
0.2.0 からの更新
Windows はインストーラをそのまま上書きで実行してください。macOS は ZIP を展開して、
置いてある pictkura.app を新しいものに置き換えてください——Gatekeeper の手順は
もう一度必要です（macOS から見ると、落としてきたのは別のファイルだからです）。
手順は README に
あります。
どちらの場合も、ライブラリ・設定・お気に入り・選別の印はそのまま残ります。
まだ出来ないこと
動画のサムネイルはWindowsのみです。.m2ts と .avi は一覧には出ますが、アプリ内で
再生できません。検索結果の並び替え（撮影日の新しい順で固定）、検索索引の再構築UI、
取り込みの中断はありません。全部はREADMEにまとめてあります。
v0.2.0
pictkura 0.2.0 is the culling release: you can now go through a burst in the viewer,
flag the frames you keep, reject the rest, and send them to the recycle bin in one pass.
The next and previous frames are decoded in the background, so stepping through a burst
rarely waits for an image to appear.
What's new
Culling. In the viewer, P picks a frame (⚑) and X rejects it (✕). Nothing is
deleted when you press X — closing the viewer lays the rejects out first, so you
confirm before anything moves, and deleting still goes through the recycle bin. ⚑ is a
separate shelf from ★ favourites, so culling never fills up the photos you wanted to keep
coming back to. By default a judgement moves you to the next photo; you can turn that off.
A viewer that keeps up with the keyboard. The next and previous full-size images are
fetched and decoded in the background before you get to them, so ← → swaps a frame
that is already there (the preloader leaves videos and cloud-only files alone, and there
is a ceiling on how many decoded pixels it will hold). Formats that have to be re-wrapped
before a browser can draw them (RAW, HEIC, TIFF) show the thumbnail underneath while the
full image is prepared, so you see the photo rather than a blank. Double-click (or 1)
toggles 100%, 0 fits to the window.
RAW from 16 makers, checked against real files. pictkura does not develop RAW; it
pulls out the display JPEG the camera embedded, along with the orientation and the
capture time. Checked on 28 real files from 16 makers: the image comes out, portrait
shots come out upright, the shot date and camera name are read, and older bodies that
only carry a small preview are documented in the README rather than failing silently.
Files that travel with your photos. A .xmp written by a raw developer — develop
settings, ratings, keywords — now follows the photo when you import it, copy or move it
to a folder, or send it to the recycle bin. .aae .dop .pp3 .on1 too, and the
list is yours to change in pictkura.toml. If you shoot RAW+JPEG, the pair lands in the
same date folder even when only one of the two carries a capture time.
Copy or move a selection to a folder. Select photos in the grid and put them straight
into a folder you pick — handy for handing a few photos to someone or filling a USB stick.
Writing the same photos to the same folder again adds nothing.
HEIC opens faster. A browser cannot draw an iPhone HEIC, so pictkura re-wraps it as
JPEG before showing it. That step now goes through mozjpeg: preparing a 24.5 MP HEIC for
display dropped from about 1.0 s to about 0.6 s (measured, same machine).
An installer that does not ask for administrator rights.
pictkura_0.2.0_x64-setup.exe installs for your user only. The MSI is still there for
installing across a whole machine.
Update notices. A few seconds after start, pictkura asks once a day whether a newer
version exists and shows a quiet line if there is one. The app never replaces itself,
and this is the only outbound connection it makes — the request carries the version and
nothing else. Turn it off in ⚙ → About.
One broken file no longer takes the app with it. A corrupt or truncated file is
skipped: the parsing and thumbnail paths no longer panic on their own, and a decoder that
panics on malformed bytes is caught rather than allowed to bring the process down.
Downloads
| You want | File |
|---|---|
| Windows 10/11, the usual case | pictkura_0.2.0_x64-setup.exe — no administrator rights |
| Windows, machine-wide install (for administrators) | pictkura_0.2.0_x64_ja-JP.msi / _en-US.msi |
| Windows, no installer | pictkura_0.2.0_x64-portable.zip |
| macOS 11+ (Apple Silicon) | pictkura_0.2.0_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.1.x
Use -setup.exe. If an MSI install is already there, the installer removes it first and
asks for administrator approval that one time. On a PC shared with other people, read the
note in the README before switching.
Known gaps
Video thumbnails are Windows-only. .m2ts and .avi appear in the grid but do not play
in the app. There is 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.0 は選別のリリースです。連写をビューアで送りながら残す1枚に印を
付け、ボツを外し、最後にまとめてゴミ箱へ。前後の絵は裏で用意しておくので、送って
いる間に絵を待つ場面はほとんどありません。
新しくなったところ
選別。 ビューアで P を押すと残す1枚に印（⚑）が付き、X でボツの候補（✕）に
なります。X を押した時点では何も消えません。ビューアを閉じるときにボツの候補を
並べて見せるので、そこで確かめてから動かせます。削除は変わらずゴミ箱経由です。
⚑ は ★ お気に入りとは別の棚なので、選別のたびにお気に入りが埋まることはありません。
既定では判定と同時に次の写真へ進みます（設定で切れます）。
キーボードに遅れないビューア。 前後の原寸を先に取ってきて、裏で展開しておきます。
← → は用意できている絵に切り替えるだけなので、待ちがほぼ出ません（先読みは
動画とクラウドのみのファイルには走らず、抱える画素の量にも上限があります）。
そのまま描けない形式（RAW・HEIC・TIFF）は詰め直しが要るぶん、出来上がるまで
サムネイルを下に敷くので、真っ白ではなく写真が見えます。ダブルクリック
（または 1）で等倍100%、0 で画面に合わせる表示に戻ります。
16メーカーのRAWを、実ファイルで確認。 pictkura は RAW を現像せず、カメラが
埋め込んだ表示用JPEGを取り出します。16メーカー28枚の実ファイルで、絵が出ること・
縦位置が縦で出ること・撮影日時とカメラ名が読めることを確かめました。小さい
プレビューしか持たない古い機種も、黙って失敗せずREADMEに明記してあります。
写真に付いているファイルも一緒に運びます。 現像ソフトが書いた .xmp（現像設定・
評価・キーワード）は、取り込み・フォルダへのコピーや移動・ゴミ箱送りのいずれでも
写真に付いていきます。.aae .dop .pp3 .on1 も同じで、対象は pictkura.toml
で変えられます。RAWとJPEGを同時に撮っている場合、片方だけ撮影日時を持たないときも
2つは同じ日のフォルダへ入ります。
選んだものをフォルダへコピー・移動。 一覧で選んで、指定したフォルダへそのまま
置けます。何枚か人に渡す、USBメモリへ入れる、といった用途向けです。同じフォルダへ
何度書き出しても増えません。
HEICが速くなりました。 iPhoneのHEICはブラウザが直接描けないので、表示の前に
JPEGへ詰め直しています。その処理を mozjpeg に替え、24.5MPのHEICを表示できる形に
するまでが約1.0秒から約0.6秒になりました（同じ機械での実測）。
管理者権限の要らないインストーラ。 pictkura_0.2.0_x64-setup.exe は自分の
ユーザーにだけ入ります。PC全体に入れるMSIも従来どおりあります。
新しいバージョンのお知らせ。 起動して数秒たつと、新しいバージョンが出ていないかを
1日1回だけ確認し、出ていれば画面の下に控えめな行を出します。アプリが勝手に入れ替わることは
ありません。 これがこのアプリの唯一の外向き通信で、送るのはバージョンだけです。
⚙ →「このアプリについて」で切れます。
壊れた写真1枚がアプリを道連れにしません。 壊れたファイルや途中で切れたファイルは
飛ばします。自前の解析とサムネイル生成からはパニックを無くし、規格外のバイト列で
パニックするデコーダは受け止めて、そこだけを失敗にします。
配布物について
| 用途 | ファイル |
|---|---|
| Windows 10/11・ふつうはこれ | pictkura_0.2.0_x64-setup.exe（管理者権限は不要） |
| Windows・PC全体に入れる（企業などの管理者向け） | pictkura_0.2.0_x64_ja-JP.msi / _en-US.msi |
| Windows・インストール不要 | pictkura_0.2.0_x64-portable.zip |
| macOS 11以降（Apple Silicon） | pictkura_0.2.0_arm64.zip |
どちらも署名していないので、初回に Windows は SmartScreen、macOS は Gatekeeper の
警告が出ます。進め方は
README に
書いてあります（macOS 15 で手順が変わった件も含みます）。
0.1.x からの更新
-setup.exe を使ってください。MSI版が入っている場合は、インストーラが先にMSIを
消してから入れます（そのときだけ管理者の許可を聞かれます）。1台を複数人で使って
いる場合は、乗り換える前にREADMEの注意を読んでください。
まだ出来ないこと
動画のサムネイルはWindowsのみです。.m2ts と .avi は一覧には出ますが、アプリ内で
再生できません。検索結果の並び替え（撮影日の新しい順で固定）、検索索引の再構築UI、
取り込みの中断はありません。全部はREADMEにまとめてあります。
v0.1.1
What's Changed
- macOSの初回起動の案内を実測どおりに直す in #7
- フォルダ追加に「参照…」ボタンを足す in #9
- USB/SDカード挿入時の自動起動（AutoPlay）に対応する in #10
- Windowsの署名なしで出る警告をREADMEに書く in #8
- 引き継ぎ資料を2026-08-16の内容に更新する in #11
- 開発日誌を非公開リポへ移す in #12
- AutoPlayの登録をアンインストールで消し、配布物の置き場を作り直す in #13
- AutoPlayの解除もれとイベント名を直し、取扱説明書に「挿しても何も聞かれないとき」を足す in #14
- 設定に言語のプルダウンを入れる in #15
- 取り込み先のプリセットを2つ足し、year: で年を絞れるようにする in #16
- 英語の取扱説明書を同梱し、READMEを英語画面に揃える in #17
- 一覧に複数選択と一括操作を入れる（お気に入り・削除） in #18
Full Changelog: v0.1.0...v0.1.1
v0.1.0
写真の取り込みと一覧表示に特化した、シンプルな画像管理デスクトップアプリの最初の配布です。
数万枚あっても待たされないことを目標にしています。
入手
| 対象 | ファイル | 備考 |
|---|---|---|
| Windows 10/11（x64） | pictkura_0.1.0_x64_ja-JP.msi |
日本語版インストーラ。PC全体へ入れるため管理者権限を求められます |
| Windows（英語UI） | pictkura_0.1.0_x64_en-US.msi |
英語版インストーラ |
| Windows・インストール不要 | pictkura_0.1.0_x64-portable.zip |
展開して pictkura.exe を実行するだけ。管理者になれない場合はこちら |
| macOS 11以降（Apple Silicon） | pictkura_0.1.0_arm64.zip |
展開して pictkura.app を好きな場所へ。初回だけ下の手順が要ります |
Windows では別途 WebView2 ランタイムが要ります（Windows 11 と、更新済みの Windows 10 には最初から入っています）。
macOS は初回だけ開き方に手順が要ります
Appleの開発者署名を受けていないため、初回はダブルクリックしても「"pictkura"は壊れているため開けません」と表示されます。壊れてはいません——未署名のアプリに対してGatekeeperが出す定型の文言です。
pictkura.appを右クリック（またはcontrol＋クリック）→「開く」→ 確認で「開く」- それで開けなければ、ターミナルで
xattr -dr com.apple.quarantine /パス/pictkura.app
必要なのは初回だけです。
できること
- USB / SDカードからの取り込み — 撮影日をもとに、決めたフォルダ構成へ自動で振り分け。コピー後にサイズを検証します
- 大量の写真の一覧表示 — 仮想スクロールと、日付ごとの索引で、枚数が増えても開くのは一瞬です
- 検索 — ファイル名・フォルダ名・カメラ名・撮影日・お気に入り。日本語は中間一致（「旅行」で「沖縄旅行」が引けます）
- ビューア — キーボードで前後、スライドショー、撮影情報（カメラ・レンズ・絞り・シャッター・ISO・GPS）
対応形式
| 種類 | 形式 |
|---|---|
| 写真 | jpg png webp avif heic heif bmp gif tif svg |
| RAW | cr2 cr3 nef arw raf orf rw2 pef srw dng（Apple ProRAW を含む）ほか |
| 動画 | mp4 mov webm avi mts m2ts mkv ほか |
AVIFのデコーダを同梱しているので、OSの拡張機能なしで開けます。
RAWは現像しません——カメラが自分の画面用に書いた表示用JPEGを取り出すので、数ミリ秒で、しかもカメラ自身の色で出ます。
設計上の約束
- クラウドにしか実体が無いファイルを勝手にダウンロードしません。OneDrive等の「オンラインのみ」ファイルは、寸法と撮影日時をOSが持っているぶんから借ります。実体を取りに行くのは、絵が要る場面まで来てからです
- 削除は必ずゴミ箱経由です。直接消すことはありません
- ハッシュ計算をしません。更新の検知はサイズと更新日時だけです
分かっている穴
| 事柄 | 内容 |
|---|---|
| HEIC / HEVC にOSの部品が要る | Windowsでは「HEIF Image Extensions」（無料）と「HEVC Video Extensions」（有料）。HEVCのデコーダは同梱しません（特許の都合） |
| 動画のサムネイルはWindowsのみ | macOSでは動画が既定の絵で並びます（再生はできます） |
| macOSではHEIC/HEIFの絵が出ません | iPhoneの既定形式なので、macOSの方はご注意ください |
.m2ts / .avi はアプリ内で再生できません |
一覧には絵・長さ・撮影日が出ます。再生は既定のアプリへ渡します |
| 検索結果の並び替えがありません | 撮影日の降順で固定です |
| 取り込みの中断ができません | 開始したら最後まで走ります |
| 索引の再構築UIがありません | 設定フォルダの pictkura.db を消すと作り直します |
macOS版は一部の機能が無い状態での配布です（上記のとおり動画のサムネイルとHEICの絵）。走査・取り込み・一覧・検索・再生は動きます。
保存先
設定と索引は次の場所に作られます（写真そのものは入りません）。
- Windows:
%APPDATA%\dev.harusame.pictkura\ - macOS:
~/Library/Application Support/dev.harusame.pictkura/
アンインストールは、アプリと上のフォルダを消すだけです。
ライセンス
pictkura は MIT ライセンス です。
同梱しているオープンソースの著作権表示とライセンス条文は、配布物の THIRD-PARTY-LICENSES.txt（アプリの「情報」画面からも開けます）にまとめてあります。
English
A small, fast desktop photo manager — the first release. It does two things well: importing from a camera card and browsing what you already have, even when that is tens of thousands of files.
Downloads
| Platform | File |
|---|---|
| Windows 10/11 (x64) | pictkura_0.1.0_x64_en-US.msi (or ja-JP for Japanese) |
| Windows, no installer | pictkura_0.1.0_x64-portable.zip |
| macOS 11+ (Apple Silicon) | pictkura_0.1.0_arm64.zip |
Windows also needs the WebView2 runtime, already present on Windows 11 and up-to-date Windows 10.
The macOS build is not signed with an Apple Developer ID. The first launch shows "pictkura is damaged and can't be opened." It is not damaged — that is what Gatekeeper shows for any unsigned app. Right-click (or control-click) pictkura.app → Open → Open, or run xattr -dr com.apple.quarantine /path/to/pictkura.app. Only the first launch needs this.
There is no Intel (x86_64) build, and no Linux build. Note that the app's interface is in Japanese.
Highlights
- Import from a card — sorted into folders by capture date, with sizes verified after each copy
- Browsing that does not stall — virtual scrolling plus a date index, so opening stays instant as the library grows
- Search — file name, folder, camera, capture date, favourites
- AVIF decoder bundled — no OS extension needed
- RAW without demosaicing — the display JPEG the camera wrote is pulled out in milliseconds, with the camera's own colour
- Cloud-only files are never downloaded on their own; deletion always goes through the recycle bin
Known gaps
Video thumbnails and HEIC pixels are Windows-only for now — on macOS videos show a default icon (playback still works) and HEIC images do not render. HEVC needs OS components on Windows (no decoder is bundled, for patent reasons). .m2ts and .avi do not play in-app. There is no sort order for results, no import cancellation, and no UI to rebuild the index.
Settings and the index live in %APPDATA%\dev.harusame.pictkura\ (Windows) or ~/Library/Application Support/dev.harusame.pictkura/ (macOS). Your photos are not stored there.
Licensed under MIT; bundled third-party notices are in THIRD-PARTY-LICENSES.txt.