WEB PACS with JPIP

本文介绍DICOM 2008标准中WEBPACS技术的应用,涵盖如何获取研究集、系列集、图像记录,DICOM图像的检索与渲染过程,以及结构报告和注释的获取方式。同时探讨了JPEG2000交互协议(JPIP)在图像流传输中的应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 
 
WEB PACS with JPIP
 
SCOPE
 
This article will provide a general description of new technology about WEB PACS finalized in DICOM (2008)
 
Symbols and abbreviated terms
 
WADO      Web Access to DICOM persistent Objects
JPIP           JPEG 2000 Interactive Protocol
 
3rd Party Library
1.      zlib to support deflate transfer syntax (Dataset encode/decode) www.zlib.net
2.      JPIP, JP2K lib    www.leadtools.com www.ware.com www.kakadusoftware.com
3.      DCMTK  dicom.offis.de/dcmtk.php.en
 
DICOM standard refer
1.      Part 3.18 (DICOM 2008)
2.      CP106 (DICOM 2008)
 
Questions
 
1.      How to get the available record set (study, series, image)
2.      How to retrieve the DICOM image
3.      How to render the DICOM image
4.      How to get the structure report
5.      How to retrieve the annotation
6.      How to retrieve the overlay and render
7.      How to work with the JPG2K streaming technology
8.      How to process (measure, adjust W/L …) the DICOM image from web server?
 
 
Available solutions
 
1.      How to get the available record set (study, series, image)
 access the database and get the recordset
2.      How to retrieve the DICOM image
[Copy from 3.18]
Annex B - Examples (Informative)
B.1 RETRIEVING A SIMPLE DICOM IMAGE IN JPEG
http://www.hospital-stmarco/radiology/wado.php?requestType=WADO
&studyUID=1.2.250.1.59.40211.12345678.678910
&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789
&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2
 
[Only the pixel coded with JPEG will be retrieved base on http]
 
B.3 RETRIEVING A REGION OF A DICOM IMAGE
Retrieving a region of a DICOM image, converted if possible in JPEG2000, with annotations burned into
the image containing the patient name and technical information, and mapped into a defined image size:
https://aspradio/imageaccess.js?requestType=WADO
&studyUID=1.2.250.1.59.40211.12345678.678910
&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789
&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2
&contentType=image%2Fjp2;level=1,image%2Fjpeg;q=0.5
&annotation=patient,technique
&columns=400
&rows=300
&region=0.3,0.4,0.5,0.5
&windowCenter=-1000
&windowWidth=2500
 
[part of the pixel coded by JPEG2000 will be retrieved and it need to be decoded explicitly before rendering]
B.4 RETRIEVING AS A DICOM MIME TYPE
Retrieving a DICOM image object using the baseline 8-bit lossy JPEG transfer syntax, and de-identified:
http://www.medical-webservice.st/RetrieveDocument?requestType=WADO
&studyUID=1.2.250.1.59.40211.12345678.678910
&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789
&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2
&contentType=application%2Fdicom
&anonymize=yes
&transferSyntax=1.2.840.10008.1.2.4.50
[JPEG coded image can be rendered directly without explicitly decode since it is a MINE type support by IE]
 
 
3.      How to render the DICOM image
To different transfer syntax DICOM file, different decoder required here to decode the file.
To Deflate (.99), zip(zlib) will be used to decode the whole dataset before parsing the pixel data.
To JPIP (.94),    (0028, 7fe0) pixel data provider URL should be parsed correctly and retrieve the JP2 image (standalone image file) from the URL and decode/render the pixel.
 
To Deflate JPIP (.95), similar to .99, decode by zlib firstly and then refer to .94 to render the pixel.
 
To JPEG2000 Lossless (.90), download the whole file and decode/render it. (DCMTK is free, but the jpeg2000 lib is not free)
 
To JPEG Lossless (.70), download the whole file and render without explicitly decoding.
 
 
 
4.      How to get the structure report
 
B.2 RETRIEVING A DICOM SR IN HTML
http://server234/script678.asp?requestType=WADO
&studyUID=1.2.250.1.59.40211.12345678.678910
&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789
&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2
&charset=UTF-8
 
[HTML format SR will be generated]
In some cases, the transfer syntax of the SR may be deflated "1.2.840.10008.1.2.1.99", the dicom file need to decoded in client side before rendering it into html.
 
5.      How to retrieve the annotation
It’s better to burn it into the pixel data in server side before send to client.
 
6.      How to retrieve the overlay and render
 
Burn it into pixel data in server side or parse it from DICOM file and render it in client side.
 
7.      How to work with the JPG2K streaming technology
Buy the encode/decode JPIP lib from 3 rd party (Ware, Kakadu, Leadtools) or implemented your own JPIP stack.
 
Retrieve the raw DICOM files and process them into JPIP content scheduledly or encode on demand when the request comes.
 
Receive and decode the content in client server and render. After the image has been retrieved completely, save the image in client side temperately for post processing.
 
8.      How to process (measure, zoom, adjust W/L …) the DICOM image from web server?
Zoom out can be processed separately since it related with JPIP, some work can be processed in server side to decrease the network IO.
 
Other works should be processed in client side, an ActiveX or similar program need to execute in client side to manipulate the DICOM file in the client cache.
  Appendix
[Copy from IHE IT Framework v3]
4.55 WADO Retrieve
This section corresponds to Transaction RAD-55 of the IHE Technical Framework. Transaction
RAD-55 is used by the Imaging Document Consumer and the Image Manager/ Image Archive
actors.
4.55.1 Scope
The WADO Retrieve transaction enables an Imaging Document Consumer to access DICOM
SOP Instances with a web-based service through HTTP/HTTPS protocol.
4.55.2 Use Case Roles
WADO Retrieve
Imaging
Document
Consumer
Imaging Document
Source
Actor: Imaging Document Consumer
Role: Issues an HTTP Get Request to access a DICOM instance.
Actor: Imaging Document Source
Role: Receives an HTTP Get Request for accessing a DICOM instance and generates the HTTP
response with the appropriate content.
4.55.3 Referenced Standard
DICOM 2007 PS 3.18: Web Access to DICOM Persistent Objects (WADO)
Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA
2007-08-30
IHE Technical Framework, vol. III: Transactions (continued)
______________________________________________________________________________
__________________________________________________________________________
135
4.55.4 Interaction Diagram
Imaging Document
Consumer
Object(s) request
(GET HTTP Request)
Imaging
Document Source
Object(s) send
(HTTP Response to the GET Request)
4.55.4 .1 WADO Retrieve
The Imaging Document Consumer issues an HTTP Get to request a specific DICOM instance
from the Imaging Document Source. The Imaging Document Source receives the request,
generates the response with the appropriate content and sends an HTTP Response to the Imaging
Document Consumer.
4.55.4 .1.1 Trigger Events
The Imaging Document Consumer wishes to retrieve a DICOM instance that is referenced within
a DICOM Manifest.
4.55.4 .1.2 Message Semantics
The message semantics are defined by the DICOM Web Access to DICOM Persistent Objects
(WADO), PS 3.18.
The WADO Retrieve transaction is performed by the Imaging Document Consumer to send a
HTTP Request-URI to the web server of the Imaging Document Source. The Imaging Document
Consumer generates the HTTP Request-URI to retrieve a DICOM instance. The DICOM
instance shall be specified with its Study Instance UID, Series Instance UID, and SOP Instance
UID in the HTTP Request-URI. The Imaging Document Consumer must obtain the host
information (e.g., web server location, and script language) of the web server to perform this
Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA
2007-08-30
IHE Technical Framework, vol. III: Transactions (continued)
______________________________________________________________________________
__________________________________________________________________________
136
transaction. The Imaging Document Consumer can map the Retrieve AE Title of the SOP
Instance to the web server host information based on its local configuration (see Appendix G).
In addition, the Imaging Document Consumer shall support the following fields in the HTTP
request:
Table 4.55-1. WADO HTTP Request Fields
HTTP Field REQ Description Values
Accept R This field is used to specify MIME
types which are acceptable for the
response
At least one of the following values:
application/dicom
image/jpeg
application/text
application/html
*/*
Other values may be included as
well
Accept-
Language
O This field specifies the language of
the object to be retrieved.
Any valid value according to
RFC2616
The Imaging Document Source shall list all media types it supports in the Accept field of the
HTTP request, and shall use WADO HTTP parameter contentType to request the desired media
type of the object to be retrieved in the HTTP response (see Table 4.55-2).
The Imaging Document Source and the Imaging Document Consumer are required to support a
number of parameters in the WADO HTTP Request-URI, as described in the following table.
Table 4.55-2. WADO HTTP Request Parameters
Parameter Name Parameter Description Requirement
Imaging
Document
Source
Imaging
Document
Consumer
Note
requestType Type of the HTTP request
performed. It must be “WADO”
R R
studyUID Unique identifier of the study R R
seriesUID Unique identifier of the series R R
objectUID Unique identifier of the object R R
contentType MIME type of the pesponse R+ R+ IHE-1
IHE-2
charset Charset of the response O O
anonymize Anonymize object O O
annotation Annotation of the object O O IHE-3
rows Number of pixel rows O O IHE-3
Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA
2007-08-30
IHE Technical Framework, vol. III: Transactions (continued)
______________________________________________________________________________
__________________________________________________________________________
137
Parameter Name Parameter Description Requirement
Imaging
Document
Source
Note
Imaging
Document
Consumer
columns Number of pixel columns O O IHE-3
region Region of image O O IHE-3
windowCenter Window center of the image O O IHE-3
windowWidth Window width of the image O O IHE-3
frameNumber Frame number of the single frame
in a multi-frame image
O O IHE-3
imageQuality Image quality factor O O IHE-3
presentationUID Unique identifier of the
presentation object
O O IHE-3
presentationSeriesUID Uniquer identifier of the series
containing the presentation object
O O IHE-3
transferSyntax Transfer syntax UID used with
DICOM image object returned in
the response
O O IHE-3
IHE-1: The Imaging Document Consumer must use the value “application/dicom” to
retrieve a DICOM SOP Instance in the DICOM Part 10 File Format. This allows the
Imaging Document Consumer to receive a SOP Instance in the native DICOM
format for full data manipulation.
The Imaging Document Consumer can also use the value “application/jpeg” to
retrieve an image encoded in JPEG baseline format if it is a single frame DICOM
image object or a single frame image encoded in a multi-frame DICOM image
object.
The Imaging Document Consumer can also use the values “application/text” or
“application/html” to retrieve a DICOM SR object represented in the text or html
format.
The Imaging Document Consumer can also use other values for this parameter as
specified in DICOM PS 3.18, if they are supported by the Imaging Document
Source.
This parameter is optional in DICOM PS 3.18. Because the default format of the
DICOM persistent object returned in the HTTP Get response in the absence of a
value in this parameter varies depending on the SOP Class of the retrieved object,
this profile requires that the parameter is supported, to improve interoperability.
IHE-2: This parameter must be compatible to the value(s) that the Imaging Document
Consumer placed in the Accept field of the HTTP Request-URI.
IHE-3: The parameter applies only to a DICOM SOP Instance if it is an image object.
Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA
2007-08-30
IHE Technical Framework, vol. III: Transactions (continued)
______________________________________________________________________________
__________________________________________________________________________
138
4.55.4 .1.2.1 Example of WADO Request-URI
The following is an example of HTTP Request-URI for retrieving a persistent DICOM object
using WADO:
http://www.hospital/radiology/wado.php?requestType=WADO&studyUID=1.2.250.1.59.
40211.12345678.678910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&
objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2&contentType=application
%2Fdicom
This example uses reponse MIME type application/dicom to request the DICOM SOP Instance
returned in the native DICOM Part 10 file format.
4.55.4 .1.3 Expected Actions
Upon reception of the WADO HTTP Request, the Imaging Document Source shall parse the
request and if there are no errors, shall construct an HTTP Get Response with the requested
DICOM instance content and return the response as specified by the DICOM WADO standard,
with HTTP response code 200 (OK).
The Imaging Document Source shall return HTTP response code 406 (Not Acceptable), if it
cannot serve the requested response MIME type(s) in parameter contentType and/or Accept
Field.
The Imaging Document Source shall return HTTP response code 404 (Not Found) if it cannot
locate the requested DICOM SOP Instance or cannot recognize the UID values specified in the
received HTTP Request-URI.
The Imaging Document Source shall return HTTP response code 400 (Bad Request) if any
required HTTP field or required WADO HTTP parameters are missing in the received HTTP
Request-URI, or any other syntactic error is detected in the HTTP Request-URI (e.g., media type
in contentType parameter conflicts with media types in Accept field).
4.55.4 .1.4 Audit Trail Trigger Events
IHE specifies a number of events that shall be reportable by means of the IHE Audit Trail (ITI
TF-II 3.20). IHE Radiology Audit Trial Option further defines a subset of these events, which are
particularly applicable to the radiology transactions.
Table 4.55-3 lists all the radiology audit trial trigger events applied to transaction RAD-55. The
last column specifies whether the sender or receiver side of the transaction is required to audit
the event.
Table 4.55-3. Audit Record Trigger Events
IHE Radiology Transaction ATNA Trigger Event(s) Audit Recording Requirements
WADO Retrieve [55] Instance-Stored Imaging Document Source shall
audit
Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA
2007-08-30
IHE Technical Framework, vol. III: Transactions (continued)
______________________________________________________________________________
__________________________________________________________________________
139
IHE Radiology Transaction ATNA Trigger Event(s) Audit Recording Requirements
Study Used Imaging Document Consumer shall
audit
Rev. 8.0 Copyright © 1998-2007: ACC/HIMSS/RSNA
2007-08-30
 
 
 
资源下载链接为: https://pan.quark.cn/s/22ca96b7bd39 在当今的软件开发领域,自动化构建与发布是提升开发效率和项目质量的关键环节。Jenkins Pipeline作为一种强大的自动化工具,能够有效助力Java项目的快速构建、测试及部署。本文将详细介绍如何利用Jenkins Pipeline实现Java项目的自动化构建与发布。 Jenkins Pipeline简介 Jenkins Pipeline是运行在Jenkins上的一套工作流框架,它将原本分散在单个或多个节点上独立运行的任务串联起来,实现复杂流程的编排与可视化。它是Jenkins 2.X的核心特性之一,推动了Jenkins从持续集成(CI)向持续交付(CD)及DevOps的转变。 创建Pipeline项目 要使用Jenkins Pipeline自动化构建发布Java项目,首先需要创建Pipeline项目。具体步骤如下: 登录Jenkins,点击“新建项”,选择“Pipeline”。 输入项目名称和描述,点击“确定”。 在Pipeline脚本中定义项目字典、发版脚本和预发布脚本。 编写Pipeline脚本 Pipeline脚本是Jenkins Pipeline的核心,用于定义自动化构建和发布的流程。以下是一个简单的Pipeline脚本示例: 在上述脚本中,定义了四个阶段:Checkout、Build、Push package和Deploy/Rollback。每个阶段都可以根据实际需求进行配置和调整。 通过Jenkins Pipeline自动化构建发布Java项目,可以显著提升开发效率和项目质量。借助Pipeline,我们能够轻松实现自动化构建、测试和部署,从而提高项目的整体质量和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值