昔の最近の出来事(2013.05)

2013/05/31

早めに帰着。

パラキスの実写映画。おおよそ原作通りという感じ。 Webを検索していたら、パラキスやNANAの原作者であるところの 矢沢あい氏は、体調不良で 2009年6月からNANAを休載しているようです。

そういや、随分前 (とその後)に OpenGLのglBegin(GL_POINTS)で点を描画すると四角くレンダリング されてて、丸でレンダリングする方法が見つけられずそのまま忘れていた のですが、glEnable(GL_POINT_SMOOTH) としておけば、丸でレンダリング できる事を知ったり(参考ページ)。
因みに、2000年に買ったビデオカードがVooDoo3のPCでは特に何も しなくても点は丸でレンダリングされてました (hairmakerのスクリーンショットとか)。

2013/05/30

早くも無く遅くも無く。

調べ事をして終了。

2013/05/29

早くも無く遅くも無く。

Web巡回して終了。

2013/05/28

早くも無く遅くも無く。

ちょろり調べごとをして終了。

2013/05/27

気持ち遅めに帰着。

ちょろりコーディング。

2013/05/26

昼過ぎ起床。

もそもそとコーディング。普段は使っていなかったのですが、 用事があってSetWindowLong()を使ったサブクラス化のコードを利用しようと したところ、Win64で動かなくなっていたのに気づいたり。 WindowsAPIバインディングのWin64対応が漏れているのか?と思い その辺を見直してみるも判らず。で、Webで調べてみると SetWindowLong()やGetWindowLong()は SetWindowLongPtr()やGetWindowLongPtr()に置き換える必要があると いうのを知り対応してみたり。

何故かOpenGLを使用したコードでやたらCPUを食うようになっていたり。 60fpsの同期をSleep()で行っているとせいぜい数パーセントくらいしか 食わなかったのが、1CPU分まるまる食うようになったという感じです。 心当たりがあるとすれば、少し前にグラフィックドライバのアップデート通知が あって、そこでは入れずにスキップしたつもりでした。 しかし、OpenGLのバージョンが2012/12/23時点では4.2.0だったのが 4.3.0になっていたため、いつの間にかアップデートが入っていた模様。 以前、旧PCでもドライバを 入れ替えるとやたらCPUを食うようになった事がありましたが、 副作用があるアップデートは勝手に入れないで欲しいなぁと 思ったりも。

2013/05/25

昼頃起床。

ちょろりコーディング。

「美の巨人たち」で紹介されていた「安藤緑山」 (参考)。 象牙でこんなの作れるの!?そんな感じ。

2013/05/24

早くも無く遅くもなく。

ちょろり調べごと。

2013/05/23

早くも無く遅くもなく。

レンダリング。終わってました。ログは以下のような感じ。

2013-05-19 17:26:27 INFO  main [mitsuba.cpp:255] Mitsuba version 0.4.3 (Windows, 64 bit), Copyright (c) 2013 Wenzel Jakob
  :省略
2013-05-23 10:10:57 INFO  ren0 [RenderQueue] Render time: 7.3950d
2013-05-23 10:10:58 INFO  main [statistics.cpp:137] Statistics:
------------------------------------------------------------
 * Loaded plugins :
    -  plugins\area.dll [Area light]
    -  plugins\bitmap.dll [Bitmap texture]
    -  plugins\constvolume.dll [Constant data source]
    -  plugins\diffuse.dll [Smooth diffuse BRDF]
    -  plugins\gaussian.dll [Gaussian reconstruction filter]
    -  plugins\gridvolume.dll [Grid data source]
    -  plugins\heterogeneous.dll [Heterogeneous medium]
    -  plugins\hgridvolume.dll [Hierarchical grid data source]
    -  plugins\lanczos.dll [Lanczos Sinc filter]
    -  plugins\ldrfilm.dll [Low dynamic range film]
    -  plugins\ldsampler.dll [Low discrepancy sampler]
    -  plugins\microflake.dll [Microflake phase function]
    -  plugins\null.dll [Null BSDF]
    -  plugins\obj.dll [OBJ triangle mesh loader]
    -  plugins\perspective.dll [Perspective camera]
    -  plugins\sphere.dll [Sphere intersection primitive]
    -  plugins\volpath_simple.dll [Simple volumetric path tracer]

  * General :
    -  Detected medium inconsistencies : 4.439 M
    -  Normal rays traced : 168.438 G
    -  Shadow rays traced : 129.390 G

  * Texture system :
    -  Cumulative MIP map memory allocations : 8 MiB
    -  Filtered texture lookups : 63.60 % (20.97 G of 32.97 G)
    -  Lookups with clamped anisotropy : 0.00 % (0.00 of 20.97 G)

  * Volumetric path tracer :
    -  Average path length : 5.73 (168.44 G / 29.40 G)
------------------------------------------------------------

約89時間(3.7日)かかりました。 Render time が7.3950d (dayの事だと思ってた)となっているのは 何の時間かよくわからず。バグっているのかも。 そして出来上がったファイルは、

$ ls -l
-rwxr-xr-x  1 TANE None 962426229 May 23 18:10 ultra_bigimage.png
$ file ultra_bigimage.png
ultra_bigimage.png: PNG image data, 35000 x 26250, 8-bit/color RGB, non-interlaced

てな感じで1GB近くあります(^^;因みにレンダリングしたシーンは Mitsubaページに置いてある この絵です。

2013/05/22

早くも無く遅くもなく。

レンダリング。あと3.3日になってました。あれ?このままいくと明日には終わる??

「Xbox One」。ハードスペックの詳細はよく判りませんが、PS4と同程度 かと思われます。TVが観られたり(チューナーではなくケーブルTV?)、 Webブラウザが搭載されたり。Kinectも標準搭載なのかしら? (後日追記:標準搭載されるみたい)

そういや、ファルコムのゲームである「ソーサリアン」の MDXデータ(X68kの音楽データフォーマット)をPC上で再生できるので 懐かしいみながら聞いてました。で、何気にWebを検索していると PC-88の オリジナル音源と思われるYouTubeデータに行き当たり、聞き比べてみたところ PC-88の方がPSGパートの鳴り方が良いなぁと思ったり。 というか、記憶の彼方にあるのはこっちの方だというのに気づいたり。 MDXの方もかなり良くできていると思うのですが、 音源やドライバが違えば再現にも限度があるといった所でしょうか。

2013/05/21

気持ち遅めに帰着。

レンダリング。あと6.5日になってました。予定より少し早めに終わるのかしら?

調べ事をして終了。

2013/05/20

気持ち遅めに帰着。

Mitsubaを使って 巨大画像を生成できないかと試してみたり。35000x26250pixを指定 してレンダリングを開始したところ、我が家のPCの実メモリ上限である 16GBに触れる勢いでメモリを消費したのちレンダリングが始まったり。 しばらくするとメモリがスワップアウトされるようで、 ワーキングメモリは3.7GB程度に落ち着いたり。で、問題はレンダリング 時間。どうやらあと9日ほどかかるらしい(^^;;;;;; CPUは100% 使っているのでちょいちょい待たされる事がありますが、 メモリが足りなくて遅くなる訳ではなく、普通にWeb見たりテキスト編集 したりする分には何も影響が無いので、レンダリング完了までしばらく 放っておこうと思います。

そういや、x86_64ではメモリ空間はどれくらいあるのかしら?と思ったり。 x64のWikipediaの 中には64bit Windowsでは1プロセスあたり8TBのユーザーモード仮想アドレス 空間とあるので、8TBまでは気にせず使って良いみたい。でも、 我が家のPCは HDDが2TBしかないので底を見ることはできません(^^;;

因みに、16384x16384pixの画像は1pixあたり4byteだとすると丁度1GBになります。 このピクセル数だとA4サイズ比率では 約13775x19482pixで1666dpi相当になります。 このサイズでは、メモリ8GB搭載マシンならばフルピクセルで せいぜい レイヤー6枚といった所でしょうか。しかし、今の8GBメモリ搭載PCが 10年後には 128倍の搭載メモリ容量(すなわち8GBx128=1TB)と同じくらいの価格容量比になったと 仮定すると、フルピクセルでレイヤー100枚も余裕だったりする訳で。 1プロセス8TBのアドレス空間なら仮定の10年後でもまだまだ全然大丈夫です。

8GBメモリ搭載とすれば33bitのアドレス空間を使用している事になります。 128倍==アドレス7bit分増加と考えると、10年で7bitずつ必要に使用していく事に なりますので、64bitに達するまでの時間は (64-33)/7*10=44.29年。そう考えると、 少なくともTANEが生きている間は、64bitアドレス空間で困る事にはならない 気がします(^^;

2013/05/19

AM中に起床。

以前、CreateDIBSection()に 2GBを超えるようなサイズを指定すると失敗する件の対応をしてみたり。 元画像自体はメモリバッファに確保し、CreateDIBSection()で確保するのは ウインドサイズだけに留めて再描画時に毎回メモリバッファからDIBに コピーするという感じ。32bitではそもそもポインタが2GBを超えた所を 指せないので意味はありませんが、64bitだと一応2GBを超えるサイズの 画像(実験したのは25000x25000pix==2.5GB)でも大丈夫になってみたり。 でも、このサイズだと全体が見渡せないので100% 表示だけだと意味無いかもなぁ?

巨大画像の生成。POV-rayを使って巨大画像の生成を試みたのですが、 何故かメモリのアクセス違反でうまく動かなかったり。 今の所、少メモリで巨大画像を生成しようと思うとInkscapeでPNGにエクスポート するのが一番簡単な気がします。

2013/05/18

起きたら午後もいい時間。寝すぎ。

先日、メガネが壊れたので修理にお出かけ。

もそもそとコーディング。勘違いに気づくのに時間がかかったり。

2013/05/17

早くも無く遅くも無く。

あまりの眠さに急速停止。

2013/05/16

早めに帰着。

Web巡回していて知った記事。

「人間対コンピュータ将棋」頂上決戦の真実 【前編】対局3日前、「棋界の武蔵」三浦八段が漏らした本音
「人間対コンピュータ将棋」頂上決戦の真実【後編】一手も悪手を指さなかった三浦八段は、なぜ敗れたのか

その後の「第23回世界コンピュータ将棋選手権」の記事。

秒間3億手を読む最強ソフト「GPS将棋」はいかにして敗れたか - 最強競う知の祭典「第23回世界コンピュータ将棋選手権」

そしてコンピュータ囲碁ソフトvs人の対局。6/4 - 6/7に開催される 「2013年度人工知能学会全国大会(第27回) JSAI2013」 内でのセッションの一つらしい。

コンピュータ囲碁はどこまで人間に迫れるか

2013/05/15

早めに帰着。

調べ事をして終了。

2013/05/14

早くも無く遅くも無く。

調べ事をしていて見つけた動画 「 X68K MDX FM音源64音(OPM*8個)+ PCM12音 RAYSTORM GEOMETRIC CITY+おまけ(1080p)」。 タイトルだけ見るとどういう事?って思いましたが動画を見てなるほど納得。 これってエミュレーター音源で鳴らしているのかな? 実機で鳴っているのを見てみたいと思った。

昔のマイコンベーシックマガジン誌上で、YK-2氏(==古代祐三氏)が 沙羅曼蛇の曲をステレオの左右チャンネル毎に分けたリストを掲載していました。 確か、片チャンネルを予めテープに録音しておいて、PCから制御可能なデータ レコーダーで再生開始すると同時にもう片側のチャンネルはPC本体で演奏 するという同期再生の例が載っていたと思います。ただ、実際に その方法を使って演奏を試みた人がどれだけ居たかは定かではありません。

2013/05/13

気持ち早めに帰着。

D言語。ラムダ式を使用した書き方と関数を使用した書き方とで、生成される 命令列に違いがあるのかしら?と思い、次のようなコードをコンパイル してみたり。

$ cat lamda_test.d
import std.stdio;
import std.string;

auto RGBA = (uint r, uint g, uint b, uint a) =>
  cast(uint)(r | (g << 8) | (b << 16) | (a<<24)) ;

uint rgba(uint r, uint g, uint b, uint a){
  return(cast(uint)(r | (g << 8) | (b << 16) | (a<<24))) ;
}

void main(string[] args)
{
  uint s ;
  s = RGBA(128,129,120,255) ;
  writef("%08x\n",s) ;
  s = rgba(128,129,120,255) ;
  writef("%08x\n",s) ;
}

$ gdc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\gdc031_2062_480\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw/gdc031_2062_480/bin/../libexec/gcc/mingw32/4.8.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.0/configure --build=mingw32 --with-arch=i686 --enable-languages=c,c++,d,lto --prefix=/mingw/gdc031_2062_480 --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 4.8.0 (GCC)

$ gdc -O2 -S lamda_test.d

$ grep -A22 _Dmain lamda_test.s
        .globl  __Dmain
        .def    __Dmain;        .scl    2;      .type   32;     .endef
__Dmain:
        subl    $28, %esp
        movl    __tls_index, %edx
        movl    %fs:44, %eax
        movl    (%eax,%edx,4), %eax
        movl    $255, 12(%esp)                                       ★A=255
        movl    $120, 8(%esp)                                        ★B=120
        movl    $129, 4(%esp)                                        ★G=129
        movl    $128, (%esp)                                         ★R=128
        call    *__D10lamda_test4RGBAPFNaNbNfkkkkZk@secrel32(%eax)   ★ラムダ式 RGBA()を呼び出し
        movl    %eax, 12(%esp)
        movl    $5, 4(%esp)
        movl    $LC38, 8(%esp)
        movl    $__D3std5stdio6stdoutS3std5stdio4File, (%esp)
        call    __D3std5stdio4File15__T6writefTaTkZ6writefMFxAakZv
        movl    $-8879744, 12(%esp)                                  ★関数rgba()はインライン展開されて即値ロードされてる
        movl    $5, 4(%esp)
        movl    $LC38, 8(%esp)
        movl    $__D3std5stdio6stdoutS3std5stdio4File, (%esp)
        call    __D3std5stdio4File15__T6writefTaTkZ6writefMFxAakZv
        xorl    %eax, %eax
        addl    $28, %esp
        ret

-8879744 == 0xff788180 で、rgbaの引数をuintにパックした値になります。 で、「あれぇ?」って感じです。ラムダ式で書くよりも、関数で書く方が速いコードが 生成されてるからです(^^;;; gdcのラムダ式のオプティマイザに問題があるのか?

2013/05/12

AM中に起床。

もそもそとコーディング。マクロっぽい簡単な関数をラムダ式を使用した 書き方に変えてみたり。しかし、32bitのgdcでは問題無かったのですが、 64bitのgdcではコンパイルエラーはしないものの、正しく実行できない 実行ファイルが生成されてしまったり。うーむ。

以下のような例でずっこけたり。

$ cat lamda_test.d
import std.stdio;
import std.string;

auto RGBA = (uint r, uint g, uint b, uint a) =>
  cast(uint)(r | (g << 8) | (b << 16) | (a<<24)) ;

void main(string[] args)
{
  uint s = RGBA(128,129,120,255) ;
  writef("%08x\n",s) ;
}

$ gdc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW64\gdc64_031_2062_480\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw64/gdc64_031_2062_480/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.8.0/configure --build=x86_64-w64-mingw32 --enable-languages=c,c++,d,lto --prefix=/mingw/gdc64_031_2062_480 --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap --disable-multilib --disable-shared
Thread model: win32
gcc version 4.8.0 (GCC)

$ gdc -O2 lamda_test.d

$ ./a.exe
Segmentation fault


gdbで見てみると、

$ gdb -q a.exe
Reading symbols from C:\cygwin\home\TANE\develop\dlang\test\a.exe...done.
(gdb) b _Dmain
Breakpoint 1 at 0x402220
(gdb) display/i $pc
(gdb) run
Starting program: C:\cygwin\home\TANE\develop\dlang\test\a.exe
[New Thread 4360.0x4d6c]

Breakpoint 1, 0x0000000000402220 in D main ()
1: x/i $pc
=> 0x402220 <_Dmain>:   sub    $0x38,%rsp
(gdb) warning: Can not parse XML library list; XML support was disabled at compile time
si
0x0000000000402224 in D main ()
1: x/i $pc
=> 0x402224 <_Dmain+4>: mov    0x48549c,%eax
(gdb) si
0x000000000040222b in D main ()
1: x/i $pc
=> 0x40222b <_Dmain+11>:        mov    %gs:0x58,%r10
(gdb)
0x0000000000402234 in D main ()
1: x/i $pc
=> 0x402234 <_Dmain+20>:        mov    (%r10,%rax,8),%r10
(gdb)
0x0000000000402238 in D main ()
1: x/i $pc
=> 0x402238 <_Dmain+24>:        mov    $0x68,%eax
(gdb)
0x000000000040223d in D main ()
1: x/i $pc
=> 0x40223d <_Dmain+29>:        mov    $0xff,%r9d        ※a=255
(gdb)
0x0000000000402243 in D main ()
1: x/i $pc
=> 0x402243 <_Dmain+35>:        mov    $0x78,%r8d        ※b=120
(gdb)
0x0000000000402249 in D main ()
1: x/i $pc
=> 0x402249 <_Dmain+41>:        mov    $0x81,%edx        ※g=129
(gdb)
0x000000000040224e in D main ()
1: x/i $pc
=> 0x40224e <_Dmain+46>:        mov    $0x80,%ecx        ※r=128
(gdb)
0x0000000000402253 in D main ()
1: x/i $pc
=> 0x402253 <_Dmain+51>:        callq  *(%r10,%rax,1)
(gdb)
0x0000000000004015 in ?? ()
1: x/i $pc
=> 0x4015:      <error: Cannot access memory at address 0x4015>
(gdb)

てな感じ。ずこっけるコードが生成される理由は調べていないのでよくわかりません。
なのですが、ずっこける事よりも ラムダ式を使えばインライン展開されるのかと思ったのですが、 そういう訳では無い所が疑問に思ったり。 というのも、「callq *(%r10,%rax,1)」でラムダ式で定義したRGBA()の命令列を 呼び出しているので、結局関数定義するのとの違いが無いように思われます。 コンパイル時に値確定可能なので、即値ロードに最適化されるのを期待していた のですがイマイチかも。因みに、-O3(インライン展開も有効)にしてみても命令列には 変化無しでした。

gcc-4.6.3+DMD2.060ベースのgdc64だと大丈夫でした。gcc-4.8.0+DMD2.062ベース のgdc64はTANEが無理矢理コンパイルを通したものなので、どこか壊れているのだと 思われます。

2013/05/11

AM中に起床。

もそもそとコーディング。といっても既存コードの整理。

2013/05/10

早くも無く遅くもなく。

DConf2013のスライドとビデオが順次公開されているようです。 こちらから 各タイトルの中のSlidesとVideoで見られるようになっていくようです。

2013/05/09

早めに帰着。

あまりの眠さに急速停止。

2013/05/08

気持ち早めに帰着。

「TAXI NY」。個人的にはオリジナルよりもこっちの方が面白く感じる気がします。

2013/05/07

早めに帰着。

あまりの眠さに急速停止。

2013/05/06

昼前起床。

もそもそとCG描いたり。なんとなくこれって感じになったので 仕上げてみたり。時々練習しないとダメだと思いました(^^;

不正なヘッダのJPEGファイルをSAIに食わせると画像が崩れる件について、 たまたまWebで見つけたJPEGファイルがたまたまそういうファイルだったので調べて 報告してみました。Webで拾った画像をIJGのjpegtranに食わせてみたところ 何故か修復されたことから、その差を調べてみたところ1バイトだけ 違っていて、それがSOFマーカーのサンプル数だったという流れです。 御参考まで。

2013/05/05

昼前起床。

録画を消化したりWeb巡回したりぐうたら過ごしたり。

CGを描こうと思い、図案を考えるも良い感じにならず。

5/4の深夜にTV朝日で放送されている「夏目☆記念日」で、 5/4はラムネの日というのを知ったり (参考)。 番組中で、ラムネ瓶(ラムネ玉(ガラス玉)の入ったあのビン)に、炭酸飲料をつめたものが ラムネという定義という事を言ってました。なので、


という感じらしい。へー。

2013/05/04

昼前起床。

org-modeでグラフを描くのにグラフ違いで Graphvizというプログラムの dotなるコマンドの存在を知ったり。Graphvizのdotコマンドだけを野良ビルド してインストール。org-modeで次のような記述により、

#+begin_src dot :file dot_example1.png :cmdline -Kcirco -Tpng
digraph {
  graph [label="糸井ステートマシン" fontname="Meiryo UI" fontsize=20]
  node [fontsize=24 style=filled,color=cyan]
  edge [fontname="MS Gothic" fontsize=10]
  寝る->食う [taillabel="十分寝た"];
  遊ぶ->食う [taillabel="腹へった"];
  食う->遊ぶ [taillabel="腹いっぱい"];
  遊ぶ->寝る [taillabel="遊びつかれた"];
  食う->食う;
  寝る->寝る;
  遊ぶ->遊ぶ;
}
#+end_src

以下のような結果画像がレンダリングされます。

[dot_example1.png]

面白いけど多分使わない(^^;

2013/05/03

昼ごろ起床。

ちょろり調べ事。

org-mode(8.0.2) + R(3.0.0 on Cygwin)で、tableデータをグラフにする件。やっぱり値渡しが うまくいってないような気が。

#+TBLNAME: pie_data
| 0.2 | a |
| 0.5 | b |
| 0.3 | c |

#+srcname: pie_chart(date = pie_data)
#+BEGIN_SRC R :file r_pie.png :width 640 :height 400 :results graphics :exports results
pie(data[,1],labels=data[,2])
#+END_SRC

#+RESULTS:
[[file:r_pie.png]]

Webにはorg-modeのshコードブロックで du コマンドを実行してテーブルを生成し、 そのテーブルをRコードブロックで円グラフにする例があったのですが、テーブルを Rコードブロックに渡すところはそのまま使えると思った訳です。でも、上記のRコード ブロック上で「C-c C-c」で実行すると、以下のようなエラーメッセージが 出る感じ。

Error in data[, 1] : object of type 'closure' is not subsettable
Calls: <Anonymous> -> <Anonymous> -> pie
Execution halted

Rのコードでprint(data)とか入れても何も出力されないようなので、 どういう値が渡されているのかを観察する事ができなかったり。うーむ。

/tmpに値渡しの一時置きデータが生成されているらしい所から手繰ったところ、 どうやら次のようにするのが正解のようでした。

#+TBLNAME: pie_data
| 0.2 | a |
| 0.5 | b |
| 0.3 | c |

#+BEGIN_SRC R :var data=pie_data :file r_pie.png :width 640 :height 400 :results graphics :exports results
pie(data[,1],labels=data[,2])
#+END_SRC

#+RESULTS:
[[file:r_pie.png]]

生成された結果画像は以下の通り。

[R_pie_test.png]

ポイントは以下。


判ってみると なーんだ って感じですが、ハマる原因は大体が些細な事だったり するので、注意深く反応をうかがうしかないかも。

ところで、円グラフというとアナログ時計の12時をスタートに右回りで 描くのが普通に思っていたのですが、Rでは3時をスタートに左回りで 描かれている(数学っぽい)ようです。描画操作はできるとは思いますが、 こういうものなのでしょうかね?

覚書。12時スタートかつ右回りにするには 「pie(data[,1],labels=data[,2], clockwise=TRUE)」てな感じでclockwiseという キーワードを使用すれば良いみたい。

2013/05/02

AM中に起床。寒い。

Rのcygwin野良ビルド。ビルド途中でエラーする件。R内の関数が何故かことごとく 見つけられずdll生成でリンカがエラーしていました。 どうやら、configureオプションに--enable-R-shlibを指定する必要があったり。 こんなのいちいち指定しなくても自動でチェックして欲しいのですが それはそれとして。他にも数学関数で logl()とか最後にlが付く系の 関数がリンクできなかったりしたのでlを削ったりして対応。 なんとなくJavaに関する何かのビルドに失敗している気がしなくはありません でしたが、無視されてビルド完了した感じだったり。で、make installして 簡単な計算とかデモとか実行したらそれとなく動いたのでなんとなく使えそう な感じに。

org-mode + R を試してみたり。 Rのコードブロックのみでグラフ画像を生成する例はうまく動きました。 続いて、orgで作成した表データを Rでグラフ化するのを試みてみたり。 しかし、Webで見つけた例を試してみるもうまくゆかず。 どうやって org表データを Rコードブロックに渡しているのか、仕組みをイマイチ 理解していないので原因の特定ができず。

そういや、「R」は名前自体の文字数が短かすぎて検索キーワードに若干困ります(^^;

以前 TV放送されていた 攻殻機動隊SAC SSS の録画を観たり。そういや もう7年くらい前の作品なのだなぁと思ったり。携帯電話の描画とかに少し 時代を感じました。
で、Webを検索していると、攻殻の新作である 「攻殻機動隊ARISE」の存在を知ったり。 「『公安9課』が最優先ラインの攻性部隊とはなり得ていない、A.D.2027。 公安捜査の権謀術数に限界を覚える荒巻の前に現れたひとりの女─ 陸軍『501機関』所属・草薙素子三佐。.....」という設定の物語みたいです。 因みに、原作の第一話はA.D.2029、SACはA.D.2030、SAC SSSはA.D.2034と いう設定。なので、全員がなんとなく若い感じの絵になってる 気がします(^^; しかも中の人(声優キャスト)は押井/神山版から 全員が入れ替わっているので、たぶん第一印象はかなり違った感じに なるんじゃないのかな?と思われます。
今のところPVでしか動いている所は観られないようですが、 劇場用の制作体制というよりはTVアニメの制作体制で作っているような 気がしたり。劇場向けであればそれこそビル群とかは今のCG技術を てんこ盛ってもやりすぎにはならないと思う訳ですが、 そういう感じでは無さそう。個人的に、攻殻アニメは 賛否はともかく その時代の最先端映像技術を全投入して欲しいなぁと思います。

2013/05/01

早めに帰着。

org-mode+gnuplotでプロットした画像を埋め込む事ができるのを知ったり。 この時、orgのテーブルで作成した表の値を参照してプロットする事もできるのですが、 HTMLにエクスポートする際に、表の方はエクスポートせずにプロット 結果画像だけをエクスポートする方法がよく判らなかったり。

応用の範囲内だったかも。「#+begin_src ... #+end_src」で指定できる コードブロックではヘッダー引数 :exports でエクスポート出力を 制御できます。で、以下のように、

#+begin_src org :exports none
#+tblname: data-table
 |   x |      y1 |         y2 |
 |-----+---------+------------|
 | 0.1 |   0.425 |      0.375 |
 | 0.2 |  0.3125 |     0.3375 |
 | 0.3 | 0.24999 | 0.28333338 |
 | 0.4 |   0.275 |    0.28125 |
 | 0.5 |    0.26 |       0.27 |
 | 0.6 | 0.25833 | 0.24999993 |
 | 0.7 | 0.24642 | 0.23928553 |
 | 0.8 | 0.23125 |     0.2375 |
 | 0.9 | 0.23333 |  0.2333332 |
 |   1 |  0.2225 |       0.22 |
#+end_src

org-modeコード自身をorgコードブロック化する事で、 「参照可能かつエクスポートしない表データ」にする事ができるようです。

グラフを描くのであれば、gnuplotよりもRとかの方がよさげですが、 RのCygwinパッケージは無い模様。野良ビルドを試みたところ、configureは 通るようですがビルド途中でエラー。原因は調べてません。

DConf 2013が始まったようです。 ライブ動画配信は無い模様。残念。Twitterで様子を伺うくらいしかできませんが、 意外と小さなセミナールーム的な所でやってるみたい。


TOP PREV