堕天使の煉獄

ついに1月中には終わらなかったな。
書庫内の画像をなんやかんやするツールアプデ開発。

でもまあ、ドン詰まってた部分はようやく解決出来そうなので、次の段階に進めてはいるのですが。

ファイルリストへの編集（助長なフォルダ除去とフィルタリング、ファイル名の桁揃え等）と、画像変換の部分を以前は全部まとめてたのを分離して、見通しを良くする感じに。

そして、書庫ファイル毎に個別に編集設定を設定しやすい感じに。

んでもちょっとまた新しい問題が出てたりも。

画像編集処理の設定って、優先順位とかあるんですよね。

例えば、トリミングは上下左右ピクセル単位で切り取る幅を指定するのだけども、その処理の前に画像の拡大縮小をしちゃったら駄目なのはわかりますよね。

回転とかも、180度とか上下反転だといいけど、90度とかだと画像の縦と横の幅も入れ替わってしまう。

グレースケール化なんかは、速度的には縮小したあとでやったほうが軽いけど、縮小前にやったほうが高品質（あんまそこまで変わらないけどｗ）で、例えばみんなアイコンサイズにしちゃうみたいな用途だと、品質とか気にするほどでもないので速度重視にしたい…なんてケースも？

とか思うと、優先順位も設定できる方がいいのかなぁとか。

そうなると、各編集設定自体をオブジェクト化して、編集リストに登録していく。
処理はリスト順で実行される。

みたいな感じがいいのかなぁ。

とか思うものの、大体ほぼ優先順位なんて固定なんだよなとおもうと、メンテが面倒になるだけじゃないかなとか思ったりもする。

そして、新機能として、範囲指定の塗りつぶし機能なんかもつけたいなとTODOメモに残ってたのだけども。
スキャンした画像の一部に、どっからか紛れ込んだチン毛を見苦しいので塗りつぶして除去したいとかできる感じの（ぉ

が、用途的には一画像に1矩形範囲だけではなく、複数登録型にしたいよな。
そうなると、全部の設定が登録型のほうが一貫性ある感じにも？

それか固定リスト+追加処理リストで、固定リストの前と後の2つのリストに追加できる形とか？

んんーやっぱ全部登録型のがいいのか？
あんまし複雑化したくないなぁ。

なんてところでちょっと考え中。


そこでちょっと転進。
そろそろ書庫に出力周りも作って行かないとなというところで、旧版はzip書庫の読み込みも書き出しも自前で読み込んでたのですが、今回は7zip使うことでzip以外の書庫にも対応できるようになったのだけども、出力はどうしようかなと。

utf8フラグ周りとか、7zipはわりと自動判別に頼ってたり、そもそもzip専用のライブラリではないので、そのへんちょっと融通聞かないところあったりするので、zip書庫の書き出しは自前でやるかなと思ってたのだけども。

でも一度7zipのライブラリの方の書庫作成機能もどんなもんか試してみたいなという気持ちもあったので、ちょっと試してみることに。
現状はzip出力オンリーだけど、7z出力もやりたくなること有るかもしれないし？


なにげに今回、googleのAIの「Gemini」使ってみたんだけど、こりゃ便利だなと。
自分でワード打ち込んでGoogle検索するよりは明確に知りたい情報出てくるので、かなり時間短縮になりそうで今はこういう時代なのかーと（ぉ

でもまあ、相変わらずたまに嘘吐くのはAIの泣き所だなーとｗ

書き出し用のコールバック周りで

streamSpec->Open(...)

とかのコード吐くんだけど、そんな関数ねぇよって怒られて
7zipSDKのサンプル見ると

streamSpec->Create_ALWAYS(...)
streamSpec->Create_NEW(...)

のどっちか使え(NEWは同名のファイルがすでにあると失敗、ALWAYSは問答無用で上書き)
とあるので書き換えたらちゃんと出来たりで。

あと、Googleの検索結果から主に生成してる？　ので、基本出てくるコードが結構古いSDKのコードだったりする。
ほんの数年前の更新で変わった部分とかが、変わる前のやつが出てきたりするので。

(旧)MY_UNKNOWN_IMP1 → (新)Z7_COM_UNKNOWN_IMP_1

みたいな。

なので、そのままコピペして～てのだけだと無理だろうなこれ。
今回のような外部のライブラリなんかだと、ライブラリ自体の理解もある程度無いと、まず何処が嘘吐かれてるのかも判らないし。
そのへんまだまだAIに丸投げとかは無理そうだなこれ。


……んで、とりあえず大体出来たっぽいんだけども、最後の書き出す所で、なんか書庫内に含めるファイルサイズの全体の総サイズを要求されてる部分があるんですよね。

処理の流れとしては、元書庫ファイルがあって、そこからファイル名とかフォルダ構成とか編集して、画像をサイズ揃えたりとかフォーマット揃えたりとか色々加工して、新しい非圧縮のzipに書き出し。

っていうツールなんだけども。

画像を書庫から読み込んで、新しい書庫に処理後のファイルを1つずつ書き出し……ファイルストリームで書き出すだけだから簡単だろ。

とおもってたんですけど、件の全体のファイルサイズを先に要求されるんですよね。
画像変換すりゃ当然ファイルサイズも変わるので、処理前に全体のサイズなんて分かるわけ無いじゃんっていう。

AIが吐き出したコードだと

struct StreamSource {
QString fileNameInZip;
QByteArray data;
qint64 size;
};
QList m_files;

みたいなのを放り込んでるんですよね
つまり、変換後の画像ファイルすべてをオンメモリで一旦持てとｗ

そりゃ無茶やろと言ってみたら、AIさんも「確かにそのとおりです！」とか返答したりしてｗ

んで解決法はというと、在るにはあるようなのですが
zipフォーマットのData Descriptor形式ってのを使わないといけないらしい。
ファイルサイズを後から追加するタイプで、書庫内ファイル毎の個別ヘッダのファイルサイズの項目とかは0になって、別項目のData Descriptorフィールドにファイルサイズが記述される感じのやつですね。

わりと書庫系ツールによっては非対応だったりする代物なので、あんまり使いたくない奴。

そして、何でそんなんになっているかといえば、「7Zipライブラリの仕様」だということらしい。

つまるところ、zip専用のライブラリではないので、zip専用の仕様には合わせてくれないということのようです。

しょぼーん。

結局、zip書庫の書き出しは結局自前でやる感じになりそうですｗ

まあ、すでに以前自分で書いたのがあるので、書き直すだけなんですけどね。
でもまあ結構昔に書いたのと、その頃はまだzipフォーマットを調べながら書いてたやつなので、結構無駄が多いコードだったりするので、そこそこ骨が折れそう。
あとzipフォーマットも、もう一度思い出さないとなｗ

んまあ、7zipだと、文字コードとか自動判別してるところとか多いので、そのへん自前だと明確にコード指定して書けるので、変な見つけにくいバグとかに巻き込まれにくいというのはメリットかも。

あとちょっと気になったのが、7zipのSDKで、kpidIsUtf8っていう定義が見当たらない問題。

utf8フラグを設定するのに使うやつなんだけど、これまたAIさんに聞いてみた所、SDKのバージョンとかによってあったりなかったりするらしい。

んでこれもZip特有の設定なので、7zipのSDK使ってZipも扱うサードパーティ製のライブラリなんかで慣例的に使われてるのが「kpidIsUtf8」という定義らしいとのこと。

んーやっぱ端から出力はzip書庫決め打ちみたいなことしてると、こういうところで齟齬がでるんだなぁと。

統合アーカイバシリーズなんかも、インターフェースを統一するために、フォーマット固有の設定周りでどないすんねんみたいなのが犠牲になってる部分多かった記憶あるもんな。

そんな感じで、今日はほとんどAIさんと会話してるだけでほぼ終わった（ぉ

レス

お名前（無記入可)

スパム対策キー: 半角英数字で「いちろくいちはちぜろさん」 と入力してください

本文(半角英数字のみの場合はスパム判定されます)