「 2012年08月 」一覧

Rhodecodeの使い方とGitの問題と


Rhodecodeの使い方

まず管理者でログインして、普段使用するユーザーを作成します。
下記の画像に示すようにしてユーザーを作成します。

ユーザーの作成が終わったら、ログアウトしておきます。
続いて先ほど作った普段使いのアカウントでログインします。
そして、”ADD REPOSITORY”を押して、リポジトリの追加を行います。

とりあえずリポジトリの名前、リポジトリの種別(git/hg)、概要などを記入して、画面下部のaddボタンを押します。Private repository にチェックを入れればプライベートリポジトリとなります。

ここでは、タイプにgitを選んでいることにします。

ある適当なフォルダで、右クリックしてtortoiseGitのCloneを選びます。
Urlには先ほどのRhodecodeのリポジトリ情報で表示されていた Clone url の部分のテキストを入力します。

取得できたら、適当にファイルを追加して、gitのAdd, Commitなど実行しておきます。
最初なので readme.txt とかファイルを用意しておくとよいかもしれません。

ここまで準備が出来たら、Rhodecodeのリポジトリへ反映させます。
tortoiseGitのメニューで Push があるのでそれを実行します。
実行するとパスワードを聞かれると思います。これはRhodecodeのユーザーに設定したパスワードを用います。

この状態でブラウザからRhodecodeの自分のリポジトリ情報を表示させてみると、今回Pushした内容が反映されているのがわかります。

GitとRhodecodeの罠(履歴とかコメントとか表示されない)

将来的にはこれからの内容は既に解決済みとなっていることでしょう。
2012/08/26現在ではGitでコミット&プッシュしているのにRhodecodeで反映されない!という問題があります。昨年の情報を見る限りではそんな人はいないようですが…。

ちょっと調べてみたところ、この原因はサーバー側のGitのバージョンによるものっぽいです。
CentOS 6.0の環境で yum install git として入ったバージョンが 1.7.1
これがあるコマンドオプションに対応していないために上記の問題が起こるようです。

これを解決するために新しいバージョンのgitを入れる必要があります。
これにはRPMForgeをyumの対象に加えて、再度gitをインストールすることで行います。

# yum install wget
# rpm –import http://apt.sw.be/RPM-GPG-KEY.dag.txt
# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
# rpm -ivh rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

# yum install git –enablerepo=rpmforge-extras

この後、gitのバージョンを確かめてみると、1.7.11.1 が入っていました。
この状態で、Rhodecodeのリポジトリに対してgitのコミットを行ったり、ブラウザからリポジトリ情報を表示させたときには、今までの操作履歴が表示されるようになっています。


Rhodecodeのインストール


はじめに

GitLabに続きRhodecodeもよさそうだったので、ここにインストールまでの手順をメモしておきます。GitLabは完全にプライベートリポジトリの扱いだったのですが、Rhodecodeは認証無しの状態でもどんなリポジトリがあるのかを見ることが出来ます。
もちろんプロジェクトの設定によっては非公開とすることも可能です。
いくつかの記事にあるように ActiveDirectory/LDAPとの認証連携が出来るのは大きなポイントかと思います。残念な点としては内部にIssueTrackerを持たないことでしょうか。これについては、外部のバグトラッカーと連携することも考えられて設計されているような感じです。

CentOSの準備

CentOS 6.0をMinimumインストールしてある状態からの手順を下記に書きます。

まず今後ネットワークを使えるようにしておきます。

ifcfg-eth0のファイルを編集します。

続いてSELinuxを無効化します。

ファイアウォールも無効化しておきます。

ここまで設定したら一度再起動します。

必要な物のインストール

Rhodecodeのインストール

途中で、リポジトリを格納する場所、管理者ユーザーの情報を入力します。

他のホストから接続できるように設定ファイルを変更します。

host = 127.0.0.1 の部分を割り当てられているIPに変更します。
(どこからでも受け付けたいなら0.0.0.0を設定する. )
そしてRhodeCodeを起動します。

5000番ポートで起動するので、http://(アドレス):5000/ にアクセスします。


あとはセットアップ時につくった管理者ユーザーでログインして、ユーザーを作成したりリポジトリの用意をしたりして運用していきます。

Apacheとの連携

httpd.confに記述を追加して、5000ポートへリダイレクトさせるようにします。

この設定の中で、アドレス中の “rhc” がプレフィックス扱いです。

production.iniを開き、[app:main]セクション内の編集を行います。

同じくファイルの末尾の部分に以下の内容を追記します。
上記のfilter-withの直後に書くとセクション情報の破壊を起こしてしまうので、セクションの切れ目で追記する必要があります。まぁファイル末尾に追記ならそういった問題が起こらないので・・・。

prefixの行に、先ほどのプレフィックス扱いとなっていた部分の文字列を設定します。

自分の環境では、このプレフィックス部分が”rhodecode” ではどうもうまく動作しませんでした。ChromeではうまくいくのにFirefox, IE9では失敗します。/rhodecode/ → /rhodecode./ というようにアドレスが展開されたところまでわかったのですが、それの原因はわからずじまいです。

環境情報

  • CentOS 6.0(x64)
  • Rhodecode 1.3.6
  • Pythonはvirtualenvを使用. (virtualenvを使用しなくても動作できることは確認しています。)

今後のネタ予定

  • 基本的な使い方
  • ActiveDirectoryとの連携
  • 外部バグトラッカー との連携


PVRTCテクスチャの解析 その5


以下は2BPPの補間モード適用状況においての話。自分用のメモですがちょっと残しておきます。

Modulation BitのLSBに 補間モードのフラグが格納される.

  • LSB = 0 なら 水平垂直の補間モード(仮にモードA)
  • LSB = 1 なら 1方向の補間モード(仮にモードB)

モードBの場合、ブロックの中心となる位置のModulation Bitの値を見る.
中心となる位置は 8×4ブロックなので LSBから数えて21番目のビット位置が見るべき値となる

  • このビットが 0 なら 水平方向のみ補間モード(仮にモードB1)
  • このビットが 1 なら 垂直方向のみ補間モード(仮にモードB2)

となる。

このようにモード振り分けに2bit使ってしまっている。
各ピクセルは2bitという点で、どのように補填するかというと、
LSBのフラグ部分に関しては、LSBから2bit目の値をコピー、同様に21番目のビットは22番目のビットの値をコピーしてくる。この状態のModulationDataは各ピクセルごとに2bitずつ割り当てられ、色の計算に使用される。

以上の処理によって、補間モード3つと各ピクセルのModulation値が求まる。

補間モードにおいて、ちょうどチェックパターンの箇所に該当する=Modulation値がちょうど存在する場所のピクセルの計算においては、2bitのModulation値がそのまま使われる。
補間モードの補間とはチェックパターンの隙間に関しての補間方法ということになるようだ。


PVRTCテクスチャの解析 その4


ようやくデコード(仮)が出来ました。
6種類くらいの並び替え方式を試していたらピタリと当てはまる物があったのです。
これで一段落かと思いきや、2BPPタイプのほうがとても難しい。
今までは割と素直な4BPPタイプの物を扱っていました。
4BPPだと処理単位が正方ブロックでModulation Dataと呼ばれる部分の並びもwhite paperにあったりして、情報が結構そろっている&解説されているためこちらを選んでいました。

しかし、2BPPの物については説明があまりないです。
2種類くらいのpdfを読んで、両者から情報をかき集めてデコードしてみたのですが、それでもまだエラーが残る状態です。

デコード後にエラーが残っている図

2BPPにおいては、Modulation Dataの部分がいろいろと複雑なようです。
まずmodeにより2種類の並びに分岐します。1つは1bitで各ピクセルをColorA or Bを選択する方式、もう一つが並びがチェックパターンとなり、white paperによると補間モードとしてさらに分岐されるとなっています。
問題はこの補間モードにあるのかと考えています。

エラーの部分を抽出

エラーがどの程度発生しているのかを調べるために、2枚の画像を引き算してみました。
その結果下記のように、エラー発生具合にもばらつきがあることがわかりました。
見ているとどうも2種類のケースがあるようで、ブロック範囲全体にエラーが散るケース、規則的にエラーが発生するケースとなっているようにもみえます。
これを2BPPの8×4ブロックで区切ってみるとそれがわかりやすい気がします。

画像の差分と、グリッド表示

このことからブロック最初のピクセル情報として取り出しているデータに関しては別の情報が格納されている可能性がありそうです。


PVRTCテクスチャの解析 その3


引き続PVRTCテクスチャのデコードをやっていました。
カラーデータの読み込みと RGBA8 への展開処理を再度チェックして修正した状態の物が下記の状態です。

とりあえず仮想イメージA,Bは使用されている色情報としては正しそうな感じになってきました。

ポイント

前回から見直した(修正した)部分は、カラーA,Bそれぞれを単に出力するのではなく、隣接するピクセルからの線形補間の処理を入れたことです。またこのときに元のRGB値を 各8bitとなるように展開処理も含めてみました。

色情報が正しそうな感じになってきたので、やはり気になるのは画素の並びです。今は普通に順番に並べていますが何か他の方法で並び替えたりするとうまくいくのでしょうか。
論文には並びについて記載しているようには見えないし、いくつかの方法でうまくいかないかチャレンジしてみようかと思います。


PVRテクスチャ形式の解析 その2


以前調べてみたときから9ヶ月くらいたっていますが、最近また調べてみてわかったことを書いておこうと思います。ここでPVR形式と言っていますが、ファイルフォーマットとしての形式のことと、PowerVRのテクスチャ圧縮 PVRTC とごっちゃになっていました。調べてみた対象としては両方とも含むのですが、どちらかといえばPVRTCについて興味があるといった感じです。

PVRTexTool v3.33を使用してみてわかったのですが、PVR形式のヘッダが昔と比べて変わっています。ざっと見たところ格納できる情報が増えていました。メタ情報が格納されるようです。
これにより先頭から52バイト目からデータがあるというプログラムコードだと正しく動作しません。PVRTexToolを使っているならぼちぼち対応しておかないといけなさそうです。
その一方で、PVRTexToolのよかった点として、旧フォーマットでも保存が出来ることです。現在のような移行期においてはこの機能にお世話になりそうです。

PVRTCのデコードにチャレンジ

仮想イメージA, Bをまず取り出してみようとコードを書いてみました。
うまくいけば、元の形状が予想できるような物が出てくるはずです (と思っています)。

その結果、次に示すような2つの画像が得られました。非常に暗いですが何か色は出ているようです。

仮想イメージA仮想イメージB

ちなみに元の画像は次のものでした。

全く正しそうな感じがしません…。うまく出てくるようならば白黒の合成用画像も出してみようと思ったのですが、これは難航しそうです。


Windows8をインストールしてみた


今週15日にMSDN向けにはWindows8やVisualStudio2012が公開されました。
そこで早速ダウンロードして空いているPCにWindows8を新規にインストールしてみました。

インストールについて

新規インストールしましたが、ユーザー設定等が出てくるのは最後の仕上げ部分となっていました。最初にどのディスクにインストールするか決めた後は、ほぼ放置でOKでした。また、ユーザー設定などの画面が出てくるまでも、インストールそのものを開始してから20分も経たないくらいでスピーディにインストール作業が完了しました。

あと、今までに無い色の紫色が基本カラーとして表示されていたのにちょっと驚きました。

デスクトップについて

以前からの予告通り、Aeroが消えていました。のっぺりとしたウィンドウになっています。Windowsキーによるメニューを出そうとすると、Metroのメニュー表示状態へ切り替わります。この挙動については個人的には不満です…スタートメニューがほしいです。

左下にマウスカーソルを合わせて、右クリックするとコマンドプロンプトやデバイスマネージャー、ファイル名を指定して実行などのメニューが出てきたので、とりあえずはこれである程度我慢はできそうです。

インストール直後だからなのかもしれませんが、古めのPCでも軽快に動いているようです。
(PentiumDualCore E6500, 2GB)

DirectX について

インストール直後では DirectX11がインストール状態となっています。ただし注意しなくてはならないのが、D3DX系のDLLが全く含まれていないことです(DirectX9のものすら入っていない)。そのためDirectXのコアだけ使ったアプリはほとんど無いでしょうから、DirectXの再頒布ランタイムのインストールは必要になりそうです。

VisualC++のランタイムについて

VisualStudio 2005(VC80) 用 50727.6910
VisualStudio 2008(VC90) 用 30729.6871

上記のものが含まれていました。従来のアプリがすんなり動きそうな感じです。
その一方で、2010(VC100)や2012のものが含まれなかったのがちょっと残念です。このことは2005,2008は既に十分古いから含めても問題ない、という意思表示なのでしょうか。

 


OpenGL 4.3とOpenGL ES 3.0が出た!


つい先日にOpenGL 4.3とOpenGL ES 3.0の仕様が公開となりました。

ES3の仕様書はこちら
http://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.0.pdf

ざっとES3について目を通してみたところ、DirectX9からDirectX10へ切り替わったときのような印象を受けました。それは、テクスチャ配列やtransform feedback, 定数バッファなどのDX10の機能が入ってきたからだと思います。transform feedbackがあるもののジオメトリシェーダーは使えないようです。そういえばどのくらい実用になるかはわかりませんが、Multi Render Targetの機能もサポートだそうです。これでスマホなどの組み込み系であっても、ディファードシェーディングによる方法が使えてくるようになるのかもと思います。普及するのは来年になるのかな。

GL4.3やES3.0で気になるポイントの1つに、テクスチャ形式が増えている点にあります。
新しいテクスチャ圧縮形式 Adaptive Scalable Texture Compression(ASTC) と呼ばれるものが入ってきているようです。また、ようやくといえるのかもしれませんが、ETC2形式についても標準サポートとなっているようです。ETC形式にはアルファ情報が入らず、一部の機種で泣かされましたが、ETC2があれはそれも解決になるのかなと思います。

ところで、ASTCはETC2の一部という感じなんだろうか・・・。ASTCは単純に圧縮技術の名称なだけで、格納しているのはETC2とかそんな感じ?  ちょっとこのあたりがまだよくわからない。

 

そういえばARM社からはMali-600シリーズが出ているようで、これがES3.0をサポートしているようです。これに合わせて、開発ツールも公開されている模様。
これをつかうと、OpenGL ES 3.0エミュレータが入っているようなので、開発自体は今からでも始められる感じです。また、OpenGL 4.3のサブセットとしてES3.0らしいので、4.3でES compatibility拡張を使ってデスクトップで開発を進めるというのもありなのかも。

OpenGLに新しいナンバーが出てきたこともあって、またグラフィックスAPI周りは盛り上がっていくような感じがして楽しみです。