ここから本文です

書庫全体表示

記事検索
検索

03.08 中山臨回電

 3月7日から8日にかけて、所定中山駅中線停泊の31Kが橋本駅に疎開しました。
 現在、平日の中山駅中線停泊は、東神奈川駅22時22分発(ねこ時間←その補足いる?)の町田行である2231Kが町田駅に到着後、中山駅へ回送電車として送られる形となっています。
 しかし、既に当ブログでも既に何度か取り上げているように、夜間停泊運用は構内都合によって留置場所が変わることがあり、今回も何らかの事情によって橋本に疎開されたと推測されます。

イメージ 1
町田駅に停車する回9331K列車@H016編成

 中山駅停泊の送り込みは、来たる3月17日のダイヤ改正以降、平日・土休日とも橋本からになるため、今後の疎開措置については橋本〜中山間の送り込み回送を運休させる形になると思われます(=現行の土休日ダイヤと同じ)。
 したがって、このような町田発の下り回送列車は、町田下中停泊列車の疎開を除いて見られなくなります。

イメージ 2
最終1本前の2325K各駅停車橋本行@H012編成

 中山駅中線の停泊列車は比較的早い時間に到着するため、通常は早朝深夜の下り電車を対岸から撮影することはできません。しかし、今回のように疎開が行われると、中線に車両が居ない状態となるため、終電間際や初電付近の電車でも撮影することができます。
 折角なので始発駅発車時刻が24時以降となる最終の橋本行を見たいところですが、中山駅では上りの最終電車の方が下りの最終電車に比べて発車時間が早いため、「上り最終電車の発車後は上りホームを閉鎖する」とのことで撤収しました。

イメージ 3
東神奈川からやってきた初電車447K@H005編成

 そんなわけで下り終電は撮れませんが、初電であれば何の問題もなく撮影できます。今回は冬季ということもあって、初電後も何本かバルブすることができました。

イメージ 4
疎開した編成は回9532Kとして橋本から返却される

 そして最後に、橋本からの返却回送です。ホーム端の定番構図で収めようと思っていたのですが、想像以上に露出が無い……。今にも雪が降るんじゃないかという3月らしからぬ天気で、厚い雲に太陽が遮られて全然明るくなりません。そんなわけで入線前に急遽場所を移動したわけですが、移動した先に同業さんが居ました。忙しなくてゴメンナサイ。
 ちなみに、今回同行する予定だった(というか正確には私がついていくと言う方が正しい?)知人の方は、疲れからか不幸にも黒塗り、じゃなくて寝過ごしてしまったみたいです。疲れがたまっているみたいなのでお大事にしてください。

★以下、オマケ。
 一昨日6日に撮影した写真も貼っておきます。決して別記事起こすのが面倒とか、そういうことではないんです。決して。

イメージ 5
S字区間を往く大船行列車800K

 先日は久々にこんなところまで足をのばしていました。構図は好きなのですが、僅かな切り位置で印象が全く異なるため、「S字」は難しいです。ちなみにインドネシアの方はS字構図のことを「snake angle」と言っていました。なるほど。鉄道ファン和英辞典に載せたい。

イメージ 6
改正で廃止される朝の大船発直通列車

 ほかにも大船行運用を同じ地点で撮りましたが、本命は逆側の下り列車。朝の大船折返し運用です。大船駅10番線発着の横浜線が無くなるということで、10番線に到着するシーンはこれまで割と撮ってあったのですが、走行のシーンがなかったということで念のため。
 もちろん夕方の始発はあるので、日の長い夏場なら1715Kや1701K(いずれも改正後の列番)の八王子行を同じように撮ることはできると思うのですが、せっかくカーブの撮影地で行先LEDも難なく写せますので、列番3桁の朝運用ということを強調してみました。そしてこのポイントなら、パッと見で磯子以南と分かってもらえるでしょう、多分。

 ちなみに、2月末の話に遡りますが当然こちらも記録しました。

イメージ 7
同じく改正で廃止となる休日夕方の大船発快速八王子行

 それにしても、LEDのダイナミック点灯速度が遅い1/125編成でありながら、特に工夫なく安心してLEDを止められるカーブの撮影地はいいですね。他にも記録しておきたい場所は残っていますが、泣いても笑っても残りの運転回数は2回です。

 結局、「中山臨回電」というタイトルにそぐわない(?)横浜線撮影近況報告になってしましましたが、今回はこんなところで。引き続き、新刊に掲載する写真を十分用意するため、各地走り回ります。

開くトラックバック(0)

02.02 雪空

この記事は2018年2月2日に撮影した内容です。
 
 雪のニュースから1週間あまり、関東平野部にはまたしても強い寒気が流れ込みました。テレビで「平成26年豪雪」の単語が何度も取り上げられるのを見て、「そういえば、あの年も雪が繰り返し降ったんだっけ」と耽ります。
 しかし、翌朝になってみると東部横浜の天気は雪交じりの雨。先週雪が降った日は用事で十分に撮影ができなかったので、今回こそはと早起きしたものの、期待外れの様相です。

イメージ 1

 あまりの寒さに家へ引き返そうかと思いましたが、「八王子では雪が降っている」との情報を入手し、人影まばらな始発列車に乗り込みました。

 列車に揺られること40分、相模原駅を発車したところで目を覚ますと、辺り一面が真っ白になっていました。「相原国境」こと七国峠を越えてからが本番と思っていましたが、十分すぎる積雪量です。

イメージ 2
イメージ 3

イメージ 4

 七国の峠は白銀に染まり、景色はまるで上越。雪は粉雪と牡丹雪を交互に繰り返して気温の不安定さを物語っていましたが、明るくなってもなお降り続きました。
 4年前、雪煙を上げて最期の力走を見せる205系を前にシャッターを切った撮影地へ向かうため、「国境」を越えて八王子に入ります。

イメージ 5

 みなみ野大橋から見るニュータウンは一面の銀世界でした。橋の形も相まって、アニメやゲームの舞台に迷い込んだような錯覚すら覚えます。駅では朝のラッシュが始まっていて、傘を片手に電車に乗り込むサラリーマンや学生の姿がありました。

イメージ 6

 みなみ野大橋から少し片倉側に進み、下り電車を撮影。望遠系の撮影地では、粒の大きい雪が一気に降ると、行先すら判読が怪しくなります。

イメージ 7

 こちらは朝夕限定の相模線からの乗り入れ車両。最近は前照灯のLED化が進められているようですが、運よく未更新タイプを撮影できました。そういえば、JRの発表によると横浜線は全駅にホームドアを設置する方針で動いているようですが、相模線直通電車もいずれは無くなる運命なのでしょうか……?

イメージ 8 イメージ 9

 もう少し片倉側に移動し、違うアングルも撮影しました。撮影地としては横浜線の中でも有名なポイントのひとつで、ほぼ同じ場所から上下線を撮ることができます。下り電車に関しては、もう少し車両を引き付けて撮影した方が魅力的な写真になるのかもしれません。

イメージ 10

 そして目的の撮影地点に到着。電柱の位置関係が非常に悩ましい場所ですが、構図はお気に入りのポイント。雪景色では小物や背景がある程度溶け込んでくれるので、ゴチャゴチャ感がなくなります。205系を撮影した時はこんなきれいに雪粒を捉えることはできなかったと思うのですが、今回はかなり綺麗に写りました。粒の大きさと風、シャッター速度の兼ね合いでしょうか。

イメージ 11

 雪粒を綺麗にとらえたのは先ほどの写真ともう一枚ぐらいで、他は普通でした。こちらは同じ撮影地での写真ですが、表示が「各駅停車東神奈川」となっていたので掲載しました。

 未明から降り始めた雪は午前9時過ぎに雨交じりに変わり、10時には完全にやみました。最後に少し雨が混じったこともあって、バラストに積もった雪はみるみる解けていきました。

イメージ 12 イメージ 13

 今年の積雪はおそらくこれが最後かと思われますが、一番行きたかった片倉のポイントも押さえられましたし、どうにかノルマは達成しました。一方、雪の相原七国峠で横浜線を撮ってみたい、というよからぬ願望も新たに生まれてしまい、終わりが見えません。
 最後に、もうおなじみかもしれませんが、片倉のポイントで撮影した205系の写真を掲載しておきます。
イメージ 14

開くトラックバック(0)

 こんばんは。

 「最近、横浜線撮ってますか?」と聞かれて思い出したのですが、つい先月まで研究に追われていたこともあってか、「横浜線撮影録」の記事を全然更新していませんでした。
 そんなわけで、最近……でもないかもしれませんが、まとめて更新します。2月以降については記事が長くなるので、頃合いをみて別途掲載させていただきます。

  12月15日 大船臨回電「回9916K」運転
 
イメージ 1
中山駅に停車する回9916K列車
 
 鎌倉車両センター入出区運用の17K運用が都合により橋本留置となり、臨時回送列車が運転されました。通常は不定期回送列車8916Kでの運転ですが、9916Kとして運転されました。
 17日に控えた春のダイヤ改正後は、平日・土休日とも大船出入区運用に大きな動きが発生しますので、不定期回送列車のダイヤもどのようになるのか注目です。


  12月17日 菊名駅橋上駅舎化
 
イメージ 2
新たにオープンした橋上駅舎の入口に立つ駅関係者ら
 
 菊名駅のバリアフリー化工事がひとつ大きな区切りを迎え、新しい橋上コンコースが12月17日の初電から供用開始となりました。これまで、JR線側の通路にはエスカレーターやエレベーターの設備がありませんでしたが、今回の工事でその問題が解消*されました。また、通路の変更に伴って1ラッチの連絡改札が廃止されたため、東横線への乗り換え時には必ず2回改札を通ることになります。工事の詳細は別途記事に起こす予定です。
※ホームとコンコースを結ぶエレベーターは、2018年2月28日に使用開始されました。


  1月11日 TASC装置性能確認試運転
 
イメージ 3
イメージ 4
▲試運転列車設定に伴う臨時回送列車

  東神奈川駅・横浜駅・桜木町駅のホームドア
 設置に先駆け、TASC装置の性能確認試運転が
 小机〜磯子間で終電後に行われました。
  これに伴い、小机駅中線停泊となる11Kが東
 神奈川駅浜2番へ疎開留置されました。
_※東神奈川駅では現在ホームドア施工中の京下・京上に発着
_
 ◀横浜駅に進入する「試9390K」試運転列車

 
  1月12日 H015編成郡山総合車セ入場
 
イメージ 5
電気機関車の牽引で東海道線を上るH015編成
 
 営業列車を用いて軌道状態を監視し、連続的なデータの集積によってメンテナンス頻度の適正化を図る「線路モニタリング装置」が横浜線にも導入されることになり、各種装置の取り付けのためH015編成が郡山総合車両センターへ配給回送されました。
 「線路モニタリング装置」は既に京浜東北線や中央線などで各線区1〜2編成程度設置が進んでいますが、横浜線では初めての導入になります。
 

  1月14日 日々の撮影
 
イメージ 6 イメージ 7
H004編成(左)とH013編成(右)

 研究がひと段落し、天気もよかったので撮影へ。久々に十日市場駅付近のポイントを訪れましたが、時期尚早だったようで木の陰が伸びていました。昼過ぎには成瀬〜長津田間のお立ち台に移動し、ちょうど運用入りしていたH013編成を撮影。3号車に搭載しているFRPキセのクーラーが目立ちます。
 

  1月17日 大船駅10番線到着「734K」
 
イメージ 8
イメージ 9

 夕方の大船折返し運用なき現在、唯一無二の存在となってしまった大船駅10番線折返し運用である「734K」を撮影。
 某ニュースサイトに掲載された横浜線のダイヤ改正情報から廃止の臭いがしましたが、まさか本当に廃止されるとは思ってもみませんでした……。

 大きなカーブを描いて駅に到着する列車(上)、
 大船駅10番線に停車する横浜線(右)


  1月19日 相原七国峠を攻略せよ
 
イメージ 10
イメージ 11

  七国峠は横浜線が相原〜八王子みなみ野間の
 トンネルで貫く区間で、一部は住都公団の手に
 より開発が進められてきた一方、手つかずの自
 然も多く残る未開の鎌倉古道です。
  この山で藪漕ぎをして単線区間風の写真を撮
 る計画から2年余り、ついに実行しました。
 
 相原トンネルに入る上り列車(左)と、
 宇津貫緑地からの夜景(上)


  1月22日 今年の雪〜その1〜
 
イメージ 12 イメージ 13
ベルが鳴りやんだホームで(左)、雪降る東神奈川駅に到着する列車(右)

 この日は朝から雪が降っていましたが、研究の関係で夜のみ撮影。深々と雪降る東神奈川駅でのカットです。テレビでは「平成26年豪雪」が引き合いに出されていましたが、横浜線は減便こそあれど大規模なトラブルに陥ることはありませんでした。夜遅くまで雪かき等に尽力して下さった関係者の方々、本当にお疲れ様でした。


  2月1日 早朝の小机駅

イメージ 14
515K各駅停車八王子行@H008編成

 夏に発刊予定で鋭意制作中の新刊『E233-6000 data library』の取材のため、初電で小机駅を訪れました。車内の小物を色々撮るには、ガラガラの小机始発が一番いいんですよね。
 写真は中線発着列車の合間に撮った下り列車。日の出が遅い冬期限定のカットです。


 駆け足で掲載してまいりました。4月からは仕事で学生時代ほど自由が利かなくなるので、今のうちに新刊で使いそうな写真は撮っておこうと走り回っております。ただ、他にもやらなきゃいけないことがたくさんあるので……もう飽和しています。本当は1つ1つ記事にして、細かく書きたいこともあるのですが、そんなわけでこのような雑なまとめになってしまうことをお許しください\(>_<@)/

開くトラックバック(0)

イメージ 1

 最近、コンピューター上で作成した3DCGデータをそっくりそのまま立体造形してくれる3Dプリンターの普及が進み、プラスチック鉄道模型も「自分で作る」時代になってきました。これまで、自作の真骨頂といえばペーパーモデルでしたが、プラスチック造形が容易に行えるようになったことで、床下機器などの小さなパーツや、製品化されていない車両のキットそのものを個人で作ってしまうケースが珍しくなくなりつつあります。
 私は横浜線の205系とE233系が専門ということで、模型もその2形式ばかり集めているのですが、日頃実車で細かい特徴を探っているだけに、模型も「買ってそのまま」というわけにはいかず、細かい加工をしたくなってしまいます。特に、横浜線の205系といえば大手メーカー「KATO」の製品が思い浮かびますが、実は床回りが実車と異なっていて、「雰囲気」や「タイプ」で割り切れないモデラーの悩みの種になっています。
 そこで今回は、KATO製品の横浜線205系に取り付ける、「DT50D/TR235D」台車を3Dプリンターで製作してみました。


  そもそも台車の何が違う?
 
イメージ 2
 205系の台車は一般に「DT50形/TR235形」と言われますが、実は山手線の32編成目から仕様が変更され、「DT50D形/TR235D形」を名乗るようになりました。
 問題なのはここからで、山手線の49編成目からは同じ「DT50D形/TR235D形」の名前で台車構造を少し変えたものが登場しました。側面に突き出している枕木方向の梁の回りが従来より厚くなっているのが特徴で、ヤテ49編成以降の205系は一部を除き全てこの台車に統一されたため、全体的には「DT50D形/TR235D形」の後期タイプが圧倒的多数となります。

 ではここで、Nゲージ鉄道模型メーカー各社のDT50形台車を見てみましょう。

イメージ 3
■KATO(K社)
 オーソドックスなDT50形台車です。車軸の表現は簡素ですが、他社に見られない特徴として応荷物重装置の棒や軸ばねの固定具が再現されています。
 しかし、左右のレリーフを180°反転させて作成しているため、応荷重装置のピンの位置が必ず片方違うほか、造形の都合なのか軸ばねの形状が残念です。

イメージ 4
■TOMYTEC(T社)
 TOMIXの製品は手持ちがないので鉄コレ用を。軸ばね部分の再現度がピカイチ。車軸やブレーキ部分もよく再現されており、側梁の穴は内側に凹ませてより実感的な見た目としています。全体的に完成度が高く好評価ですが、付随台車のTR235は製造していないため、付随車でもDT50が付いています。

イメージ 5
■MICROACE(M社)
 TOMYTECには及びませんが、車軸や軸ばね部分の造形は奮闘しています。空気ばねが他社に比べて薄く大きい点が特徴です。
 残念なのは、側梁や軸受けの下部分の厚みが大きくなりすぎてバランスを崩しているのと、台車側面中央部の突起が省略されている点です。

イメージ 6
■GREEN MAX(G社)
 側梁の穴や車軸のピン表現、ブレーキ回りは頑張っていますが、複雑な構造の軸ばねを円柱3つで片付けるという暴挙をしています。ほかにも、軸ばねから側梁に向かって謎の線が伸びているなど、全体的に雑な印象。入手性はいいので、なにかの素材には使えるかもしれません。

イメージ 7
 台車で大切なのは「バネ」ということで、各社の軸ばね構造の比較を作りました。見た目にもかなり影響を与える部分だと思うのですが、形状は各社まちまちといったところ。再現度では先述の通りTOMYTECさんが優勝ですかね。
 ただ、205系の台車をリアルにしたいからと言って鉄コレの台車を大量に入手するのは困難ですから、どこかで妥協が必要になってくるでしょう。
 ところが、ご覧のとおりヤテ49編成以降の「DT50D後期形」の台車はそもそも製品がありません。妥協するにもしきれない状況なのです。


  3DCGで描くDT50D後期形台車
 
 それではいよいよ、横浜線の205系に必要不可欠な「DT50D/TR235D」後期形台車の自給自足体制に入ります。
 3DCGのソフトはいろいろありますが、模型用のパーツを作るにあたってスケールがわかることが必要最低限の条件になるため、これまで趣味で使っていたMetasequoiaのフリー版では対応できないことが発覚。眠っていた123D designというソフトを使うことにしました。そしてこの記事を書くためにソフトの説明を使用と思ったのですが、昨年中にサービスが終了していて、公式サイトも閉鎖されたとのこと。なんてこった。
イメージ 8

 123D designは、メモリこそ喰うもののシンプルで使いやすいソフトでした。図面や写真、既製品の台車を参考にちまちま基本図形を組みわせて描きあがったレリーフが上の図です。わざわざ「メーカーが製品を作らないから」ということで身の程知らずの自作をするというわけですから、妥協無しでの自分との勝負です。
 最終的にKATO製品に付けることになるので、KATO製台車をノギスで細かく採寸し、サイズを合わせて行きます。

イメージ 9
 おなじみの構造。最初は基本部分とレリーフを分けて製造し、工作段階で組み上げて1つの台車にすることを考えていました。しかし、既存の集電板を使うことを考えると、レリーフの中央部には集電板が挟まるため、基本部分との接着はレリーフ上部の限られた面積で行わざるを得ません。流石に強度がもたないので、一体成型に計画変更です。

イメージ 10
 画面上で組み上げてみます。
 結構それっぽい感じになりました……!! せっかくなので既製品の台車を履いているときよりも、少し車高が下がるように調整し、ブレーキ回りなど残りのパーツを作ります。
 また、動力台車は別途設計を行う必要があるため、ノギスとにらめっこしながら値をメモしていきます。

イメージ 11

 ブレーキ回りを描き分け、DT50D(上)とTR235D(下)のレリーフが完成しました。これを180°反転……ではなく鏡像反転して、基本部分と連結すれば台車の出来上がりです。180°反転すると、応荷重装置の棒の位置が変わってKATOの二の舞になってしまいます。
 基本的に凹凸をどこまで細かく表現できるかはプリンターの性能にお任せでよいのですが、ブレーキ回りのシリンダーなどは細すぎると造形自体ができないため、利用するサービスの条件をよく確認する必要があります。(→DMM利用:アクリル(Xtreme Mode)の場合

イメージ 13
 最後に、オマケとして「差圧弁」というものをつけます。これは片方の空気ばねが異常をきたした際に、左右の空気ばねの空気を融通させて車体のバランスを保つための弁で、ボルスタレス台車における大切なアイテムのひとつです。
 ところが、台車の片側にしかついていないため、大抵の模型では省略されているのです……。


イメージ 12

 入稿用データは動力台車1両分を含む2M2T構成とし、8個の台車をランナーでつなげて1つにしました。
 今回はDMMを利用しますが、DMMは入稿データを必ず1つの立体にまとめなければならないため、複数のパーツがある場合にはこのようにランナーでの接続が必須です。また、台車は垂直に立てた方が良い結果が得られます(後述)。


  入稿そして結果は……

イメージ 14

 データはstl形式で出力し、DMMの専用フォームにアップロードします。すると自動でデータチェックが行われ、各材質に対する見積もりがメールで届きます。
 鉄道模型のパーツは基本的に「アクリル」の「Xtreme Mode」を利用することになるので、見積もりの該当項目が製造に必要な単価と言うことになります。単価は材料によって当然異なりますが、「初期費用」「体積による費用」「空間による費用」の3つのパラメーターで決定される用です。「体積による費用」「空間による費用」の違いは、体積が3D構造物そのものの大きさを表すのに対し、空間は構造物に外接する直方体の大きさを表しています。つまり、同じ体積の立方体と球では、球のほうが値段が高くなります。

イメージ 15

 こちらが完成した台車です。こだわった軸バネやブレーキ回りの構造がよく表現されていて満足です。かかった費用は約4000円で、1両あたり1000円といったところ。市販の台車に比べると2倍程度の値段になりますが、3Dプリンター界隈ではこれぐらいが相場ではないかと思います。「空間による費用」を工夫すればもっと安くできるのかも……?
 さらっと「台車は垂直に立てた方がよい」と先述したのですが、これは3Dプリンターの印刷方向(=積層方向)による都合です。レリーフが地に対して垂直方向に存在するデータを入稿した場合、最も繊細なレリーフの部分の再現精度が著しく低下するほか、車輪を入れる際にある程度必要な柔軟性もなくなってしまいます。「細かく再現したい面」を「地面と平行に」したデータを入稿するといい結果が得られます。もちろん、サービスやプリンターによって違いはありますので、DMMのアクリル(Xtreme Mode)以外での条件は分かりませんが、異方性があるということだけは認識していただいたほうがいいかもしれません。

イメージ 16
 動力台車も組み上げてみました。左にある黒い台車がKATOの既製品です。少し取り付け部分が緩かったので、再調整する必要がありそうですが、走行試験は一応クリアしてくれました。
 素材自体が結構脆いので、台車を入れるときに細心の注意が必要です……。以前に実験で作った動力台車は、台車をはめたりはずしたりするときにポキポキ折れてしまいました。この辺りは今後の課題ですね。


 塗装はまだですが、1編成換装したらまた記事にしようと思います。また、DMMにはクリエイターがアップしたファイルを公開して、3Dデータや成果物を販売できる環境がありますので、準備が整い次第この「DT50D/TR235D」後期形台車も出品したいと考えています。
 今後は205系の床下機器やクーラーも作っていきたいと思いますので、暖かい目で見守ってあげてください。

開くトラックバック(0)

 本の制作で地味に大変なの作業のひとつが「写真の選定」である、という話は最近いろいろなところでしています。最新作の『失われた205を求めてⅡ』ではそれについてサークル京都支部長である"お茶"と語っていますし、私自身事あるごとに愚痴を漏らしています。

 いったいなぜそれほどまでに大変かと言うと、これまでに撮影してきた横浜線の写真があまりにも多すぎるので、「昔撮った臨時回送列車の写真をここに使いたいな〜」などと思い始めようものなら、数十分は簡単に無駄にしてしまうのです。さらに、編集中は「次のH014編成の写真だけど、これまでに載せた写真と撮影地は被らない方がいいし、配置からして右向きでカーブの構図がいいな……」といった感じで、膨大な写真から細かい条件に見合うものを探し出すという途方もない作業が"頻繁に"発生します。
 そんな無駄の多い作業も流石に凝りてきたので、最近はファイル名に「撮影日付」と「編成番号」を入れることにしました。検索時に編成番号を入れれば、その編成の写真だけピックアップされるという当たり前のことにひどく感動。しかし、その感動も束の間……問題に直面しました。もうお分かりでしょう。

正直、面倒くさい。

 写真を開き、日付と編成番号を確認して手入力。あほらしい。しかもハードディスクにはリネームしていない過去3年分のデータが眠っています。これは無理だ。

 ある日、Twitterで「入力された二次元画像から絵師の性別を当てる」という面白いアカウントがあることを知った私は、ふと大学でOpenCVを触ったのを思い出します。
 OpenCVとは、画像や動画の処理・解析を手助けしてくれるオープンソースの巨大なライブラリで、各種OSに対応しており幅広い分野で使われているものです。大学時代は、OpenCVを顔認識や画像変換程度にしか使っていませんでしたが、折角の機会なのでもう少し遊んでみることにしました。

 そんなわけで、
「横浜線E233系の写真のファイル名を、ボタンひとつで撮影日+編成番号に変える」
ソフトウェアの開発を目指します。


 ファイルの読み込みなど基本的なところはさておき、最大の問題は「編成番号をどのように推定するか」ということです。今回は編成写真を対象に考えているので、編成写真の車両先頭部分から編成番号部分のみを抜きだし、文字化するという手順になります。
 OpenCVには標準で顔認識用の分類器が付属しています。分類器は大量のサンプル画像を集めれば自作することもでき、「猫の顔検出器」や「アニメ顔検出器」など偉大な先人による様々な分類器が公開されています。しかし、今回は「横浜線の編成番号」を検出しなくてはなりません。当然そんなものはあるわけがないので、作ります。
 編成番号の大きさは写真全体のサイズに比べて小さいので、最初から編成番号を当てにいこうというのは無謀です。そこで、まずは車両の先頭部を検出することを考えます。

 コンピューターに「どんな画像が正しく」「どんな画像が違うのか」を学習させるため、まずはポジティブ画像(=正解とされる画像)を集めます。およそ7000枚必要と言われていますが、流石にE233系の写真はまだ7000枚もないので、手元にあった600枚を使います。
イメージ 1

 元写真をひたすら切り抜くこと3時間、傾きや光線、構図がばらばらの正面画像データが600個できました。完成したファイルはサイズがバラバラなので、全て同じサイズになるようにフリーソフトで400px四方に一括変換。ファイル名はスペースが混ざると機械学習時にエラーとなるため、一括リネームして000〜599.jpgとしました。
 さて、やっとの思いで作り上げた正解画像一覧ですが、学習データには「不正解画像」も必要です。不正解画像はネガティブ画像とも呼ばれますが、これが少なすぎると学習が十分に行えません。しかし、具体的な数の基準はなく、その中身も「正解でなければ何でもいい」という具合。先人の知恵を借りようにも、ポジティブとネガティブの比は2:1が望ましいという意見もあれば、1:2のほうがよいという意見もあり、全く役に立ちません。今回はとりあえず1000枚を用意することにし、ほかの電車や風景、住宅、人の写真などありとあらゆる画像を放り込みました。画像サイズはポジティブ画像に合わせ、こちらも400px四方に一括変換し、ファイル名も000〜999.jpgに。
イメージ 2

 OpenCvのbinフォルダに、「pos」「neg」「cascade」フォルダを作成し、ポジティブ画像はposフォルダに、ネガティブ画像はnegフォルダにそれぞれ保存して下準備は完了。
 続いて、学習データをコマンドプロンプトを使って作成します。[参考1][参考2]
 まず、正解画像は1つのベクトルファイルにまとめなくてはならないため、早速OpenCVに付属しているツールを使います。OpenCVは最新バージョンが3ですが、2.4と3.0では色々と変わりすぎていて大学時代苦労した思い出があるため、馴染みの深い2.4を使いますw

 1.コマンドプロンプトを管理者権限で起動

 2.初期階層を移動
  OpenCVがC:\直下にある前提での記述です。保存先がC:\直下でないと、作業途中で
  エラーを吐くことがあるようです。x64,vc12は作業環境に合わせて。 
  cd C:\opencv\build\x64\vc12\bin

 3.ポジティブ画像の一覧を作成
  コマンドプロンプトを使えば、指定したディレクトリに含まれるファイルの一覧を一括
  で出力できます。ただし、ポジティブ画像は座標情報が必要なため、出力されたファイ
  ルの末尾を補います。

  (置換前) poslist.txt
  C:\opencv\build\x64\vc12\bin\pos\000.jpg
  C:\opencv\build\x64\vc12\bin\pos\001.jpg
  C:\opencv\build\x64\vc12\bin\pos\002.jpg
  C:\opencv\build\x64\vc12\bin\pos\003.jpg
  C:\opencv\build\x64\vc12\bin\pos\004.jpg
  ……
  (置換後) [jpg]→[jpg 1 0 0 400 400]
  C:\opencv\build\x64\vc12\bin\pos\000.jpg 1 0 0 400 400
  C:\opencv\build\x64\vc12\bin\pos\001.jpg 1 0 0 400 400
  C:\opencv\build\x64\vc12\bin\pos\002.jpg 1 0 0 400 400
  C:\opencv\build\x64\vc12\bin\pos\003.jpg 1 0 0 400 400
  C:\opencv\build\x64\vc12\bin\pos\004.jpg 1 0 0 400 400
  ……

  座標はスペース区切りで正解画像の切り抜き範囲を表しており、[個数] [左上x座標] [左上
  y座標] [横幅] [高さ]から成ります。1枚の画像内に2枚の正解画像を設けるときは、[個数]
  が2となり、1つめの[左上x座標] [左上y座標] [横幅] [高さ]に続いて、2つめの[左上x座
  標] [左上y座標] [横幅] [高さ]を表記します。
  今回は全て切り抜き済みなので、すべて「1 0 0 400 400」でいいというわけです。

 4.ネガティブ画像の一覧を作成
  ネガティブ画像の一覧もコマンドプロンプトを使って一括出力します。座標情報は不要
  ですが、相対パスで記述しなくてはならないため手直しします。

  (置換前) neglist.txt
  C:\opencv\build\x64\vc12\bin\neg\000.jpg
  C:\opencv\build\x64\vc12\bin\neg\001.jpg
  C:\opencv\build\x64\vc12\bin\neg\002.jpg
  C:\opencv\build\x64\vc12\bin\neg\003.jpg
  C:\opencv\build\x64\vc12\bin\neg\004.jpg
  ……
  (置換後) [C:\opencv\build\x64\vc12\bin]→[.]
  .\neg\000.jpg
  .\neg\001.jpg
  .\neg\002.jpg
  .\neg\003.jpg
  .\neg\004.jpg

 5.ポジティブ画像を1つのベクトルデータに変換
  ポジティブ画像は1つのデータにまとめておく必要があります。ここで付属ツールのひとつ
  である「opencv_createsamples」が登場します。
  opencv_createsamples.exe -info poslist.txt -vec ./vec/pos.vec -num 600 -w 400 -h 400

  -info では先ほど作成したポジティブ画像の一覧データを指定します。
  -vec ではベクトルデータの保存先とファイル名を指定します。
     フォルダは自動作成されないため、あらかじめ作らないとエラーになります。
  -num はポジティブ画像の数(一覧データの行数)です。
  -w -h はそれぞれ画像の横幅と高さを表しています。

  作成に成功すると、指定した保存先にvecファイルが生成されます。

(5.5.ベクトルデータをまとめる)
   実は、「opencv_createsamples」には1つのサンプルから傾きなどが異なる複数のサ
  ンプルを作り出してvecファイルにまとめる機能もあります。
   この機能を使うと、5枚のサンプルでも各100枚のデータを合成することで500枚分相
  当のサンプルを得ることができるのですが、1つにまとめなければならないvecファイル
  が5つ生成されてしまうため、合成作業が必要になります。
   合成作業にはmergevecが便利ですが、python版しか見当たりませんでした。もし使
  う場合はpythonを実行できる環境も必要です。
  python mergevec.py -v ./vec -o ./vec/pos.vec
   当初はこの機能で約1万枚分のサンプルを取りましたが、結果から言うと現実の600枚
  にはかないませんでした。用途によってはアリなのかもしれませんが、今回はお蔵入り。

 6.学習データの作成
   学習データは、これまた付属のツールを使ってゆっくり作成していきます。サンプル
  の数や精度により所要時間は異なりますが、中断・再開も可能です。numPosはポジテ
  ィブ画像の数、numNegはネガティブ画像の数ですが、ポジティブ画像の数は実際の8
  割〜9割程度にしておかなければならないとか。(480=600x0.8)
  opencv_traincascade.exe -data ./cascade/ -vec ./vec/pos.vec -bg ./neglist.txt -numStages 10 -numPos 480 -numNeg 1000

  数値などは違いますが、学習中の様子はこのような感じ。
イメージ 3

 放っておくと、いつの間にか「Train dataset for temp stage can not be filled. Branch training terminated.」となって終了し、指定の保存先に学習ファイルである「cascade.xml」が生成されます。学習ステージが多ければ多いほど厳格な分類器ということになりますが、多すぎるとかえって検出できなくなることも。実装側でも調整パラメータがあるので、ほどよいところでやめにします。

 では実際にE233系の"顔認証"をしてみましょう。C#で開発するため、OpenCVのラッパー「OpenCvSharp」を使います。バージョンはOpenCV本体にあわせて2.4.10。dllの類は実行ファイルのある場所に移しておく必要があるらしく、片っ端からコピーしました。[参考3]
private void CascadeFinder(string cascade_file, string path) {
// カスケード分類器の準備
        Mat image = new Mat(path);
        CascadeClassifier cascade = new CascadeClassifier();
        cascade.Load(cascade_file);
        Rect[] faces = cascade.DetectMultiScale(image, 1.1, 3, 0, new OpenCvSharp.CPlusPlus.Size(image.Height / 18, image.Height / 18));
// 顔候補のうち面積の一番大きいものをマークする
        int t = 0, tmp = 0;
        for (int i = 0; i < faces.Length; i++) {
                if (faces[i].Width > tmp) {
                    tmp = faces[i].Width;
                    t = i;
}
}
        // 顔の枠を描画する
        Cv2.Rectangle(image,
                    new OpenCvSharp.CPlusPlus.Point(faces[t].X, faces[t].Y),
                    new OpenCvSharp.CPlusPlus.Point(faces[t].X + faces[t].Width, faces[t].Y + faces[t].Height),
                    new OpenCvSharp.CPlusPlus.Scalar(0, 255, 0), image.Height / 240, LineType.AntiAlias);  
// 基本画像のリサイズ
float height = image.Height;
float width = image.Width;
float resize = 0;
if (image.Height >= image.Width) { // 縦長画像の場合
                resize = width * (400 / height);
                Cv2.Resize(image, image, new CvSize((int)resize, 400), 0, 0, Interpolation.Cubic);
} else { // 横長画像の場合
resize = height * (600 / width);
                Cv2.Resize(image, image, new CvSize(600, (int)resize), 0, 0, Interpolation.Cubic);
}
// pictureBox1に表示
pictureBox1.Image = OpenCvSharp.Extensions.BitmapConverter.ToBitmap(image);
image.Dispose();
 }
 cascade.DetectMultiScaleが検出部分で、引数には検出精度の設定項目が含まれます。第5引数と第6引数にそれぞれ検出最小サイズ・検出最大サイズが指定できます。編成写真では全体の面積に占める電車の顔の割合が大きくなるため、小さい領域の検知は誤検知である可能性が高いです。しかし、入力画像の大きさは不定なので、画像の高さを基準にして最小サイズを設定しています。同じ理由で、直後のfor文では検出領域のうち最も大きいものを取り出すようにしています。
 実際にプログラムを動かしてみると、先頭の顔部分が緑枠で囲われており、一応検出には成功した様子。
イメージ 4

 しかしよく考えると自分の撮影データを学習に使っているんだから、自分の写真で検出できるのは当然かも……ということで、Googleで横浜線E233系の編成写真をかき集めて実験。スクショは載せられませんが、100枚中80枚成功という結果でした。
……横浜線の写真全然なくて、100枚集めるのがめちゃくちゃ大変でした。

 問題はここから。
 顔を検出できても、編成番号が分からなければ意味がありません。例によって番号は小さいので、検出した顔を9分割し、編成番号が含まれる部分をトリミングすることにしました。
イメージ 5

 リサイズ前の元画像から、4番部分をトリミングして編成番号を探そうというものです。これぐらい範囲が狭まれば、編成番号の場所も機械学習で当てられるだろうと調子づきます。バカのひとつ覚えで、今度は編成番号の学習データを作りました。その数530個。
イメージ 6

 早速機械学習させてみますが、学習ステージが3から先に進みません。これは、「学習用データが悪い」ことにほかなりません。しかし、一応cascade.xmlは生成されているため、ものは試しと実践してみます。

イメージ 7

 ……これはダメだ。
 車両前面のように「大きいところ」とはいかないので、条件に合った検出部分は全て描画させましたが、列番やYokohama Lineのロゴが検出されてしまっています。一見すると、y座標が一番高い枠を読めばいいように思えますが、他の画像ではガラス内の映り込みや光の反射も編成番号として検出してしまっており、どうしようもありません。
 誤検出部分を中心に新たにネガティブ画像を量産し、再度学習させてみましたが、多少マシという程度で使い物にはなりませんでした。

 そこで、より特徴的な点からの相対距離で検出することを考えます。
 というのも、顔の位置や角度などは写真によって様々ですが、中のパーツ自体は動かないため、「絶対に見つけられる点」からの相対的な距離で検出すれば間違いなく編成番号を当てられるだろう、ということです。トリミング済みの範囲で一番特徴的な点は……
イメージ 8

こ こ

 というわけで白・黒・黄緑の3色が分かれるポイントを基準点とする方針に。流石にこれも600個、というのは疲れるので100個くらいで訓練させてみました。
 同時並行で画像をテキスト化するOCRを準備。TesseractというOCRが便利そうだったのでNuGetから導入しました。検出に必要なのは「H」と「0〜9」だけなので、精度を高めるためにもその旨を記述。
private void FormationOCR(Bitmap image) {
// オブジェクト定義
var tesseract = new Tesseract.TesseractEngine(@"C:\tessdata", "eng");
tesseract.SetVariable("tessedit_char_whitelist", "H1234567890");
// 画像呼出
        var img = new System.Drawing.Bitmap(image);
        // OCRの実行と表示
        var page = tesseract.Process(img);
        // 内容による分岐
        string formation = "";
        formation = page.GetText().Replace(" ","").Replace("H", "").Replace("00","0");
        try {
        int f = 0;
        f = int.Parse(formation);
        comboBox1.SelectedIndex = f;
        } catch {
comboBox1.SelectedIndex = 0;
}
}
 TesseractEngineでは学習データファイルのあるディレクトリを指定し、第2引数で言語を指定しています。データはこちらからダウンロード可能。ここでは最終的にH---,H001〜H028が書かれたコンボボックスの値を選択しています。さて、これでどうか……

イメージ 9

イメージ 10

やりました!

 撮影日時はExifデータの0x9003を読んで変換しているだけで、保存名はこれまでの自分の保存ルールにのっとって「YYYYMMDD_HHMM(H***)」になっています。編成は主動による指定および修正も可能な仕様です。
 もう少し他の写真でも実験。夜間の写真は読取精度が落ちますが、意外と読めているものもありました。本当はそれこそOpenCVで画像処理してOCRに突っ込んであげるべきなんでしょうが、とりあえず読めてはいるので様子見です。
イメージ 11

 こちらは曇天。イメージ 12

 顔の検出精度は7〜8割程度。顔が見つからないと編成番号は当然見つかりません。イメージ 13

 基準点は学習用データが足りていないのでまだまだ未熟で、たまに車体側面を拾ってしまうようです。そうすると当然編成番号の枠もずれてしまいます。
イメージ 14

 とりあえず、思い付きの企画もどうにかひと段落ということで、手元の画像200枚を使って編成の判定ができるかを試してみました。
イメージ 15


 結果はご覧のとおり。正面検出率は先述の通り7割程度ですが、その中で編成の判定ができたのは4割未満と課題の残る結果です。「判定失敗」には、そもそも基準点が特定できず編成番号が発見できないものと、編成番号の枠がずれてOCR処理をしても結果が得られなかったもの、枠は正しい位置にあったがOCR処理が上手くいかなかったものが含まれます。
 相対位置による編成番号の枠決定については、顔として判定される枠の大きさや編成自体の傾きを考慮に入れてはいるものの、まだ詰めが足りておらず、位置がずれてしまう写真も多々あるのが現状です。今後は、枠の位置をより正確にすること、そして傾き補正などを施すことでOCRの読取精度を高めていきたいところです。

 ところで、機械学習用の画像を大量に用意したり、ああでもないこうでもないと試行錯誤したり、やっぱりファイル名を1つずつ地道に手で打った方が早かったんじゃない?という点についてはノーコメントということでお願いします。

開くトラックバック(0)

本文はここまでですこのページの先頭へ
みんなの更新記事