画像処理屋視線のお話です。それぞれの長所を考えてみました。 人間の目：「適応的」な部分が最大の特徴だと思います。 じっと見て小さな差を見つける事もできるし、一瞬の情報から大局的な情報を得る事もできます。 見えにくいと思ったら、目を細めたり無意識に行いますよね？色情報なども無意識に使ったり、無視したり。 カメラの目：目的に特化したカメラでは、人間を超えてます。 例えば、人間の目では「適応的」に頑張っても、とても暗い中では眼力に限りがあります。 しかし、光学的に増幅して得た映像は人間より暗い空間でも対象物が見えるのです（完全に光の元を遮断すると見えません） 人間の目には感知できない波長も特化したカメラならば見えます。これは、音の世界でも同じですね。 赤外や紫外は、人間が見える「可視光」と言う範囲を超えた波長を使うので更に話が変わります。 画像処理屋の仕事は、これら「目」の部分から得られた情報を「脳」の部分で処理する部分を「実現する」が仕事になります。 ＊ニュースは、弊社メルマガで配信されてます。

実現手段にソフトやハードで開発提供してますが、「FPGAによる高速化」とご案内している事で誤解がある事が珍しくありません。 ソフトで実現した処理は、どんな処理でも専用ボードを開発すれば「高速化できる」が大きな誤解なんです。 むしろ、FPGAによる高速化できる処理は限られてます。 大量に同じ演算を【同時】に実行して良い処理。コンボリューションフィルタなどが、一番適している例です。 積和演算を【同時】に行っても良いので必要数の乗算と加算回路を搭載すると、どんなに広範囲でも１クロックで結果が得られます。 また「パイプライン処理」が可能なものも、Ａと言う処理とＢと言う処理を、ソフトでは、Ａ処理後にＢ処理を行い、またＡ処理に戻る。 がハードではＡ処理後Ｂ処理に移る時同時にＡ処理を行う事で処理時間が速い方の時間が消えていきます。 ５段のパイプラインでも１段分の時間で結果が得られる。と言うものです。 ちなみに、大容量の画像データにアクセスする際には、メモリもデータバス幅がとても広いGPUボードなども有効です。 ＊ニュースは、弊社メルマガで配信されてます。

エンジニアたるもの、振り返らず前を見よう。 と情報発信してきましが、あえて今回はこのタイトルにしてみました。 私の歩んだ道をご紹介します。 学校では、偶然「画像処理」をアルバイトにしてる先生の研究室に入りました。卒業して社会人として初めての仕事が「カメラを使った検査装置」の開発でした。 メインのCPUがモトローラの6809。画像処理部も74シリーズを使ってハードウェア回路を設計しました。 二値のテンプレートマッチングボードが、6Uサイズ２枚の規模でした。 自分で作った回路のソフトは自分で作る。が当たり前。カメラも最初は撮像管で後にCCDやCMOSに変わりました。 次のフェーズでは、CPUも68020でOSにUNIX、CPUボードも自前設計でした。 特殊な画像処理部は、AMDのビットスライス2901を使いました。このデバイスのお陰でマイコンの仕組みを習得しました。 偶然にも新卒から現在まで「画像処理」に関わり続けてます。 ハードとソフトの両方の設計経験が今の「システム設計」に活きていると思います。 ＊ニュースは、弊社メルマガで配信されてます。

用途によっては、動作時間保障をきっちり行わないと「使えない」画像処理があります。 「動作時間保障」にも、更に２種類を紹介します。 例１，検査装置用途 生産ラインの製造タクトタイム以内に処理を終わらせないと、次の検査対象を検査できません。 しかし、画像データが入力されてから、結果を出すまでの遅延時間は、タクトタイム内である必要はありません。 結果に対して、リジェクトする機構までの遅延は許容できます。 この「遅延が許容される」を上手に使って、尚且つ「遅延時間は固定で保証する」を守れば例２より、実現コストが削減できます。 例２，追突防止 自動ブレーキと呼ばれるもの等が説明が楽かと思います。 衝突防止ブレーキなので、検知してから「止まれ」と判定するまでの時間は速ければ速いほど良いです。 しかし、カタログスペックに落とすには制動性能とセットになるので、「最大遅延」として動作速度保証が必要になります。 こちらは、例１よりコストをかけても速度を取ります。 同じ用語でも違う性能を求められるので、要望理解が大切と言うコラムでした。 ＊ニュースは、弊社メルマガで配信されてます。

先端技術には、誰も試して無い。と言う怖さがあります。 ソフトウェアの進化で、自動アップデートも珍しくなくなりましたが、ハードウェアは、中身を後から入れ替える事は未だ実現できていません。 設計者は色々な配慮の結果「隠し」にする事があるのでご紹介します。 LSIやFPGAに設定されているレジスターは、外部から「設定」を行う為に備えられます。 この「設定」が「色々沢山設定できればより良い」と誤解を受けやすく沢山の設定があれば、その設定の意味を理解し、設定の順番なども考慮が必要になります。 理想的は「一切設定不要」で「電源を通電すれば動作開始」が使い易いです。 しかし、デバイスを設計した側と利用する側では、想定外の使用方法や想定環境と異なる使用があります。 そこでそれらにも対応すべく「設定」を表に出す事になります。 多ければ良いわけでもない。少ないと汎用性に欠ける。と悩むものです。 これに助けられた事も多いですし、これを公開されてなく困った事もありました。 私達が提供するFPGAもこの様な悩みながら仕様を決めていきます。 ＊ニュースは、弊社メルマガで配信されてます。

弊社の仕事説明をさせて頂くチャンスは、２種類です。 １、商談時　初取引の方に対しての会社紹介 ２、求人時　応募者の方に対する仕事内容紹介 １は、商談に入るぐらいですから、あまり色々なケースはなくスムースです。 ２の求人時の方が、ご応募者さんの背景から、どのようなところから説明するか探り探りになります。 例えば「画像処理業界は全く初めて」の場合もあれば「受託開発」と言うビジネススタイルが初めて。の場合もあります。 弊社の特殊性としては、少数でアルゴリズム開発、ソフト開発、ハード開発と異なるスキルが必要な業務を行っている為に必要な社内共通言語としての「Ｃ＋＋」と言う説明部を、ご理解頂く説明が難しい事もあります。 そこを乗り越えて、業務を理解頂かないと「こんな仕事とは思っていなかった」と双方にとって不幸になりますので、この部分の共通認識化には時間を惜しまずご紹介を続けてます。 ＊ニュースは、弊社メルマガで配信されてます。

「外部委託していたのでソースコードと回路図しか残っていなく仕様書が無いけど」 今回のテーマを見て、「あるある」との方も少なくないと思ってご紹介します。 まず、私達も上記の切り出しには関わりたくない。事をお伝えします。 ソースコードや回路図を、頑張ってステップ実行したりながら「仕様書もどき」を作る事は可能ですが、各所に「何故そのような方法で実現したか？」は逆流できないからです。 自分達で設計する時は、先に仕様書を作成しますので、実現手段で迷った時にも、仕様書に振り返れば「どちらの手段で実現すべきか」がわかります。 もちろん最初に作った仕様書ですから、設計しながら「この仕様の方がよりよい」に気づく事も「この仕様は、ここが矛盾」に気づく事もあり、設計を終えて（終えた時にできるものがソースコードや回路図）仕様書を改定する事は多々あります（改定しない方が珍しい）。 川を逆流して行ったら、ダムがあった。のように逆流できないものだと考えた方がスムースと考えてます。 ＊ニュースは、弊社メルマガで配信されてます。

画像処理だけの話ではありませんが、ハードに近いソフトエンジニアの参考になればと、変数のお話（ノウハウ）をご案内します。 SoCFPGAをご存じでしょうか？FPGAに組込用が内臓されたものです。 現在の主流は、TOP２社ともARMを内臓してます。ハード的な用語になりますが、このARMは「ハードコア」と呼ばれる物です。 一方もっと昔から、FPGAに小さなマイコンを内臓したい。 との要望に応える為に、FPGAの自由に組めるロジック回路を内臓できる仕組みを、各メーカーとも備えてます。 XILINX社では、MicroBlaze（TM)と言う名称でソフトコアを提供してます。 ハードコアと、ソフトコアは用途で使い分けてます。 ここで、知られていない注意点です。 cher型の変数が、MicroBlazeは、signed、ARMは、unsignedと言う点です。 え？と思われるかもしれませんが、符号付きか否かで同じ計算式でも答えは異なる事はご存じの通りです。 この注意点を知らずに移植すると、悩んでしまう事なのでご紹介してみました。 ＊ニュースは、弊社メルマガで配信されてます。

エンジニアの方にはご理解頂けると思いますが、とても難しいタイトルですね。 コラムなので、解り易く説明すると、我々人間が設計しているものの「間違いを探す」行為です。 しかし、難しくさせる理由は、全てが一人の人間が設計したものでは無い。と言う一点に尽きると思います。 例えば、ソフトの場合ですと、それを動作させるＯＳとかパソコンとかは、他人が設計したものです。 ハードウェアですと、装置が単独で使われるものでも、使っている電子部品までを装置設計者が設計したものではない為です。 不具合の原因が見つかるまでは、自分の設計部の間違いを見つける事が主になりますが、自分の設計以外の部分の不具合であった事も多々あります。 この切り分けと責任範囲の定義が難しいですが、グレーゾーンまで配慮している日本のエンジニアは、多々いらっしゃるでしょう。 当社のコラムが無くなるまでは、「デバッグ」と言う行為は無くならないと確信してます。 ＊ニュースは、弊社メルマガで配信されてます。

コンピュータを例に、人間が生み出す物は年々進化し続けてます。 メモリーの記録容量だったり、演算速度だったり、動作クロックだったり。 半導体の露光幅が、光の限界でナノで頭打ちと言われた事もありましたが色々な知恵で、進化し続けてます。 クロック周波数も、これ以上高いと皆電波になってしまう。と言われた事も、乗り越えて、更に多重化技術も進んでいます。 一方、人間の脳のキャパは、どうでしょう。 私は、脳科学者でも生物としての人間についても全くの素人なので答えは知りません。 自分を見ると、携帯やスマホのお陰で電話番号を覚えなくなったり、ナビのお陰で地図を覚えなくなったり、世代が変わるとキャパも増えているのでしょうか？ あまり、人間の性能UPに気づけてないので「広く深く」を求めません。 「広く」の人と「深く」の人は、別々に必要で「チームプレイ」で一つの成果を生み出す事を、日々行ってます。 今回のコラム、残念ながら投げっぱなしになります。 ＊ニュースは、弊社メルマガで配信されてます。

弊社の強みは、画像処理に特化した開発会社。 アルゴリズム開発からアプリ、ファーム、デバイスドライバ、ハード化と全て自社内開発だと、アピールしてます。 時々聞かれる事が「ハードエンジニアと、ソフトエンジニア」どちらが大切ですか？とか、どちらが難しいですか？です。 両方同じ会社内である事のメリットは、お伝えできますがどちらか一方を選ぶとか比較した事はありません。 また、時代と共にも変化しますが、敢えてコラムに書いてみます。優劣ではないく、比較してみたいと思います。 　比較項目　　　　ソフトエンジニア　　ハードエンジニア １）習得期間　　　　　１年　　　　　　　　５～１０年 ２）必要人数　　　　　大勢　　　　　　　　　少数 ３）相手の分野の知識　無くても可　　　　　　必須 ４）開発ツール　　　　選択が多い　　　　　　選択が少ない ５）表現言語　　　　　選択が多い　　　　　　選択が少ない 比較はできますが、優劣や上下ではありません。 また各項目のコメントも２０年前では、大きく異なってました。 １０年後に話題にしてみたいです。 ＊ニュースは、弊社メルマガで配信されてます。

正式には、アジャイルソフトウェア開発との事です。 弊社では無縁の開発手法ですが、この手法を文化としているお客様に淡々とこの手法のメリットを教えて頂いた事があります。 予想以上の成果が出せる。短期間で開発終了する事がある。など長所も沢山教えて頂きました。 ここまで「企業文化」として、この手法を取り組まれている方にお伝えする話ではありません。 表面的に「仕様を決めず、トライ＆エラー」で開発する。と勘違いされている場合が危険なのです。 仕様は頭の中。など危険なオーラが感じられます。 画像処理に限ったお話でもありませんし、弊社では複数の開発パターを使い分けているのでもありませんので、このテーマは「開発手法」を調べるきっかけになれば、幸いです。 ＊ニュースは、弊社メルマガで配信されてます。

エンジニアとして、技術を極めるには「深さ」か「広さ」の選択に迫られる事があります。 会社という組織としては「浅く広く」のメンバーも必要です。 「極めたい」となると、一部の天才を除くとどちらかを選択しないと、脳のキャパオーバーになると考えてます。 当社のエンジニアが、その選択に迫られるのは早い人でも入社後５年程度かと思います。 「深さ」を選択したからと言って、１分野だけ。ではなく、２つ目の分野をマスターしていく事もありますし、１つ目の分野が突然別の理論に淘汰されたりする事もあります。 プログラミング言語などの手段の選択も同様です。 色々な言語を使い分けるエンジニアも居れば、使う言語は１つでも何故かそのエンジニアが書くプログラムは高速動作します。 エンジニア集団と言っても「十人十色」。弊社の社是「一人一芸」もこんな事も意識した言葉です。 ＊ニュースは、弊社メルマガで配信されてます。

画像処理で実現する「検査」にも、お使いになる「利用者」にとって色々な異なる目的がありますので、ご紹介致します。 例えば、ある材料の開発を行うセクションの場合です。 色々な材料を使って「難燃材料」の開発を行う方の検査です。 燃焼実験を行う際に、どの程度燃えて自然鎮火したか？を測定する燃焼検査です。 この用途の場合利用者にとっては、メジャーであり同じ対象物を測定して、同じ数値になる事が重要です。 異なる用途の例として「量産検査」をご紹介します。 例えば、表示装置の量産検査を例にします。 検査装置としては、不良は全て検出しますが「量産検査」の場合「量産品質」に規定があります。 例えば、不良画素があっても一番小さい単位であれば、５個までを良品とする。 大きさが規定を超えると１個でも不良とする。と言うような規定です。 この場合、画像処理では一番小さいものも検出しますが、判定はう少し上のレベルで良否を決めます。 二つの極端な事例をご紹介しましたが、「画像検査」とのくくりでもご用途次第で、開発する内容が異なる事例紹介でした。 ＊ニュースは、弊社メルマガで配信されてます。

FPGAの回路設計を仕事とされて居る方は、各社ツールの「論理合成時間」に悩まされていると思います。 このテーマは、筆者が「世の中にFPGAなるものが登場した」と言う時代から、存在し続けるテーマです。 PALやGAL時代には問題ではありませんでしたが、同時代のASIC設計では意識してました。 パソコンに搭載されているCPUの性能も飛躍的に向上しているのですが、FPGAの論理合成時間は相変わらず＊時間かかる状況です。 シミュレーション環境で「テストベンチ」を作るのですが、実チップでのデバッグ時にの内部信号状態を見る機能（チップスコープとかシグナルタップとか）を使うと、更に論理合成時間が長くなります。 この話は、ソフト屋さんにはなかなか理解してもらえません。 幸い弊社は少数にて、ハード担当ファーム担当デバイスドライバ担当とすぐ近くで作業しているのでファームから「この信号を見て下さい」に対応する時間がかかる事を理解して依頼を考えます。 今回は、進化に開発環境の性能向上が追いつかない事例をご紹介いたしました。 ＊ニュースは、弊社メルマガで配信されてます。

言葉の違いは、国語辞典で調べて下さい。 エンジニアコラムなので、「憶測の危険性」と推測の為の「仮説」について考えてみます。 仕様決めからデバッグまで、色々なシーンでこのテーマは該当します。発散しない為に「デバッグシーン」で考えてみます。 画像処理の開発ですと、ノイズだらけでも映像が変形しても「画像（二次元配列のデータ群）」が得られるようになると、ビジュアル面からも不具合を推測します。 憶測でありがちなのが、「ここが悪いのかも？」と試行錯誤で色々試してしまう行為です。 どんな事を試して、その結果がＡだった場合、その結果がＢだった場合をそれぞれ「仮説」として、ぞれぞれの結果を得た場合の原因も「仮説」にするのです。 これらが整理できるまで試してはいけません。 仮説を考えずに試す事が習慣になってしまうと、その沼から抜けるのは運になってしまいます。経験を積んでしまうと、この試行錯誤でも当たって不具合が治ってしまう事が多くなります。 これが「危険性」なのです。人間が考え、設計するのですから、そこに「ミス」が混じり「デバッグ」が必要になります。 ＊ニュースは、弊社メルマガで配信されてます。

先端技術開発もお客様からの依頼で開発します。 しかし、定石技術と呼ばれる処理の組み合わせで目的を達成できれば、そちらの方が良い事も沢山あります。 定石と呼ばれるぐらいですから、昔から広く使われてます。 大学の教科書に載っている事も多く、この「古くから」は２５年以上前ですと、特許の縛りが無いのです。 また、同じ処理結果を出すにも色々な計算方法がありますが、定石と呼ばれる技術は、多くの手法との競争に勝って生き残っているものですので、贅肉が削られている事も多いです。 定石の組み合わせだけ？そんな公知技術の組み合わせならば、すぐに真似されるでしょ？ どんな処理の組み合わせかを、わざわざ宣伝しない限り真似も簡単ではないです。 定石処理だけの組み合わせが理想と書きましたが、８割か９割は定石で処理できても、残り１割の壁に当たると、未知のアプローチも開発する必要があります。 最後の１割があるから、弊社へのご相談も頂けその「新しい技術」をお伝えする為に、展示会に出展しているのですから、この話題を書く適任者と言えないかもしれません。 ＊ニュースは、弊社メルマガで配信されてます。

人間の脳のキャパは、半導体規模の進化のように増えていないかと。 昔話をするのは衰退の一歩ですが、半導体の進化の話の為にお許し下さい。 半導体の進化は、「（露光）光の波長の限界で」とか、色々な理由でこれ以上のゲート規模は増えない。と何度も言われ、何度も克服してきました。人間の知恵は留まる事を知らない。と振り返ってます。 私が始めてASICを設計した当時は、3000ゲート程度が最大規模でした。半導体メーカー様のデザインルームで「テストパターン」で、回路動作検証率（HiとLoに変化した場所と、一度も変化してない場所の率）を95％にするまで出図できない。と。 現在は、FPGAでも「5000万ASICゲート」などと言われてますからもう桁違いです。 人間の脳のキャパが増えて、これだけの大規模でも一人で設計できる訳ではありません。規模が増えた事を、専用回路や、内臓メモリ、ハードコアCPUなどが内臓される事にも恩恵を受けてます。デバイスメーカーが用意するIPを使う事は、ある意味ブラックボックスになります。 難しい課題の話になってしまいました。 ＊ニュースは、弊社メルマガで配信されてます。

何かを開発するには、設計前に「仕様書」をきっちり決める事が理想だと思い込んでいました。 しかし、「仕様をきっちり決めない方がより良いものができる」がポリシーだと熱く語るお客様企業に出会って学んだお話です。 それぞれの長所、短所からご紹介します。 【仕様を決める】長所は何度かご案内しているかと思いますが、仕様を決める過程で、「トレードオフ」がなされ目的に対して最適アプローチができる点です。設計中やデバッグ中で不安になる事もありますが、最初の仕様がキッチリ決まっていれば、ブレる事もありません。 【仕様を決めない】長所は、開発中に新しいアイデアが生まれてきたら柔軟に仕様を変えて行く事で、「より良いもの」を生み出せる。との事でした。当時理解するまでは「それでは無駄な費用が発生しませんか？」と、思ってました。 「仕様を詳細までキッチリ決めようとするとスタートが遅れるでしょ？」と。そのプロジェクト完了後に、開始時には気づかない便利な機能が盛り込まれた新製品が完成したのです。 いつまでも柔軟でありたい。と考えるきっかけになったエピソードです。 ＊ニュースは、弊社メルマガで配信されてます。

初お披露目デモ「QRコードマルチフォーカス読取」の反省点や次の展示会に向けての改良考えました。 反省点は、会場に３つのデモを展示しましたが、このデモだけが「一見して、何が画像処理デモかわからない」とのお声を頂きました。 ＷＥＢカメラを使って、異なる距離にQRコードを貼った箱が置いてあるので、それらを同時に読む技術を開発しました。とアピールしたかったのですが。 デモだけ見ても、上記がわかった方は１名もいらっしゃいませんでした。口頭説明無しでは、折角の技術をお伝えできませんでした。 しかし、今回でこのデモは止めよう。と思わなかった反応もありました。 説明後、「うちは光学系メーカーで高速に焦点を変えられるものを試作したけど、何に使えば良いか検討中だった。コラボして展示しない？」とのお話や「展示会にフォークリフトオモチャを置いてそこにカメラを付けて動かせば？」などのヒントも頂きました。 展示会ですので、チラ見して「なんだろう？」と思って頂かなければお立ち寄り頂けません。伝われば「欲しかったんだ」と言って頂ける技術だと言う事も収穫できました。 ＊ニュースは、弊社メルマガで配信されてます。

広い知識と深い知識があればエンジニアの理想ですが。 特別な天才を除くと、人間には１日の時間が公平に与えられています。 そこで、「広い知識」か「深い知識」かの選択が必要になります。 この選択と、両方欲しいを解決する策が「組織」であり、チームプレイです。 ＫＩＴは、会社が一つのチームとなり深い知識担当と、広い知識担当の情報交換により問題解決と言うチームプレイを行ってます。 人間は「脳の中身をコピーして渡す」ができませんので、「上手にコピーして渡す」がコミュニケーション能力になります。 伝える情報の中には、「相手も知っているだろう」と無意識に思い込んでいる部分が抜けて情報伝達してしまう事があります。 それを防ぐ為に相手の「反応を見る」事が、コミュニケーションテクニックです。 毎週の定例会議前に、「コミュニケーションタイム」と言う時間を作って鍛えてます。 小学校の掃除当番のように、毎週「テーマを出す人」が順番にその時間を使って、どんな「コミュニケーションタイム」にするかを決めます。 このコラム、雑談になってきたのでここまでにします。 ＊ニュースは、弊社メルマガで配信されてます。

手前味噌になりますが、タイトル通り呼んで頂ける事や、引き出しが多いね。とご評価頂ける事があります。 シンクロナイズドスイミングではありませんが、その為に見えない努力もしてます。それが「コア技術の仕込み」です。 前回に続き、正直にご案内すると「コア技術」になるのは結果からです。 狙っても、コア技術にならずに没になるものもあります。 仕込みを予算すると「展示会時の集客費用」と考え、時間を確保します。 開発が主業ですから、期の代わり目が「仕込み」のチャンスなのです。 次の仕込みネタは「展示会終了後の振返り会」で、デモに対する評価を行います。 評価は「一瞬で気づいて頂けたか？」「見た目の新しさ」「技術説明での新しさ」などの項目別に、評価を行います。 また、同時に「実現できたら驚かれる」「技術説明で驚かれる」などの「次」に対する評価も出しておきます。 一生懸命開発して、一回の展示だけで終わったものもあります。 成長して、具体的案件に使用し「素晴らしい」との声を頂けた時。 エンジニアと言う職業を選んで良かった。と思える瞬間です。 ＊ニュースは、弊社メルマガで配信されてます。

想像とは違い、胸を張る話ではありません。 「開発現場の生のコラム」として、ご案内します。 画像処理の処理速度高速化の際に、プチテクニックとして連続したアドレスアクセスにする。があります。 これは、DRAMのアクセス速度が、RowAddressと、ColumnAddressの変化では、アクセス速度が異なる。を意識したコーディングです。 ある画像処理で（説明の簡素化の為）横方向の積分処理と、処理の後すぐに縦方向の積分処理を連続して行う。を経験の浅い担当が開発してました。 報告された処理時間が、遅いので上記の処理順番を意識しているか？あえて順番を逆にしたら、処理時間がどのように変化するか？を報告させました。 結果、順番はどちらも同じ処理時間。との事でした。 そこで、個別の処理時間を報告させたところ、後段で処理した方が２倍速い。との報告でした。 ここまで書けば「オチ」も見えてきたかもしれません。 アドレスを意識してコーディングするより、順番に関わらずキャッシュにヒットするので、後段の処理が高速である事がわかりました。 生の事例です。 ＊ニュースは、弊社メルマガで配信されてます。

以前のニュースでもご案内した「オンラインセミナー？」が、現実となりました。 初めてのオンライン形式なので、進め方を練習している次第ですが、具体的な事を主催者様からお聞きした所、想定外がありました。 １）受講者の方は、ソフトをインストールできるとは限らない ２）受講者の方は、カメラをＯＮできない企業様もいる この２点です。 会場でのセミナーでは「実習」がありますが、オンラインでは、受講者に考えて頂く時間を取る事はできない。 までは想定しており、今回追加した新しい項目分を実施する準備をしてました。 前半で「画像処理の定石説明」は、会場ですと説明した操作を、会場のＰＣにて実際の操作頂くのですが、ソフトをインストールできない方は、講師が操作している画面を見るだけになってしまい、何処まで身につくか？が不安です。 更に、カメラが使えない事で、受講者の方に伝わったのか？の反応を感じられない事が不安です。 会場でお顔を見ていれば、わかりにくいと感じた内容は説明を変えて補足してました。 結果はいずれご紹介する機会がれば、ご案内します。 ＊ニュースは、弊社メルマガで配信されてます。

本製品は、画像処理の定石処理を実装していて、開発やデバッグ時に、必要な処理をプログラムせずに「試せる」ものです。 今回、Ver.2.1.1.0C　から　Ver.2.1.1.0Dに、更新されました。 このソフトは、製品版も試用版も同じものです。ライセンスキーを入力して頂き、製品版として全機能が使えるようになります。 その「ライセンスキー」が、用意していた組み合わせを全て販売や、「画像処理学習セットキャンペーン」「画像処理セミナー」で使いきってしまい、新たなプロテクト方式に切り替える必要がありました。 開発環境が当時アイコンなどのGUIを簡単に作れるツールがボーランド社製品だった為、弊社都合でVisual Studio環境に移植しました。 実装している画像処理の機能には一切変更がありませんが、一部操作ボタンなどがメニューになったり見た目が変わりました。 これまでのユーザー様も、すでに取得済み「ライセンスキー」を入れて動作します。 新しいバージョンに移る場合、古い方をアンインストールしてから、インストールして下さい。 ＊ニュースは、弊社メルマガで配信されてます。

二十数年前から、本業の開発の隙間で、セミナー講師を担当させて頂いておりますが、ここ２年間は、コロナ禍の影響で開催中止になっています。 今回開催が決まったのは、感染者が大きく減っていた時期でした。 弊社セミナーの差別化は、画像処理の開発現場からの声なので、お集り頂いた受講者の方に「今日、これが知りたい」と思っている方は？と挙手頂き、ニーズの多い部分に注力する事と、実習時に皆さんの操作画面を見て「ここに引っかかっている」と思って、個別に声掛けヒントをお伝えしているところです。 このコラムの時点では、主催様も「リスク回避」に注力し、会場での対面を想定しているとの事です。 主催：日本テクノセンター　２月２４日（木） https://www.j-techno.co.jp/seminar/seminar-47031/ 可能性として、「初のオンラインセミナー」に変更されるかもしれません。 「反応を見てアドリブで」が、オンランでも成立するのか？半信半疑ですが、オンラインに切り替わっても、「参加して得るものがあった」を目指します。 ＊ニュースは、弊社メルマガで配信されてます。

色々な異なる会社様でも生産管理の名称がつく部署の方からの画像処理相談は、昔から多いです。 その内容は「検査」が共通キーワードでした。 多くは不良品検査、生産された製品の検査です。 今回「生産管理」をテーマに選んだのは、検査以外にも色々な業務があり、それら業務のいくつかを「画像で」とのご要望を頂く事の紹介です。 検査以外のテーマを羅列してみます。 １）人の動き 工場で作業している方の動きをトレース ２）搬送車の位置をトレース 無人工場ほどの設備で、当然搬送車の位置は制御器が把握していると思っていたので、それを運転する装置と完全に分離してトレースしたいとの事で、第三者検証的に驚いたお話でした ３）入庫管理 出庫管理はすべて自社製だから取り決めし易い。 しかし入庫となると、多種多様な企業からの入庫なので、梱包されている箱の大きさも色々で、中身の数量チェックもルール化しにくいとの事。 生産管理の業務はとても広い業務区分で、まだまだ「画像を使ってこんな事できませんか？」とのご相談は、新しい出会いがありそうです。 ＊ニュースは、弊社メルマガで配信されてます。

年間最大2回と定めていた「画像処理セミナー」ですが、感染症の影響とオンラインセミナーでは伝わらない。 との判断から、長期間実施できずに今日を迎えてます。 その間技術の進歩もあり、セミナーにて教科書として使う「資料」も更新しております。 画像処理の応用分野や、画像サイズ、ピクセルレートなどの「業界情報」から、実現手段が「ソフト、ハード」だったものに、GPUプログラミングを加えたり。 資料だけでなく、講義も「参加者の皆様の関心のある分野」にアドリブで話題を追加していますので、今回も新情報の部分はどんな話になるか？ 当日の楽しみです。 主催は、日本テクノセンター様です。 2022年2月24日開催予定です。 https://www.j-techno.co.jp/seminar/seminar-47031/ 日々「画像処理」に特化した開発を行っている現場からの、生の情報をお伝えしたいと毎回考えております。 講師紹介割引もメルマガ読者様に有効です。 画像処理に関するご質問も、セミナー講義内容に関わらず、ご持参下さい。 ＊ニュースは、弊社メルマガで配信されてます。

弊社の主業務である、お客様のご要望に合わせた「専用処理」を開発する際の商談の話です。 商談と言っても、ほとんどが「仕様決め」です。 お客様のご要望を伺い、それを実現する為の提案を行います。 毎回異なる産業分野や異なる用途なので、一度でご要望を理解する事は難しいです。 そこで、「仕様」のキャッチボールが商談に該当します。 その時のトークが「控え目」とか「保守的」とか、キャッチボールしている相手の方からでなく、その両方の間に入っている方に、見られる事が稀にあるようです。 弊社の場合、商談する人間がそのまま開発する担当になる事が多いです。 あまり深く考えずに「できます」とお話して進んでしまうと「やっぱり想定した手法ではできません」では、そこまで検討した時間が両者にとってデメリットになるからです。 しかし「できません」と簡単に発言するのは、開発会社としてNGです。 どんなアプローチだと、実現できるのか？ そのアプローチのメリットとデメリットは何か？ を直接成果物を使われる方との議論ができること。これが営業トークのメリットです。 ＊ニュースは、弊社メルマガで配信されてます。

先日、５年計画の大きな研究テーマにご利用頂く「画像処理」の最終年度、最終納品をさせて頂き、最後の「納品説明会」を実施してきました。 ある行為を人間が行っているのですが、その行為を「無人化したい」と言うテーマの画像認識部を弊社で開発してました。 「無人化」は、良くあるテーマで、多くのテーマが省力化が目的です。 ５年間の基礎研究から実際の装置を開発する。テーマは、費用も期間も大がかりでした。 用途によっては、それなりの価値があるのだろう。と思って画像処理部を担当させて頂いて、無事装置も完成しました。 最後の納品説明会で「装置全体の用途」をお伺いして驚いた事は、「無人化」は省力化ではなく、必須機能だったのです。 対象物が医薬品になるものなので、人間が関わらない事で「菌」などに触れない為の「無人化」だと教えて頂きました。 画像処理の開発は長年手掛けておりますが、これだけの長い期間を一緒に開発させて頂き、真の目的をわかっていなかった未熟さを知った事と、同時に画像処理を必要とされる方々に、まだ出会いきれていない先の楽しみを感じた次第でした。 ＊ニュースは、弊社メルマガで配信されてます。