OpenCV4 × YOLOによる物体検出技術の製造業向け応用

近年、製造業における品質管理や自動化のニーズが高まる中、画像処理技術の進化が注目されています。弊社では現在、社内画像処理ライブラリにOpenCV4YOLO(You Only Look Once)を組み合わせた物体検出機能の追加を進めており、生産ラインでの外観検査や誤組検査への応用を視野に入れた事前検証を行っています。

OpenCV4とYOLOの技術的特徴

OpenCVは画像処理の定番ライブラリであり、フィルタ処理や輪郭抽出、幾何変換など多彩な機能を備えています。一方、YOLOは深層学習ベースの物体検出アルゴリズムで、画像内の複数の対象物を高速かつ高精度に検出できる点が特長です。これらを組み合わせることで、従来のルールベースの検査では困難だった複雑な形状や微細な違いの検出が可能になります。

製造現場での活用例

  • 外観検査:製造工程でのOK品/NG品をリアルタイムで選別
  • 誤組検査:部品の有無や配置の誤りを自動判定
  • 工程監視:作業手順の逸脱や異常動作の検出

これらの検査は、従来は人手に頼っていた部分が多く、検査精度や作業負荷に課題がありました。画像処理による自動化は、検査品質の均一化と省人化を同時に実現する手段として、今後ますます重要性を増すと考えられます。

今後の予定

弊社では、検証段階で得られた知見をもとに、製造業向けに最適化された画像処理ライブラリの開発を進めてまいります。現場のニーズに即した柔軟なソリューション提供を目指しています。

Macの容量削減

VS for Macがサポート終了してからはMacで開発を行うことがなくなったため、
Macの用途はもっぱら次の3つです。
・MAUIのビルド(のためにWindowsのVSとペアリング)
・iPhoneアプリのリリース申請
・iPhoneアプリの証明書更新
今回MAUI9.0(.NET9.0)に対応する必要が生じ、
そのビルドのためにXcodeのバージョンアップを行おうと思ったのですが、
OSが対応していなかったためまずはOSの更新から行うことになりました。

しかし、Macの容量はもうパンパンで残り2GB(そんなことあります?)となっていたので、
Finder上で目に付いた不要そうなファイルを整理しました。
それにより空きが8GB弱となり、ダウンロードされるOSの容量7GB弱分を確保できたので
意気揚々と更新を開始したのですが、容量が足りないと怒られました。
更新時に25GB弱必要だそうです。Oh…

設定のストレージから整理しろ(※)と言われたのでストレージを見てみたところ、
詳細を確認可能な項目の内、デベロッパの項目が47GBと抜きんでていました。
※Macにいまだに不慣れなのでiOSと同じ形式でストレージが管理できるの失念していました
中身を見てみるとXcode関係で、
iOSデバイスサポートのセクションに数GB単位の項目がずらりと並んでいました。
消せそうだと思い調べてみたところ、

ここは、実機デバッグをするとシンボル情報などが実機からダウンロードされて保存されるようです。
実機のOSバージョン毎に追加され、一つが大きいので、肥大化しやすいようです。
消しても次回接続したときにまた作成されます。

引用元:開発macの空き容量を20GB以上増やした。 #iOS – Qiita

とのことだったので全て削除して50GB以上の空きができ、
無事OSの更新を開始できました。
長年デバッグのために接続したデバイス・OSの情報が蓄積され続けていたのですね。。。

以下のキャプチャは消している最中のものです。

大分容量に余裕が出たので、
MAUIのビルドのためにVSとMacをペアリングする際によく容量が少なくなってると注意を受けて
Xamarinのキャッシュを削除していたのですが、その必要もなくなりそうで良かったです。

以上です。

特定の言語

こんにちは mtj です

自分は昔はCOBOLだったり JAVAだったりそれこそC,C++等も覚えたりしましたが
JAVAを勉強している時に別の学生に言われたことは「C++が一番なんじゃないの?」のようなセリフでした
おそらくどこかの教授の受売のような話なのでしょうが 自分は用途に対する利点と欠点はあったとしても〇〇の言語が一番のような話は無いと思っています。

同じようにCが基礎 だから覚えないといけない という話も基本無視するレベルの話だと思っています。

言語はその時々で必要な物を選択できてこそエンジニアだと思っています
時々は必要な開発期間、コスト等すべて含めてとなります

C#よりC++のほうが実行速度が早くとも 実行時間が100秒が99秒になるレベルであればコストが一番低い方を選択するべきだと思っています

OpenCV4で実現するテンプレートマッチングのマスク処理対応

製造業における画像処理技術は、品質管理や工程監視においてますます重要性を増しています。弊社では社内画像ライブラリをOpenCV2からOpenCV4へとアップグレードし、テンプレートマッチングにおけるマスク処理への対応を実現しました。

OpenCV2の限界とOpenCV4の進化

OpenCV2では、テンプレートマッチングにおいてマスク画像を使用することができず、背景ノイズや不要領域が一致率に影響を与えるケースが多くありました。これにより、微細な部品の検出や位置合わせにおいて誤検出が発生するリスクがありました。

OpenCV4では、テンプレートマッチングにマスク画像を指定できるようになり、テンプレート画像の中で注目すべき領域だけを比較対象にすることが可能となりました。これにより、検出精度の向上誤検出の低減が期待できます。

製造現場での活用例

例えば、電子部品の外観検査において、端子部分のみをテンプレートとしてマッチングさせることで、基板の模様や背景の影響を排除できます。これにより、検査工程の自動化がより高精度に行えるようになり、不良品の流出防止にもつながります。

今後の展望

弊社では、OpenCV4の導入を皮切りに、AIベースの画像認識技術(YOLOやTensorFlowなど)との連携も視野に入れ、より高度な検査・分析システムの構築を進めています。画像処理の精度と柔軟性を両立させることで、製造業のDX(デジタルトランスフォーメーション)を支援してまいります。

画像処理の導入や既存システムの改善をご検討中の方は、ぜひお気軽にご相談ください。

数学の面白さ

こんにちは mtj です

プログラマーに数学がいるかいらないかについては自分はプログラムを書くだけならいらないと思っている派です
現代であれば誰かが作ったライブラリを使えば計算も気にせず思った通りの物がだいたい作れてしまいます。

しかし プログラムはそういったとこまで自分が作るので楽しいという側面があります。
物理現象等を再現するのに大事になってくるのが数学、各学問の計算式等になります

自分も学生の時に物理と流体の本を読みながら流体のシミュレーターのような物を作成しました
再現に必要な計算式をピックアップしコードに落とし込み 実際の流体動作の再現をできた時はかなり楽しい物でした

アナログな電気回路を再現するならそれらの知識 自分がやったような流体であれば物理系の知識 波形、光学であればそういった知識等
現実世界で発生している現象をデジタル、ソフトで再現するというのはソフトの触り始めとしても悪くないのではないかと思いました

それこそ始めたてはコンソールでHello worldを出したりしますが 慣れてきたら自分で頭を作って作るアプリが一番楽しいと思います

C#11と12の機能いくつか

本日から弊社のメインとなる案件のプロジェクトにて
使用可能なC#のバージョンが12まで引き上げられました。
(今までは9や10でした。)
使用可能になった11と12の機能にさらっと目を通して来たので、
知らなかった便利そうな機能や使ってみたかった機能を4つほど紹介してみます。

1. 生文字列リテラル

string longTxt = """
    toooooooooooooooooooo...
        looooooooooooooooooong...
            teeeeeeeeeeeeeeeeeeeeeext...
    """;

文字列をダブルクォーテーション3つで囲うことで、
エスケープなしで改行や特殊記号などを含めた生の文字列を
ソース内に直接記述可能となるそうです。
改行を含んだ長文の文字列の可読性が改善されてかなり便利そうなのですが、
社内ツールの英語化用日本語抽出ツールに対応が必要になりそうなのは懸念点です。

C# 11 の新機能 – C# ガイド – C# | Microsoft Learn

2. コレクション式

List<int> No = [1, 2, 3];

リストなどのコレクションの値をpythonのような構文で
簡潔に作成できるようになったようです。
毎度冗長だな、、、と思いながら書いていたのでありがたいです。

C# 12 の新機能 – C# ガイド – C# | Microsoft Learn

3. ファイル修飾子

file class LocalObject { }

可視性を記述されたソースファイル内に限定する修飾子です。
ファイル外のクラスとは名前の競合も起こらないので、
そのソースでしか使用しないちょっとしたクラスを定義するのに便利そうです。
使ってみたかったのでうれしいです。

ファイル キーワード – C# reference | Microsoft Learn

4. usingによるタプルのエイリアス

using AtoF = (int A, int B, int C, int D, int E, int F);

usingによりタプルに名前を付けることができます。
何度か登場して冗長に感じるもクラスにするほどではないタプルを
省略して書けるので便利そうです。
使いたいことが今まで何度かあって、
その度に言語バージョンに泣かされていたのでこれもうれしいです。

タプル型 – C# reference | Microsoft Learn

以上です。
他の機能も含め新機能使っていきたいです。

OpenCV4対応による画像処理の高速化

社内画像ライブラリを最新のOpenCV4に対応させることで、画像処理の高速化を実現しました。
製造業の現場で求められる高精度な検査や解析において、処理速度の向上は大きなメリットとなります。

今回の対応では、テンプレートマッチングによる一致箇所の検出、濃淡補正による濃淡箇所の抽出、メディアンフィルタやバイラテラルフィルタによるノイズ除去など、複数の処理を最適化。
特にバイラテラルフィルタは、エッジを保持しながらノイズを除去できるため、外観検査に有効です。

これらの技術により、画像処理の精度と速度を両立し、製品品質の向上と検査工程の効率化に貢献します。
画像処理の導入や高速化にご興味のある方は、ぜひご相談ください。

システムの検討

こんにちは mtj です

自分たちはシステムを依頼される側ですが 相手により依頼のされ方はバラバラです。

やりたい事、出したいデータ等を依頼される方、結構具体的な内容の資料を作らる方等あり
どちらが楽かというと一概には言えないと思います

具体的な場合のほうが作るだけだったりありますが 実現不可能な物を具体的に書かれていたり
システムとして矛盾があるような場合もあります

やりたい事、出したいデータのみの場合も あまりにも抽象的すぎたり、システムのイメージがなかったりするとそれも話が長くなります。

自分が思うシステムを依頼する場合に必要な物といえば

  • システムに対する具体的な作業(データを見て〇〇する等)
  • そのデータを表示、出力するために必要なデータ(人が入力 データベースから取ってくる等)
  • 作業のために必要な具体的なデータ(データが〇〇の時は△△する等)

システムは何かすらの最終出力がある物だと思っているので 自分が抑えるのはシステムの最終結果どうしたいかを抑えます
そこが曖昧の場合は良いシステムが作れないと思っています。

改めて思うとUMLのユースケース、シーケンス図はユーザー側でも覚えたほうがいい図なんだと感じました。

スクレイピング機能のエラー対応

先日、スクレイピング関係の機能の不具合対応を行いました。
スクレイピングにより抽出したWebページをWebViewにより表示する機能なのですが、
実行により404のエラーページが抽出され、エラー表示となってしまう不具合でした。
根本原因は対象のWebページの仕様変更による誤ったページの抽出だったので、
現在の仕様に合うように抽出処理の修正を行いました。

しかしこの修正を行った後でも、
正しく抽出したページが稀に404などのエラーページになる可能性があり、
その場合同じエラー表示となってしまうため、対策を入れることにしました。
WebページをWebViewで事前に開く前にHttpWebRequestによりHttpStatusCodeをチェックし、
エラーの400番台以上なら別のページを試行するようにしました。

これにて解決かと思ったのですが、人間なら問題なくアクセス可能なページでも
プログラムからだとbot対策のWebApplicationFirewall(reCAPTCHAなど)に引っ掛かり
エラーコードが返って来るケースもあるとわかりました。
そのケースのレスポンス内のHTTPについて調査したのですが、
サービスにより内容が異なるようで汎用的にWAFのレスポンスか判定は不可能に思われたので、
ひとまずWAFの可能性のあるエラーコード(※)の場合は通すようにしました。
これで一旦様子見してみます。
※403, 406, 418, 503, 1020(チャットAIにも教えてもらいました)

OpenCV2とOpenCV4の共存(既存資産を活かしつつ最新機能を導入)

社内で長年活用してきた画像処理ライブラリはバックエンドに「OpenCV2」を使用しています。

今後の機能拡張やアルゴリズム強化のために「OpenCV4」の導入を進めてきました。
しかし、両者はDLL名やネームスペースが重複しているため、そのままでは共存できず、新旧ライブラリの併用が大きな課題となっていました。

そのため、OpenCV4のソースコードを一部修正し、DLL名およびネームスペースをOpenCV2と競合しないように調整しました。
この修正により、既存のOpenCV2ベースの実装には一切手を加えることなく、OpenCV4の高度な機能を新規開発に取り入れることが可能となりました。
これまでの資産を活かしつつ、段階的な技術アップデートが実現できる柔軟な環境が整いました。

今後はOpenCV4を活用し、より高度なAI処理やGPUアクセラレーション技術の導入にもスムーズに対応していく予定です。