ヴェズルフェルニルの研究ノート

座右の銘「ただ一人犀の角のように歩め」的な研究活動ノート

【Python】pipenvによる仮想環境構築

以前の記事にPoetryによるPython仮想環境の構築方法について書いたが、最近はPython仮想環境としてPoetryではなく、以前使っていたpipenvをまた使うようになっている。

blog.ketus-ix.work

Poetryはパッケージ管理方法が独特で何だか使いにくく感じられるようになってきた。GitHubなどに上がっているPythonプログラムはvirtualenvやpipenvを利用してるものものが多いし、requirements.txtの扱いもpipenvの方がやリ易い。

pipenv.pypa.io

自分の備忘録として、pipenvのインストールと使い方を記事として残しておくことにする。

pipenvのインストール

pipenvのインストール方法として、システム側に入れるのと、言語ツール環境に入れるのの2つの方法がある。

pipenvをシステム側に入れる

$ sudo apt install python3-pip
$ pip3 install pipenv
% brew install pipenv

pipenvを言語ツール環境に入れる

pyenvを使っている場合

$ pyenv install 3.10.12
$ cd
$ pyenv global 3.10.12
$ python --version
Python 3.10.12
$ pip install pipenv

asdfを使っている場合

$ asdf install python 3.10.12
$ cd
$ asdf global python 3.10.12
$ python --version
Python 3.10.12
$ pip install pipenv

pipenvによる仮想環境作成/削除

仮想環境の作成

pyenvを使っている場合

$ mkdir PROJECT_DIR
$ cd PROJECT_DIR
$ pyenv local 3.10.12
$ python --version
Python 3.10.12
$ pipenv --python 3.10.12
Creating a virtualenv for this project...
Pipfile: /Users/LOGNAME/PROJECT_DIR/Pipfile
Using /Users/LOGNAME/.anyenv/envs/python/3.10.12/bin/python3 (3.10.12) to create virtualenv...
⠸ Creating virtual environment...created virtual environment CPython3.10.12.final.0-64 in 1593ms
....    ....
....    ....

✔ Successfully created virtual environment!
Virtualenv location: /Users/LOGINUSER/PROJECT_DIR/virtualenvs/.venv
Creating a Pipfile for this project...

asdfを使っている場合

$ mkdir PROJECT_DIR
$ cd PROJECT_DIR
$ asdf local python 3.10.12
$ python --version
Python 3.10.12
$ pipenv --python 3.10
Creating a virtualenv for this project...
Pipfile: /Users/LOGNAME/PROJECT_DIR/Pipfile
Using /Users/LOGNAME/.asdf/installs/python/3.10.12/bin/python3 (3.10.12) to create virtualenv...
⠸ Creating virtual environment...created virtual environment CPython3.10.12.final.0-64 in 1593ms
....    ....
....    ....

✔ Successfully created virtual environment!
Virtualenv location: /Users/LOGNAME/.local/share/virtualenvs/PROJECT_DIR-zadK1Q9j
Creating a Pipfile for this project...

仮想環境が作成されると、Pipefileというファイルが作成される。この中にインストールしたパッケージ情報が記述される。

また、以下の環境変数を設定しておくと、プロジェクトディレクトリの中に.venvというディレクトリが作成され、仮想環境のPythonインタープリタおよびパッケージはこの中にインストールされる。

export PIPENV_VENV_IN_PROJECT=true

仮想環境の削除

$ cd PROJECT_DIR
$ pipenv --rm

pipenvによるパッケージ管理

パッケージの追加

$ pipenv install PACKAGE_NAME

開発用パッケージの追加

$ pipenv install --dev PACKAGE_NAME

パッケージの削除

$ pipenv uninstall PACKAGE_NAME

pipenvによるPythonプログラム実行

仮想環境によって直接プログラムを実行

$ pipenv run python PROGRAM.py

仮想環境を起動して、プログラムを実行

$ pipenv shell
$ python PROGRAM.py

プロジェクトのパッケージ管理

PipfilePipfile.lockの存在するプロジェクトで(使用バージョンの)パッケージをインストールする

$ pipenv sync

Pipfileから(最新バージョンの)パッケージをインストールする

$ pipenv install

Pipfileからパケージをインストールし、アップデートがあればアップデートする

$ pipenv update 

requirements.txtを作成する

$ pipenv lock -r > requirements.txt

requirements.txtを利用してパッケージをインストールする

$ pipenv install -r requirements.txt

Stable Diffusion Web UI | SageMaker無料プランを利用して画像生成

GPU搭載ノートPCにStable Diffusion Web UIを導入して本格的に画像生成をやり始めた。

外出中も画像生成がやりたくて、そこそこ重量(GPU搭載機は大抵2kg強)のあるノートPCを持ち歩いたりしている。しかし、やはり重さには耐えられられず、長時間の外出には軽量ノートPCしか持っていかなかったする。

Google ColabのGPUリソースを利用して画像処理や機械学習プログラムを作ったりしたことはあったが、いままで画像生成には使ったことはなかった。Google Colabの無料プランでは最近Stable Diffusion Web UIの使用に制限がかけられるようになって、10分位使うと警告が表示されるようになったそうだ。この警告を無視してそのままを使い続けると、アカウントが停止されてしまうんじゃないだろうか。

Google ColabでStable Diffusion Web UIを動かして画像生成を行う方法が掲載されているサイトがあるが、現在無料プランではこの方法は使えないので、やりたかったら有料プランに移行するしかない。小生もこれからGoogle Colabで画像生成をやってみよう思っていた矢先に、この情報を知った。

そこで、Google Colab無料プランに代わる方法を探してみたら、Amazon SageMaker Studio Lab(SageMaker Studio無料プランの名前)でGPUリソースを使えることを知った。これとngrokというサービスを組み合わせると、SageMakerを利用してStable Diffusion Web UIによる画像生成ができるらしい。さっくこの方法を試してみた。

SageMaker Studio Labのアカウント作成

現状SageMaker Studio Labのアカウトはリクエスト方式で作成するらしい。

下のサイト画面の[Request free account]を押して、開いた画面にメールアドレスと要求されている情報を入力すればアカウント作成申請が出せる。

実際にやってみると、小生の場合は、アカウント作成申請を出してから24時間で申請認可メールが送信されてきた。

アカウント申請認可メールに記載されているリンクにアクセスすると、SageMaker無料プランの新しいアカウントを作成することができる。

ngrokのアカウント作成

ngrokというのは、ローカルPC上で稼働しているHTTPサーバーを外部公開できるサービスだ。無料と有料プランあるが、無料プランでも十分な機能が使えて、今回の目的に問題なく利用できる。

ngrok.com

ngrokのサイトのトップ画面から[Sign up for free]を押して、開いた画面に必要な情報を入力すればアカウントを作成できる。

ngrokのアカウントを作成したら、Authtokenというものを記録しておく。これがngrokのサービスを利用するためのAPIトークンになる。

SageMaker版Stable Diffusion Web UIノートブックの作成

SageMaker StudioはJupyter Notebookを使ってPythonプログラムを実行できるサービスだが、SageMaker用のStable Diffusion Web UIノートブックを公開掲載しているサイトがある。

github.com

このGitHubページに掲載されているノートブックを利用すると、簡単にSageMaker上でStable Diffusion Web UIを実行することができる。

このページのSageMaker用ノートブックはモデル別に分かれており、一つの作者モデルとStable Diffusion Web UIを組み合わせた全部で150超もの種類が用意されている。HunggingFaceとCivitai上の有名なモデルがほぼ網羅されており(逆に、このサイトに掲載されているモデル名をCivitaiで検索することで、どんなモデルが有名で良く利用されているのか知ることができた)、この中から好みのモデルが組み込まれたものを選んでノートブックを作成すると、そのモデルを使った画像生成がすぐに始められようになっている。ここまでやってくれるのは素晴らしいことだ。感謝の意を表しながら、有り難く使わせてもらおう。

本ページ上の適当なモデルのノートブックを選んで、その右側の[nightly]というリンクをクリックする。

すると、SageMakerのサイトへ移動して下のような画面になる。この画面の[Compute type]GPUを選んで[▶ Start runtime]を押すと、GPUインスタンスが開始される。GPUインスタンスが開始されると、[Copy to project]が押せる状態になる。

ただし、[▶ Start runtime]を押しても、警告が表示されてGPUインスタンスが開始されないときがある。利用ユーザーが多くGPUインスタンスに空きがないとこうなるのだろう。この場合は、しばらく待ってから何回か上の操作を繰り返すと、GPUインスタンスを取得できるようだ(ただし、時間帯によっては何度トライしてもGPUインスタンスを取得できないときがある。その場合は、数十分待ってから再度トライしてみると良い)。

上の画面の[Copy to project]を押すと、続いて下のような画面が表示されるので、ここでは[Copy Notebook Only]という選択肢をクリックする。

さらに、下の画面が表示されたら、そのまま[Select]を押す。

すると、新しいノートブックが作成されて、その中に上述のGitHubページで選択したリンク元のソースがコピーされる。

SageMaker版Stable Diffusion Web UIノートブックの実行

SageMaker上にノートブックが開いたら、その中のソースコードの一番下の行に"enter_ngrok_authtocken_here"という記述があるので、これを前述のngrokのAuthtokenの値に置き換える。

ここまでの操作が済んだら、本画面上部のボタンを押せば、このノートブックが実行される。

数分待つと、下のようなhttps:/**********.ngrok-free.appというリンクが存在するメッセージが表示されるので、このリンクをクリックする。

すると、下のような画面が表示される。

この画面の[Visit Site]ボタンを押すと、ブラウザ上にStable Diffusion Web UIの画面が起動する。あとは、この画面を使って画像生成を行うことができる。

補足情報

SageMaker上でStable Diffusion Web UIのノートブックを実行したときに、下のようなエラー・メッセージが表示されてノートブックが停止することがある。

TypeError: __init__() got an unexpected keyword argument 'socket_options'

その場合は、ノートブック内のソースコードに以下のような一行を追加して、再度ノートブックを実行すると解決できる。

  !mkdir /home/studio-lab-user/content
  %cd /home/studio-lab-user/content

  %env TF_CPP_MIN_LOG_LEVEL=1

  %conda install -q -y aria2
  %conda install -q -y libglib2.0-0
  %conda install -q -y glib
  %pip install -q opencv-python-headless huggingface-hub
  !pip install -q torch==2.0.0+cu118 torchvision==0.15.1+cu118 torchaudio==2.0.1+cu118 torchtext==0.15.1 torchdata==0.6.0 --extra-index-url https://download.pytorch.org/whl/cu118 -U
  !pip install -q xformers==0.0.18 triton==2.0.0 -U
+ !pip install -q httpx==0.24.1 -U

  !git clone -b v2.2 https://github.com/camenduru/stable-diffusion-webui
  ....    ....
  ....    ....
  ....    ....
  ....    ....

SageMaker版Stable Diffusion Web UIノートブックの停止

Stable Diffusion Web UIを使い終わったら、実行中のノートブック・セッションを停止するのを忘れないようにしよう。

ブラウザ上にSageMakerのセッション開始画面が残っているなら、それを表示させる。あるいは、ノートブック画面からメニュー[Amazon SageMaker Studio Lab][Open Project Overview Page]を選ぶと同じ画面が開くので、この中の[■ Stop runtime]を押すと、現在のセッションが停止される。

こうしておくと、残りのセッション時間分は後でまた続けて使うことができる。1回のセッションで最大4時間、24時間で合計4時間使用可能だ(少し前まで合計8時間だったらしい)。

SageMaker版Stable Diffusion Web UIにモデルを追加する方法

SageMaker無料プランには15GBの永続ストレージが付属している。

15GBでは複数のモデルを一度に使い分けるのは無理があるが、SageMaker用Stable Diffusion Web UIノートブックのファイル構成はオリジナルと同じなので、モデルファイルをコピーしてやればモデルを追加することはできる。

SageMakerノートブックの左上のフォルダ・マークをクリックすると左側にファイルビュー・パネルが開くので、ここでディレクトリをcontent/models/Stable-diffusionと辿って、ファイルビューの中にモデルファイルをドラッグするか、あるいは本画面上部の上向き⬆ボタンをクリックして、モデルファイルを選択してやればコピーできる。

追加したモデルを利用するには、本画面上部のを押して一旦を停止させてもう一度ボタンを押してノートブックを再起動するか、あるいはStable Diffusion Web UI画面の[Stable Diffusion checkpoint]メニュー横の更新ボタンをクリックすれば選択できるようになる。

一つのモデルファイルのサイズは大体2〜10GB位なので、追加できたとしても全部で2〜3個のモデルが限界ではないだろうか。生成作成される画像分のストレージ空き容量も考慮する必要があるので、モデルを変更したければ、既存のモデルファイルを削除して新しいものをコピーした方が良い。

 

本記事の方法を使えば、(画像生成処理を実行しているのはSageMakerのGPUインスタンスなので)低スペックなPCでも画像生成を行うことができる。外出中にインターネットが利用できる場所で数時間の空きがあったら、そのときに画像生成をやることができる。手軽に始められるのにStable Diffusion Web UIが使えるので、いまのところこの方法が気に入っている

現在はSageMakerのGPUインスタンスを取得するのに、それほど待たされない状況だ。しかし、SageMakerの無料プランでGPUリソースの利用者が増えてくると、さらにセッション時間が減ったり、将来Google Colabの無料プランと同じように制限される可能性もあるかもしれない。クラウドGPUリソースを使って本格的に画像生成をやるなら、やはりいずれかのコンピューティングサービスの有料プランを利用する方が良いのだろう。

【参照リンク】

note.com

Stable Diffusion Web UI|Ubuntu 22.04でのインストール

前記事でEasy Diffusionというものを紹介したが、同様のプログラムとしてStable Diffusion Web UIというのがある。

blog.ketus-ix.work

じつは、Stable Diffusionを利用して画像生成をやるなら、こちらが本命のプログラムだ。画像生成処理に適用できる数多くのパラメータが用意されており、それらを調整することで多種多様な画像を生成できる。インターネット上での使い方などの情報量が多く、モデル配布サイトでもこのStable Diffusion Web UI用のパラメータ設定値が記載されていることが多い。

お触り入門的にやるなら、Easy Diffusionでも良いと思うが、本気でStable Diffusionによる画像生成をやるなら、現状このAUTOMATIC1111版Stable Diffusion Web UIの一択だと言って良いほど広く使われている。

github.com

このStable Diffusion Web UIをUbuntu 22.04上にインストールして使い始めたので、自分の備忘録も兼ねて、その手順を書いておく。

NVIDIA GPUドライバのインストール

前記事では、CUDA ToolkitとcuDNNのインストール方法の説明は省略したが、本記事では書いておこう。

ただし、この2つは後述のAnacondaやMinicondaを使って作成したPython仮想環境の中にインストールすることもできる。システム側のCUDA,cuDNNとは分離された環境となるので、この方が融通性が高い(システム側のCUDA,cuDNNは別のソフトウェアの開発用に使っているので、弄るのは避けたかったという理由もある)。今回はこの方法を使った。

このような環境を作るのための条件として、システム側にNVIDIA GPU用ドライバがインストールされている必要がある。同ドライバがまだインストールされていない場合(nvidia-smiコマンドで確認できる)は、以下の操作によってインストールすることができる。

ubuntu-drivers devices
== /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.0 ==
modalias : pci:v000010DEd0000249Csv00001043sd00001602bc03sc00i00
vendor   : NVIDIA Corporation
model    : GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB]
driver   : nvidia-driver-545 - third-party non-free
driver   : nvidia-driver-525-open - distro non-free
driver   : nvidia-driver-470-server - distro non-free
driver   : nvidia-driver-535-server - distro non-free
driver   : nvidia-driver-535-open - distro non-free
driver   : nvidia-driver-525-server - distro non-free
driver   : nvidia-driver-520 - third-party non-free
driver   : nvidia-driver-470 - third-party non-free
driver   : nvidia-driver-535-server-open - distro non-free
driver   : nvidia-driver-545-open - third-party non-free recommended
driver   : xserver-xorg-video-nouveau - distro free builtin
  

GPUの種類にもよるが、大抵はrecommendedとして最新バージョンが推薦されるはずだ。CUDAやcuDNNを利用する場合は、この推薦されているバージョンの-openでない方を選択する。

つまり、上のような出力情報なら、nvidia-driver-545をインストールするべきだ。

sudo apt install nvidia-driver-545
reboot

nvidia-driverをインストールしたら、システムを再起動しておく。

Stable Diffusion Web UI用Python仮想環境の作成

Minicondaのインストール

Stable DiffusionはPythonで記述されたプログラムなので、稼働ベースとしてPython仮想環境を利用するケースが多い(システム側のPythonを使うのは避けた方が良い)。

Python仮想環境ツールにはいくつかの種類があるが、Stable Diffusionを使うときに広く利用されているのはAnacondaやMinicondaなどのconda系仮想環境のようだ。

ここでは、Minicondaを使うことにする。

curl https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -o Miniconda3-latest-Linux-x86_64.sh
chmod +x Miniconda3-latest-Linux-x86_64.sh
./Miniconda3-latest-Linux-x86_64.sh

なお、言語環境ツールとしてpyenvやasdfを利用している場合は、以下のコマンドによってMinicondaをインストールすることができる。

  • pyenv
pyenv install miniconda3-latest
pyenv global miniconda3-latest
asdf install python miniconda3-latest
asdf global python miniconda3-latest

Python仮想環境の作成

Stable Diffusion Web UI用の仮想環境を作成する。仮想環境の名前は任意で良いが、ここではsdwebuiとしておく。

conda deactivate
conda create --name sdwebui python=3.10
conda activate sdwebui

CUDAとcuDNNのインストール

作成した仮想環境の中にCUDAとcuDNNをインストールする。

conda install -c conda-forge cudatoolkit=11.8.0
pip install nvidia-cudnn-cu11==8.6.0.16

さらに、CUDAとcuDNNライブラリへのパスを通すために、以下のような設定を追加する。

mkdir -p $CONDA_PREFIX/etc/conda/activate.d
echo 'CUDNN_PATH=$(dirname $(python -c "import nvidia.cudnn;print(nvidia.cudnn.__file__)"))' > $CONDA_PREFIX/etc/conda/activate.d/env_vars.sh
echo 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CONDA_PREFIX/lib:$CUDNN_PATH/lib' >> $CONDA_PREFIX/etc/conda/activate.d/env_vars.sh

上の操作が済んだら、この仮想環境を再起動する。

conda deactivate
conda activate sdwebui

Stable Diffusion Web UIのインストール

インストール

上記でcondaコマンドによって作成したPython仮想環境上にStable Diffusion Web UIをインストールするので、この仮想環境がアクティブ状態になっていることが、同プログラムのインストールおよび起動条件となる。もし仮想環境がアクティブ状態になっていない場合は、上で作成した仮想環境をconda activate sdwebuiコマンドによってアクティブ状態にしておく。

Stable Diffusion Web UIのインストールは、以下のように、ソースを取得した上でシェルスクリプトwebui.shを実行すれば開始できる。

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
cd stable-diffusion-webui
./webui.sh

インストール処理が完了すると、自動的にブラウザが起動して、その中に下のような画面が表示される(ベージURLは127.0.0.1:7860)。

補足情報

COMMANDLINE_ARGSの設定

GPUを利用した画像生成処理の高速化が図れるxFormersを有効にする場合、ファイルwebui-user.shを以下のように編集する。

vi webui-user.sh
-#export COMMANDLINE_ARGS=""
+export COMMANDLINE_ARGS="--xformers"

Stable Diffusion公式でもこの機能を有効することが推薦されており、確かにGPU搭載機では画像生成が速くなるので、NVIDIA GPU搭載機の場合はデフォルトでこの機能を有効にした方が良い。

GPU VRAMが4GBより小さい場合は、COMMAND_ARGS=の設定を下のようにすると、画像生成処理でVRAMメモリがより効率的に使われる。

COMMAND_LINE_ARGS="--xformers --medvram --opt-split-attention"

GPU VRAMが8GBより小さい場合は、同設定を下のように変更すると、画像生成処理でVRAMメモリがより効率的に使われる。

COMMAND_LINE_ARGS="--xformers --lowvram --opt-split-attention"

webui.shによるインストールの結果、PyTorch 2.0以降が追加された場合(webui.sh起動時の出力情報、またはpip listコマンドで確認できる)は、以下にように変更することで、--xformersと同等の画像生成処理の高速化が図れる。

-export COMMANDLINE_ARGS="--xformers"
+export COMMANDLINE_ARGS="--opt-sdp-attention --opt-sdp-no-mem-attention"

現在、小生のGPU搭載機ではこの設定を使っているが、この辺の設定はStable Diffusion Web UIのバージョンによって違ってくるので、あくまでこれは参考情報として見てほしい。

Cannot locate TCMalloc警告の解決

シェルスクリプトwebui.shを実行すると、Cannot locate TCMalloc (improves CPU memory usage)という警告メッセージが表示されるが、下のコマンドによってTCMalloc(GoogleC/C++用メモリアロケータ)をインストールすれば、これを回避できる。

sudo apt install --no-install-recommends google-perftools

仮想環境の自動起動

シェルスクリプトwebui.shによるStable Diffusion Web UIの起動時に、自動的に仮想環境を起動したいなら、以下をwebui-user.shの先頭に追加しておく。

#!/bin/bash
eval "$(conda shell.bash hook)"
conda activate sdwebui

Stable Diffusion Web UIの動作確認

Stable Diffusion Web UIの初歩的な使い方はEasy Diffusionと似ている。

説明文だけから画像を生成する場合は、[txt2img]タブ画面上のテキストボックスにプロンプト文を入力して、[Generate]ボタンを押す。モデルから画像を生成したい場合は、[Stable Diffusion checkpoint]メニューからモデルを選んで、同タブ画面上のテキストボックスにプロンプト文を入力してした上で、[Generate]ボタンを押すと、画像の生成が開始される。

モデルファイルをディレクトstable-diffusion-webui/models/Stable-diffusionへコピーして、Stable Diffusion Web UIを再起動するか、[Stable Diffusion checkpoint]メニュー横の更新ボタンを押せば、追加したモデルが選択できるようになる。

プロンプト用のテキストボックスが2つあるが、上側が生成したい画像の説明、下側が生成したい画像に対する否定的な説明を入力する。両方のプロンプト文を入力すると、より目的に合った画像が生成されやすくなるようだ。

前記事と同じように、適当に選んだモデルを使って、Stable Diffusion Web UIによる画像の生成をやってみた。お借りしたモデルとプロンプトはこちら。

civitai.com

civitai.com

【追記】〔2023-12-04〕

Intel MacにもStable Diffusion Web UIをインストールしてみた。インストールは問題なくできて(NVIDIA GPUドライバ、CUDA、cuDNNは当然インストールしていないが)、画像の生成もできることはできる。

ただし、やはり画像生成に時間がかかってしまう。上と同じ条件で画像を生成してみたが、1分40秒かかってしまった。NVIDIA GPU搭載機(VRAM 16GB)では2秒だから、この差は大きい。

小生はまだM1/M2 Macを持っていないんだけど、これらだと画像生成がもっと速くなるんだろうか。もし生成時間が1分以内になるのなら、M1/M2 Macでも画像生成を本格的にやれると思う。 やっぱり早くApple Silicon Macを手に入れないとダメだなぁ。

【参照サイト】

https://blog.csdn.net/weixin_41216652/article/details/131995014blog.csdn.net

pywkt.com

Easy DiffusionによるStable Diffusion画像生成ことはじめ

いま流行りの生成系AIについに手を出し始めた。生成系AIで一番やってみたかったのは画像・動画の生成なので、Stable Diffusionを使ってみることから始めた。

オープンソースのStable Diffusionを利用した画像生成プログラムがいくつか存在するが、その中からEasy Diffusionというものを選択して動かしみた。

easydiffusion.github.io

GPU搭載ノートPCとIntel Macの両方で試してみた。

ちなみに、前者のスペックは以下のとおり。

 CPU : AMD Ryzen 9 5900HX(コア数 8,スレッド数 16)
    動作周波数(標準/最大):3.3GHz/4.6GHz
 メモリ : 32GB
 GPU : NVIDIA GeForce RTX 3080 Max-Q VRAM 16GB

なお、NVIDIA GPU搭載機ではあらかじめCUDA ToolkitとcuDNNをインストールしておく必要があるが、これらについては説明を省略する。

Easy Diffusionのインストール

Easy Diffusionのインストールはすごく簡単だ。

ダウンロードしたzipファイルを解凍して、作成されたディレクトリの中でstart.shというシェルスクリプトを実行するだけだ。

cd easy-diffusion
./start.sh

このシェルスクリプトPython仮想環境、Pythonライブラリ、Stable Diffusion本体、モデルファイルなどすべてのコンポーネントのインストールをやってくれる。

Easy Diffusionの動作確認

上記のシェルスクリプトによるインストールが完了すると、自動的にブラウザが起動して、そこに下のようなEasy DiffusionのUI画面が表示される(ベージURLはlocalhost:9000)。

[Enter Prompt]テキストボックスに生成したい画像について説明する文言を入力して、[Make Image]ボタンを押せば画像の生成が開始される。

上述スペックのGPU搭載機だと、サイズ512x512 1枚のみの画像の生成に4秒位だが、Intel Mac(CPU:Core i9 2.9GHz 6コア/12スレッド,メモリ:32GB)だと4分位かかる。あらかじめ判っていたことだが、画像生成AIの利用にはGPUが必須だと言えるだろう。

Easy Diffusionのモデル適用方法

最近多くのサイトで観られるリアル系美女、コスプレ、アニメ調などのAI画像は元となるモデルファイルを利用して、それをStable Diffusionなどの画像生成AIに適用することで作成されている。

こういう画像生成AI用モデルを配布しているサイトがいくつかあるが、その中で一番有名なのがCivitaiだ。このサイトから適当に選んだモデルを入手して、Easy Diffusionを使って画像の作成をやってみた。

civitai.com

上のモデル・ページ内の[ V1.5 - Pruned ]というのを選択してダウンロードしたファイルaniverse_v15Pruned.safetensors(約2.0GB)をディレクトeasy-diffusion/models/stable-diffusionへコピーして、Easy Diffusionを再起動するか、後述の[Model]メニュー横の更新ボタンを押すと、追加したモデルの選択が可能になる。モデルの変更は[Generative]タブ画面内の[Image Settings][Model] メニューによって切り替えることができる。

プロンプト文はモデルのページに掲載されているいくつかの例から選んだが、これを工夫することで、自分の目的に合った画像を生成することもできるようになるのかもしれない。画像生成AI用のプロンプト文が掲載されているサイトもたんさん存在している。

しかし、このように自分で作成した画像を晒してしまうと、観た人にその人の嗜好が想像できてしまうなぁ。

いま画像生成AIが大流行しているのは、こういうモデル配布やプロンプト掲載サイトの出現によって、誰でも高品質なAI画像を手軽に作成できるようになったことも影響しているのだろう。

画像生成AIを始めた目的はこの方面で稼ぐ方法を見つけられたらと思っているからだ。ディープラーニング開発の経験はあるので、本気でやればStable Diffusionなどの学習・生成ネットワークモデルを深く理解できる自信はある。その知見からモデルのカスタマイズまでできるようになれば、他の人とは違った画像を作成できるようになれるかもしれない。

動画・絵師クリエーターへの憧れもあったので(技能やセンスがないので諦めていたが)、AIの力を借りているとしても画像生成をやるのはすごく楽しい。これから、しばらく画像生成AIの研究に集中して取り組んでいき、最終的に自分のセンスが反映された画像や動画を作成できるようになりたい。

【参照サイト】

relax-tech.net

LimaによるDocker Desktop代替環境の構築

最近Node.js + ExpressやPython + FastAPIなどを使って、サーバー・プログラムを作ることが多くなってきた。

サーバー・プログラムを作るときは、Dockerを利用するかどうかでぜんぜん作業効率が違ってくる。

小生のメインPCはMacなので、いままでMac版Docker Desktopを使っていたが、Docker Desktopの商用利用には「一定規模以上の企業で利用する場合有料サブスクリプションが必要」という制限がある。

いまやサーバー・プログラム開発にはDockerは欠かせない存在なので、Docker Desktopに代わる別の方法を探していたらLimaというものを見つけた。

github.com

LimaはQEMUベースの仮想マシン・ツールで、Dockerに代わる仮想マシン環境として利用すると、Docker Desktopを利用しなくてもDockerコンテナを扱うことができるようになる。

本記事では、Limaを利用したDocker環境の構築方法を紹介しよう。ただし、いまのところMacでしかLimaを利用していないので、Mac限定の内容で書いておく。

LimaおよびDockerのインストール

% brew install lima

Dockerコンテナの作成や操作のためにdockerコマンドは利用するので、dockerバッケージはインストールしておく必要がある。

% brew install docker

docker-composeを利用する場合は、それもインストールする。

% brew install docker-compose

LimaによるDocker仮想マシンのインストール

下のコマンドによって、Dockerエンジンとなる仮想マシンをインストールできる。

% limactl create --name=default template://docker

これがDocker Desktopに含まれているdockerデーモンに代わるものとなる。

limactl createコマンドによってインストールした仮想マシンは停止状態となっている。

% limactl list
NAME       STATUS     SSH            VMTYPE    ARCH      CPUS    MEMORY    DISK      DIR
default    Stopped    127.0.0.1:0    qemu      x86_64    4       4GiB      100GiB    ~/.lima/default

この仮想マシンを起動するには、下のコマンドを実行すれば良い。

% limactl start
% limactl list
NAME       STATUS     SSH                VMTYPE    ARCH      CPUS    MEMORY    DISK      DIR
default    Running    127.0.0.1:60022    qemu      x86_64    4       4GiB      100GiB    ~/.lima/default

コマンドlimactl createではなくlimaclt start --name=default template://dockerを使うと、Docker仮想マシンのインストールと起動まで同時に行える。

Docker仮想マシンが起動状態だとCPUパワーを消費するので、Dockerコンテナを利用しないときは、limactl stopコマンドによって停止しておいた方が良いだろう。

あとは、dockerコマンドを使ってDockerイメージの生成やコンテナの起動などの操作が行える。

Lima Docker仮想マシンのリソース制限変更

Dockerコンテナの内容によっては、Docker仮想マシンの使用リソース制限を拡張しないとビルドできないときがある。

下の一連の操作によって、Docker仮想マシンのリソース制限値を変更することができる。

% limactl stop default
% limactl list
NAME       STATUS     SSH            VMTYPE    ARCH      CPUS    MEMORY    DISK      DIR
default    Stopped    127.0.0.1:0    qemu      x86_64    4       4GiB      100GiB    ~/.lima/default
% limactl delete default
% limactl create  --cpus=6 --memory=8 --disk=800 --name=default template://docker
% limactl list
NAME       STATUS     SSH            VMTYPE    ARCH      CPUS    MEMORY    DISK      DIR
default    Stopped    127.0.0.1:0    qemu      x86_64    6       8GiB      800GiB    ~/.lima/default
% limactl start default

Lima Docker仮想マシンとDocker Desktopの共存

LimaのDocker仮想マシンを利用するならDocker Desktopをアンイストールできるが、Docker Hub閲覧機能などを利用したくてこれを残したい場合もあるだろう。

Docker Desktopに含まれているdockerデーモンの起動状態は、下のコマンドによって知ることができる。

% docker context list
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT                                      KUBERNETES ENDPOINT   ORCHESTRATOR
default             moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux       moby                Docker Desktop                            unix:///Users/LOGNAME/.docker/run/docker.sock
lima-default *      moby                                                          unix:///Users/LOGNAME/.lima/default/sock/docker.sock

Lima Docker仮想マシンが稼働している状態では上のようになっているが、Docker Desktopを起動すると、これは下のような状態に変わる。

% docker context list
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT                                      KUBERNETES ENDPOINT   ORCHESTRATOR
default             moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux *     moby                Docker Desktop                            unix:///Users/LOGNAME/.docker/run/docker.sock
lima-default        moby                                                          unix:///Users/LOGNAME/.lima/default/sock/docker.sock

dockerコマンドの実行時に使われるデーモンは、このdockerコンテキストによって管理されている。

下のコマンドを実行すると、dockerコマンドの実行時に使わるコンテキストはLima Docker仮想マシンになる。

% docker context use lima-default

これをDocker Desktop側のdockerデーモンに変える場合は、下のコマンドを実行する。

% docker context use desktop-linux

なお、Lima Docker仮想マシンを利用して作成したDockerイメージとDocker Desktopのdockerデーモンによって作成したイメージは別々に管理されている。前者のイメージをDocker Desktopで見ることはできないし、後者のイメージをlima-defaultコンテキスト有効時のdocker imagesコマンドで見ることもできない。

【参照リンク】

lima-vm.io

nopipi.hatenablog.com

stella_vslam | Dockerによるビルドと動作確認〔Mac編〕

前記事で行ったDockerによるstella_vslamのビルドを動作確認をMac上でもやってみた。

blog.ketus-ix.work

結論から先に書くと、PangolinViewer版stella_vslamはビルドはできるが動作させることはできなかった。

stella_vslamのドキュメントサイトにもMacはNGだと記載されている。

stella-cv.readthedocs.io

SocketViewer版stella_vslamはビルドも動作確認も問題なくできる。ただし、Dockerコンテナの起動方法がUbuntuの場合とは異なっている。

PangolinViewer版stella_vslamはNGだが、記録として、作業内容を書いておく。

PangolinViewer版stella_vslamのビルドと動作確認

Dockerイメージのビルド

前記事のコマンドによって、PangolinViewer版stella_vslam Dockerイメージのビルドは問題なくできる。

ただし、Docker Engineのメモリ・リソース制限をデフォルト値より大きくしておく必要がある。Docker Desktopの場合は、下の画面からその設定値を変更できる。

おおよそ14GB以上なら、本Dockerイメージをビルドできるようだ。

Dockerコンテナの起動

当然ながら、ビルド生成したDockerコンテナの起動は問題なくできる。本コンテナを起動するコマンドは前記事と同じ。

Dockerコンテナの動作確認

PangolinViewer版stella_vslamはX GUIを利用しているプログラムなので、MacにもX Window Systemが必要だ。MacX Window System XQuartzがインストールされていることが前提条件となる。

X GUI利用DockerコンテナをMac上で起動する方法が下のリンクにまとめられている。

blog.aoirint.com

このページに記載されているすべての方法を試したが、ダメだった。

コンテナ内のstella_vslamプログラムがホスト側Xディスプレイの存在を認識できても、ほとんんどのケースで下のようなエラーが出力されて停止してしまう。

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X11 Error: BadValue (integer parameter out of range for operation)
terminate called after throwing an instance of 'std::runtime_error'
  what():  Pangolin X11: Failed to create an OpenGL context

MacOpenGLリダイレクトを有効にする下のコマンドを実行済みの状態でもダメだ。

% defaults write org.macosforge.xquartz.X11 enable_iglx -bool true

もしかすると、stella_vslam側で使われているOpenGLMac側の同バージョンが関係しているのかもしれない。

上の参照ページに記載されている各方法を試した際のstella_vslamプログラムの挙動を観ていると、「socatを使う方法(UnixソケットをTCPにリレーする方法)」が上手くいく可能性が高そうな感触はあるんだけど。

DockerコンテナのXディスプレイ出力先をMacホストではなく仮想マシンなどの他のPCへリダイレクトすると動くかもしれないが、それではMac上で動いているとは言えないだろう。

また時間があったら、本問題にトライしてみようと思っている。

SocketViewer版stella_vslamのビルドと動作確認

Dockerイメージのビルド

前記事のコマンドによって、SocketViewer版stella_vslam Dockerイメージ(stella_vslam本体とsocket-viewer)のビルドは問題なくできる。

Dockerコンテナの起動

socket-viewer

% docker run --rm -it --name stella_vslam-viewer -p 3001:3001 stella_vslam-viewer
WebSocket: listening on *:3000
HTTP server: listening on *:3001

Macでsocket-viewerを起動する場合は、-p 3001:3001オプションを付加してコンテナを起動する。これは、DockerコンテナのTCPポートをホスト側へポートフォワードする設定だ。

ここで、Webブラウザからhttp://localhost:3001/へアクセスする。

そして、socket-viewerコンテナが起動している状態で下のコマンドを実行する。

% docker inspect stella_vslam-viewer | grep -m 1 \"IPAddress\" | sed 's/ //g' | sed 's/,//g'
"IPAddress":"172.17.0.2"

このコマンドによって、socket-viewerコンテナのIPアドレスを知ることができる。

stella_vslam本体

stella_vslam本体コンテナは以下のコマンドによって起動する(--net=hostオプションは不要)。

% docker run --rm -it --name stella_vslam-socket \
    --volume ~/VSLAM/Docker/stella_vslam/vocab:/vocab:ro \
    --volume ~/VSLAM/Docker/stella_vslam/dataset:/dataset:ro \
    stella_vslam-socket
root@f3eb6409feb7:/stella_vslam_examples/build# 

Dockerコンテナでの動作確認

stella_vslam本体コンテナ(stella_vslam-socket)が起動したら、下のコマンドを実行する。

  • コンテナ stella_vslam-socket
# ls /
bin   dataset  etc   lib    lib64  ...   ...   ...   stella_vslam           sys   usr   vocab
...   ...   ...   ...   ...  ...   ...   ...   ...   stella_vslam_examples  tmp   var
# echo -e "SocketPublisher:\n  server_uri: \"http://172.17.0.2:3000\"" >> /stella_vslam/example/aist/equirectangular.yaml
# cat /stella_vslam/example/aist/equirectangular.yaml
....    ....
....    ....
SocketPublisher:
  server_uri: "http://172.17.0.2:3000"

これは、stella_vslamのコンフィグレーションファイルにsocket-viewerコンテナ(stella_vslam-viewer)のURIIPアドレスとWebSocketサーバーのポート番号)設定値を追加している。

上の操作が済んだら、同コンテナ内でstella_vslamプログラムを起動すれば、Webブラウザのウィンドウにグラフィック描画画面が表示されるはずだ。

  • コンテナ stella_vslam-socket
# At the /stella_vslam_examples/build directory
# pwd
/stella_vslam_examples/build
# ls /
bin   dataset  etc   lib    lib64  ...   ...   ...   stella_vslam           sys   usr   vocab
...   ...   ...   ...   ...  ...   ...   ...   ...   stella_vslam_examples  tmp   var
# ./run_video_slam \
    -v /vocab/orb_vocab.fbow \
    -m /dataset/aist_living_lab_1/video.mp4 \
    -c /stella_vslam/example/aist/equirectangular.yaml \
    --frame-skip 3 \
    --no-sleep \
    --map-db-out map.msg \
    --viewer socket_publisher

-cオプションで指定するコンフィグレーションファイルは、上記の操作で書き換えたものでなければならない。

stella_vslam | Dockerによるビルドと動作確認

以前の記事でUbuntu 20.04上でのstella_vslamのビルドと動作確認を行ったが、stella_vslam用のDockerfileが在るので、Dockerを使ったビルドと動作確認もやってみた。

blog.ketus-ix.work

stella_vslamのドキュメントサイトに記載されている内容とほとんど同じだが、自分の備忘録として記事に書いておく。

stella-cv.readthedocs.io

以降の作業は、Ubuntu 20.04上でDocker-CE 24.0を使って行った。

Dockerのインストール

Dockerが導入済みでない場合は、インストールしておくこと。

NVIDIA GPU搭載PCの場合は、nivida-dockerもインストールしておくと、DockerコンテナでGPUが利用されるので動作速度が向上する。

stella_vslamのGitHubリポジトリから取得したファイルの中に、Dockerをインストールできるシェルスクリプトが収納されている。

Ubuntu上にDockerが未インストールの場合は、これらのシェルスクリプトを利用すると良い。

$ git clone --recursive https://github.com/stella-cv/stella_vslam.git
$ cd stella_vslam/scripts/ubuntu
$ ./install_docker.sh
# GPUを利用する場合は、下のコマンドも実行する
$ ./install_nvidia_docker.sh

サンプルデータセットの取得

stella_vslamのDockerコンテナ内で動作確認に使用するサンプルデータセットをダウンロードしておく。

この操作用のシェルスクリプトがstella_vslamのリポジトリに含まれている。

$ git clone --recursive https://github.com/stella-cv/stella_vslam.git
$ cd stella_vslam/scripts/ubuntu
$ ./download_sampledata.sh

PangolinViewer版stella_vslamのビルドと動作確認

Dockerイメージのビルド

$ mkdir -p ~/VSLAM/Docker
$ cd ~/VSLAM/Docker
$ git clone --recursive https://github.com/stella-cv/stella_vslam.git
$ cd stella_vslam
$ docker build -t stella_vslam-desktop -f Dockerfile.desktop . --build-arg NUM_THREADS=`expr $(nproc) - 1`

Dockerコンテナの起動

# ログインユーザからのX11ディスプレイへのアクセスを許可
$ xhost +local:
# コンテナの起動
$ docker run -it --rm -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix:ro \
    --volume ~/VSLAM/Docker/stella_vslam/vocab:/vocab:ro \
    --volume ~/VSLAM/Docker/stella_vslam/dataset:/dataset:ro \
    stella_vslam-desktop
root@0b8206d0372f:/stella_vslam_examples/build# 

GPUを利用する場合は、docker runコマンドに--gpus allオプションを付加してコンテナを起動する。

なお、stella_vslamのリポジトリに上の操作をすべて実行するシェルスクリプトが含まれている。

下のコマンドを実行すると、サンプルデータセットの取得、PangolinViewer版stella_vslam Dockerイメージのビルド、同コンテナの起動まで行える。

$ git clone --recursive https://github.com/stella-cv/stella_vslam.git
$ cd stella_vslam/scripts/ubuntu
$ ./download_sampledata.sh
$ ./build_stella_vslam_docker.sh

Dockerコンテナでの動作確認

  • コンテナ stella_vslam-desktop
# At the /stella_vslam_examples/build directory
# pwd
/stella_vslam_examples/build
# ls /
bin   dataset  etc   lib    lib64  ...   ...   ...   stella_vslam           sys   usr   vocab
...   ...   ...   ...   ...  ...   ...   ...   ...   stella_vslam_examples  tmp   var
# ./run_video_slam \
    -v /vocab/orb_vocab.fbow \
    -m /dataset/aist_living_lab_1/video.mp4 \
    -c /stella_vslam/example/aist/equirectangular.yaml \
    --frame-skip 3 \
    --no-sleep \
    --map-db-out map.msg

SocketViewer版stella_vslamのビルドと動作確認

Dockerイメージのビルド

stella_vslam本体

$ cd ~/VSLAM/Docker
$ git clone --recursive https://github.com/stella-cv/stella_vslam.git
$ cd stella_vslam
$ docker build -t stella_vslam-socket -f Dockerfile.socket . --build-arg NUM_THREADS=`expr $(nproc) - 1`

socket-viewer

$ cd ~/VSLAM/Docker
$ git clone --recursive https://github.com/stella-cv/socket_viewer.git
$ cd socket_viewer
$ docker build -t stella_vslam-viewer .

Dockerコンテナの起動

socket-viewer

$ docker run --rm -it --name stella_vslam-viewer --net=host stella_vslam-viewer
WebSocket: listening on *:3000
HTTP server: listening on *:3001

先にsocket-viewerを起動し、ここで、Webブラウザからhttp://localhost:3001/へアクセスする。

stella_vslam本体

$ docker run --rm -it --name stella_vslam-socket --net=host \
    --volume ~/VSLAM/Docker/stella_vslam/vocab:/vocab:ro \
    --volume ~/VSLAM/Docker/stella_vslam/dataset:/dataset:ro \
    stella_vslam-socket
root@0b8206d0372f:/stella_vslam_examples/build# 

SocketViewer版stella_vslamでは、上の両方のdocker runコマンドに--net=hostオプションを付加してコンテナを起動するようにする。

Dockerコンテナでの動作確認

  • コンテナ stella_vslam-socket
# At the /stella_vslam_examples/build directory
# pwd
/stella_vslam_examples/build
# ls /
bin   dataset  etc   lib    lib64  ...   ...   ...   stella_vslam           sys   usr   vocab
...   ...   ...   ...   ...  ...   ...   ...   ...   stella_vslam_examples  tmp   var
# ./run_video_slam \
    -v /vocab/orb_vocab.fbow \
    -m /dataset/aist_living_lab_1/video.mp4 \
    -c /stella_vslam/example/aist/equirectangular.yaml \
    --frame-skip 3 \
    --no-sleep \
    --map-db-out map.msg \
    --viewer socket_publisher

stella_vslamプログラムが起動すると、Webブラウザのウィンドウに下のようなグラフィック描画画面が表示される。

Dockerを使えばプラットホーム環境に影響を与えることなく、プログラムのビルドを行えるのが良い。一度Dockerコンテナを作成してしまうと、動作確認だけが目的ならこちらの方が楽だろう。

ただし、小生は現在stella_vslamの動作解析や改造が主たる作業なので、いまはDockerを積極的に利用していない。元ソースや改造完成版ソースでのビルド確認、特定のデータセットでの動作確認などではDockerを利用している。また、上のsocket-viewerサーバーを稼働させるときもDockerを使っている。小生のメインPCはMacParallels Desktopを利用しているが、適時これとDockerを使い分けている。サーバー系の開発では、仮想マシンやDockerコンテナを利用すると作業効率が上がる。