マンセルカラーシステム/PCCS/HSVについての覚え書き

軽く調べたので軽くまとめる。

マンセルカラーシステム / PCCS / HSVの共通点

まず、「マンセルカラーシステム」も「PCCS」も「HSV」も規格化された色空間であるという点は共通である。

そして、その空間は、以下の3軸で表現されるという点も共通である。

• 色相
• 明度
• 彩度

この空間を可視化するとこんな感じになる。

彩度 - Wikipedia

マンセルカラーシステム / PCCS / HSVの差異点

このように共通点を持つ3つの色空間だが、差異もある。

光源色/物体色

まず、「HSV」と「マンセルカラーシステム&PCCS」には大きな違いがある。

HSVは、光源色を表現するのに対して、 マンセルカラーシステムとPCCSは、物体色を表現する。

よって、マンセルカラーシステムやPCCS上の色が、実際にどのような視覚となるかは光源によって変わる。

物体色と光源色の違いについて-楽しく学べる知恵袋 | コニカミノルタ 色は光/光源色と物体色

色空間の形状

HSVの色空間は円柱状に表現できるのに対して、マンセルとPCCSの色空間は歪んでいる。Wikipediaの「彩度 - Wikipedia」に以下の記述があったが詳細は理解していない。

マンセル表色系やPCCSの色空間はNCSやオストワルト表色系に似ているが、人間の知覚を重視しているため、歪んだ形をしている。

そのため、彩度が最大のときの明度は必ずしも50%ではなく、色相によって異なる。例えば黄色では明度が高いとき、紫色では明度が低いとき、彩度を高くできる。

マンセル表色系では彩度の最大値も異なる。最大彩度はマンセル表色系で10から14、PCCSで9である。

彩度 - Wikipedia

マンセルカラーシステム | 基礎編 | TOYO INK 1050+

補色

次に、マンセルカラーシステムとPCCSの相違点だが、色相の作りに違いがある。色相を円環状に並べた時、180度対角にある色の事を「補色」と言う。

• マンセルカラーシステムでは、補色が物理補色
• PCCSでは、補色が心理補色

に、なるように定義されている。

物理補色というのは、混ぜ合わせた時無彩色になる色の組み合わせである。

心理補色というのは「ある色を見つめた後に現れる残像の色」である。例として赤を見つめた後、白紙に目を移すと青が見える。

補色 | 現代美術用語辞典ver.2.0

HSVからマンセル/PCCSへの変換

HSVは光源色、マンセル&PCCSは物体色だから単純な変換はできない。

…が、対応表もあるらしい。何らかの光源を定義することで対応付けているのか? 良く分からない。

Photoshopで理論的に配色はできないものか検証してみた │ Design Spice

WSJ - Good! よいホームページを創ろう講座5.3−色見本・表色系−PCCS Color List - RGB CMYK HSV

突如として実装の話題になるが、Pythonのcolor-scienceというパッケージにxyY色空間からマンセルカラーシステムへの変換を行うコードが入っていた。これを使えばxyY色空間からの変換できるかもしれない。xyY色空間についてよく分かっていないので詳しくは説明できない。

colour.notation.munsell Module — Colour 0.3.10 documentation

まとめ

上記のように理解したんだけどあってるんだろうか???

image segmentationについての覚え書き

Image segmentationについて軽く調べたのでまとめておく。

Image segmentationには大きく分けて2つの種類がある

1. semantic segmentation

画像内をいくつかの小領域に分割する手法。
画像内に映る被写体ごとに分割を行う。

2. superpixel segmentation

画像内をいくつかの小領域に分割する手法。
画像内で、色/距離などが似た集団毎に分割を行う。

semantic segmentationの手法

• インターネット上で見つけたまとめ

【ディープラーニング】 セマンティックセグメンテーション手法のまとめ - 旅行好きなソフトエンジニアの備忘録

Semantic segmentation

Semantic Segmentationのサーベイ - takminの書きっぱなし備忘録

• Facebookが公開しているsemantic segmentationのライブラリ。

Facebook、Deep learningベースのコンピュータビジョン物体検出アルゴリズム「Detectron」をオープンソース化。活用した研究論文も多数公開済み | Seamless

基本的にsemantic segmentationはDeeplearningでやってる研究が多い。

superpixel segmentationの手法

scikit-imageによく手法がまとまっている。 解説とともに実装も手軽に試せて最高。

Comparison of segmentation and superpixel algorithms — skimage v0.14dev docs

様々な手法が提案されており、実行速度やsegmentationの結果などが大分異なる。

とりあえず高速な手法が必要な場合は、Realtime + superpixel segmentationみたいなキーワードで調べると良さげ。

よく見かける手法として、SLICという手法がある。 論文は読んでないが、画像内のピクセル同士を色と距離を説明変数にしてK-Meansでクラスタリングしているようだ。

色はK-Meansの説明変数として使うのでマルチチャンネルの画像も使える。

さらに、次元を1つ上げて動画に対してSLICを行う事も可能で、そうすると、複数の画像にまたがるsuperpixelが得られ、物体追跡に応用する事ができるようである。

イメージとしては、写真を積み上げて3次元の物体にしたあと、クラスタリングによって3次元のsuperpixelを得るような感じだろうか?(想像でしゃべってます)

superpixel segmentationに関連する話題

関連する領域としてNormalized Cutという手法もあるみたいだけど理解していない。

Normalized Cut — skimage v0.14dev docs

Mean shift

Mean shiftを使ったsegmentationを行っている事例も見かける。 自分は、Mean shiftに対してエッジを保持したまま平滑化を行う手法という捉え方をしていたけどこう言う使い方もあるんですね。なるほどです。

Mean shift pixel cluster - File Exchange - MATLAB Central

Mean Shift Segmentation in Matlab | Shawn Lankton Online

Matlabを使った実装が多いけどOpenCVにも入ってるみたいなので、これを使えばPythonでもやれるはず。

OpenCVのエッジ保持平滑化フィルタ - Qiita

superpixel segmentationのためのデータセット

UCバークレーが公開しているBSDS500というデータセットがあった。このデータセットを使っている論文を探すと色々見つかるかも知れない。

UC Berkeley Computer Vision Group - Contour Detection and Image Segmentation - Resources

ただし、segmentationの他にedge detectionのためにも使われているデータセットなので、edge detectionの論文も多く引っかかってくる。

Google Kubernetes Engineをちょっと動かしてみました

はじめに

Google Kubernetes Engineをちょっと動かしてみました。

内容としては@mihiratさんが書いたkubernetes初心者のための入門ハンズオン - Qiita の前半を辿ってみた作業ログです。@mihiratさんありがとうございました。

Google Kubernetes Engineはdockerコンテナをフルマネージドで実行できるサービスです。なんか巨大なデータの分散処理に使えないかなぁと思って調べてみてる所です。

参考にした資料

• kubernetes初心者のための入門ハンズオン - Qiita
• Google Kubernetes Engine  |  Google Cloud Platform
• Kubernetes Engine クイックスタート  |  Kubernetes Engine のドキュメント  |  Google Cloud Platform

作業ログ

セットアップ

• project作成

> gcloud projects create --name try-k8s
No project id provided.

Use [try-k8s-190412] as project id (Y/n)?  y

Create in progress for [https://cloudresourcemanager.googleapis.com/v1/projects/try-k8s-190412].
Waiting for [operations/pc.6812860857256074521] to finish...done.                                                                          

> gcloud config set project try-k8s-190412
Updated property [core/project].

• clusters createしてみる➡エラー➡kubectlを入れないとダメ

> gcloud container clusters create k0 --zone asia-northeast1-a
WARNING: Accessing a Kubernetes Engine cluster requires the kubernetes commandline
client [kubectl]. To install, run
  $ gcloud components install kubectl

ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=The Kubernetes Engine API is not enabled for project try-k8s-190412. Please ensure it is enabled in the Google Cloud Console at https://console.cloud.google.com/apis/api/container.googleapis.com/overview?project=try-k8s-190412 and try again.

• kubectlを入れる

> gcloud components install kubectl

• もう一度clusters create➡エラー➡consoleでk8sを有効化する必要がある

> gcloud container clusters create k0 --zone asia-northeast1-a
ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=The Kubernetes Engine API is not enabled for project try-k8s-190412. Please ensure it is enabled in the Google Cloud Console at https://console.cloud.google.com/apis/api/container.googleapis.com/overview?project=try-k8s-190412 and try again.

• 表示されたURLを開いて[有効化]ボタンを押したが、同じページにリダイレクトされてしまう。

  • 今回、この検証に使っているアカウントは課金を有効化していなかったからかも知れない。(未確認)
  • 課金を有効化して、再び[有効化]ボタンを押した所、webにconsole画面が表示された。上手く行ったらしい。

• もう一度clusters create➡できた。

  • 数分くらいかかった気がする。

> gcloud container clusters create k0 --zone asia-northeast1-a
Creating cluster k0...done.                                                                                                                
Created [https://container.googleapis.com/v1/projects/try-k8s-190412/zones/asia-northeast1-a/clusters/k0].
kubeconfig entry generated for k0.
NAME  LOCATION           MASTER_VERSION  MASTER_IP      MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
k0    asia-northeast1-a  1.7.8-gke.0     35.200.97.160  n1-standard-1  1.7.8-gke.0   3          RUNNING

動かしてみる

• nginx起動➡一瞬で起動した…

> kubectl run nginx --image=nginx:1.11.3
deployment "nginx" created

• get podsでステータス確認。

> kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
nginx-1062973755-dcsqc   1/1       Running   0          1m

• 上記ではポート空いてないらしいので空ける。
  • この1行でport80が空き、ロードバランシングされるらしい。
  • え…簡単。

kubectl expose deployment nginx --port 80 --type LoadBalancer

• get servicesでステータス確認。
  • serviceというのはpodより大きな粒度の管理単位です。
  • おや? EXTERNAL-IPがになっている。

> kubectl get services
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP      10.43.240.1    <none>        443/TCP        11m
nginx        LoadBalancer   10.43.251.87   <pending>     80:32240/TCP   42s

• 数分後に再びget servicesしたらEXTERNAL-IP割り振られていた。

> kubectl get services
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP      10.43.240.1    <none>        443/TCP        14m
nginx        LoadBalancer   10.43.251.87   35.200.7.89   80:32240/TCP   2m

アクセスしてみる

EXTERNAL-IPに表示されたIPにブラウザからアクセスしてみる。 ...出来てる。すごい

後片付け

• 消しておこう

> kubectl delete svc nginx
service "nginx" deleted

> kubectl delete svc kubernetes
service "kubernetes" deleted

• 消えた

> kubectl get services
No resources found.

今日はここまで

はじめてのdocker | データ分析環境を用意してみた

背景

pythonでデータ分析環境を準備する時、色んなツールを使ってパッケージをインストールする場合があると思う。

• brewやyumでインストールするライブラリ
• pipやcondaでインストールするライブラリ
• ソースコードからbuildするライブラリ

上記のように様々な手段でライブラリがインストールされた環境を別のマシンで再現するのが面倒くさいのでなんとかしたい。

全てがcondaのパッケージ管理で完結するならcondaのenvironment.yml(Managing environments — Conda documentation)を使えばいいけど、condaだけで完結しないケースが増えてきたので困った。

やってみた事

• dockerにデータ分析環境を作ってみる。
• 試しにこんな環境を作ってみる。
  • pyenv + minicondaのインストール
  • boostのインストール + dlibのインストール

dlibは、C++製の画像による物体認識ツール。
anacondaでインストール出来る( Dlib :: Anaconda Cloud )が、これは最新のversionでは無い(2017年12月24日時点)ので、sourceを落として来てビルドする。その環境をdocker image化して再現可能な環境にしてみる。

注釈

• これを書いている者はdockerについてほぼ何の予備知識も持たない。この記事はやってみた事の記録であって、あまり整理された情報じゃないですごめんなさい。
• ここに書いてある内容には間違いや不正確な点が含まれるかも知れない。

前提

• ホストOS: MacOS 10.11.6

Dockerのインストール

まずMacにDockerをインストールする。

> brew install docker
> brew cask install docker

/Applications/Docker.appができるので、これをクリックして起動する。

Docker環境をHomebrewで手軽に作成 - Qiita

起動確認

docker psというコマンドで起動確認が出来る。

> docker ps
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

上記のようにCONTAINERの一覧が表示されなかったら、インストールできてないか、もしくは、dockerのデーモンが起動してない可能性を疑ってみるといいかも。

コンテナイメージのpull

docker pullというコマンドでコンテナイメージをpull(イメージをダウンロードして使える状態にすること)ができる。

> docker pull ubuntu 

docker imagesで取得したコンテナイメージの一覧を表示。

> docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              00fd29ccc6f1        9 days ago          111MB
alpine              latest              e21c333399e0        3 weeks ago         4.14MB

alpineというのはdocker向きの軽量なLinuxディストリビューションらしく、たしかにサイズがたった4.1MBしかない。index | Alpine Linux

興味はあったけど、よく知らないけどalpineのパッケージ管理ツールでデータ分析関連のパッケージで無いやつがあったりしてハマるのが嫌だったので今回はとりあえずUbuntuにしてみた。

コンテナの起動

> docker run -it --name "python-dlib" ubuntu     

"python-dlib"というのは、このコンテナに付けた名前です。 今日は、こいつの上にPython + miniconda + dlibな環境を準備していきます。

apt-getを実行してdocker commitする

とりあえず起動したコンテナ上に何が入ってるんだろう。 aptは入っているがpythonとかgitは無いっぽい事が分かる。

root@be6e91df27f0:/# apt -v
apt 1.2.24 (amd64)
root@be6e91df27f0:/# python -V
bash: python: command not found
root@be6e91df27f0:/# git
bash: git: command not found

とりあえずgitを入れてみる。

root@be6e91df27f0:/# apt-get update
root@be6e91df27f0:/# apt-get install git -y
root@be6e91df27f0:/# git --version
git version 2.7.4

dockerでは、コンテナに対して行った変更をdocker commitコマンドでイメージに反映できるらしいのでやってみる。

ホストマシン上で、docker commitコマンドを叩く。 この時、CONTAINER IDを指定する必要があるのでdocker psコマンドで調べておく。

> docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
be6e91df27f0        ubuntu              "/bin/bash"         8 minutes ago       Up 8 minutes                            python-dlib
> docker commit be6e91df27f0 "install-apt_git"

docker imagesを見ると、新たなコンテナイメージが作成されている事が分かる。

> docker images
REPOSITORY          TAG                 IMAGE ID            CREATED              SIZE
install-apt_git     latest              fbff7fa6f76d        About a minute ago   240MB
ubuntu              latest              00fd29ccc6f1        9 days ago           111MB
alpine              latest              e21c333399e0        3 weeks ago          4.14MB

引き続き色々インストールしてみる。

pyenv-installerでpyenvをインストール。

参考: Pyenvの使い方 - Qiita

root@be6e91df27f0:/# apt-get install curl -y
root@be6e91df27f0:/# curl -L https://raw.githubusercontent.com/pyenv/pyenv-installer/master/bin/pyenv-installer | bash

root@be6e91df27f0:/# echo 'export PATH="$HOME/.pyenv/bin:$PATH"' >> ~/.bashrc
root@be6e91df27f0:/# echo 'eval "$(pyenv init -)"' >> ~/.bashrc
root@be6e91df27f0:/# echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bashrc
root@be6e91df27f0:/# source ~/.bashrc
root@be6e91df27f0:/# pyenv -v
pyenv 1.2.0

次に minicondaをインストール

root@be6e91df27f0:/# pyenv install  miniconda3-4.3.30
Downloading Miniconda3-4.3.30-Linux-x86_64.sh...
-> https://repo.continuum.io/miniconda/Miniconda3-4.3.30-Linux-x86_64.sh
Installing Miniconda3-4.3.30-Linux-x86_64...

BUILD FAILED (Ubuntu 16.04 using python-build 20160602)

Inspect or clean up the working tree at /tmp/python-build.20171224075203.7994
Results logged to /tmp/python-build.20171224075203.7994.log

Last 10 log lines:
/tmp/python-build.20171224075203.7994 /
/tmp/python-build.20171224075203.7994/Miniconda3-4.3.30-Linux-x86_64 /tmp/python-build.20171224075203.7994 /
WARNING: bzip2 does not appear to be installed this may cause problems below
PREFIX=/root/.pyenv/versions/miniconda3-4.3.30
Miniconda3-4.3.30-Linux-x86_64.sh: line 333: bunzip2: command not found
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

エラーった。

bunzip2: command not foundと言われているので、入れる。

root@be6e91df27f0:/# apt-get install bzip2 -y

再びやったら通った。

root@be6e91df27f0:/# pyenv install  miniconda3-4.3.30
...
Installed Miniconda3-4.3.30-Linux-x86_64 to /root/.pyenv/versions/miniconda3-4.3.30

miniconda環境に切り替える。

oot@3fb9ed676e35:/# pyenv global miniconda3-4.3.30 
(miniconda3-4.3.30) root@3fb9ed676e35:/# python -V
Python 3.6.3 :: Anaconda, Inc.

この辺で再びdocker commitしておく。 これで、minicondaのインストールのみ終わった状態のdocker imageが出来た。これはこれで他の用途に使えるだろう。これは便利だ...

> docker commit 3fb9ed676e35 "setup-miniconda-py36"

dlibのインストール

dlibをソースコードからインストールする方法について、ここに大変親切な解説が載っていたので、この方法でインストールする。

installing_dlib_on_macos_for_python.md · GitHub

boostのインストール
cmakeのインストール

# apt-get install libboost-all-dev -y
# apt-get install cmake
# apt-get install build-essential

dlibのリポジトリをcloneしてくる。

# git clone https://github.com/davisking/dlib.git

ビルドしてインストール。

# cd dlib
# mkdir build; cd build; cmake .. -DDLIB_USE_CUDA=0 -DUSE_AVX_INSTRUCTIONS=1; cmake --build .

# cd ..
# python3 setup.py install --yes USE_AVX_INSTRUCTIONS --no DLIB_USE_CUDA

dlibの最新版が入った。

(miniconda3-4.3.30) root@0698b5cfb786:/# python
Python 3.6.3 |Anaconda, Inc.| (default, Oct 13 2017, 12:02:49) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dlib
>>> dlib.__version__
'19.8.99'

docker imageの保存

さて、途中から薄々気づいていたがdocker imageの構築は、今回のように直接コンテナのshellを操作するのではなく、Dockerfileと呼ばれるDSLを記述することによって構築されることが望ましいようだ。

Dockerfileはテキストベースで、軽量で共有しやすく、設定内容が明示的だからである。

とは言え、shellの操作によって作られたdocker imageを共有する方法もなくはないようだ。

docker saveコマンドを使うことで、docker imageがファイルとして出力できる。

> docker save setup-dlib:latest > setup-dlib.tar

また、docker loadでこのファイルを読み込んでimageとして使う事ができる。

> docker load < setup-dlib.tar

差し当たりではあるが、これで、様々な手段でライブラリを導入した環境を保存、再構築可能になった。

まとめ

• dockerを使うことで分析環境の保存、再現が可能になる。
• 課題
  • Dockerfileを使ったイメージの構築。
  • ホストOSとファイルを共有したい時どうするんだろう。
  • Alpine Linux気になる。
  • とりあえず動いたけど色々前提知識が無い。