  |
はてなキーワード: jpegとは
拡張子も本来の正しい単語を使おうって流れができて、jpgがjpegになったんだよ
同じ流れで、.mpegなんてのもある
でも結局拡張子は種類判別に過ぎないので、3レターコードみたいなものだろって3桁に揃える流れに戻った
その後に登場したのが.mp4とかな
その後もwindowsは内部的に利用するファイルの拡張子は超ロングにしたりする
かくしてごちゃごちゃになったわけ
ファイル名が同じでも拡張子がjpegとjpgで違うファイル扱いになるのは納得いかねぇよ
Photoshopでjpegファイル開いてjpegって書いてあるフォーマットで保存したらjpgになるの納得いかねーよ何でファイル二つになるんだよ事故ったじゃねーかよ
私はただの会社員で、栄養の関わる知識はネットに転がっている程度しかありません。
この献立表は作り置き用です。
日曜日にまとめて買い物→調理→冷蔵・冷凍するためのプロセスです。
本当に申し訳ないんですが、購入してからすぐにカッターで本を解体してスキャンしてPDF化します。（スキャン後はマスキングテープでくっつけて本棚に入れてあります）
PDF化する理由は、献立を組み上げる作業は全てPC上で行っていきますが、PDFの方が本よりもレシピを探しやすいというのが1番の理由です。
また、最後はレシピ1つ1つを画像ファイルにするので、一旦PDFにしておいた方がその作業が楽になるという理由もあります。
スキャン環境が無い場合は、タブレットやスマホを使用してレシピの内容まできちんと読める状態の解像度で撮影し、画像ファイルタイトルに頁数を振っておくといいです。
1つずつレシピを読み込んで表計算アプリケーションに情報を書き出します。
PC上で計画・管理、スマホ上で閲覧出来るのが理想なので、私はMicrosoftのオンラインExcel（無料版）を使用しています。
｜【料理タイトル】｜【ジャンル】｜【調理方法】｜【冷凍可否】｜【PDF頁】｜
上記の順番でセルに入力していきます。次から詳細を掘り下げます。
△：野菜なしでタンパク質のみ 例）鶏のてりやきからしマヨソース
緑：鶏肉
茶：牛肉
黄：たまご
青：魚
薄橙：大豆
使用されている調味料を元にジャンルを記入、セルの色付けをします。
色付けの凡例は次の通りです。
水色：お酢（さっぱり系）
9割は振り分けられますが以下のように振り分けが難しい料理もあります。
→オリーブオイルとしょうゆを使ってるけどどちらかといえば洋食かな～→薄緑
レンジ調理、フライパン調理、鍋調理、トースター調理等を記入します。
山本ゆりさんの一部のレシピ本には冷凍の可否が書かれていますが、冷凍NGの食材が使用していなければ自己責任でOK認定にしています。
→豆腐、じゃがいも、卵、きゅうり、レタス、水菜、アボカド、ちくわ等
この後に情報を入れ替える作業があるので、どのレシピがどこに掲載されているかを把握しておくために頁数を記入します。
https://f.hatena.ne.jp/lyri/20240522143436
※「翌日」は「翌日に食べないとだめ」、要するに「冷凍不可」を意味します。
※余談ですが、料理タイトルをグレーアウトしているのは新しい本において調理の未済管理のために私が作ってみたレシピに施しているだけです。左側の★は子供が美味しい連発したレシピです。△は子供の苦手食材、苦手調理方法を含んでいるレシピです。
現在は書き込んだ頁順にレシピが並んでいると思われますが、これらをタンパク質順にソートします。
https://f.hatena.ne.jp/lyri/20240523101436
こうすることで「鶏が足りない！」 「ここに豚が欲しい！」 「トマト系のレシピ無いかな～」 「レンジ調理できる副菜ないかな～」等、検討時のレシピの検索が非常に便利になります。また、PDF頁数も一緒に移動することで索引機能を果たします。
例）
主菜A：◎肉入り野菜炒め（玉ねぎ・にんじん・キャベツ）→主菜に野菜たっぷり入ってるな～「○かぼちゃの煮物」を添えとくか
主菜B：○ぶり大根（大根）→大根だけか～緑もないし「◎なすとピーマンの甘辛味噌」にしよう
どうしても「○主菜＋○副菜」となる場合は【我が家の毎日食べても飽きない野菜】を味噌汁の具やサラダにしています。
キャベツ、大根、トマト、ピーマン、ごぼう、にんじん、かぼちゃ、ブロッコリー、おくら、わかめなど。もっと増やしたい。
これらの味噌汁とサラダは応急処置なので、わざわざ表には書いていません。
現在は子供が少食なので主菜と副菜のみにしていますが、もう少し大きくなったら味噌汁とサラダもレギュラー入りさせたいし、その時は味噌汁ルーティーンも組み込んでいきたいです。
（後で見本を載せていますが、現在は子供のストライクゾーンが和食に多いので偏りがちです。成長に伴って変革していきたいです）
理由は調理のモチベーションを保つため、1品目をレンジ調理している間に2品目の材料を切ったり下ごしらえをしたり出来るので時短になるため、レンジ調理したものはそのまま粗熱を取って冷蔵庫や冷凍庫に入れてしまうので、フライパンや鍋を洗う回数や手間を減らせるからです。
毎日作る時間が確保できるのであれば、フライパン調理のみで構成しても良いと思います。私も本当はそうしたいです。
火：主菜２ 副菜Ａ（冷蔵保存） ←副菜は原則2日間で食べきります
金：主菜５ 副菜Ｂ（冷凍保存） ←副菜は原則2日間で食べきります
冷蔵：主菜１ 主菜２ 副菜Ａ ←冷凍NG食材を含んでいてもOK
私は作り置きよりも作りたてのおかずを食べたい派です。なので、水曜日だけは子供が好きで野菜もたくさん食べられて比較的調理時間が短くて手間がかからないなおかずを組み込んでいます。親子丼、ピラフ、グラタン（ほぼシチュー）、オムライス、焼きそば、パスタ等です。
ただし、山本ゆりさんのレシピ（特にレンチンするやつ）は一旦冷まして味が浸透してから再度加熱して食べるとめっっっっっっっっっちゃくちゃ美味しいので、作り置きに向いているものが多いとも感じています。
冷凍したおかずの解凍方法は、食べる瞬間の24時間前頃から冷蔵庫に入れておくと自然解凍されます。
私は前日の夕食後に冷凍庫から冷蔵庫へ移動しています。そうすると冷蔵したものと同程度の加熱時間で食べられます。
ちなみに水曜の主菜３は使用するお肉や魚だけ日曜の買い物直後に冷凍して、火曜の夜に冷蔵庫に移動して自然解凍された状態で調理します。
https://f.hatena.ne.jp/lyri/20240523103013
水曜日のセルが黄色なのは、私が献立を考える際に「ここは固定！」とわかりやすくするために塗った名残なので特に意味はありません。
タンパク質、野菜数、ジャンル、調理方法のバランスが割と整っているのではないでしょうか。
完璧に組み立てるのは正直かなり難しいです。
例えば上画像の5週目の木曜と金曜は○と△で構成されてしまっているので、更に味噌汁を追加するか、もしくはバターしょうゆの味付けとスナップえんどうに合いそうな野菜（いんげんとかアスパラ？）を追加したいところです。味噌汁を新たに作る方が簡単で食卓の見栄えは良いです。
これらは更に小さいセルで管理すると見える化でき、ジャンルや野菜のばらつきをチェックできます。
入れ替えの際はこちらの更新も必要で面倒ですが、やっておくと新たなレシピを組み込む際に非常に明快になります。
https://f.hatena.ne.jp/lyri/20240522151313
入れ替えが発生する要因として1番多かったのは、ジャンルの偏りと野菜の偏りです。
中華系ばっかりで胃もたれやばいな！とか1週間ずっとブロッコリーとキャベツ食ってるな！等です。
散らすと飽きが来なくて良いです。
カレーやシチューは1ヶ月に1回にする等、何かを固定すると組み立てやすかったです。
また魚のレシピが少なくなりがちなので、まずは魚を設置してみるといいかもしれません。
主菜も副菜も夜に食べきってしまうのではなく、基本的に翌日の朝食とお弁当でも食べています。
金曜の主菜５は翌週月曜日の朝食とお弁当にするので、金曜分と月曜分に小分けにして冷凍すると尚良いです。
私は面倒なので金曜分をまるごと解凍して夕食に出し、その後粗熱を取って再冷凍しています。（あんま良くない？）
献立表を組み終わったらレシピのPDFから画像ファイル（PNGやJPEG等）を作成して、Googleドライブのようなクラウドストレージに格納します。
PDFを画像ファイルに変換するアプリケーションを使用したり、私はScreenpressoを使用して切り取っています。
https://f.hatena.ne.jp/lyri/20240523114245
これは4周目のフォルダです。1ファイル700KBくらいでした。サイズは600×600くらい。
文字が読める程度の解像度と読み込み速さを確保できれば良いです。
1レシピずつ参照しながら必要な食材や調味料を書き出します。使用個数まで書いておくとわかりやすいです。
→合計で1個あれば足りるね！使い切りたいから野菜南蛮に1/2個使うか！等の計画を立てられます。
記録は私はGoogleKeepを使用しています。PCで書き出し、店舗ではスマホで閲覧します。
材料は一旦全部書き出して、冷蔵庫に残っているものがあれば消していきます。
例えば私は玉ねぎ、にんじん、じゃがいもは袋で買っていて、冷蔵庫に残っていることが多いので照合します。
調味料は滅多に無くならないので書き出しの際に省略することが多いです。（使い切った時の達成感すごい）
そうするとリストを上から順番に追っていくだけで買い物が終わります。
野菜→魚→乾物→肉→乳製品みたいなざっくりとした順番で大丈夫です。
クラウドストレージに保存した画像ファイルを見ながら進めます。
収納ラック等で1段高い位置にスマホを置いて、調理場所を広く確保すると汚れないので良いです。
余談ですが包丁とまな板は2セット用意して野菜用と肉魚用で分けています。
以上です。
普段喋り言葉で草生やしまくりのブログ執筆やツイートしかしてないので至らない部分があったらご指摘ください。
最後に、私が実際に運用している献立表のジャンルと一部の野菜のばらつきを見える化した一覧表をご参考までに。
https://f.hatena.ne.jp/lyri/20240524094732
ワンポイントアドバイス: novelai v3はartist名の指定が重要なんで先頭に置くとよい
ixyとかsuurin_(ksyaro)って入れるとガラッと絵が変わるんで試してみそ
昔作ってたケモR18プロンプトあるから参考にしてちょ(要品質向上プロンプト機能off)
ネガティブはけっこう使いまわしがきく
---
作家名, [very long hair], furry female, grey fur, sex, girl on top, naughty smile, in heat, :3, {fang}, looking back at viewer, arched back, body fur, sideboob, covered nipples, thighhighs, skirt lifted by tail, tail raised, pussy juice, breath, sweat, hair ornament, spoken heart, [wind], [[small breasts]], [penis,[cum in pussy], ejaculation], orgasm, [rating:Explicit, nsfw], {very aesthetic, best quality, highres}, [sunlight, palm tee, sky, cloud],
---
{copyright, copyright name, copyright notice, {bad hands}, signature, logo, text, comic}, lowres, {bad}, error, fewer, extra, missing, worst quality, jpeg artifacts, bad quality, watermark, unfinished, displeasing, chromatic aberration, extra digits, artistic error, username, scan, [abstract], {censored}, fox, letterboxed, anatomical nonsense, deformed, {{chibi}}, {blind, empty}, heterochromia, multiple views, pubic hair, bald, pawpads, paw gloves, animal feet, copyright, copyright notice, censor, censored
---
例えば「画像は3色で保存されてるけど、それぞれ何色か知ってる？」と聞いたら
情報理論関係無くRGBを答える人は多いと思う（たまにこれすら答えられないプログラマーがいるが・・・）
ところが「JPEGって各画素に対して8bitなんだけどどうやって3色を割り振ってる？」って聞くと分からないプログラマーが多い
普段のプログラミングでJPEGを貼り付けるだけならこんなこと知らなくても問題無いんだが
ちょっと複雑なことをするときはこの手の知識が必要になってくる
同様に「人間の可聴周波数は？」とか「それをどうやってデジタルに保存してる？」とかも知らない人が多い
こういう知識を持ち合わせずに「音声認識結果が悪いのでハイレゾにしてみました」とか言ってきたりして頭が痛くなる
他にも情報量の概念を知らずに圧縮しようとしたり公開鍵のことを知らずにセキュリティに関する実装をしたりIPパケットを知らずにネットワーキングしようとしたり
基本的な知識を知らずにプログラマーになってる人間が多すぎて問題になってる
幹部なんかは「基本情報を持ってたらいいんだな！」「応用情報を取らせよう！」みたいな対策をやりがちなんだが
一夜漬けで終わらせる人がかなり多くて前述の質問に答えられない人もIPA資格は持ってたりする
普通に情報系の大学を出ていれば授業で単位を取得しているはずなんだが
大学はもっとザルで簡単に単位を取れてしまうので全くアテにならない
一番問題なのは、知識を知らなくてもプログラミングできてしまうので
下手に経験を積むと情報理論なんかの基礎を知らないまま「優秀プログラマー」として認知されてしまい
更に本人もその自覚を持ってしまってリーダー的な立ち位置になってしまう
こうなると外部からの指摘を受けてもなかなか訂正しないし酷い状態でプロジェクトが荒れ地になる
あ、NovelAiって書いてたね。じゃあBREAKは無いね。悪い。
by {{{作家名}}}, animal furry female adolescent {{imaizumi_kagerou}} from side, Touhou, [[[official art, official style]]], gray {{body fur}}, standing skirt lift thigh focus, {sexually suggestive, rating:Sensitive}, [very aesthetic, best quality, highres], [[eyes visible through hair, hair between eyes, long hair, long brown hair]], [looking to viewer], [red eyes], {large detailed best quality eyes}, [snout, slit pupils, :3 naughty smile, animal ears, wolf ears], {wolf tail}, oversized clothes, {white dress with long sleeves, skirt lift}, thighs, [[crotch, groin peek]], hair ornament, tail ornament, drunk, in heat, spoken heart, breath, sweat, wet, sweat, {sexually suggestive}, {pixel art}, [[sun, town, alley]], [very aesthetic, best quality, highres]
neg:
{{copyright, copyright name, copyright notice, {bad hands}, signature, logo, text, comic}}, {blind, empty eyes, no pupils, mismatched pupils, eye reflection, half-closed eyes, squinting}, lowres, {bad}, error, fewer, extra, missing, worst quality, jpeg artifacts, bad quality, watermark, unfinished, displeasing, chromatic aberration, monochrome, extra digits, artistic error, username, scan, [abstract], [bad vulva], [asymmetrical], {letterboxed}, [[darkness]], anatomical nonsense, {fingernails, nail polish, fingers, hand focus}, deformed, chibi, heterochromia, multiple views, bad multiple views, {asymmetrical breasts, breasts apart, flat chest}, {{censor, censored}}, pubic hair, bald, pawpads, paw gloves, animal feet, copyright, copyright notice, {blush}, alternate color, shiny pokemon, [skin], [[[[realistic, cel shaded, animated]]]], senko (sewayaki kitsune no senko-san), fox, red fur, dark, darkness, simple background
一応StableDiffusionの動作原理についての解説読みながら書いたんだが
そもそも「手を入れた部分が極端に少ないか無」というのは要するに「既存の絵とそっくり」ということだが、人間がわざわざ寄せるようにプロンプトしない限りそんなことは基本起きない
まさか開幕から「AIの学習は人間の学習と同じ」前提に立った部分を置いてオペレーターの人間の介在について出してくるとは思わなかったが、この言い方では「人間がそう指示を出せば"既存の絵とそっくり"な出力ができる」から事例次第では権利者が訴え出られるとも考えられる
引用の適法性の観点に立って「手を入れた部分が極端に少ないか無」を考えたのはそういうことではない。学習モデルに入ってる画像とテキストの組み合わせが合計6組だろうが100億組だろうが、動作として"入ってるデータのみ"を使った出力ならば、盛り込んだデータ数に関わらず「引用部分が従である」が成立しないので引用が成り立たないという話。つまり無断転載の可能性が出てくるということ
追えない
ここについては「生成済みのAI出力のJPEGかPNGを見せられても内部処理は追えない」という意味であれば正しい
ただ生成AIのシステムもコンピュータープログラムである以上「プログラム動作時のデータ処理の流れを追うログ出力コードを盛り込むことは不可能」なんてことはない(開発者がソースの段階でコードを足せる)ので「内部処理を追うことができない」は正しくない
人間からすればログを読んでどのデータがどう処理されたかを理解するのが困難、かつデータ数と処理の手数が膨大なので手に負えないというだけの話
調べてみたらひどいクソ仕様だったので、同じ轍ふまないように知見共有します。
なお、消えてしまったデータは息子の卒業式の動画データ。復元不能。
ストレージは壊れるものという前提は理解しているつもりなので、状況ごとにいくつかのバックアップ体制は取ってある。
安くなったとは言えすべてのストレージをSSD化するには至っていない。
そのため、OSやソフトウェアなんかはSSDにインストール、写真や動画などのサイズがでかいデータはRaid HDDでミラーリングして格納するようにしている。
それ以外にもそれほどサイズの大きくないデータはonedriveとかのクラウドストレージを利用。そのデータもRaid HDDでミラーリングして二重にバックアップ体制を敷いている。
趣味で写真をやっているのだが、今回の事故はその編集のフローの中で起こった。
編集と格納は別で考えているので、アクセス速度が高いほうがいい編集はSSD上で行い、格納はRaid HDDに行っている。
そのタイミングでgoogle photoに分散バックアップ、必要に応じて家族なんかと共有を行う。
つまり、撮影が終わったら最初にすることは、SSD上にあるデスクトップの一時フォルダに写真と動画データをコピーすることから始まる。
Raid HDDに格納するのは、編集ソフトでレタッチが終わってからだ。
まずは写真データから編集を行い、RAWデータから無事にjpegデータへと書き出してHDDへの格納が終わった。
そのタイミングで妻からの頼まれごとのためにメールをpdfプリントして名前をつけて保存しようとした。
めったに使わない機能なのだが、指定されたのはonedriveフォルダだったので、そのまま保存をクリック。
ところが、PCからonedriveフォルダにアクセスしても出力したpdfデータが見つからない。
おかしいなと思ってもう一度出力を試みて保存フォルダのパスを確認してみる。
すると、今現在HDD側に指定してあるonedriveのパスが、SSD上のデフォルトのパスに指定されているようだった。
ここで思い至ったのが、確かPCにonedriveを設定した際にうっかりデフォルト設定のまま起動してしまい、その後、HDD上にパスを切り替えたという状況だった。
「そうかぁ。保存先を変更すると元のファイルを移動させるんじゃなくてコピーを作ってしまうんだな」なんて感じに妙に納得しつつ、もう一度しっかりとパスを確認した上でpdfをコピーしてからSSD上のonedriveをshift deleteで削除した。
エクスプローラーを閉じてデスクトップに戻ってくると妙な違和感。
ない。
はぁ？と思ってPCをダブルクリックすると、すぐに警告ウィンドウが開いて「デスクトップへのパスが間違っています」といったエラー表示。
焦る。かなり焦る。
ウィンドウをすべて閉じても、デスクトップ上にはデフォルトのアイコンだけが並んでいるだけ。
頭真っ白。
多少大事なデータはあったかなと思いながらも致命的と言えるものは思いつかず（まだ見落としてるだけかもしれない）、しかし、すぐに一時フォルダごと動画データがないことに気づく。
写真はすでにjpg出力してあるので、RAWデータが消えてしまったのはなんとかなる。
子供の卒業式の動画はまだ変換をかけてもないし、当然アップロードもしていない。
終わった。
あまりにもショックだ。
読み飛ばしここまで。
結局何が原因だったかというと、最初にonedriveをセットアップする際に、デフォルトの保存先、なおかつデスクトップやマイドキュメントなんかもバックアップに含めるという設定で始めてしまったからだったらしい。
この、onedriveのバックアップにデスクトップを含めるという操作をすると次のようなことが起こる。
「本来はC:\Users\ユーザー名\Desktopにあるはずのデスクトップデータが、C:\Users\ユーザー名\onedrive\Desktopに変更される」
・onedriveのバックアップからデスクトップを含めないように設定変更
この2つの動作を行ったにも関わらず、何故かこのパソコンのデスクトップは、C:\Users\ユーザー名\onedrive\Desktoに残ったままになってしまったというわけだ。
そのため、C:\Users\ユーザー名\Desktopにデスクトップがあると思いこんでいた自分は、C:\Users\ユーザー名\onedriveにあるonedriveのフォルダを、疑うことなく削除することができた。
そしてその結果、デスクトップにおいてあったデータのすべてを失った。
いや、流石にこんなクソ設定想定できないでしょ。
大事なデータを守るっていう名目があれば、大事なデータの格納先をそんな簡単に変えていいと思ってる？
それ、誰に許可取ってやってるんだよっていうさ。
その辺の共通プロトコルを、バックアップソフトが、しかもOSの提供元がやっていいのかよっていう。
これはちょっと言わせてくれ。
マイクロソフトクソだわ。
まぁ、なんというか皆さんも気をつけてください。というか、こんなの気をつけようがないけどな。
どこに気持ちをぶつけたって息子の大事な思い出は帰ってこないのはわかってるけど、やるせなさくらい吐き出させて。
※追記
ブラウザonedriveのゴミ箱にデータが残っている可能性はゼロです。
その理由は以下の通り。
このパソコンは1ヶ月ほど前に新規にセットアップしたものでした。
そのセットアップの過程で、onedriveをインストールする際にデフォルトの保存先、なおかつデスクトップをバックアップという設定にしてしまいました。
ここでノールックで設定してしまった自分が一番悪いことは認めます。
onedriveのセットアップが終わったあと、同期に時間がかかっていておかしいな？と思ってファイルのアップロード履歴を確認したところ、あらかじめ古いパソコンからコピーしてあったデスクトップのデータをアップロードしようとしていたので、慌てて設定を見直して、デスクトップ同期のオフ、保存先をHDDに変更しました。（変更した順番は書いてある通り覚えていません。順番が逆だったら起こり得なかったかも）
この操作によって、onedriveの保存先はHDDに変更になり、デスクトップの同期も停止しました。
しかしそうした操作を行ったにも関わらず、デスクトップの保存先はC:\Users\ユーザー名\Desktopに戻ることはなく、C:\Users\ユーザー名\onedrive\Desktopのままになってしまっていました。
そのことに気づかずに1ヶ月以上作業を続けていたなかで、記載の通りSSD内に同期されていないonedriveフォルダを発見したので削除した結果、デスクトップのデータが消失しまったという話です。
そして卒業式の動画データをデスクトップにコピーしたのは、onedriveの同期を切ったずっとあとのことです。
もともとonedriveにバックアップするつもりもないし、バックアップされていないのでwebに残っているはずもないのです。
デスクトップのデータがそんなところに格納されていることがわかっていれば、もともと削除なんてしません。
同期されていないすでに使われていないonedriveのデータだけしか削除するつもりではなかったのに、何故かその中に現在進行系で使っているデスクトップのデータが格納されていて、一緒に削除されてしまったというお話です。
ちなみに、削除直後は本当に何が起こったのか意味がわかりませんでした。
その後にマイコンピューターを開いた際、別ウィンドウでエラーが出たことで初めて状況が理解できたということです。
そのエラーが「デスクトップC:\Users\ユーザー名\onedrive\Desktopにアクセスできません」といった内容のエラーです。
デスクトップ？お前なんでそんなとこに保存されてたの？からの、そういえば思い出してみればこんなことあったよなーで、原因に思い至ったというわけです。
SDカードの復元を試みましたが、サイズの大きい動画データですので、ヘッダーは読み込めたものの、データそのものはすでに別の写真データに書き換えられてしまっていたせいかちゃんと開けませんでした。
SDカードからデスクトップにデータを移すタイミングというのは、行事ごとに撮影が終わったらSDを空にして新しく撮影できる状況を作るためなので、基本的にはデスクトップにコピーしたあとは次の撮影前に必ずフォーマットすることを習慣づけています。
それは、毎回SDカードを空っぽにすることで、現像のときにデータの重複が起こらないようにするためです。（趣味で写真を取っているので撮影枚数が莫大。尚且つ現像ソフトで不要データを削除するので、SDを空にしないと、削除後にまたコピーしてしまったりと効率が悪いため）
撮影→データをデスクトップに一次保存→次回撮影時にSDカードのフォーマット→時間があるときにPC上のデータを選別、現像→バックアップ含めてデータを格納→SDカードから新しい撮影データをPCにコピー→次回撮影時にフォーマット→時間あるときにPC上のデータを選別、現像→・・・・
SDカード自体も紛失の危険性とか考えてそれほど信用しているメディアではないので、できるだけデータが保管されている時間を短くするようにしています。
個人的には、このワークフローが一番データの保存性も高く、無駄も少ない処理方法だと思っています。
だって、デスクトップを間違って消すなんてこと普通しないでしょ。
壊れたなら仕方ないって、それはそれで納得できるんだって。
流石にこんなことまで想定したワークフロー作れってのは無理な話ですよ。
すでにonedriveからデスクトップの同期も切ってて、しかも別フォルダでonedriveがちゃんと稼働してるのに、まさか自分のデスクトップがC:\Users\ユーザー名\onedrive\Desktopに保存されてるなんて思う？
Webスクレイピングツールは一般であまり認知されていないが、Webを中心としたIT界隈では常識的なツールであり、端的に言えば登録したWebページを巡回し更新を監視するツールである。
似たようなものにRSSやAtomフィードリーダーなどが存在するものの、Webスクレイピングツールの業界共通認識としては、監視するWebページにRSSやAtomフィードが無くともWebページ情報の差異を過去と現在で計算し、変更の閾値を超えたWebページの更新を通知し、そして保存できるというものである。
変更の閾値という処理が挟まれる理由として、広告などを代表例にWebページ閲覧時の更新の度に変化する可能性があるため1%でも更新が通知されると更新の通知が膨大となるため些細な変更を無視するためだ。
もしWebスクレイピングツールで更新されているページにPDFやJPEGなどのバイナリファイルが存在したとしても、PDFやJPEGなどのバイナリファイルが存在したとき多くの場合Diffと呼ばれる差分検出ツールを用いてバイナリファイル単位で変更があったかどうかを監視している。
Colaboなど現代の多くの団体はWebを活用して運営されているため情報をWebを介して告知するので、暇空茜応援団はそれを逆手に取り情報更新を監視している。
暇空茜応援団が即座にWeb情報の更新へ反応するのはこういった背景があるのだ。
逆に言えばWebページの更新を秒間で行うなど更新通知を飽和させるカウンターなどを想定できるが、閾値を変えればその様なカウンター手法を無視できるため意味がないし、特定のキーワードだけ抽出することも可能なので無駄なリソースとなるため無駄であると忠告しておきたい。
ファミマの複合機から 400dpi JPEG のスキャン画像を直接自分のスマホに送れることを知って確信した。
買おうかどうしようか少し迷ってたけど、コンビニが近くて印刷やスキャンはたまに使うだけくらいなら機械を持ってる必要ないねえ、これ。
もちろん、コンビニが近くにないとか、印刷やスキャンを日常的に利用する人はこの限りではない。
自宅にスキャナプリンタが必要か・必ずしも必要ではないかの分岐点はあるだろう。
白黒20円、カラーが40円。間をとってコピー・スキャン単価を１枚30円くらいとしよう。
スキャナプリンタの価格はカカクコムの売れ筋上位10機種の平均価格（本日現在）をとって18,507円としよう。
スキャナプリンタの製品寿命は法定耐用年数をとって5年としよう。
これをもとに計算すると、月に10ページあたりが損益分岐点となるね。
（平均価格は最安値から導いているので、分岐はもっと上ブレするはずだけど）
直接のコスト以外にも、
などなど変数は色々あるし人それぞれなので定式化できないが、何となく「プリンターはパソコンの周辺機器として家にあって当然のもの」という意識のままで思考停止しちゃっているのならば、一度立ち止まって検討しなおす価値はあると思う。
とここまで考えて、車も同じだなあと思った。
使用頻度、ランコス、利便性もろもろ加味して持つか持たないかの選択は人それぞれだろう。
ほかのあらゆるサブスクにも言えるかもしれない。
せっかく課金したのにユーザが増えまくっているのか滅茶苦茶重くなっていて最悪。
だから流出したモデルを使ってローカルでNAIの環境を構築する。
ネットには情報もだいぶ転がってるけど陳腐化した情報があまりに多いため増田にまとめることにした。
もしかしたらこの記事もすでに陳腐化しているかもしれないが…単純に間違ってたらトラバで教えてほしい。
もちろん自己責任。この記事を見て導入した結果何かあっても増田は何も保証しない。
英語がわかる人はこっちを見た方が早いと思う。今は導入RTAができるくらい導入は楽になっている。
https://rentry.org/nai-speedrun
VRAMが2GB以上あるNVIDIA製のグラフィックボードがあればローカル環境を構築できる。
GPUの世代はGTX700シリーズ以降。なので一昔前のミドル級ボードでも動作するらしい。
IntelのオンボードGPUでも実行する方法があるらしい(stable_diffusion.openvino)が今回は割愛する。自分で探してね。
その他の推奨環境は以下の通り。
対応OS：Windows7以上(と言うがM1Macでも動作する方法があるとかなんとか)
メインメモリ：16GB以上(VRAMもたくさん必要だが起動時にメインメモリも大量に食う。WebUI起動時にタスクマネージャを見ているとよくわかる)
スマホしか持ってないような人やこういうのがよくわからない人はNovelAIを使った方が良いと思う。
今は重いけど、きっとそのうちみんな飽きてサーバも軽くなるかもしれないし。
(追記)NovelAIがリソースを確保してサーバが軽くなったからリスクを背負ってまで導入しなくても良いかも
(追記)Pythonは当然3系。最新の奴を入れれば問題無い。
導入方法はいちいち書かないけど、「python --version」や「git -v」で
正常にバージョン情報が出る(パスがきちんと通っている)ことはちゃんと確認しよう。
Stable Diffusion web UIはStable Diffusionやそれをベースとした画像生成AIを利用するためのフロントエンド。
その中でも特に開発が活発でデファクトスタンダードとなっているのがAUTOMATIC1111版だ。
導入したい適当なディレクトリに対してPowerShellなどで
「git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git」
なお、AUTOMATIC1111版は数時間単位でコミットが行われるから
定期的に「git pull origin master」で更新しよう。
クライアントはqBitTorrentが一番楽だと思う。
ここにはさすがにmagnetリンクは書かないから各自ググって欲しい。
結構誤解されがちなことだが流出データ50GBを全部ダウンロードする必要は無い。
必要なファイルはanimefull-final-prunedディレクトリの中身とanimevae.ptだから5GBちょっとくらいなんじゃないかな。
もし余裕があるならmoduleディレクトリの中身もダウンロードすればいいけど、ぶっちゃけ必要無いんじゃないか？
まずはanimefull-final-prunedの中身のファイルをリネーム。
「model.ckpt」を「animefinal-full-pruned.ckpt」のようなわかりやすい名前にして、
「animevae.pt」を例えば「animefinal-full-pruned.vae.pt」のような拡張子以外は同じファイル名にする。
WebUI起動フォルダ配下の\models\Stable-diffusionにリネームしたファイルを移動させれば配置はOK。
ちなみにmoduleディレクトリの中身は\models\hypernetworksに移動させて使う。
それらのファイルを設定で適用させると画風が結構変わるがNovelAI再現とは関係無いみたいだ。
(追記)moduleディレクトリの中身の.ptファイルはhypernetworksという技術によって画風などを学習したものらしい。
すでに複数のイラストレーターの画風を学習したptファイルが作成されており議論を呼んでいる。
自分のグラボのVRAMが4GB未満の場合は「set COMMANDLINE_ARGS=」の後に
4GB未満の場合は「--medvram」、2GB未満の場合は「--lowvram」とパラメータを追加しておこう。
自分の持ってるグラボのVRAMがわからないときはGPU-Zなどで調べよう。
またGTX1600系固有のバグ(単色の画像が出力される)があるらしいので
その場合は「--no-half-vae」もしくは「--no-half」や「--precision full」とパラメータを追加。
ちなみにパラメータに「--xformers」を追加してxformersを導入・使用すると
消費VRAMが減って画像生成処理時間も短縮されるので是非導入しよう。
画像からdanbooruのタグをAIで調査するdeepdanbooruを利用する場合は「--deepdanbooru」を追加。
のようになる。
ターミナルやPowerShellなどでwebui-user.batを起動しwebUIの初期導入と起動を行う。
過去には手動でCUDA等を導入する必要があったが、現在はこの初期導入でだいたいの導入が行われる。
ずいぶん楽にはなったがその分初期導入の時間は結構長い。10分～20分くらいかかるかもしれない。
途中で導入処理がエラーで止まってしまった場合は管理者権限で実行するなどして対応して欲しい。
起動ができたらSettingで以下の設定を変更してNovelAIに近づける。
Stop At last layers of CLIP modelを2に、
Eta noise seed deltaを31337にする。
これで設定は完了！
設定を合わせて完全にNovelAIと同じ内容になったのかを確認するテストがある。
出力結果から海外じゃHallo Asuka Testなんて呼ばれている。
これは初期SEEDをはじめとする設定内容が完全に一致していれば同じ出力結果を得られる仕組みを利用している。
プロンプトの内容：masterpiece, best quality, masterpiece, asuka langley sitting cross legged on a chair
ネガティブプロンプトの内容：lowres, bad anatomy, bad hands, text, error, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, normal quality, jpeg artifacts,signature, watermark, username, blurry, artist name
https://i.imgur.com/Bfl5qJB.jpg
なお、このテストはAUTOMATIC1111のバージョンやxformersの適用状態によっては微妙に違う画像が出力されることがあるらしい。
xformersを適用させている増田の環境だと確かに二つ並べると間違い探しレベルの違いがあった。
「Booru tag autocompletion for A1111」を導入すればNovelAIのように自動でdanbooruのタグを保管してくれる。
画像生成AIモデルはStable DiffusionがOSSのため派生が結構多い。
自前で追加学習もできるため自前で学習した追加AIモデルを4chanのような掲示板などで共有する人もいるらしい。
しかしそのようなモデルの中にウィルスのような悪意のある動作を行うものもあるらしい。
FBIがペドフィリアを一網打尽にするためにIPアドレスなどの個人情報を抜き出す動作を行うロリ特化AIモデルを掲示板で配布していて
しかもそれには本物の児童ポルノが教師データとして使われている…などという都市伝説的な話が今界隈を賑わせている。
https://b.hatena.ne.jp/entry/s/togetter.com/li/1954578
ノイズを削るは違うでしょ。減算しかしないのか？んなわけない。人間のように線を引いたり色を塗ったり切り貼りしたりしないだけで、やってるのは「描く」だよ
NN型のAIは原理的に人間の脳でやってる事と変わらんので、今人間がやってる事で違法でない事をAIがやったから違法って事にするのは難しい
ヒトの脳とは全然違う。
人間が補助線引いて曲線や体の全体の配置を把握してるのをノイズで学習して、いろんな類型を食わせるとAIが必要条件を覚えていくって感じなんだな。
え？
ほんとそれ！
惜しいけどなんか違う。学習済みのNNは特徴抽出してるわけじゃなくて、入力に学習した特徴を畳み込んで出力する。
ランダムノイズから「そうじゃない」を否定して描いてるのは過程GIF見れば分かるんだが、結果的には違法JPEGのつぎはぎが出てくるんだわ。
わりと正しい。
いえ。画像そのものではないが、パーツ（学習した特徴量）の組み合わせを出力してます。
宿ってねーよw
遺伝的アルゴリズムとは全然違うけど、概念レベルでいえばそういうこと。
超解像技術の進化というより、超解像を実現する手法のバリエーションの一つって感じ。
まあ、ほとんどの人が良く分かってないんだろうな、ワイもだが
人の脳を模して造られたのがNN
