C++によるDICOMファイル解析
■ このスレッドは過去ログ倉庫に格納されています
あらよっと!
こんな糞スレでも愛着が沸いてきたー
保守してやんよ
1000行くまでは俺様以外書き込みするんじゃねーぞ ファイルフォーマットよりも通信規格がわからん・・・。 >>135
モダリティメーカーでプログラム組んでた俺がぶっちゃけると、DICOMタグが多すぎて、
全部把握できずに、とりあえずプライベートタグで対応しまくり。
あとから標準タグでも行けたと知っても時既に遅しってパターンがほとんど。 >>160
TOTOKU (東京特殊電線) - サブピクセル製品を真っ先に出したが。
が。の後が気になるw struct _endian{
union{
short s;
char c[2];
} u;
} endian_test = {0x55AA};
bool is_little_endian = (endian_test.u.c[0] == 0x55);
DICOM通信意味不明すぎるだろ
日本語の噛み砕いた資料ないの? >>173
そうなのか?
OSIの基本を知ってさえいれば、難易度の低いAP層プロトコルだろ
量が大きいから全体を理解/把握するのは大変かもしれないけど、
それは技術的な問題では無いし、意味不明でもない そりゃそうだw
HTTPのプロトコル仕様を知っている人は多いと思うけど、
実際に実装できるプログラマは少ない
たとえ作れる人でも、普通は既存のライブラリを利用する DICOM通信は、PDU仕様がLDAPやX.509みたいに
OSI標準のASN.1で定義されていれば専用のコンパイラがあるから
少しは実装が楽になったと思うけど、
独自の仕様で定義されている点が残念なところ 一番の問題点は仕様がアホみたいに巨大かつ肥大化を続けてることだろう HTTP実装はまた流行るよ。
VPSが安くなってきたから。
レンタルサーバが安くなってくると同時にLinuxが流行ったのと同じ感じ。 長文pdf作るより標準ライブラリ作って配布した方がいいと思うの・・・ 仕様が膨大&複雑すぎて、肝心のデータの受け渡しでトラブル起こりまくりだよね。DICOMって。
ばかげてる。 3Dプリンタで模擬の臓器や骨を作りたいんだけども、DICOMって座標情報に対応してる?
voxelから無理矢理変換して、さらに影とかを修正するしか無いのかな・・・? 零点をどこに合わせるかは撮影者の腕次第だが
スライス間隔とピクセルの大きさがタグに書かれているから
そこから座標を構築できる
詳しくはPDF読め
注意点
撮影方法によってはスライスが重なっていたり飛び飛びになっている
CTではthin sliceデータを自分で再構成するより
モダリティで再構成したほうがノイズの少ないものができる機種がある
(仕掛けは非公開だが内部に持っているraw dataを利用している?) >>184
他の規格でもそうだが
情報交換することを優先するなら
解釈の差が生まれないように規格を設計すべきだし
平均的労働者が短時間で理解できる仕様を構成すべきなんだが
実際に起きているトラブルはそんなところじゃなくて
あり得る可能性の重みを無視して実装を省略した結果起きている
ことがまれによくある
セントリシティが吐いたデータを他で読めないのとかは
そんな感じじゃないか? >>186
いちおー座標による3Dにも対応してるのね、ありがとう
PDFが厚すぎて、読む気にもなれんのよ・・・w 結局EXIFみたいなファイル、ディレクトリ構造なんだからまず基本データ型のデコードメソッド作って
その構造エントリ名含めて丸ごとXMLに吐き出させて外部ツールで解析、統計分析等したらいいのに 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
W85R2 ■ このスレッドは過去ログ倉庫に格納されています