Androidでネットワーク状態を知る

タグ: | 投稿日: 投稿者:

takeです。

弊社の動画配信サービスをAndroidで利用する際、現在のネットワーク状態により
配信する動画のビットレートを決定していたのですが。。。

当初のアプリ配信時には、ネットワーク状態は3GとWifiしかなくてWifiなら高ビットレート、
3Gなら低ビットレートを選択みたいな事をアプリからやってました。
が、時代の流れとは早いもので昨今ではWiMAX(+WiMAX)やらLTEやら新しいネットワークが増えてきました。

ユーザにとっては回線速度があがってとってもありがたい話しなんですが、開発者にとっては
たまったもんじゃありません(汗
上記のように3GとWifiのみで判定していると、プログラムの組み方によっては高速回線であるはずの
WiMAXやLTEが『3G』と判断されて画質の悪い低ビットレートの動画が配信されてしまいます。

この状態を回避する為に、正しいネットワーク状態を取得してみましょう。

まず、ネットワーク情報を取得する為、AndroidManifest.xml に以下のコードを記述します。

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

これでネットワーク状態を取得する準備ができました。

次は、取得メソッドです。

public enum NetworkStatus {
   OFF,
   MOBILE,
   WIFI,
   WIMAX,
   LTE,
}

public NetworkStatus getConnectedState(Context context) {

	ConnectivityManager manager = (ConnectivityManager)context.getSystemService(CONNECTIVITY_SERVICE);
	NetworkStatus status = NetworkStatus.OFF;

	NetworkInfo info = manager.getActiveNetworkInfo();
	if (info == null || info.isConnected() != true) {
		// OFF
		return status;
	}

	switch (info.getType()) {
	case ConnectivityManager.TYPE_WIFI:			// Wifi
		status = NetworkStatus.WIFI;
		break;
	case ConnectivityManager.TYPE_MOBILE_DUN:	// Mobile 3G
	case ConnectivityManager.TYPE_MOBILE_HIPRI:
	case ConnectivityManager.TYPE_MOBILE_MMS:
	case ConnectivityManager.TYPE_MOBILE_SUPL:
	case ConnectivityManager.TYPE_MOBILE:
		switch (info.getSubtype()) {
		case TelephonyManager.NETWORK_TYPE_LTE:
			status = NetworkStatus.LTE;			// LTE
			break;
		default:
			status = NetworkStatus.MOBILE;		// Mobile 3G
			break;
		}
		break;
	case ConnectivityManager.TYPE_WIMAX:		// Wimax
		status = NetworkStatus.WIMAX;
		break;
	}
	return status;
}

一応これで取得できるはずなんですが、LTEを判定できるのは API Level 11(Android3.0) からなんです。
Galaxy S II LTE SC-03D みたいな Android2.3なのにLTE搭載機は正常に判定できるかわかりません。

では。

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

tmuxのちょと便利な設定

タグ: , | 投稿日: 投稿者:

nor です。

今日は CUI LOVE な人間必須の「tmux」のちょと便利な設定を紹介します。
※ tmux? というかたは、ググってください。

tmux (or screen) を活用しているかたは、C-t [1-9] ですいすいウィンドウを移動しているに違いない今日この頃ですが、screen ですとウィンドウ数が 10 を超えた場合、ウィンドウ移動が極端にめんどくさくなります。
ええ、引越しの梱包くらいめんどくさいです。

そこで、登場! 素敵な tmux !

なんと、↓の設定を$HOME/.tmux.conf に追加するだけで、C-t space⏎ [ウィンドウ番号] で移動できちゃうんです!
すごく楽なんです。

 unbind space
bind space command-prompt "select-window -t '%%'"

↑の設定を保存したら、tmux 起動

tmux

C-t space !!!

tmux

ウィンドウ名 11 を入力

tmux

キタコレ!

tmux

一気にウィンドウ11に移動です!(まあ 1 からなんで C-t p でも移動できるんですが……)

これであなたも、tmux に夢中ですね!

ちなみに、nor の .tmux.conf は↓な感じです。

unbind C-b
set -g prefix C-t
bind C-t last-window

set-window-option -g utf8 on

set-option -g base-index 1
set-option -g default-shell /bin/zsh
set-option -g status-fg white
set-option -g status-bg colour18
set-option -g status-interval 5

setw -g window-status-current-fg red
setw -g window-status-current-bg colour18
setw -g window-status-current-attr bold
setw -g mode-keys vi

set -g pane-active-border-fg black
set -g pane-active-border-bg cyan

bind s split-window -v
bind v split-window -h
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

unbind space
bind space command-prompt "select-window -t '%%'"

unbind r
bind r source-file ~/.tmux.conf
Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

PrestaShopのカスタマイズ

タグ: | 投稿日: 投稿者:

今日はバレンタインデーです。先週に引き続き、雪が大量に降っています。
さらに風邪を引いてしまいました。辛いけど、そんな辛さをグッと堪えて気合いで情報発信します。kikuです。

先日PrestaShopを少し使ったのですが、日本語の文献が全然なくて困りました。
インストールの手順なんかはそこそこあったのですが、そこからカスタマイズしていく方法が全然わかりませんでした。

なので今回の記事は、「インストールされた状態のものをカスタマイズするにあたってどのファイルを弄ればいいのか」を記していきます。
ちなみにPrestaShopの超初心者向けの記事となっています。

今回はトップページを修正していきます。自分のファイルを開きながらご覧ください。
トップページのコントローラは

/controllers/front/IndexController.php

が呼ばれます。このファイル内にある

initContent()

メソッドが走ります。このメソッド内の処理で

$this->setTemplate(_PS_THEME_DIR.’index.tpl’);

が呼ばれているはすです。ここでは管理画面で設定したテーマ(デフォルトのテーマ名は default)のトップページのViewが呼ばれています。
このViewは

/themes/{設定したテーマ名}/index.tpl
(モバイルなら /themes/{設定したテーマ名}/mobile/index.tpl)

です。index.tpl内は

{$HOOK_HOME}

のみ記述されています。これは先ほどのコントローラからViewに渡したデータです。
このViewはsmartyで書かれているのでよくわからない方はsmartyの書き方を調べてみればわかるはずです。
$HOOK_HOME の中身は先ほどのコントローラの

$this->context->smarty->assign(‘HOOK_HOME’, Hook::exec(‘displayHome’));

赤字の部分です。これは具体的には

/classes/Hook.php

exec()

メソッドが呼ばれています。メソッドの中の処理については割愛します。

トップページだけだと大体こんな感じですね。ヘッダーとフッターなども別のところから呼ばれていますが、これは次回以降に書ければ書こうと思います。
今回は簡単ですがこんな感じで終わります。

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

デブサミ2014 〜1日目〜

タグ: , , | 投稿日: 投稿者:

こんにちはベッチです。

昨日はデブサミ1日目でした。

まずはChefのセッション

私自身はOpsの人間ではなくDevの人間なのですがChefについては関係なくもないので参加しました。
DevOpsの時代ですし。
別のセッションでサイバーエージェントのフロントエンジニアの方も自分のドメインに固執するのではなく「越境しよう!」って言ってたなー。
良いサービスを作るには必要な事ですよね。
クックパッドさんもSalesとDevとOpsで1チームをつくって各部署の境をなくしたかたちでプロジェクトを進行しているそうです。

で、Chefの話ですが今回のセッションはGREEさん。

相当数あるサーバにChefを導入する場合、Chef Serverで一元管理するのが常套手段だと思っていたのだけど、GREEさんは自社のサーバ管理システムと役割が重複するという事でChef Serverを使わずにChef Bridgeという独自でつくった簡易Chef ServerみたないものとChef Soloで運用しているとの事だった。

あと、クックブックの内容は以下のツールを使用して結構しっかりとテストしているみたい。

  • serverspec/Test Kitchen(ブラックボックステスト)
  • chefspec(ホワイトボックステスト)
  • Foodcritic(Lint)

サーバの設定がテストできるってよく考えたら斬新。
Chefによって冪等性の確保ができるというのは、サーバ設定を属人的にさせない手段としては良いいですよね。

ちなみに参加された方の中で実際に業務でChefを利用しているのは1割程度でした。

次にherokuのセッション

基本的にサービス紹介でした。
なんでも今後force.comのデータとの連携ができるようになるとの事でした。
ただ、基本的にRailsアプリ作る時に使うくらいでしか今のところお世話にならないだろうなと、自分は。

最後はサイバーエージェントさんのフロントエンジニアの方のセッション

「え、ちょっとフロントやること多すぎじゃない!?」っていう事でしたが、やること多すぎなのはフロントエンジニアだけじゃないだろと思いつつも、現場のあるある的な話がちょっと面白かった。
で、その「やる事多すぎ」な状況をいろんなツールを使って解決しようとしてきた結果最終的に今はGruntとJenkins使って落ち着いてるとの事。
弊社ではGrunt使うほどまでフロントごりごり系案件はあまりないですが、個人的に使ってみたいツールではあるかな。
余談話として、プロジェクトによってはプロデューサーが女子のところがあるそうです。
というか男女比が6:4の会社ですからそんなプロジェクトはざらで、そういう位置づけにいる女子は俗にいうキラキラ女子ってやつです。
そのキラキラ女子の中には、金曜日当日に本番リリースをぶっこんでくるギラギラ女子もいるとの事でした。
「もう広告うっちゃいましたよー❤」っていって。
仲がいいんですね。

総括として他の会社の現場の事がわかったり、同じ事で悩んでたりするなーっていうのを感じれたのが良かったと思います。

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

プロジェクト管理ツールとかの話

こんばんは。
たまには誰からも邪魔されずに1つのプロジェクトにがっつりのめりこんだ開発をしたいなと思っているベッチです。

今日はプロジェクト管理ツールの話です。

弊社ではプロジェクト管理ツールとしてRedmineを使っています。
最近、1.4から2.3にアップデートしました。

アップデートというよりも、開発していく上で便利なプラグインが最初から入っているalminiumをインストールしました。

https://github.com/alminium/alminium

この時に、1.4のsqliteから2.3のmysqlへのデータ移行でうまくmigrationできなかったので手動で移行しました。
休日丸1日かけて・・・

苦労した甲斐もあってなんとか移行できましたが、若干データ移行がミスってますww。
ま、影響少ない部分だからいっか。

前置きはさておき、一番使いたかったのがredmine_backlogというスクラム開発用のプラグインです。

https://github.com/backlogs/redmine_backlogs

ストーリーやタスク、スプリントの管理、かんばんの表示/更新がRedmineで使用できます。

使ってみると若干融通がきかない事もありはがゆかったりします。

で、今回のRedmineの移行で何度かエラーが出た時にソースを追っていく過程でRailsに慣れ始めてきたのでこの勢いでRailsを使えるようにしてRedmineを使いやすく改修していくぜ!っていう目標をたてたりたてなかったり。

あと、実は裏でJenkinsを動かしているのでRedmineやGitと連携して開発を効率よくまわしてやるぜ!っていう目標をたてなかったりたてたり。

そんな事を考えているうちに来週末はデブサミが始まったり始まらなかったり。

http://event.shoeisha.jp/devsumi/20140213/

2日とも行きます。

それでは良い週末を。

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

[備忘録]役立つコマンド

タグ: , , | 投稿日: 投稿者:

最近、喉風邪にやられ人と会話すら辛いモリです。

何かと役に立つコマンドがあってもすぐ忘れてしまうという事で、備忘録として残します。

GITコマンドの【DIFF】を紹介。 GITの差分を見る時ってすっっっごい見づらいですよね!?(自分だけ?

たとえば、以下のソースを変更して

		  <div class="well sidebar-nav">
			<ul class="nav nav-list">
			  <li class="nav-header">Sidebar</li>
			  <li class="active"><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li class="nav-header">Sidebar</li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li class="nav-header">Sidebar</li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			</ul>
		  </div><!--/.well -->

こんな感じに。。。。

		  <div class="well sidebar-nav">
			<ul class="nav nav-list">
			  <li class="nav-header">Sidebar</li>
			  <li class="active"><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link追加した文字</a></li>
			  <li><a href="#"></a></li>
			  <li class="nav-header">Sidebar</li>
			  <li><a href="#">上書かれた文字</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li class="nav-header">Sidebar</li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			  <li><a href="#">Link</a></li>
			</ul>
		  </div><!--/.well -->

【git diff】を実行したとき
無題

【git diff --color-words --word-diff-regex='\\w+|[^[:space:]]'】を実行したとき

無題1

追加した文字は『緑』で削除した文字は『赤』で表示してくれます。
なにがどぉ~なったのかが一目でわかりますね!

ちなみに、ローカル環境でツールが使えるならEclipseやWinMergeなどに任せちゃってます ( ^0^;

無題2

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

サーバの運用管理

タグ: | 投稿日: 投稿者:

こんにちは。工藤です。

インフラ屋さんとして業務を行っていますが、サーバの管理、運用なども行っています。この管理、運用業務が意外と頭を悩ませる内容で、どうやって管理をしたら良いか試行錯誤の日々です。

いったいヨソの会社ではどうやってサーバの管理を行っているのだろうか?エクセル?自作ツール?

サーバと一口に言っても関わる人間が多く、また用途も様々。誰かが専任で管理をするなどほぼ不可能。当たり前かもしれないが、内容がニッチなんでそんな便利ツールを作って公開する人なんていないだろ…

 

いたーーーーーーーーー!!

 

ライブドアさんが数千台規模のサーバを管理するために作成したツール「yabitz」

https://github.com/livedoor/yabitz

完全にサーバ管理に特化しているため、その他の用途としてほぼ使用できないくらいにカスタマイズ不能。サーバ管理業務を行った事がある者にしか分からないある種の怨念すら感じる。弊社サーバ台数はせいぜい数百といったところなので、まだまだヒヨッコではありますが、このツールの作成者の方にはシンパシーを感じざるを得ません。

サーバ管理業務を行う上で必要な項目を過不足なく設定でき、かつ操作感もダイレクト!エレガント!これでもう営業から「この顧客で使用しているサーバって何台?」とか、開発から「このIPのサーバってどこにあるの?」とか、経理から「課金、非課金のサーバは?」といった問い合わせ(※あくまで弊社の場合)に対してggrksスピーディに対応する事ができます。非常に重宝しており、作者の方には何かの折にごあいさつに伺いたいと思うほどです。

世のサーバ管理業務担当者にGOD BLESS YOUだ。

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

シャレオツなAPIドキュメントページを作ろう

タグ: , , | 投稿日: 投稿者:

ギロッポンよりこんにちは、ニタです。

今回はWebAPI向けのドキュメントジェネレーター「apiDoc」を紹介します。

ドキュメントジェネレーターといえば、ApiGenやDoxygen、phpDocumenterなどありますが、それらはクラス内メソッドについてのドキュメントであり、外部向けのドキュメントとしては不要な内容も記載されてしまいます。
RESTfulなAPIドキュメントとしてはちょっとドキュメントとしての意味合いが違います。
サンプルを見ていただくとわかると思いますが、apiDocは独自記法ではありますが、生成されたドキュメントの見易さとしては他のドキュメントジェネレーターより上だと思います。

※先日、弊社のサービス「extorage」のAPIが公開されましたが、そちらのドキュメントページの生成でも使用しています。

インストール

npmよりインストールしますので、予めインストールしておいてください。
まあ、node.jsと一緒にインストールされますので、node.jsをインストールすればいいでしょう。
mac以外は知りません。

brew install node

npm install apidoc -g

ソースへの表記方法

javaDocとは違う独自記法をメソッドのアノテーションに表記します。
パラメータの説明はこちらにありますが、ざっと書くと以下のようになります。


/**
 * メソッドへのリクエスト方法、URL、名前
 * @api {get} /api/username username (ユーザー名)
 * apiのバージョン
 * @apiVersion 1.0.0
 * apiの名前。生成されたページでのアンカー名になる。
 * @apiName ユーザー名
 * 所属するAPIグループ
 * @apiGroup API
 * 詳細説明。HTMLも表記可能。
 * @apiDescription 現在ログイン中のアカウントユーザー名を返却します
 *
 * APIリクエスト時の返却内容のサンプル。ファイル形式がjsonの場合、以下のようにします。
 * @apiSuccessExample Success-Response(example):
 *     HTTP/1.1 200 OK
 * {
 *     "UserName" : ユーザー名,
 *     "message" : "OK",
 *     "response" : 200
 * }
 * エラー名。複数表記可能。
 * @apiError NotFound 見つかりませんでした
 * エラー時の返却内容サンプル。同じくjson形式で。
 * @apiErrorExample Error-Response(example):
 * HTTP/1.1 404 Not Found
 * {
 * "error" : "ファイルが見つかりません。",
 * "message" : "Not Found",
 * "response" : 404
 * }
 */
public function username(){
    // すばらしいコード
}

生成

実行コマンドは以下になります。

apidoc -i path/to/dir -f ".*\\.php$" -o path/to/output/dir -t template/path/

コマンドオプション

-i 対象のソースがあるディレクトリパス
-f 上記-iで指定したディレクトリのどのファイルを対象とするか。1つのファイルだけの場合はファイル名を指定。デフォルトでjsファイルを対象とするので、上記のように拡張子指定も可能。
-o 生成したデータの出力先。
-t テンプレートディレクトリ。apidoc -hでデフォルトテンプレートのパスを参照可能。

実行すると、このようなページが生成されます。フラットデザインがイマドキ感があってシャレオツですね。
apiDoc__sample

基本的にこれだけで生成可能ですが、APIのサービス名やバージョン、利用方法などの総合的な説明文などは、生成時に、別ファイルを読み込ませます。
※apidocの実行は、以下の2ファイルがあるディレクトリ上で行わないと読み込まれないようです。

package.json 生成するAPIのサービス名、説明文、バージョンなどを管理。
API.md 総合的な説明文。Markdown記法で表記。pakage.jsonにファイル名を追記して読み込ませる。

package.json

{
"name": "sample API",
"version": "1.0.0",
"description": "サンプルAPIのドキュメント",
"apidoc": "This is a description, it will be ignored if parameter apidocFilename exist.",
"apidocFilename": "API.md"
}

API.md

# ご利用にあたって

ここに利用方法などの記載する。

## 共通URL
各APIのエンドポイントのURLは以下を共通して使用します。
http://examp.le/sample/

※ユーザー名取得の場合

http://examp.le/sample/api/username

apiDoc__sample_API_-_1_0_0-9

apiDoc__sample_API_-_1_0_0-15

また、テンプレートはbootstrapを使用しているので、カスタマイズも可能です。

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

openstackの勉強会に行ってきました

タグ: | 投稿日: 投稿者:

こんにちは。土方です。

学生時代はinteropぐらいでしか聞かなかったクラウドコンピューティングですが

最近ネット上でもいろいろと見かけるようになり、需要が日々増しているように感じられ

オープンソースで動くopenstackの勉強会に参加してきました。

※詳細についてはhttp://openstack.jp/news/20140120.htmlに記載されております。

(写真に写ってますけどもう少し前に座ればよかったなぁと改めて思います。。)

勉強会の概要に書いてあった通り、openstackで出来る事を紹介されましたが

openstackのGUI上で仮想ネットワーク、仮想ルータを設置し仮想サーバをインターネット接続できるようにするというのが一番分かりやすく、便利そうだなぁと思いました。

導入方法について一切触れられなかったので調べてみたら以下のURLでopenstack及び各コンポーネントのインストール手順が記載されているようです。

http://www.server-world.info/query?os=CentOS_6&p=openstack_havana&f=1

休日の空いた時間に自宅PCの中に仮想マシンを仕込んで用意し試してみようかなぁと思います。

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook

プレモルの宣伝でやってるエフェクトを真似してみた(その方式).vol2

タグ: | 投稿日: 投稿者:

いかおです。

前回の「プレモルの宣伝でやってるエフェクトを真似して」の続きです。

一つ一つのピクセルがuyvy422でくるとなると、hueへの変換は以下の様になります

まず、RGBにします。
R = 1.000Y + 1.402V
G = 1.000Y – 0.344U – 0.714V
B = 1.000Y + 1.772U

hue = 180 / π * atan2(√3 * (GB), 2 * R – (float)GB)

※double atan2(double y, double x); // math.h のやつね

これでHueがマイナスである場合がありますので、マイナスだったら
360を足します

これでやうやくHueになります。

こんな計算を例えば(たかだか)1080iでやろうとすると
毎秒この計算を、1920x1080x30 回やりますとかなりゴーヂャスなPCでも間に合いません

確かにこのままやったら再生が間に合わなかった
で、最初に全パターン計算しといてテーブルに格納するんです
マッチングテーブルですねぇ・・・

ただ、yuv値ってそれぞれ(この場合)8bitですが、実際の値の範囲は

y 16~235
u(cb)/ v(cr) 16~240

こんな感じになりますが、とりあえず全部作っちゃえってんで、ソースコード公開!!
★RGB全パターンからHueを求めてYUVのテーブルに押し込みます。

.
#define KOSUU     256
.
.
    memset((char *)YUVTable, 0x00, sizeof(uint16_t) * KOSUU * KOSUU * KOSUU);
    double root3 = sqrt(3);
    float  hue;
    for(int ir=0;ir < KOSUU;ir++){
        for(int ig=0;ig < KOSUU;ig++){
            for(int ib=0;ib < KOSUU;ib++){
                float y, u, v;
                uint8_t ucy, ucu, ucv;
                y = (0.299f  * ir) + (0.577f * ig) + (0.114f * ib);
                u = (-0.169f * ir) - (0.331f * ig) + (0.5f   * ib);
                v = (0.5f    * ir) - (0.419f * ig) - (0.081f * ib);
                if((round(y) < 0.0f) || (round(y) > 255.0f)){
                    syslog(LOG_ERR, "Y overfloow at(%d:%d:%d)", ir, ig, ib);
                    continue;
                }
                if((ir == 0) && (ig == 0) && (ib == 255)){
                    u = 255.0f;
                } else if((round(u + 128.0f) < 0.0f) || (round(u + 128.0f) > 255.0f)){
                    syslog(LOG_ERR, "U overfloow at(%d:%d:%d)", ir, ig, ib);
                    continue;
                }
                if((ir == 255) && (ig == 0) && (ib == 0)){
                    v = 255.0f;
                } else if((round(v + 128.0f) < 0.0f) || (round(v + 128.0f) > 255.0f)){
                    syslog(LOG_ERR, "V overfloow at(%d:%d:%d)", ir, ig, ib);
                    continue;
                }
                ucy = (uint8_t)round(y);
                ucu = (uint8_t)round(u + 128.0f);
                ucv = (uint8_t)round(v + 128.0f);
                hue = 180 / M_PI * atan2(root3 * ((float)ig - (float)ib), 2 * (float)ir - (float)ig - (float)ib);
                if(hue < 0.0f) hue = hue + 360;
                YUVTable[(ucy * KOSUU * KOSUU) + (ucu * KOSUU) + ucv] = (uint16_t)round(hue);
             }
         }
     }

これを、Hue中央値とレンジを指定させといて、比較のため”0″変位に置き換えて

 // m_hue   ..中央値
 // m_range ..レンジ
 // m_gap   ..変位値(0変位比較のための加算する値) 
 // こんな風にしといて         
 if((m_hue + m_range) > 360)
    m_high = (m_hue + m_range) - 360;
  else
    m_high = m_hue + m_range;

  if(((int)m_hue - (int)m_range) < 0)
      m_low = ((int)m_hue - (int)m_range) + 360;
  else
      m_low = m_hue - m_range;         if(m_low > m_high){

  m_gap = 360 - m_low;
  m_low = 0;
  m_high = m_high + m_gap;
......
  uint16_t nowHue = YUVTable[(y * KOSU * KOSU) + (u * KOSU) + v] + m_gap;
  if(nowHue > 360) nowHue = nowHue - 360;
  if((nowHue <= m_low) || (nowHue >= m_high)){
      // モノ黒にする
  }

で、前回のサンプルでもいまいちキレイじゃないので、調査の上、
キレイにして掲載します(いずれね)

Share on Google+Tweet about this on TwitterShare on StumbleUponShare on Facebook