下面是我设计的Dicom Server，各位看官帮审查一下（特别有

scarab

C-Find Service就略过去吧，因为我已经把支持extended behavior的C-Find搞定了.
下面谈一下C-Move和C-Store吧（主要是关于传输语法的设计）:
C-Move scu/scp和C-Store scu/scp要支持的non-compression transfer syntaxex包括三种：
(1)Implicit  VR Little Endian, (2)Explicit VR Little Endian, (3)Explicit VR Big Endian
要支持的compression transfer syntaxes包括:
(1)Baseline JPEG(Process 1), (2)Extended JPEG(Process 2(8-bit), 4(12-bit)), (3)Lossless, Non-Hierarchical JPEG(Process 14), (4)Lossless JPEG(Process 14)
当启动Move scu的时候，我提供一个选项movescu ... -transfer..,该-transfer选项主要让用户来输入一个他想要的传输语法。然后该传输语法同Move SCP进行协商，如果协商通过的话Move SCP来检查一下要Move的图象的transfer syntax UID(0002,0010)，如果协商的传输语法同(0002,0010)都是非压缩的传输语法，则根据协商的传输语法来启动C-Store SCU,然后C-Store SCU来根据非压缩的传输语法进行byte swap之后发送过去（假定C-Store SCU和SCP都协商通过的话)；但是如果协商的传输语法和(0002,0010)和要发送图象的传输语法不都是非压缩的，则我要调用dcmjpeg的转换函数把要发送的图象转换成要协商好的传输语法的图象，然后启动C-Store SCU按照C-Move协商好的传输语法进行发送(假定C-Store SCU和SCP都协商通过的话)。

这样设计合理吗？因为我个人认为如果我的C-Move和C-Store服务要支持以上传输语法的话，压缩和非压缩必须要经过图象转换才可以。然后把图象转换成协商好的传输语法的图象再进行发送。
谢谢指教！

JB

我今天逛坛子的时间用完了，明天再细看你的设计。
不过是有条件的。把你们培养出来以后，你们今后可要积极应聘做我的雇员噢。

scarab

[这个贴子最后由scarab在 2003/04/18 05:28pm 第 3 次编辑]

JB，我可以仰起头冒昧地问你一下：成为你的职员需要什么条件？
我想你也不会招收我这不称职的职员的，鄙人毕竟天资愚钝难成大器
另外，你再帮我解释一下ENCAPSULATION和COMPRESSION有什么区别，在DICOM术语中。
encapsulated的图象都是压缩过的吗？凡是encapsulated的图象的pixel data的长度都是(FFFFFFFFH)吗？
PS 3.5-2001 Page 49所述:"A.4 TRANSFER SYNTAXES FOR ENCAPSULATION OF ENCODED PIXEL DATA"谈论的是native和encapsulated,，难道encapsulation的pixel data包括native和encapsulated两种？？？？！！
如果把一个压缩的图象Lossless JPEG(Process 14)按照协商的Explicit VR Little Endian进行storage，你会怎么做？
标准我已经看了4-5天了，对各种传输语法的问题一片迷茫和焦躁，别的方面还行因为专业性不强。
如有不便，你发到我信箱里：lvjianshan@163.com

JB

老弟别急。看了 4-5 标准算设么？ 我 1992 ACR-NEMA 2.0 时就开始了，从 1993 年至今直接间接参加 DICOM 标准制定。共十年有余。
我不是针对你个人而言的，国内整个医疗软件水平可以培养。国内还是人才济济，你们就缺乏美国这种环境来了解世界先进技术的底细，也可多些好的技术领头羊和企业家来带带提高整体水平。
在 Siemens/Acuson 四年跟我的几个中国人现在都在是其他公司做大拿了，初来咋到连 C 的语法都搞不通。美国人、印度人也有好的。有个 27 岁美国小伙子，我非常兴赏，花了不少精力培养。2000 我回北京度假 3 个礼拜，那小伙竟在前一个周末得了个无名病死了。真让我伤心！那时候在硅谷雇人难哪；现在大家都失业。有些印度人太不听话，当面一套背后一套，再聪明也很难使人信任。

JB

言归正传，你的　ＤＩＣＯＭ　服务器的构思方向是对的。还有许多思考和设计工作要做。就　ａｓｓｏｃｉａｔｉｏｎ　ｎｅｇｏｔｉａｔｉｏｎ　里的　ｐｒｅｓｅｎｔａｔｉｏｎ　ｃｏｎｔｅｘｔ，一般来说：
ｏ　　Ｓｔｏｒｅ　ＳＣＰ　可以敞开大门，来者不拒。
ｏ　　Ｍｏｖｅ　和　Ｓｔｏｒｅ　ＳＣＵ就有许多讲究
比如说吧，我　ｑｕｅｒｙ　你的服务器，要调一些超声心动图。除了　ｄｅｆａｕｌｔ　ｔｒａｎｓｆｅｒ　ｓｙｎｔａｘ，我也支持　ＪＰＥＧ　ｌｏｓｙ。你是要给我　Ｉｍｐｌｉｃｉｔ　ＶＲ　Ｌｉｔｔｌｅ　Ｅｎｄｉａｎ　还是　ＪＰＥＧ　ｌｏｓｓｙ　啊？另外还有一些东西是无法　ｎｅｇｏｔｉａｔｅ　的，这对服务器关系不是十分大，可是对观测站影响很大。这些包括颜色　（如　ＲＧＢ，ＹＢＲ＿ＦＵＬＬ，ＹＢＲ＿ＦＵＬＬ＿４２２，ＰＡＬＥＴＴＥ　ＣＯＬＯＲ，等等）。
做学徒头　３　年要勤快担水、劈柴、烧火，不能着急。美国学校里都灌输这些东西。

scarab

谢谢指教！

scarab

下面引用由JB在 2003/04/19 02:22am 发表的内容：
老弟别急。看了 4-5 标准算设么？ 我 1992 ACR-NEMA 2.0 时就开始了，从 1993 年至今直接间接参加 DICOM 标准制定。共十年有余。
我不是针对你个人而言的，国内整个医疗软件水平可以培养。国内还是人才济济，你　...

不着急能行吗？以前没有真正接触过DICOM，现在要花费半年做一个DICOM SERVER，而且没有像你这样的领头羊，能不上火吗？
我们不是缺乏这种环境来了解世界先进技术的底细，而是缺少思想。我最欣赏的是西方的文艺复兴时代，从此以后西方文明百花齐放，百家争鸣，这样才能为先进技术提供精神源泉。举一个简单的例子：XML算做一个先进技术吗？我不认为是，但是他能够把一个文本文件制定一套标准，然后大家都遵循这一标准，于是一切都显得那么明朗和简单---这就是思想。想超过别人不能步人家后尘人云亦云，而要从根本上改变自己，迎头赶上。

JB

半年能做出个 robust 的 server 是个不错的成就。其实半年 DICOM 能入门就很好了。
但是美国国家、公司和个人都有钱，能办成很多其他国家做不到的事，所以处处爱做老大。想要中国甚至日本来定个什么标准，美国来 follow，那是很难做到。所以高科技东西中国只好尾随。
但是中国许多能做到的东西美国也是做不到的，这是中国为什么能在过去 20 年高速发展的原因。

scarab

其实开发量应该不是很大，因为有ctn和dcmtk代码库，而且我对ctn库比较熟悉，所以主要的工作量应该在设计上，应该考虑怎样设计一个支持多种压缩和非压缩的传输语法(考虑对图象的处理[dcmtk有代码])及relational query的robust dicom server

jameszhang72

下面引用由JB在 2003/04/19 05:59am 发表的内容：
言归正传，你的　ＤＩＣＯＭ　服务器的构思方向是对的。还有许多思考和设计工作要做。就　ａｓｓｏｃｉａｔｉｏｎ　ｎｅｇｏｔｉａｔｉｏｎ　里的　ｐｒｅｓｅｎｔａｔｉｏｎ　ｃｏｎｔｅｘｔ，一般来说：
ｏ　　...

没有商业头脑，SCP只能提供给注册用户，注册用户就由你的配置文件来控制了，注意，管理员密码保护哦！

JB

老弟“来者不拒”指的是 association negotiation 里的 presentation context 而不是用户。
即使是用户，只有老式的 DICOM SCP 才严格控制那些用户能存取东西。新的至少要能 configurable。

scarab

是的，这点我们要考虑：注册用户我们是通过AETitle来控制授权的
JB的SCP来者不拒应该是指授权用户容错性问题吧？

JB

scarab, CTN 的 AETile 控制 association 至少是十年老的做法。医院用户和 PACS 管理员会碰到和很多不必要的难题。考虑加所附 setting UI。

scarab

谢谢JB大哥，既然不用AETitle的话，该如何做呢？难道用户需要提供用户名和密码，然后我到我的数据库中进行验证？

JB

AETitle 还是可以用，但是要能 diable 这个　checking.
看看　ｄｃｍｔｋ　里的　ｏｐｅｎ　ｓｓｌ．