• 車種別
  • パーツ
  • 整備手帳
  • ブログ
  • みんカラ+

root220(^_-)-☆のブログ一覧

2013年08月22日 イイね!

ANDROID Pperカメラの核心

いままで理論を色々と書いてきましたが、

アプリがいい感じに仕上がってきました。

動作スピードもそこそこ満足出来る感じで!!

やはりPaperカメラは画像の諧調をRGB565に落としてるのが確認できました。

ARGB8888の画像ではなくてRGB565にしても同じ画質になるのが確認できたので間違いないでしょう。

処理「の流れは

処理1
YUV->ARGB565
->Yデータを白黒->エッジ作成->5ビットまで圧縮
処理2
ARGB565->トーン合成->エッジ合成->スケッチ原画のαブレンディング

※処理1と処理2は並列演算

以上のアルゴリズムで同じ画像が出来上がります。

あとは色々なエフェクトを独自で追加していく作業が~








Posted at 2013/08/22 01:53:53 | コメント(0) | トラックバック(0) | 日記
2013年08月21日 イイね!

Android Paperカメラの核心パート3



さて今回は発熱と携帯の性能について

昨今パソコンの性能の指針であった動作周波数!!2.4GHzあたりで打ち止めになってます。
これは周波数を上げていくと、性能が上がるんですが、発熱が物凄いことになってしまい、
ここが限界となってしまってるからです。

で・・・・CPUの数を増やして性能を上げる方向へと転換しています。

携帯も同じで去年は2CPUから4CPUなんて時代になってます。

でも!CPUが増えようと、プログラムが1CPUしか使えないプログラムだと・・・・・
パラパラとしか動かないものになってしまいます。

で、これを回避するのがスレッド処理

同じ仕事を平行して行うのでCPUを個数分使いまわす感じで動かします。
JAVAでは簡単ですがCでスレッドはちょっと難しい~のですが・・・・・

ここで問題が発生します。

凄く複雑な計算を繰り返し行ってると、携帯が発熱を始めます。
ARROWSなんかは50°くらいまでになっちゃいます。
発熱を抑えるため携帯は性能を下げる処理に入り結果してプログラムが思うように動作しない、原因がつかめないパラドックに入ってしまいます。
JAVAだけで作ってるならば、ま~発熱はあんまりしないでしょうけど(笑

典型的な例はパズドラ、凄い発熱する機種があります。

4CPU+GPU(グラフィックCPU)でそれぞれ分散処理を行ってれば、必然的に発熱コース

ところがです!!!!!!!
Paperカメラは意外と発熱しないのです。難しい処理を独自アルゴリズムで軽い計算にしてるのか??
たぶんOPEN GLで描画処理をGPU側で行ってると推測出来ます。

同様の処理が完成したのですが、発熱と性能ダウンの対策で現在パラドックス状態なのです、ただ!!!ある一つの解決の方策が見えてきました。

データ量を減らす。人間の目には感じることがない領域のデータを減らせば、計算量が減るのではないかと・・・・・・

試しに、スケッチの、もととなる白黒原図を32ビット画像から16ビット画像に変更してみたところ処理が1.5倍高速に、発熱も減りました。

マンガイラスト風にするのならばカメラから流れてくる画像データも半分の諧調でいいのだから、データ量が半分になるのでさらに高速になると思います。
動作速度もPaperカメラに近づきました。

フレームレートは毎秒25前後(4cpu機種で)、アニメ並みの動作です。

なんかチューニングをしている感じで、あるところまでは行くのですが、その先・・・・・・
カリカリチューンではなくて、万能な高性能、難しいです。その答えを見つける感覚が車ににている感じです。

Paperカメラの作者さんは天才だと思います。数学的、そしてデザインセンス

世界で同種のカメラは3つあります。
一つはPaperカメラ、もう一つはCartonカメラ(速さはあるのですがOpenGlを使い切ってないため手抜きしたスケッチエフェクトが人造的でいま三です)
最後の一つは和製の私のアプリ

今回の話はここまで、続きは次回で

















Posted at 2013/08/21 00:58:01 | コメント(0) | トラックバック(0) | 音楽/映画/テレビ
2013年08月18日 イイね!

Android Paperカメラの核心に触れるパート2

さてさてPaperカメラの第二弾

数学的な話ですが(笑

デジタル2値画像の距離変換について,これまでシティブロック(4近傍)距離とチェスボード(8近傍)距離については高速な方法が提案されていたが,実用上最も重要なユークリッド距離については決定的な方法は知られていなかった.

ところが最近,ShihとWuによって非常に効率的な方法が提案された.この方法は,3x3のウインドウで画像を2回(順方向に1回,逆方向に1回)走査するだけで正確なユークリッド距離変換が求まるという画期的なもので,通常サイズの画像ならほとんど一瞬で距離変換が完了する.

Frank Y. Shih and Yi-Ta Wu, ``Fast Euclidean distance transformation in two scans using a 3 x 3 neighborhood," Computer Vision and Image Understanding, vol.93, no.2, pp.195-205, Feb. 2004.

また,ボクセルデータなどの3次元画像への拡張も既に同著者によってなされている.

なんのこっちゃ??いやいや、実は
こんな画像を作るのに必要なのですが・・・・・・・
画像の輪郭を描画するのにユークリッド距離を計算するんですが、平方根の計算があるので計算に時間がかかってしまいます。

上記の理論を適用すると
640x480の画像は614400回も計算が必要になります。

じゃあどうするの???

全部足し算と引き算で計算するのです。

こんな感じ

int min, max;
if ( workx < 0 ) workx = -workx;
if ( worky < 0 ) worky = -worky;
if ( workx < worky )
{
min = workx;
max = worky;
} else {
min = worky;
max = workx;
}

int total1=((( max << 8 ) + ( max << 3 ) - ( max << 4 ) - ( max << 1 ) +
( min << 7 ) - ( min << 5 ) + ( min << 3 ) - ( min << 1 )) >> 8 );

if ( workx2 < 0 )
    workx2 = -workx2;
if ( worky2 < 0 )
workrky2 = -worky2;

if ( workx2 < worky2 )
{
min = workx2;
max = worky2;
}
else
{
min = worky2;
max = workx2;
}

int total2=((( max << 8 ) + ( max << 3 ) - ( max << 4 ) - ( max << 1 ) +
( min << 7 ) - ( min << 5 ) + ( min << 3 ) - ( min << 1 )) >> 8 );
r=(total1+total2);
//rは距離、エッジ強度を2とすれば(total1+total2)/2*2=total1+total2と簡略出来る
これならば半分の時間で計算出来ます。

でもですね、この計算はカメラデータyuvをRGBに変換してエッジ計算すると

Galaxy S2(2CPU)で30ms

Galaxy S3(4CPU)で20msかかっちゃいます。


エフェクトするのにちょっと厳しいせめて10msで完了しないとダメダメ

で次に行うのが並列処理

カメラからYUVデータが来たらRGB変換とエッジ処理

エフェクトはあらかじめ並列処理が完了したエッジデータを使用すればいいのですが・・・・


これでも厳しい~

じゃあPaperカメラは??どうやってんの????


この答は次回で(笑


おまけ:激重い計算プログラム(参考にしちゃダメですよん)
見てのとおりループ計算のオンパレード
計算時間は加算・引き算<掛け算<割さん<平方根の順にクソ重くなる
(short)rint(sqrt(workx*workx+worky*worky))なんて計算したら使い物になりゃしません
エレガントに足し算・引き算・ビットシフトで計算すいりゃ平方根も必要ありません


通常の計算方法
double Wx[3][3] ={{-base1,base3,base1},
{-base2,base4,base2},
{-base1,base3,base1}} ;
double Wy[3][3] ={{-base1,-base2,-base1},
{base3,base4,base3},
{base1,base2,base1}} ;

double Wx2[3][3] ={{0,0,0},
{0,1,0},
{0,0,-1}} ;
double Wy2[3][3] ={{0,0,0},
{0,0,1},
{0,-1,0}} ;
for(i=1;i {
for(j=1;j {
int a, aa, r, rr, g, gg , b, bb, counts,glay;
a = aa = r = rr = g = gg = b = bb = counts = 0;
for(ii=-1;ii<2;ii++)
{
for(jj=-1;jj<2;jj++)
{
   aa = pixelsSrc[(i+ii) + (j+jj) * width ] & 0xFF000000;
    r = pixelsSrc[(i+ii) + (j+jj) * width ] & 0x00FF0000;
     r = r >> 16;
     g = pixelsSrc[(i+ii) + (j+jj) * width ] & 0x0000FF00;
     g = g >> 8;
     b = pixelsSrc[ (i+ii) + (j+jj) * width ] & 0x000000FF;

  f[ii+1][jj+1]=r;
}
}
workx =0.0 ;
worky =0.0 ;
for(ii=0;ii<3;ii++)
{
       for(jj=0;jj<3;jj++)
    {
workx += Wx[ii][jj]*f[jj][ii] ;
    }
}
for(ii=0;ii<3;ii++)
{
    for(jj=0;jj<3;jj++)
    {
worky += Wy[ii][jj]*f[jj][ii] ;
    }
}
workx2 =0.0 ;
worky2 =0.0 ;
for(ii=0;ii<3;ii++)
{
for(jj=0;jj<3;jj++)
{
workx2 += Wx2[ii][jj]*f[jj][ii] ;
}
}
for(ii=0;ii<3;ii++)
{
for(jj=0;jj<3;jj++)
{
worky2 += Wy2[ii][jj]*f[jj][ii] ;
}
}


int total1=(short)rint(sqrt(workx*workx+worky*worky));
int total2=(short)rint(sqrt(workx2*workx2+worky2*worky2));
r=(total1+total2)/2*shickness_lebel;
Posted at 2013/08/18 21:47:07 | コメント(0) | トラックバック(0) | 音楽/映画/テレビ
2013年08月17日 イイね!

AndroidアプリとiPhoneアプリ

現在アプリ作家として活躍中??

先月マックを購入!したのですが・・・・Appleサーバーがダウンしてて、今週にやっとアプリ登録が出来るようになりました。


狙えiPhoneベスト!!(笑


で・・・・Androidのほうは着実に売れてはいて、年間で車1台分くらいは売れてるのですが、なかなかその先に行けない。
売上は全て子どもの大学授業料~へ消えてます(泣・泣

どうしたらいいものやら・・・・・・
Posted at 2013/08/17 20:01:39 | コメント(0) | トラックバック(0) | 日記
2013年08月17日 イイね!

Andoid アプリ Paperカメラの画像合成の核心を解明!!しちゃった(かも

Andoid アプリ Paperカメラの画像合成の核心を解明!!しちゃった(かもみなさん、お久ぶりです。
本業がアプリ製作作家となってしまいました(笑
※夜に執筆活動しております。昼間は技術職で・・・・・・


で本題のPaperカメラ!皆さんインストールしてますか??
大人気ですので、入ってますよね。

このアプリ漫画チックにリアルタイムにマンガ画像が見れるのですが、似たものを作ると・・・・
ある壁にぶち当たります。

時間!と言う壁!!

今の携帯は2CPU,4CPUが当たり前ですが、この性能を生かし切るためにC言語でアプリを作る
んですが、(JAVAではまったく使えませんので)
カメラからのデータは毎秒30枚のデータが流れてきます。時間で言うと33ms
これが曲者で、画像編集に使うRGB形式ではなくて、YUV形式で流れてきます。

YUVをRGBに変換して画像のエッジ計算に普通に計算すると画像1枚の処理に約70msかかってしまいます。

これでは紙芝居程度の速さ(泣

エッジ計算は行列計算なのですが、よ~く式を展開すると非常に簡単な式に展開する
ことに気が付きます。

プリューウィットフィルタの3x3のデータは0と1、つまり0の式は消せるので、16行の式になってしまいます。(3x3x3=通常は27行)
そして、割り算、掛け算を使用しないで、全て足し算引き算とシフト演算にすると
なんと!1枚の画像を処理するのに30msまで短縮出来ます。

ここまではいいのですが・・・このままだと写真に輪郭線が入った間抜けな画像になります。

そこで! Paperカメラには、画像のコントラストを微妙に合成計算する処理が入ってます。ここがこのアプリの売りの部分なんでしょう。要は画像を白黒に変換し諧調をダウンさせ、明度を調整し、輪郭線が入った画像と合成すると!!

はい!Paperカメラと同じ画像が出来上がります。

でも後半の処理はRGB->HSV->RGBなんて合成をするので、通常に計算すると!60msかかってしまいます!合計100ms~

ユーザーは軽快に動くアプリを求めます。紙芝居では売れません。

じゃあ、どうすればいいの!

ここが、作家さんたちのノウハウなのです。

作家さんたちは、勉強会に行ったり、セミナーに参加したり(汗

でも本題の部分は、なかなか・・・・・・・

ヒントはHSVに変換しなくても たった7行の簡単な式に出来ます。
※ネットには情報ないので、自分で手計算で数式を作ったのですが・・・・(汗

これは動画画像の圧縮にも使われる手法なのですが・・・・・

この変換式と輪郭線画像の計算を並列処理すると、リアルに動くPaperカメラが出来上がります。

ま~OpenGl ES2.0を使うともっと高速化できるのですが・・・・・・・
保存処理と動画保存処理を簡単に済ませるのはCで作ったほうがいいのかも。

お盆明けには動画のカテゴリーで公開する予定です。

アプリの名前も募集しちゃおうかな(笑

あなたの命名したアプリが全世界で公開される!!素敵なことだと思います。













Posted at 2013/08/17 19:53:40 | コメント(0) | トラックバック(0) | 音楽/映画/テレビ

プロフィール

「[整備] #クラウンハイブリッド 運転席イージーアクセスのアクティブ化について https://minkara.carview.co.jp/userid/552794/car/2584349/8261422/note.aspx
何シテル?   06/10 21:44
アイコンもなくUNNOWNな人や,ブログ・整備手帳も全くない不気味な方、女子と勘違いされてフォロー申請された方は 「絶対にフォローしません」 臭いで分かりま...
みんカラ新規会員登録

ユーザー内検索

<< 2013/8 >>

    123
45678910
111213141516 17
181920 21 222324
25262728293031

リンク・クリップ

KICKER L7TDF12 
カテゴリ:その他(カテゴリ未設定)
2025/05/10 11:45:11
MAXWINドラレコカメラ修理 
カテゴリ:その他(カテゴリ未設定)
2025/05/03 06:00:24
BSM取付 
カテゴリ:その他(カテゴリ未設定)
2025/02/08 01:18:22

愛車一覧

トヨタ クラウンハイブリッド ジャイ子2号 (トヨタ クラウンハイブリッド)
新型クラウンです 納車2018 7月初旬工場出荷 納車されました 車体は1000番の初期 ...
トヨタ プリウス トヨタ プリウス
クラウンが雪害で破損したための代車
ダイハツ タフト よっこら正一 (ダイハツ タフト)
買い物下駄に注文しちゃったぜ 大雪にはクラウンは、もったいないってことで
トヨタ ルーミー 下駄 (トヨタ ルーミー)
下駄です!あくまでも下駄(笑 Dのオネーたまの甘い誘惑に騙され、近所の買い物に発表1か月 ...

過去のブログ

2025年
01月02月03月04月05月06月
07月08月09月10月11月12月
2024年
01月02月03月04月05月06月
07月08月09月10月11月12月
2023年
01月02月03月04月05月06月
07月08月09月10月11月12月
2022年
01月02月03月04月05月06月
07月08月09月10月11月12月
2021年
01月02月03月04月05月06月
07月08月09月10月11月12月
2020年
01月02月03月04月05月06月
07月08月09月10月11月12月
2019年
01月02月03月04月05月06月
07月08月09月10月11月12月
2018年
01月02月03月04月05月06月
07月08月09月10月11月12月
2017年
01月02月03月04月05月06月
07月08月09月10月11月12月
2016年
01月02月03月04月05月06月
07月08月09月10月11月12月
2015年
01月02月03月04月05月06月
07月08月09月10月11月12月
2014年
01月02月03月04月05月06月
07月08月09月10月11月12月
2013年
01月02月03月04月05月06月
07月08月09月10月11月12月
2012年
01月02月03月04月05月06月
07月08月09月10月11月12月
2011年
01月02月03月04月05月06月
07月08月09月10月11月12月
2010年
01月02月03月04月05月06月
07月08月09月10月11月12月
2009年
01月02月03月04月05月06月
07月08月09月10月11月12月
ヘルプ利用規約サイトマップ
© LY Corporation