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つの
タグが揃ってセンサーの内側で正の面積になるときだけです。そのうえで、プレビューを取り出せた道では
他の申告と同じ関門を通ります——プレビューより小さい値は信じません。DMC-LX7 が
そのままなのはこれです。プレビューが取り出せなかった道には比べる相手がいないので、
縁の値がそのまま入ります。読むのは、Panasonic独自のTIFFヘッダを直して読む道の上です
（見本のPanasonic系はすべてこの道を通ります）。
見本の DMC-LX7 .rw2 がこれに掛かる1台で（縁は 1824x1368、プレビューは 1920x1440）、
寸法は変わりません。この見本はもともと小さい記録で、ファイル自身がセンサー全体を
1904x1384 と書いています——縁のほうがこの個体には正しく、プレビューが大きいだけです。Leica の Digilux と D-LUX は Panasonic 製で同じ作りを
自社名で出すので、メーカー名では切っていません。
配布物について
| 用途 | ファイル |
|---|---|
| Windows 10/11・ふつうはこれ | pictkura_0.2.4_x64-setup.exe（管理者権限は不要） |
| Windows・PC全体に入れる（企業などの管理者向け） | pictkura_0.2.4_x64_ja-JP.msi / _en-US.msi |
| Windows・インストール不要 | pictkura_0.2.4_x64-portable.zip |
| macOS 11以降（Apple Silicon） | pictkura_0.2.4_arm64.zip |
どちらも署名していないので、初回に Windows は SmartScreen、macOS は Gatekeeper の
警告が出ます。進め方は
README に
書いてあります（macOS 15 で手順が変わった件も含みます）。
0.2.3 からの更新
Windows はインストーラをそのまま上書きで実行してください。macOS は ZIP を展開して、
置いてある pictkura.app を新しいものに置き換えてください——Gatekeeper の手順は
もう一度必要です（macOS から見ると、落としてきたのは別のファイルだからです）。
手順は README に
あります。
どちらの場合も、ライブラリ・設定・お気に入り・選別の印はそのまま残ります。
すでにライブラリに入っている写真も直りますが、速さが2通りあります。
寸法がまったく無い写真——上の Panasonic の .RAW 2枚——は、次の起動で
もう一度調べ直され、その回に寸法・撮影日時・カメラ名がまとめて入ります。
この2枚は絵を作れないので作り直すサムネイルがそもそも無く、
起動時のこの道だけが経路です（それで足ります）。
プレビューの寸法が既に入っている写真——Leica の .rwl——は別の話で、
誰も探しに来ません。あとから寸法を埋める掃きが見るのは
「プレビューの寸法が記録されていない行」だけで、0.2.2 以降に取り込んだ写真は
それを持っているからです。直るのは、その写真がもう一度処理されたとき
——新しく取り込んだとき、ファイル自体が変わって再スキャンされたとき、
サムネイルの置き場から追い出されて作り直されたとき。
0.2.2 より古いライブラリなら、その掃きが拾って直します。
まだ出来ないこと
動画のサムネイルは、OSがコンテナを開ける範囲までです——Windows はシェルから、macOS は
AVFoundation から借りています。mp4 と mov は H.264 と HEVC（hvc1）の見本で出ること、
.avi は macOS では何も返らないことを実測しています——Windows のシェルは
.avi のサムネイルを返します。取り出すコマは常に先頭なので、黒からフェード
インする動画は黒いタイルになります。Linux は経路そのものが無く、配布物も出していません。
.m2ts と .avi は一覧には出ますが、アプリ内で再生できません。検索結果の並び替え
（撮影日の新しい順で固定）、検索索引の再構築UI、取り込みの中断はありません。
どこにも寸法を申告していない RAW——見本では Blackmagic の CinemaDNG が1件——は
いまも寸法が空のままです。全部は README にまとめてあります。