無線ルータ（Aterm）をつなぐとUPnP（DLNA）サーバが見えなくなる ― 2017年09月02日 12:03
LANスイッチにAterm WG1200HP(WiFiルータ）をブリッジモードでつなぐと、同じスイッチに接続しているTwonkyやfoobar2000などのUPnP(DLNA)サーバが検出できない事象が頻繁に発生する。更改前のバッファローのWiFiルータでは、発生していなかった。
こうなると、自作の「UPnP音楽再生指示」などが用をなさない。foobar2000のUPnP BrowserからもTwonkyなどが見えなくなる。
※ブリッジモードにするのは、LANスイッチとWiFiネットワークを同一ネットワークにして、UPnP(DLNA)サーバをWiFi経由で利用できるようにするため。
原因切り分けのために、試しにAtermをLANスイッチから外してみると、サーバ検出ができるようになる。やはり、Atermに何らかの問題がある様子。
疑わしい設定を探してみると、基本設定では、UPnP機能が標準でオンになっている。ブリッジモードでは、用をなさない機能だが、オフにしてみる。一時的に改善したように思われたが、しばらくすると検出できない状況が再発する。
WANは使用していないので、LAN側設定をみてみる。標準でオンになっているのは、DHCPサーバとLAN側Pause機能。DHCPサーバは、ブリッジモードでは動かないので、関わりがあるとすれば後者。802.3xのフロー制御であろうか。念のため、オフにしてみる。あわせて、スイッチ側でも、Atermを接続しているポートを再起動（Ciscoのshutdown, no shutdownコマンド)してみる。
どうも、これで、UPnP(DLNA)サーバが検出できない状況が改善された様子。UPnPのマルチキャストパケットをAtermのLANスイッチが受信すると、バッファオーバーフローの合図を出してしまうのだろうか。少し様子を見る。
P.S.
LAN側Pause機能をオフにしてしばらく様子を見たが、数日でUPnP(DLNA)サーバが見つからない事象が再発。Atermを接続しているLANポートを閉じると症状が治まる点は変わらない。いろいろ試行錯誤したところ、Atermの動作モードをローカルルータモードにすると、症状が治まる。理由はすぐには思いつかないが、内部の実装の相違ということだろうか。
水郡線、磐越東線 ― 2017年09月06日 12:56
夏の18切符。最後は、水戸から、水郡線、磐越東線とぐるっと乗りつぶしの旅。
常磐線から、水戸で水郡線に乗り換え。カラフルな車体のディーゼル。
時刻表を見ると、朝方は常陸太田行きの便が良く、立ち寄ってもスケジュールには余裕がある。
沿線には高校が数多くあり、車中は通学の高校生が入れ替わり乗り降り。常陸太田の駅を降りると、3方向に分かれていく。うちの一つについていくと、高台を登り詰めて、太田第一高校。学園祭が近いのか、気合いの入った表玄関。
少し戻ると、太田城址。石碑には舞鶴城址。小学校の敷地内なので、玄関前から見るだけ。
それよりも、敷地前の正方形の空き地が気になる。
駅に戻りすがら街並みを見ると、立派な木造の民家や蔵など見どころはあるが、どれも傷みが激しい。整備されれば、いい通りになるのだけど。そのうち、梅津会館は威容を誇る。
いつも出掛けると縁があるのが猫。常陸太田の街中でも。
駅に戻ると、隣に観光案内センターとレンタサイクル。坂が多い町を意識してか電動アシスト車。
終着駅の線路止め。駅から一両分ほどもない。操車場は駅の手前。
郡山方面に向かうために、上菅谷に戻る。
郡山までは、それほど標高差もなく、のんびりと田畑の実りを眺める旅。ぽろぽろと乗り降りがある。途中、常陸大子で後ろ1両切り離し。
郡山は3番線に入線。ホームの先は線路止め。
お昼過ぎなので、昼食を物色。駅そばは、新幹線ホームのある駅舎の方。地元色薄めなので、駅弁を調達。肉々しい気分ではなかったので、山菜栗めし。お店の推しは、海苔のりべん。
ここからは、磐越東線。こちらは、喜多方行でもお世話になった気動車。早めに入線しているので、のんびりしていると席がなくなる。
この路線は、夏井川に沿って下り、渓谷美が楽しめるが、景色を見るには、ロングシートなのが少し残念。座らず、前後にかぶりつくのが正解かも。車中の検札を見ていると、年配の18切符の旅行者が多い。
いわきに到着。四ツ倉の方には、ちっと便が悪い。
素直に水戸に戻って、鹿島臨海鉄道。
大洗で下車して、ガルパンラッピング列車の制作応援記念乗車券を購入。北浦湖畔までの乗車券つき。停車時間が5分あるので、そのまま乗ってきた列車に戻ることも可能だと待合室で気がついたが、後の祭り。
次の列車まで時間があるので、構内をぶらぶら。なぜか、改札内に自転車が多数置かれ、レンタサイクルの案内。どうも、盗難が多い様子。ここは平坦地なので、アシストなしで大丈夫。
乗り継ぎは、新型車。大鉾田で乗り換え。
新潟トランシス製の8001。車内は少し静かになった。JRに合わせて電気式気動車にすれば、とも思うが、平坦路線で値段も高そうだから、そこまで要らないのか。隣県なのに県庁所在地どうし、千葉市から水戸市は遠いので、JRに乗り入れて直通運転を夢見たりするが、どうだろう。
鹿島神宮駅でも長い待ち時間。駅前にイートインのあるミニストップがあるのが有難い。
SoftwareBitmapからbyte配列を得る ― 2017年09月12日 16:51
SoftwareBitmapの個々のピクセルにアクセスして編集するために、byte配列に変換する。明るさの変換などは、streamアクセスでも構わないが、任意の点の位置を変換するような処理では、byte配列が必要になる。
MSの文書では、COMインタフェースを用いる方法が解説されているが（上の方のコメントアウトしたコード）、unsafeコードになる。他に方法はないかと、BitmapEncoderからstreamを介して、BitmapDecoderにデータを受け渡し、そこからピクセルデータを得る手順を考える。
445行：InMemoruRandomAccessStreamを用意。次の行でBitmapEncoderに紐付け。
447行：編集対象のSoftwareBitmapをBitmapEncoderに紐付け。
451行：イメージデータをstreamに書き出し。
461行：streamをBitmapDecoderに紐付け。
462行：BitmapDecoderからPixelDataProviderを生成。
464行：PixelDataProviderからbyte配列を取り出す。
取りだしたbyte配列は、XAMLのImageの標準と同じBGRA8形式なら、ピクセル数の4倍のサイズ。データの並び順は、左上の原点からスタートし、横方向に右に進み、端まで行くと、次の行、という順。
効率は良くないかもしれないが、VSのデバッグ画面を見る限り、メモリの使用量が大きくなりすぎるようでもない。一度きりの処理であれば、問題はなさそう。
どじょう、そば ― 2017年09月15日 16:32
佃煮を買いに宗吾参道の川魚やさんにでかける。店先には、天然どじょうと書かれた水槽。ときどき、水面に息をしに上がってきて、くるっとターンして戻っていくのは見てて飽きない。
せっかくなので、同じく参道近くの甚兵衛そばに寄る。レビューサイトを見ると大人なら2枚くらいとあるが、小腹が空いたときにちょっと寄るくらいなら1枚でも。
C# delegate 使ってみた ― 2017年09月20日 08:09
C#のdelegate、教科書的にはわかっていたが、使える形で理解していたとはいえない。実際のところ、使用する局面がないと身につかないもの。
今回、メモリ上に展開した画像のピクセルデータについて、明度や彩度を調整する処理を書いてみると、ピクセルを体現するクラスのメソッド呼び出しを除くと、ほとんど同じ処理をいくつも書いていることに気づく。異なる部分を関数にして、引数渡しにすれば、まとめられそう。
457行：delegateの定義。引数渡しにする関数の形を宣言するようなもの。
460行：引数渡しにしたい関数の実体のひとつめ。delegateの形に合わせている。以下、複数個続くが、ピクセルを体現するクラスのメソッド呼び出しが異なるのみ。
426行：このクラスのパブリックなメソッドのひとつめ。460行目の関数名を引数にしている。
496行：引数で渡された関数を呼び出す。
関数名を引数に取るメソッドの定義。SoftwareBitmapをbyte配列に変換し、全てのピクセルについて、引数で渡されたメソッドを呼び出し、更新したbyte配列をSoftwareBitmapに戻す。この部分の記述が一つにまとまった。
SIMDのVector処理を試してみる ― 2017年09月27日 19:26
画像の明度、彩度を調整する処理について、高速化のためにCPUのSIMDを利用したVector処理を試みる。SSEやAVXといった仕組みである。UWPアプリでは、System.Numericsをusingで導入することで利用できる。参考文献はこちら。
定義の部分。赤枠内がVectorの定義。明度や彩度の計算には、ピクセルのRGB（各8bit）のそれぞれの値の最大値と最小値の導出、それらの足し引きが必要。vminが最小値、vmaxが最大値、vsumが最大値と最小値の合計、vdeltaが最大値と最小値の差分。データ型はushort。合計を求めるときにbyteでは、オーバフローする。
難しいのは、Vector処理をどこに適用するかの構想。ピクセルはBGRA8で構成されているので、４要素のVector4が思い浮かぶが、明度や彩度の計算では、ピクセル内のBGR相互の演算が必要。これに対応する演算やメソッドは用意されていない。
そこで、今回はBGRそれぞれをバラして、別々のVectorに設定し、同時にBGR間の演算を複数個一括で行うことを考える。バラしてVectorに構成しなおすオーバヘッドと、複数個一括演算の効率向上のせめぎ合い。
いくつ同時に処理できるかは、277行目で取得。手許の環境は、AVXは未実装。SSEになるのか、8を返すので、ushort(16bit)が8個で128bit。
処理の本体部分。tryで囲んだ内部で、ピクセルデータを格納するbyte配列からBGRそれぞれのVectorを生成。try catchは、不正なインデックス例外が多発したためのデバッグ用。
次の囲みで、Vector間の大小判定、加減算を行う。
その下のコメントで、乗除算も行っているが、ushortではオーバフローになるし、誤差も大きいので実用にならない。その下のfor文でVectorをバラして、doubleで計算することに。
性能向上度合いはどうか。1024x800程度あれば、数割ほどの短縮。画像が大きくなれば、効果は大きくなる。ただし、実際の操作では、メモリ管理などのオーバヘッドの方が大きく、体感できる効果は大きくない。副作用として、コードが長くなるのと、抽象度が下がる。
この先は、CUDAなどGPUに任せることになるか。OpenCLに手をつけるべきか、どうしたものか。
最近のコメント