[DCMEE-1968] HSQL Wrong column type: installed, expected: bit Created: 16/May/13  Updated: 16/May/13

Status: Open
Project: dcm4chee
Component/s: DB
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Rascovsky Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: hsql
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Running the HSQL distribution of dcm4chee 2.17.3 fails to deploy completely due to a hsql wrong column type error:

2013-05-15 22:24:30,110 INFO  -> (main) [org.hibernate.tool.hbm2ddl.SchemaValidator] Running schema validator
2013-05-15 22:24:30,112 INFO  -> (main) [org.hibernate.tool.hbm2ddl.SchemaValidator] fetching database metadata
2013-05-15 22:24:30,657 INFO  -> (main) [org.hibernate.tool.hbm2ddl.TableMetadata] table found: PUBLIC.AE
2013-05-15 22:24:30,659 INFO  -> (main) 
[org.hibernate.tool.hbm2ddl.TableMetadata] columns: [fs_group_id, ae_desc, installed, department, cipher_suites, vendor_data, institution, hostname, station_name, ae_group, wado_url, pat_id_issuer, aet, passwd, pk, port, acc_no_issuer, user_id]
2013-05-15 22:24:30,691 WARN  -> (main) [org.jboss.system.ServiceController] Problem starting service persistence.units:ear=dcm4chee-web-ear-3.0.3-hsql.ear,unitName=dcm4chee-arc
javax.persistence.PersistenceException: org.hibernate.HibernateException: Wrong column type: installed, expected: bit

This had been mentioned previously in this forum post:

http://forums.dcm4che.org/jiveforums/thread.jspa?messageID=24078&#24078






[DCMEE-1915] Add a new file status called UNCOMPRESSABLE Created: 10/Dec/12  Updated: 17/Jan/13

Status: In Progress
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Muhammad Mahmood Riyadh Assignee: Muhammad Mahmood Riyadh
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DCMEE-1927 FileStatus values do not get correctl... Resolved
Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

In some cases, we may not have the ability to compress/decompress images with certain PhotometricInterpretation. In those cases, we want to mark those when a status so that those are not being retried to compress over and over.

Add UNCOMPRESSABLE = -5 to FileStatus class.






[DCMEE-1936] scheduler does not run for ScheduleStudiesForDeletion after failover to new master node Created: 18/Feb/13  Updated: 18/Feb/13  Resolved: 18/Feb/13

Status: Open
Project: dcm4chee
Component/s: Deleter
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christopher Archer Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

When the current master node had to be restarted, deletes were no longer seen from the new master node. The log in INFO mode would not show any indicators that ScheduleStudiesForDeletion was being periodically run.

The symptom is a steady decline in free online cache and the related log messages showing only the (declining) free space on the current online cache volume.



 Comments   
Comment by Christopher Archer [ 18/Feb/13 ]

Suggested change:

dcm4jboss-sar/src/java/org/dcm4chex/archive/mbean/FileSystemMgt2Service.java, method stopService
add

super.stopService();





[DCMEE-2043] ContentEditService - error when using 'mergePatients()' Created: 25/Mar/14  Updated: 25/Mar/14

Status: Open
Project: dcm4chee
Component/s: Web
Affects Version/s: dcm4chee-2.17.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jamie Henning Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MSSQL 2008R2 running on Server 2008 R2


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

When using the 'mergePatients()' in the service:ContentEditService, it throws the following error after entering in the PK to keep and the PKS to merge from.

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Failed to invoke operation
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:285)
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

root cause

javax.management.IntrospectionException: Failed to find PropertyEditor for type: [J
org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:251)
org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:278)
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

note The full stack trace of the root cause is available in the JBossWeb/2.0.1.GA logs.






[DCMEE-2059] C-MOVE-RQ Illegal List of UIDs in Unique Key Attribute (0020,000E) Created: 12/Jun/14  Updated: 12/Jun/14

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: dcm4chee-2.18.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Fred Fuchs Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java 1.6.0_26


Attachments: Text File ListofUIDS_server.log    
Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

The complained tag content is:

(0020,000e) 682 Series Instance UID 1.3.46.670589.11.0.0.11.4.2.0.8014.5.2044.2007120509302996841\1.3.46.670589.11.0.0.11.4.2.0.8014.5.2044.2007120509223367724\1.3.46.670589.11.0.0.11.4.2.0.8014.5.3464.2007

which should be valid according to Part 4 C.2.2.2



 Comments   
Comment by Fred Fuchs [ 12/Jun/14 ]

Dcm4chee log

Comment by Fred Fuchs [ 12/Jun/14 ]

? DCMEE-507





[DCMEE-2052] WADO Prefetch Service returning emtpy DICOM fields Created: 09/May/14  Updated: 09/May/14

Status: Open
Project: dcm4chee
Component/s: WADO
Affects Version/s: dcm4chee-2.17.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: TJ Moretto Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi. I am trying to include the Content Date and Content Time values in my file names that are exported using a WADO prefetch rule. These fields are populated in my DICOM data, but are always empty when trying to use them in the wado-prefetch.xsl (see content-date and content-time vars)

Here's a sample of my wado-prefetch.xsl:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:output method="xml"/>

  <!--
        Output format:
                <wado-prefetches>
                        <prefetch wadourl="" [exportPath=""] />
                        ...
                </wado-prefetches>

        wadourl: WADO URL without objectUID.(will be added for every image of the series)
        exportPath: optional path for export. {0} will be replaced with SOP Instance UID.

    The following parameters are made available by the application:
    source-aet   - AET of the Storage SCU from which the series was received
    retrieve-aet - AET of the Query Retrieve SCP from which the series can be retrieved
    wado-baseurl - BASE URL for WADO request (Format: http://<host>:<port>/wado?requestType=WADO
    export-path  - Base directory path to wich images are exported

    These parameters may be to define rules that depend on the source or retrieve AET.
    <xsl:param name="source-aet">DCMSND</xsl:param>
    <xsl:param name="retrieve-aet">DCM4CHEE</xsl:param>
  -->
  <xsl:param name="source-aet"/>
  <xsl:param name="retrieve-aet"/>
  <xsl:param name="wado-baseurl">http://localhost:8080/wado?requestType=WADO</xsl:param>
  <xsl:param name="export-path">exported</xsl:param>

  <xsl:template match="/dataset">
    <xsl:param name="patient-id" select="attr[@tag='00100020']"/>
    <xsl:param name="study-uid" select="attr[@tag='0020000D']"/>
    <xsl:param name="series-uid" select="attr[@tag='0020000E']"/>
    <xsl:param name="study-date" select="attr[@tag='00080020']"/>
    <xsl:param name="study-time" select="substring(attr[@tag='00080030'],0,7)"/>
    <xsl:param name="content-date" select="attr[@tag='00080023']"/>
    <xsl:param name="content-time" select="substring(attr[@tag='00080033'],0,7)"/>
    <xsl:param name="series-number" select="attr[@tag='00200011']"/>
    <xsl:param name="sop-instance-id" select="attr[@tag='00080018']"/>
    <wado-prefetches>
      <!-- Prefetch images with special width and height of Series with specified Referring Phyisican
      <xsl:if test="attr[@tag='00080090']='Doe^John'">
        <prefetch>
                    <xsl:attribute name="wadourl">
                      <xsl:value-of select="$wado-baseurl"/>
                      <xsl:text>&amp;studyUID=</xsl:text><xsl:value-of select="$study-uid"/>
                      <xsl:text>&amp;seriesUID=</xsl:text><xsl:value-of select="$series-uid"/>
              <xsl:text>&amp;rows=64</xsl:text>
                          <xsl:text>&amp;columns=64</xsl:text>
                  <xsl:text>&amp;imageQuality=70</xsl:text>
                    </xsl:attribute>
        </prefetch>
      </xsl:if>
      -->
      <!-- Prefetch and export images witch are received from modality 'DCMSND'  -->
      <!--<xsl:if test="$source-aet='DCMSND'">-->
      <prefetch>
        <xsl:attribute name="wadourl">
          <xsl:value-of select="$wado-baseurl"/>
          <xsl:text>&amp;studyUID=</xsl:text><xsl:value-of select="$study-uid"/>
          <xsl:text>&amp;seriesUID=</xsl:text><xsl:value-of select="$series-uid"/>
          <xsl:text>&amp;imageQuality=100</xsl:text>
        </xsl:attribute>
        <xsl:attribute name="exportPath">
          <!--<xsl:value-of select="$export-path"/>-->
          <xsl:text>/home/dcm4chee/shared/<%= rails_env %>/exported/images</xsl:text>
          <xsl:text>/</xsl:text><xsl:value-of select="normalize-space($source-aet)"/>
          <xsl:text>/</xsl:text><xsl:value-of select="normalize-space($patient-id)"/>
          <xsl:text>/</xsl:text>
          <!--<xsl:value-of select="normalize-space($study-date)"/>-->
          <!--<xsl:value-of select="normalize-space($study-time)"/>-->
          <xsl:value-of select="normalize-space($content-date)"/>
          <xsl:value-of select="normalize-space($content-time)"/>
          <xsl:text>.{0}.jpg</xsl:text>
        </xsl:attribute>
      </prefetch>
      <!--</xsl:if>-->

    </wado-prefetches>
  </xsl:template>

</xsl:stylesheet>





[DCMEE-2048] ERROR: relation "published_study" already exists Created: 18/Apr/14  Updated: 18/Apr/14

Status: Open
Project: dcm4chee
Component/s: DB, Scripts
Affects Version/s: dcm4chee-2.18.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Rascovsky M.D. M.Sc Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

ERROR: relation "published_study" already exists when running sql/create.psql

Line 862 of sql/create.psql reads:

CREATE INDEX published_study ON published_study(study_fk);

I think it should read:

CREATE INDEX published_study_fk ON published_study(study_fk);

Sorry, new to JIRA, don't know how to make a patch.






Enable deployment of multiple FileSystemManagement services (DCMEE-449)

[DCMEE-990] Update Service descriptions in dcm4chee WIKI Created: 22/Oct/08  Updated: 22/Oct/08

Status: Open
Project: dcm4chee
Component/s: Documentation
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Gunter Zeilinger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





Possibility to bind a filesystem to a specific calling AET (DCMEE-285)

[DCMEE-1035] "fs group sort in" rules based on xml/xsl Created: 25/Nov/08  Updated: 25/Nov/08

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Peter Heiles Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

additionally to sort in received date based on calling aet it shall be possible to sort in data to fs groups based on dicom attributes. an xml/xsl based solution in storescp is preferred






[DCMEE-1376] Outbound C-Store coercion can only read values that are stored in the patient/study/series/instance blobs Created: 12/Feb/10  Updated: 12/Feb/10

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.14.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Bubba Ganoush Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The outbound C-Store coercion can only read values that are stored in the patient/study/series/instance database blobs. In other words, the out-cstorerq.xsl files cannot read any values that are only stored in the DICOM file. So, any attribute that is not in the dcm4chee-attribute-filter.xml cannot be read by the stylesheet. Reference: method makeCStoreRQ in QueryRetrieveScpService.java






[DCMEE-656] JMX Services that are not part of dcm4chee-arc must also provide Security Audit messages on update of attributes! Created: 29/Nov/07  Updated: 30/Nov/07

Status: Open
Project: dcm4chee
Component/s: Audits, JMX
Affects Version/s: dcm4chee-2.13.0
Fix Version/s: None

Type: Task Priority: Major
Reporter: Franz Willer Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The AuditLogger (dcm4chee-audit) register AttributeChangeListener for all attributes of a configuration which is provided from the distribution build of dcm4cheee-arc.
The 'external services (Store2Dcm, XDsService (after move to dcm4chee-xdsa-repository),..) are not covered by this configuration at the moment!



 Comments   
Comment by Gunter Zeilinger [ 30/Nov/07 ]

I propose to modify dcm4chee-audit-logger to read the configuration about which MBean attribute changes should be audited from individual configuration files - one by MBean - found in the configured AttributeChangeConfigurationDirectory (default e.g.: conf/dcm4chee-audit-attribute-change/), instead of reading a single configuration file (AttributeChangeConfigurationURL), including attribute information for all MBeans. Then, the install script for additional dcm4chee components only need to copy the dcm4chee-audit-attribute-change configuration files of additional deployed MBeans into (e.g.) conf/dcm4chee-audit-attribute-change/.





[DCMEE-1572] Option to delete as much studies as possible from the next filesystem when running out of disk space Created: 17/Dec/10  Updated: 17/Jun/11

Status: Open
Project: dcm4chee
Component/s: Deleter
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Peter Heiles Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

To avoid heavy fragmentation an option to delete as many studies as possible from the next filesystem shall be implemented.






[DCMEE-1692] OSGI please Created: 21/Apr/11  Updated: 21/Apr/11

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Andriyko Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

It would be great if one could run dcm4chee as an OSGI bundle inside jboss, instead of going through the weird "Override part of the jboss installation" procedure.

Has anyone thought about making dcm4chee osgi compliant?
Is it possible for me to help with this?



 Comments   
Comment by Andriyko [ 21/Apr/11 ]

This would also solve the problem of using old outdated jboss version.

Comment by Damien Evans [ 21/Apr/11 ]

dcm4chee is a very large system with many components. While I agree it would be nice if the dcm4chee components were OSGi bundles, it would be a huge amount of work. I could see the MBean services being translated to OSGi in a pretty straightforward fashion, but there is a significant amount of code in the EJB layer as well. In order to do this, one would almost have to rewrite dcm4chee from the ground up. I did that once (converted all EJBs to Spring services, and all JBoss-extended MBeans to standard MBeans). It was a lot of work, took a long time, and was out of date even before it was done (because development was continuing on the main code). The only code that survived that work was the JPA entity bean model.

Doing something like this would require a commitment from all parties involved in dcm4chee development.

Comment by Andriyko [ 21/Apr/11 ]

I understand, but is the current situation any better?
I mean - it is using an outdated platform, and it is not clear how it works (at least to me).

Regarding the huge amount of work - most of the code can be salvaged. It is still Java after all.

Comment by Damien Evans [ 21/Apr/11 ]

What about "if it isn't broke, don't fix it"? The software works great, and is extensible.

I think that what would probably happen sooner than OSGi is an update to the JBoss platform. There is already a JIRA issue to update to JBoss 6. To me, that makes much more sense.

Comment by B Reuben Peter-Paul [ 21/Apr/11 ]

I agree OSGI support would be a great update!

I also agree that updating the JBoss platform support to 6 would be another great step forward!

I disagree with the "if it isn't broke, don't fix it".

I think that DCM4CHEE should be separated from JBoss 4.2.3 and released as a standalone Enterprise Application that can be run on any application server. OSGI-ifying DCM4CHEE would be a great way to achieve this.

Comment by Damien Evans [ 21/Apr/11 ]

Out of curiosity, who are you guys and how do you use dcm4chee? You all seem to have come out of the blue here. I don't disagree with your desires though. I think that updating to JBoss 6 would happen sooner than OSGi though. If you want to help out with that, it would be greatly appreciated. See DCMEE-1214

Comment by Damien Evans [ 21/Apr/11 ]

You can also write your own OSGi DICOM services using the dcm4che2 toolkit.





[DCMEE-1655] Support dicom query on Referring Physician identifier (stored in 0008,0096 / 0040,1101 / 0008,0100) as SCP Created: 28/Feb/11  Updated: 28/Feb/11

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nico Vannieuwenhuyze Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

NA



 Description   

In the current version of DCM4CHEE you can only query for studies requested by a specific physician based on the name of the physician (0008,0090).

It would be good if the ID of the physician could be stored in the database (e.g. in study custom attribute/field) and linking the attribute "0008,0096 / 0040,1101 / 0008,0100" to a custom db field would be supported in dcm4chee-attribute-filter.xml.






Consider Study Permissions in Web Interface functions (DCMEE-588)

[DCMEE-1265] Only allow to export Studies or parts of Studies by DICOM Send, for which the user associated with the Destination AE has Read permission Created: 31/Aug/09  Updated: 31/Aug/09

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Gunter Zeilinger Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DCMEE-1760] Enable query/matching of nested private attributes Created: 04/Nov/11  Updated: 04/Nov/11

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Anthony Webster Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

It seems that one cannot perform matching on private attributes nested in private sequences. This imporvement would be most welcome.

For instance, at the study level :

0099,0010 __
0099,1001 SQ
>0099,1002 LO
>0099,1003 PN

I'd like to perform CFind query/matching on 00991001/00991003.






[DCMEE-1820] DCM4CHEE Management of the Move SCU Service Created: 13/Mar/12  Updated: 13/Mar/12

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: Wishlist
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: David Davies Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

In dcm4chee, DICOM objects that are transmitted out of the system (either as the result of a C-MOVE, or autoforwarding/routing) end up going through the Move SCU Service. Currently there is no easy way to manage the move process other than the ability to define a retry strategy and to remove all (move) messages from the underlying queue - individual messages cannot be identified and removed. Finally, failed (retries exhausted) messages are simply discarded.
The main project goal is to create a management interface for the Move SCU Service. This includes a management console view of what has been sent, transfer times, delete queued transmissions, send immediately, etc.
I have proposed a solution that utilizes the Unified Worklist and Procedure Step implementation - see:
http://www.dcm4che.org/confluence/display/ee2/Move+SCU+Queue+Improvements






[DCMEE-2069] QR-Service throws NullPointerException Created: 21/Aug/14  Updated: 21/Aug/14

Status: Open
Project: dcm4chee
Component/s: PIX
Affects Version/s: dcm4chee-2.18.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Schlosser Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

When querying archive with wildcard

findscu -c EE2001663RAD@10.54.108.171:11112 -L PATIENT -m 00100020='3*' 

following exception is thrown:

[org.dcm4chex.archive.dcm.qrscp.QueryRetrieveScpService] Query DB failed:
java.lang.NullPointerException 

An other query throws the following:

WARN  FINDSCU->EE2001663RAD (TCPServer-1-298) [org.jboss.resource.connectionmanager.TxConnectionManager] Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@
40372a53[state=NORMAL mc=org.jboss.resource.adapter.jdbc.local.LocalManagedConnection@47ac639c handles=1 lastUse=1408642161695 permit=true trackByTx=false mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool@781f795
2 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@5a56341a xaResource=org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@6bfbb87 txSync=null]
java.sql.SQLRecoverableException: Keine weiteren Daten aus Socket zu lesen
        at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1157)
        at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:290)
        at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192)
        at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
        at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:193)
        at oracle.jdbc.driver.T4CStatement.executeForDescribe(T4CStatement.java:873)
        at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1167)
        at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1289)
        at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:1491)
        at oracle.jdbc.driver.OracleStatementWrapper.executeQuery(OracleStatementWrapper.java:406)
        at org.jboss.resource.adapter.jdbc.WrappedStatement.executeQuery(WrappedStatement.java:226)
        at org.dcm4chex.archive.ejb.jdbc.BaseReadCmd.execute(BaseReadCmd.java:88)
        at org.dcm4chex.archive.ejb.jdbc.BaseDSQueryCmd.execute(BaseDSQueryCmd.java:78)
        at org.dcm4chex.archive.dcm.qrscp.FindScp.newMultiCFindRsp(FindScp.java:305)
        at org.dcm4chex.archive.dcm.qrscp.FindScp.doCFind(FindScp.java:187)
        at org.dcm4che.net.DcmServiceBase.c_find(DcmServiceBase.java:154)
        at org.dcm4cheri.net.ActiveAssociationImpl.run(ActiveAssociationImpl.java:238)
        at org.dcm4cheri.util.LF_ThreadPool.join(LF_ThreadPool.java:174)
        at org.dcm4cheri.net.ActiveAssociationImpl.run(ActiveAssociationImpl.java:164)
        at org.dcm4cheri.server.DcmHandlerImpl.handle(DcmHandlerImpl.java:249)
        at org.dcm4cheri.server.ServerImpl.run(ServerImpl.java:288)
        at org.dcm4cheri.util.LF_ThreadPool.join(LF_ThreadPool.java:174)
        at org.dcm4cheri.util.LF_ThreadPool$1.run(LF_ThreadPool.java:221)
        at java.lang.Thread.run(Thread.java:682)
 
WARN  FINDSCU->EE2001663RAD (TCPServer-1-301) [org.dcm4chex.archive.ejb.jdbc.BaseCmd] failed to execute sql: SELECT patient.pat_attrs FROM patient WHERE (patient.merge_fk IS NULL) AND  (  ( (patient.pat_id = '100')AND(patient.pat_id_issuer = 'MY') )OR ( (patient.pat_id = '1001')AND(patient.pat_id_issuer = 'YOUR') )OR ( (patient.pat_id = '1002')AND(patient.pat_id_issuer = 'HER') )OR (
...

Archive has PIX-Query activated.
Other wildcard-queries, such as '2*', work.






[DCMEE-2040] Stop/Start of CompressionService should restart the cleanup scheduler Created: 14/Mar/14  Updated: 14/Mar/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-dc, trunk
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Kevin Eagles Assignee: Kevin Eagles
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DCMEE-1954 Decouple temp-image cleanup schedule ... Resolved
Tracking Status:
Test State - Not tested




[DCMEE-1969] Provide MWL search on Patient Birthdate Created: 16/May/13  Updated: 22/Nov/13

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Samuel Imriska Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by DCMEE-2019 Provide a possibility to query MWL by... Closed
Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Provide a search on patient birthdate in MWL






[DCMEE-1814] problem with column type on sql server prevents dcm4chee from starting up Created: 07/Mar/12  Updated: 05/May/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Bubba Ganoush Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

If you check out dcm4chee from trunk, build and deploy it for SQL Server, you will get this error in the log file when JBoss starts up:

09:15:55,031 WARN [ServiceController] Problem starting service persistence.units:ear=dcm4chee-web-ear-3.0.1-mssql.ear,unitName=dcm4chee-arc
javax.persistence.PersistenceException: org.hibernate.HibernateException: Wrong column type: sps_status, expected: int
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:720)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:127)
at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
...

This error prevents many EJBs from starting up.

A workaround is to change the column type in SQL Server to int:

drop index sps_status on mwl_item
alter table mwl_item alter column sps_status int
create index sps_status on mwl_item(sps_status)

While I am sure this is not the real fix, this will at least allow JBoss to start up error-free and allow dcm4chee to receive images...



 Comments   
Comment by Ruben [ 25/Apr/13 ]

This is also happening to me with dcm4chee-2.17.1-mssql and MSSQL 2012 Express... What the description of the issue says fixes the problem to me as well

Comment by Rubin Webb [ 05/May/14 ]

Same issue for me, the workaround fixed it though. Got stuck for a day or so before I found this, thank you.





[DCMEE-1919] New Series Flag, incorrect trigger logic Created: 03/Jan/13  Updated: 19/Jan/13  Resolved: 03/Jan/13

Status: Open
Project: dcm4chee
Component/s: Storage
Affects Version/s: dcm4chee-2.17.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Daniel Chaffee Assignee: Damien Evans
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, PostgresSQL


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Overview:

The default DCM4CHEE code assumes that if a Study with multiple Series' is
being ingested, then first every instance of one Series will be ingested,
then every instance of the next Series, and so on, proceeding in order.
However it is possible for instances from multiple Series' to be
intermixed during ingest. This causes a toggling of this value as the instances for previously processed series come in 'out of order'. Instead of triggering off the the series id changing, this uses a cache(guava cache) to determine if it is a series that has not been identified yet on the association. The order the instances arrive does not matter. Below are some snippets to implement, but there are likely a few dependent items missing. I think the gist of it is covered however and more details can be provided. The guava cache is an eternal dependency we added, so i am not necessarily including that as the impl can be swapped out to use any other cache with minimal code modification.

Instead of doing

StoreSCP.java
if (newSeries)
{
   seriesStored = initSeriesStored(ds, callingAET, retrieveAET);
   assoc.putProperty(SERIES_STORED, seriesStored);
}

we implemented our own cache(using google guava library) and did

StoreSCP.java
if (newSeries)
{

	seriesStored = initSeriesStored(ds, callingAET, retrieveAET);

	// If this is the first instance of a particular Series being
	// ingested, store the
	// seriesStored object in the seriesStoredCache!

	// Check the cache for entries for this Association
	Map<SeriesIdentifier, SeriesStored> seriesStoredCacheValueMap = seriesStoredCache
		.getIfPresent(assoc);

	// If this is the first entry for this Association, create a new
	// Map
	if (seriesStoredCacheValueMap == null)
	{
		seriesStoredCacheValueMap = new HashMap<SeriesIdentifier, SeriesStored>();
	}

	// Add this seriesStored object to the Map
	SeriesIdentifier seriesId = new SeriesIdentifier(ds);
	seriesStoredCacheValueMap.put(seriesId, seriesStored);

	// Put this Map into the cache
	seriesStoredCache.put(assoc, seriesStoredCacheValueMap);
}

Additionally. modified the handleSeriesStored method to use the cache.

StoreSCP.java
protected SeriesStored handleSeriesStored(
        Association assoc,
        Storage store,
        Dataset ds) throws FinderException, RemoteException, Exception
{

	// Modified "handleSeriesStored" to check the cache (instead of the
	// association property) for whether or not this Series has been stored
	// previously
	SeriesIdentifier seriesId = new SeriesIdentifier(ds);
	Map<SeriesIdentifier, SeriesStored> seriesStoredCacheValueMap = seriesStoredCache
		.getIfPresent(assoc);
	SeriesStored seriesStored;

	if (seriesStoredCacheValueMap == null)
	{
		seriesStored = null;
	}
	else
	{
		seriesStored = seriesStoredCacheValueMap.get(seriesId);
	}

	// Returns null if this is a new Series for the given association
	return seriesStored;
}

The SeriesIdentifier class is a newly added class defined below

SeriesIdentifier.java
public class SeriesIdentifier
{
    /**
     * Study that this series belongs to
     */
    private StudyIdentifier theStudyIdentifier;

    /**
     * Series instance uid
     */
    private String          theSeriesUid;

    /**
     * Constructor
     * 
     * @param aStudyDataSet
     *            dataset that identifying information will be collected from
     */
    public SeriesIdentifier(Dataset aStudyDataSet)
    {
        theStudyIdentifier = new StudyIdentifier(aStudyDataSet);
        theSeriesUid = aStudyDataSet.getString(Tags.SeriesInstanceUID);
    }

    /**
     * get series uid
     * 
     * @return series instance uid
     */
    public String getSeriesUid()
    {
        return theSeriesUid;
    }

    /**
     * get study identifier
     * 
     * @return series identifier
     */
    public StudyIdentifier getStudyIdentifier()
    {
        return theStudyIdentifier;
    }

    /**
     * Overrides the equals method Checks to see if two instances belong to the
     * same study
     */
    @Override
    public boolean equals(Object other)
    {
        if (other == null)
        {
            return false;
        }
        if (other == this)
        {
            return true;
        }
        if (this.getClass() != other.getClass())
        {
            return false;
        }
        SeriesIdentifier otherSeriesIdentifier = (SeriesIdentifier) other;
        if ((otherSeriesIdentifier.getStudyIdentifier())
            .equals(getStudyIdentifier())
            && otherSeriesIdentifier.getSeriesUid().equals(getSeriesUid()))
        {
            return true;
        }
        else
        {
            return false;
        }

    }

    /**
     * Overrides the hashCode method
     */
    @Override
    public int hashCode()
    {
        return getStudyIdentifier().hashCode() + theSeriesUid.hashCode();
    }

    /**
     * Overrides the toString method
     */
    @Override
    public String toString()
    {
        return getStudyIdentifier().toString() + "\\" + theSeriesUid;
    }
}





[DCMEE-1830] Compressed pixel data in (0088,0200) is not properly decompressed Created: 10/Apr/12  Updated: 22/Jan/13

Status: Open
Project: dcm4chee
Component/s: Compression
Affects Version/s: dcm4chee-2.17.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Damien Evans Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File orig-1.2.840.113619.2.131.571110706.1226051996.105600.dcm     File transcoded-1.2.840.113619.2.131.571110706.1226051996.105600    
Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

We are having an issue with encapsulated data in the Icon Image sequence (0088,0200) tag during transcoding. In short if we receive a study that has compressed pixel data in this sequence dcm4chee will not properly decompress this pixel data if the study is requested in Implicit VR Little Endian (IVRLE). If the data set transfer syntax is IVRLE then the pixel data in that sequence should also get decompressed and transcoded to IVRLE, but it isn't.

If we let dcm4chee do the compression it will successfully also decompress and transcode to IVRLE, however, If we received the study already compressed it will not decompress that pixel data in the sequence. The difference is in how dcm4chee represents the pixel data (as an OW and a fixed length) vs. how it arrives from elsewhere (as an OB with undefined length). According to CP-165 OB with undefined length is valid so this seems like a use case that might have been missed in the transcoding logic of chee/che

CP-165 defines the rules for how (0088,0200) should be structured if it is compressed (encapsulated), although provides no guidance for how it should be when in native format. It seems CP-165 really was put in place to allow an encapsulated data set to have uncompressed data in the (0088,0200) sequence. I suspect they were not thinking of this sequence containing compressed data if the entire dataset is IVRLE... it's not explicitly defined, but highly unlikely this is a desired/intended case.

Note: This is also reproducible in the dcm4che2 toolkit by taking an originally compressed JPEG Lossless (1.2.840.10008.1.2.4.90) instance and using dcm2dcm to transcode it to IVRLE. The pixel data inside the sequence remains compressed, while the pixel data outside the sequence is properly decompressed.



 Comments   
Comment by Ben Mehling [ 18/Jul/12 ]

The attached (de-identified) studies provides an example of this issue. The first (orig-) is the study compressed, the second (transcoded-) is the same study after being sent into CHEE and pulled out again in IVRLE. The following command was used to pull the study out:

dcmqr -L TEST1_AET <AETitle>@<hostname>:<port> -q PatientID=QCTEST1 -cget -cstore 1.2.840.10008.5.1.4.1.1.128:1.2.840.10008.1.2 -cstoredest .

You'll note the second study is larger (as expected, it's uncompressed). Using dcm2txt you can view the following sequence:

6812:>(0028,0103) US #2 [0] Pixel Representation
6822:>(7FE0,0000) UL #4 [7552] Group Length
6834:>(7FE0,0010) OW #-1 Pixel Data
6842:>>(FFFE,E000) #4 [0\0] Item
6854:>>(FFFE,E000) #7516 [20479\20991\10496\0\0\32768\0\32768\0\0\0\0\0\32768\
14378:>>(FFFE,E0DD) #0 Sequence Delimitation Item
14386:(0095,0000) UL #4 [26] Group Length
14398:(0095,0010) LO #6 [SIENET] Private Creator Data Element
14412:(0095,100C) UN #4 [\00\00\00\00] ?
14424:(0097,0000) UL #4 [26] Group Length
14436:(0097,0010) LO #6 [SIENET] Private Creator Data Element
14450:(0097,1003) UN #4 [\01\00\00\00] ?
14462:(0099,0000) UL #4 [38] Group Length
14474:(0099,0010) LO #6 [SIENET] Private Creator Data Element
14488:(0099,1002) UN #4 [\00\00\00\00] ?
14500:(0099,1005) UN #4 [,\00\00\00] ?
14512:(7FE0,0010) OW #32768 [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

Note the presence of the "OW #-1", indicating encapsulated (compressed) data even though the study was requested as IVRLE.

Comment by Daniel Chaffee [ 03/Jan/13 ]

A solution was created for this problem. First there is a change to QueryRetieveSCPService.java to enable decompression of the IIS.

Below the line for

QueryRetieveSCPService.java
adjustAccessionNumberOnRetrieval(mergeAttrs, assoc, dest);

add

QueryRetieveSCPService.java
//decinoressIconImageSequence is driven from jmx as an added attribute to queryRetrieveSCPService. It can be True/False to enable this capability.
if (decompressIconImageSequence)
        {
            // Immediately after the FileDataSource below parses the header 
            // of a file into a Dataset, this will decompress any Icon Image 
            // Sequence pixels in the Dataset. If this throws an exception, 
            // the usual result is successful transmission of an incomplete 
            // image.
            datasetUpdater = new DatasetUpdater() {
                @Override
                public Dataset updateDataset(Dataset ds) {
                    return IconImageSequenceUtils.decompress(ds); 
                }
            };
        }
        else
        {
            datasetUpdater = null;
        }

//Below is the entire IconImageSequenceUtils.java class

IconImageSequenceUtils.java
package org.dcm4chex.archive.util;

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.StringWriter;

import javax.imageio.stream.ImageInputStream;
import javax.imageio.stream.MemoryCacheImageInputStream;

import org.dcm4che.data.Dataset;
import org.dcm4che.data.DcmDecodeParam;
import org.dcm4che.data.DcmElement;
import org.dcm4che.data.DcmEncodeParam;
import org.dcm4che.data.DcmObject;
import org.dcm4che.data.DcmObjectFactory;
import org.dcm4che.data.DcmParseException;
import org.dcm4che.data.DcmParser;
import org.dcm4che.data.DcmParserFactory;
import org.dcm4che.data.DcmValueException;
import org.dcm4che.data.FileMetaInfo;
import org.dcm4che.dict.Tags;
import org.dcm4che.dict.VRs;
import org.dcm4chex.archive.codec.DecompressCmd;
import org.dcm4chex.archive.exceptions.ConfigurationException;

import org.jboss.logging.Logger;

/**
 * Utility class to parse/edit an Icon Image Sequence
 * 
 * @author <a href="mailto:mmesser@peakehealthcare.com">Mark Messer</a>
 * @version 1.0.0
 * @since 30 November 2012
 */
public class IconImageSequenceUtils
{

    private static Logger    log     = Logger
                                         .getLogger(IconImageSequenceUtils.class);

    /*
     * Methods that take a StopTag argument will stop parsing a Dataset at a
     * given tag. Use MAX_TAG to stop at EOF instead.
     */
    private static final int MAX_TAG = 0xFFFFFFFF;

    /**
     * Returns true if ds contains an Icon Image Sequence.
     * 
     * @param ds
     *            Dataset to check for an Icon Image Sequence, typically the
     *            header of an image
     * @return true if ds contains an Icon Image Sequence
     */
    public static boolean hasIconImageSequence(Dataset ds)
    {
        boolean hasIIS = false;
        Dataset iisContents = ds.getItem(Tags.IconImageSeq);

        if (iisContents != null)
        {
            hasIIS = (iisContents.length() > 0);
        }
        return hasIIS;
    }

    /**
     * Returns true if ds contains an Icon Image Sequence, and the Icon Image
     * Sequence contains compressed pixels.
     * 
     * @param ds
     *            Dataset to check for an Icon Image Sequence, typically the
     *            header of an image
     * @return true if ds contains an Icon Image Sequence with compressed
     *         pixels.
     */
    public static boolean hasCompressedIconImageSequence(Dataset ds)
    {
        Dataset iisContents = ds.getItem(Tags.IconImageSeq);

        /*
         * Compressed pixels are formatted differently than uncompressed.
         * Compressed always have a length of -1. Uncompressed always >= 0.
         */
        if (iisContents != null)
        {
            DcmElement iisPixels = iisContents.get(Tags.PixelData);
            if ((iisPixels != null) && (iisPixels.length() == -1))
            {
                return true;
            }
        }
        return false;
    }

    /**
     * Returns ds with decompressed Icon Image Sequence Pixels, if possible.
     * Returns ds unchanged on failure or if no Icon Image Sequence exists.
     * These cases are normal returns.
     * <p>
     * There is no error return. If ds cannot be returned unchanged or with
     * successfully decompressed IIS pixels, then an exception must be thrown.
     * <p>
     * Throwing an exception is a last resort. All checked and runtime
     * exceptions generated while attempting to decompress pixels are caught.
     * (Decompression errors or invalid IIS data can generate runtime
     * exceptions.) Errors are allowed to propagate.
     * <p>
     * Returning ds unchanged does not guarantee that ds is in a valid state.
     * E.G. If an image is being decompressed, then DICOM requires the IIS
     * pixels to be decompressed.
     * 
     * @param ds
     *            Dataset that may contain an Icon Image Sequence, typically the
     *            header of an image
     * @return either ds with the pixels successfully decompressed, or ds
     *         unchanged
     */
    public static Dataset decompress(Dataset ds)
    {
        // Get the contents of the first (and only) item in the IIS.
        Dataset iisContents = ds.getItem(Tags.IconImageSeq);

        if (iisContents != null)
        {
            /*
             * Compressed pixels are formatted differently than uncompressed.
             * Compressed always have a length of -1. Uncompressed always >= 0.
             */
            DcmElement iisPixels = iisContents.get(Tags.PixelData);
            if ((iisPixels != null) && (iisPixels.length() == -1))
            {
                log.info("Decompressing Icon Image Sequence pixels");

                // Save values in case we need to build a GWL item.
                String errMsg = "";
                String tsOrig = null;
                Throwable t = null;

                /*
                 * Decompression will be done in a temporary Dataset. ds will
                 * remain unchanged until the very end.
                 */
                DcmObjectFactory oFact = DcmObjectFactory.getInstance();
                Dataset iisCopy = oFact.newDataset();
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                Dataset iisDecomp = null;
                try
                {
                    iisCopy.putAll(iisContents, DcmObject.REPLACE_ITEMS);

                    FileMetaInfo fmi = ds.getFileMetaInfo();
                    if (fmi != null)
                    {
                        /*
                         * Write the IIS to a byte array. No compression change.
                         * The byte array is equivalent to an in-memory minimal
                         * image file.
                         */
                        tsOrig = fmi.getTransferSyntaxUID();
                        DcmEncodeParam encNoChange = DcmEncodeParam
                            .valueOf(tsOrig);
                        iisCopy.writeFile(baos, encNoChange);

                        /*
                         * Transcode the byte array to another image file-like
                         * byte array, decompressing the pixels.
                         */
                        ImageInputStream inDecomp = new MemoryCacheImageInputStream(
                            new ByteArrayInputStream(baos.toByteArray()));
                        ByteArrayOutputStream baos2 = new ByteArrayOutputStream();
                        DcmParser decompressor = DcmParserFactory.getInstance()
                            .newDcmParser(inDecomp);
                        decompressor.setDcmHandler(iisCopy.getDcmHandler());
                        decompressor.parseDcmFile(null, Tags.PixelData);
                        DecompressCmd cmd = new DecompressCmd(
                            iisCopy,
                            tsOrig,
                            decompressor);
                        int newPixelDataLen = cmd.getPixelDataLength();
                        iisCopy.writeFile(baos2, DcmDecodeParam.EVR_LE);
                        iisCopy.writeHeader(
                            baos2,
                            DcmDecodeParam.EVR_LE,
                            Tags.PixelData,
                            VRs.OW,
                            (newPixelDataLen + 1) & ~1); // Length must be even
                        cmd.decompress(DcmDecodeParam.EVR_LE.byteOrder, baos2);

                        /*
                         * DICOM requires all tags to have even length, and
                         * specifies how to pad tags with odd length.
                         */
                        if ((newPixelDataLen & 1) != 0)
                            baos2.write(0);

                        /*
                         * Read the byte array back to a Dataset with no
                         * compression change.
                         */
                        ByteArrayInputStream bias = new ByteArrayInputStream(
                            baos2.toByteArray());
                        iisDecomp = oFact.newDataset();
                        iisDecomp.readDataset(
                            bias,
                            DcmDecodeParam.EVR_LE,
                            MAX_TAG);
                    }
                    else
                    {
                        errMsg = "Cannot find transfer syntax";
                    }
                }
                catch (DcmParseException e)
                {
                    errMsg = "DICOM data could not be parsed";
                    t = e;
                }
                catch (DcmValueException e)
                {
                    errMsg = "DICOM data could not be read";
                    t = e;
                }
                catch (IOException e)
                {
                    errMsg = "IO error";
                    t = e;
                }
                catch (ConfigurationException e)
                {
                    errMsg = "Configuration error";
                    t = e;
                }
                catch (UnsupportedOperationException e)
                {
                    errMsg = "Unsupported operation, such as use of an unsupported compression algorithm";
                    t = e;
                }
                catch (Exception e)
                {
                    errMsg = "Unknown error";
                    t = e;
                }

                if (!errMsg.isEmpty())
                {
                    //do something with the error message. Log perhaps.
		    //log.error(errMsg);
                    return ds;
                }

                /*
                 * Wrap the decompressed IIS content in an Icon Image Sequence
                 * and insert it into ds, overwriting the original IIS.
                 */
                DcmElement sq = ds.putSQ(Tags.IconImageSeq);
                sq.addItem(iisDecomp);
            }
        }

        return ds;
    }
Comment by Mark Messer [ 05/Jan/13 ]

This small bug needs a lot of explanation.

Partial solution

This only decompresses Icon Image Sequences during export via C-GET or C-MOVE. It does not affect images exported with a file copy, as can be done with the web interface. This solution cannot be used by dcmsnd because it would add unwelcome dependencies.

No decompression is needed during import, or for images already present in dcm4chee. dcm4chee ignores the icon image sequence.

DICOM issues

DICOM has special rules for Icon Image Sequence (IIS) pixel compression

The transfer syntax defines format of an image, including compression. The main pixels must follow the transfer syntax.

IIS pixels may be compressed as dictated by the transfer syntax. If the transfer syntax specifies compressed pixels, the IIS pixels may alternatively be formatted as if the transfer syntax was EVRLE (uncompressed).

IIS compression does not affect many images

Few images have IIS pixels. IIS pixels are usually uncompressed when created - They are thumbnails. Most applications ignore an IIS. Very few compress IIS pixels.

As a rule of thumb, IIS pixels should never be compressed. An application is within its DICOM rights to compress IIS pixels. But it might be considered rude. Compressed IIS pixels cause other applications with common shortcomings to create invalid images.

Compressed IIS pixels make it easy to generate invalid images

Suppose an image arrives with main and IIS pixels compressed. dcm4chee ignores the IIS pixels when it decompresses the image or changes the compression. The IIS remain compressed as they were. The image is now invalid. This is incorrect behavior, but quite common.

Furthermore, no tag is left in the image that says what the original IIS compression is. Now there is no easy way to decompress the IIS pixels.

This errors is usually harmless. The IIS pixels are seldom used. Most applications ignore the IIS compeletly.

However, it is not always harmless. An application is within its DICOM rights to refuse to handle an invalid image. For example, the Sante free viewer cannot parse an image with uncompressed main pixels and compressed IIS pixels.

Uncompressed IIS pixels make an image immune from becoming invalid this way

Suppose an image has uncomressed main pixels. Suppose dcm4chee changes the compression of the main pixels, and ignores the IIS pixels. The uncompressed IIS pixels remain valid.

The VR is the only confusing part. It is handled correctly. All compressed transfer syntaxes have explicit VR. The uncompressed transfer syntaxes are EVRLE and IVRLE. (Ignore big endian. It is never used.) When the transfer syntax is changed, dcm4chee sets the VR of all tags. The IIS pixels are just another tag.

Design considerations

Decompression is done in a rather round about way. An in-memory Dataset is turned into an in-memory "file". The "file" is transcoded into a second decompressed in-memory "file." This "file" is read to get an in-memory Dataset.

This is done because the machinery of dcm4chee is intended for images that may be too big to fit in memory. Decompression is done from file to file.

Error handling

The error handling works (with some caveats), but it could be improved. The first caveat is that decompress() allows errors to propagate. It should not do this. All exceptions should be caught.

dcm4chee has a bug

If an exception is thrown while C-GET or C-MOVE is sending an image, the usual result is corrput data. An invalid partial image will be sent successfully.

The correct response to an exception that prevents a valid image from being sent would be for the DICOM association to return an error status.

An IIS decompression failure need not prevent an image from being sent, even if this makes image invalid. Most clients will want the C-GET or C-MOVE to succeed with the IIS pixels unchanged.

It is possible that some clients would want an IIS decompression error to make the C-GET or C-MOVE fail with an error status. If so, a configuration option could be created to allow this.

Catching exceptions

IconImageSequenceUtils.decompress() catches (almost) all exceptions that it creates. This allows C-GET and C-MOVE to continue on decompression error.

decompress() should not catch exceptions. decopmress() is a utility. The client should handle errors. The decompress() doc comments should declare all the exceptions it can throw.

Bad data can make decompress() throw unchecked exceptions like NullPointerException. I don't know if errors like ArithmeticException are possible. decompress() should declare that it can throw Throwable.

The anonymous DatasetUpdater should catch and log all exceptions thrown by decompress().

Simply logging the exception may not be enough, but it is the best we can do. If the client expects decompressed Icon Image Sequences, leaving one compressed may be the equivalent of silently corrupting data. The error should be logged in a way that comes to the attention of a human, but dcm4chee has no mechanism for this. This is caveat number 2.

The DatasetUpdater declaration permits no error return, and only premits JMException exceptions to be thrown.

The decompressIconImageSequence switch

The decompressIconImageSequence switch is a safety valve. It is possible that decompress() could have a bug. If so, it would be desirable to turn it off and revert to the former behavior.





[DCMEE-1887] Corrupt ECG Waveform freezes RID Created: 10/Oct/12  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Open
Project: dcm4chee
Component/s: RID
Affects Version/s: dcm4chee-2.17.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Simon Schlosser Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

oracle_V2.17.1_PRE_2012-10-10_1000;attached DICOM file


Attachments: File 1.11.111111.36034394625682067374171008254477958300.dcm    
Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Docs - No, Config affected - No, Test State - Not tested

 Description   

When rendering corrupt ECG Waveform (display via webinterface), modal window freezes. See attached DICOM file.
Expected behaviour when rendering not possible is an abort/exception.
No errors in server.log:

2012-10-10 16:11:14,467 DEBUG -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.web.RIDServiceDelegate] RIDdelegate.getRIDDocument called
2012-10-10 16:11:14,467 DEBUG -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.mbean.RIDService] getRIDDocument:org.dcm4chex.rid.web.RIDDocumentRequestObject@8212c81
2012-10-10 16:11:14,480 DEBUG -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.mbean.RIDSupport] Found Dataset:
0014 	(0008,0016) UI #30 *1 [1.2.840.10008.5.1.4.1.1.9.1.1] //SOP Class UID
0052 	(0008,0018) UI #50 *1 [1.11.111111.36034394625682067374171008254477958300] //SOP Instance UID
-0001 	(0008,0020) DA #8 *1 [20121010] //Study Date
-0001 	(0008,0021) DA #8 *1 [20121010] //Series Date
0110 	(0008,0022) DA #8 *1 [20121010] //Acquisition Date
0126 	(0008,0023) DA #8 *1 [20121010] //Content Date
...
-0001 	(0040,0244) DA #8 *1 [20070102] //Performed Procedure Step Start Date
-0001 	(0040,0245) TM #10 *1 [112148.000] //Performed Procedure Step Start Time
2012-10-10 16:11:14,488 DEBUG -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.mbean.RIDSupport]  check against:[text/html, application/xhtml+xml, application/xml, */*]
2012-10-10 16:11:14,488 DEBUG -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.mbean.RIDSupport]  check application/pdf:false ,application/*: false
2012-10-10 16:11:14,488 DEBUG -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.mbean.RIDSupport]  check */*:true
2012-10-10 16:11:14,488 INFO  -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.mbean.ECGSupport] get ECG document! docUID:1.11.111111.36034394625682067374171008254477958300
2012-10-10 16:11:14,490 INFO  -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.web.RIDServiceDelegate] doGet: resp returnCode:200
2012-10-10 16:11:14,490 INFO  -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.web.RIDServlet] --- sendResponse started! :org.dcm4chex.rid.mbean.RIDStreamResponseObjectImpl@58ac7f91
2012-10-10 16:11:14,490 INFO  -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.web.RIDServiceDelegate] respObject execute
2012-10-10 16:11:14,490 INFO  -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.mbean.RIDStreamResponseObjectImpl] InputSTream closed!
2012-10-10 16:11:14,490 INFO  -> (http-10.231.161.51-8080-53) [org.dcm4chex.rid.web.RIDServlet] --- sendResponse finished!





[DCMEE-1888] A check for file system availability should be made before create a DeleteStudyOrder. Created: 10/Oct/12  Updated: 22/Jan/13  Resolved: 10/Oct/12

Status: Open
Project: dcm4chee
Component/s: Deleter
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ken Dawson Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Config affected - No

 Description   

Adding check for file system availability before creating deleteStudyOrders. This would prevent database record deletion if file system cannot be reached.






[DCMEE-1937] Whitespace-only Code item attributes not recognized as empty - lead to NULL exceptions on INSERT Created: 19/Feb/13  Updated: 19/Feb/13  Resolved: 19/Feb/13

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Christopher Archer Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Currently, CodeBean.java checks whether Code items are empty based on an incomplete evaluation of the attributes. For instance, in method checkCodes, a Code item with attributes (e.g. code value and code designator) that consist only of whitespace characters are not considered empty. However, attempts to save such codes result in multiple errors
ORA-01400: cannot insert NULL into ("DBADMIN"."CODE"."CODE_VALUE")



 Comments   
Comment by Christopher Archer [ 19/Feb/13 ]

Suggested fixes:

To have checkCodes correctly handle attributes consisting only of whitespace characters, modify CodeBean.java method checkCodes to below:

/**

  • Check all codes in a sequence and return true if the sequence is null/empty or
  • there is at least one existing valid code, otherwise return false
  • @param prompt - description of sequence, used in log message
  • @param sq - sequence containing code items
  • @return true if no codes exist or at least one code is valid, false otherwise
    */
    public static boolean checkCodes(String prompt, DcmElement sq) {
    if (sq == null || sq.isEmpty() || sq.countItems() == 0) { return true; }
    int validCount = sq.countItems();
    for (int i = 0, n = sq.countItems(); i < n; i++)
    Unknown macro: { Dataset item = sq.getItem(i); if (isValueEmpty(item.getString(Tags.CodeValue))) { log.warn("Missing Code Value (0008,0100) in " + prompt + " - ignore item."); validCount--; } else if (isValueEmpty(item.getString(Tags.CodingSchemeDesignator))) { log.warn("Missing value for Coding Scheme Designator (0008,0102) in " + prompt + " - ignore item"); validCount--; } else if (isValueEmpty(item.getString(Tags.CodeMeaning))) { log.warn("Missing Code Meaning (0008,0104) in " + prompt); } }

    return (validCount > 0);
    }

private static boolean isValueEmpty(String str) { return ((str == null) || (str.trim().length() == 0)); }

To intercept and ignore invalid codes before attempting to store in the database, change method valueOf as follows:

if (item == null) return null;

final String value = item.getString(Tags.CodeValue);
+ if (isValueEmpty(value)) { + log.warn("Missing Code Value - ignore item"); + return null; + }
final String designator = item.getString(Tags.CodingSchemeDesignator);
+ if (isValueEmpty(designator)) { + log.warn("Missing Code Designator - ignore item"); + return null; + }
final String version = item.getString(Tags.CodingSchemeVersion);
final String meaning = item.getString(Tags.CodeMeaning);

and method addCodesTo

if (sq == null || sq.isEmpty()) return;
Dataset item = sq.getItem(0);
if (item.isEmpty()) return;

  • c.add(CodeBean.valueOf(codeHome, item));
    + CodeLocal codeItem = CodeBean.valueOf(codeHome, item);
    + if (codeItem != null) { + c.add(codeItem); + }
    for (int i = 1, n = sq.countItems(); i < n; i++) {
  • c.add(CodeBean.valueOf(codeHome, sq.getItem));
    + codeItem = CodeBean.valueOf(codeHome, sq.getItem);
    + if (codeItem != null) { + c.add(codeItem); + }
    }




[DCMEE-1804] Transient failures on decompression Created: 21/Feb/12  Updated: 22/Jan/13

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.17.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Brendan Moloney Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux 64-bit (Debian)


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Several compression algorithms (at least JPEG LS and JPEG Lossless) have transient failures on decompression. The causes the retrieved DICOM data to have no pixel data. I have taken a number of steps to eliminate faulty hardware as a root cause. See this thread for details: http://forums.dcm4che.org/jiveforums/thread.jspa?threadID=4452&tstart=0

I see the following error in the logs:

2012-02-16 05:30:47,937 INFO COUCH->AUTOTRAN2 (Thread-2891) http://org.dcm4cheri.net.FsmImpl sending pc-3 123:C_STORE_RQ with Dataset
class: 1.2.840.10008.5.1.4.1.1.4/MR Image Storage
inst: 1.3.12.2.1107.5.2.32.35139.2011051917293341093627539/?
2012-02-16 05:30:47,937 INFO COUCH->AUTOTRAN2 (Thread-2891) http://org.dcm4chex.archive.util.FileDataSource M-READ file:/dicom/2012/2/16/5/3EAA02D8/193A7A25/81629CB8
2012-02-16 05:30:47,938 INFO COUCH->AUTOTRAN2 (Thread-2891) http://org.dcm4chex.archive.codec.CodecCmd start decompression of image: 120x120x1 (current codec tasks: compress&decompress:1 decompress:1)
2012-02-16 05:30:47,999 INFO COUCH->AUTOTRAN2 (Thread-2891) http://org.dcm4chex.archive.codec.CodecCmd finished decompression in 61ms. (remaining codec tasks: compress&decompress:0 decompress:0)
2012-02-16 05:30:48,000 ERROR -> (Thread-2891) http://org.dcm4chex.archive.dcm.qrscp.QueryRetrieveScpService Exception during move of 1.3.12.2.1107.5.2.32.35139.2011051917293341093627539
javax.imageio.IIOException: Decoder cannot decode input.
at com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageReader.decode(CLibJPEGImageReader.java:134)
at com.sun.media.imageioimpl.plugins.clib.CLibImageReader.getImage(CLibImageReader.java:497)
at com.sun.media.imageioimpl.plugins.clib.CLibImageReader.read(CLibImageReader.java:575)
at org.dcm4chex.archive.codec.DecompressCmd.decompress(DecompressCmd.java:230)
at org.dcm4chex.archive.util.FileDataSource.writeTo(FileDataSource.java:494)
at org.dcm4cheri.net.DimseImpl.writeTo(DimseImpl.java:128)
at org.dcm4cheri.net.DimseWriterImpl.write(DimseWriterImpl.java:92)
at org.dcm4cheri.net.AssociationImpl.write(AssociationImpl.java:327)
at org.dcm4cheri.net.ActiveAssociationImpl.invoke(ActiveAssociationImpl.java:182)
at org.dcm4chex.archive.dcm.qrscp.MoveTask.retrieveLocal(MoveTask.java:425)
at org.dcm4chex.archive.dcm.qrscp.MoveTask.run(MoveTask.java:355)
at java.lang.Thread.run(Thread.java:662)
2012-02-16 05:30:48,000 INFO COUCH->AUTOTRAN2 (ActiveAssoc-3074) http://org.dcm4cheri.net.FsmImpl received pc-3 123:C_STORE_RSP
class: 1.2.840.10008.5.1.4.1.1.4/MR Image Storage
inst: 1.3.12.2.1107.5.2.32.35139.2011051917293341093627539/?
status: 0






[DCMEE-1795] Memory leak on study deletions Created: 06/Feb/12  Updated: 22/Jan/13

Status: Open
Project: dcm4chee
Component/s: Deleter
Affects Version/s: dcm4chee-2.17.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Brendan Moloney Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux (Debian 6), mysql


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

While performing testing I needed to delete all of the studies in the archive (about 9,000 studies total). I set it so that studies that had not been accessed for one hour would get deleted. I also set it to delete the studies from the database. Memory usage slowly grew as the deletions occurred until it hit the 4GB limit for the heap. Some studies are larger than average, but it seems like this should not affect memory usage during deletions. The server was not handling any other transactions at the time.



 Comments   
Comment by Brendan Moloney [ 21/Feb/12 ]

This issue seems to have some other root cause. The most likely candidate is transaction timeouts while trying to delete very large studies. See this forum topic for more information: http://forums.dcm4che.org/jiveforums/thread.jspa?threadID=4463&tstart=0





[DCMEE-1951] Error retrieving large DICOM Objects Created: 12/Apr/13  Updated: 12/Apr/13

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: jason crane Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

at least for dcm4chee with psql


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Retrieving DICOM objects with file size > sizeof int is failing with the following error in server.log:
org.postgresql.util.PSQLException: Bad value for type int : 2782114486

FYI, we are storing RawDataStorage instances with several ~1GB elements.

After turning up logging I tracked this down to ./org/dcm4chex/archive/ejb/jdbc/RetrieveCmd.

pacsdb.files.file_size is a bigint and correctly reflects the size of the stored object. However, when attempting to retrieve the object with dcmqr I receive the above error in the server.log. In RetrieveCmd.java it looks like the file_size field is being mapped through an int (getInt), rather than long int to FileInfo.size. Making the following changes and rebuilding fixed the problem for me. Is this a reasonable fix that can be incorporated into the project.

diff RetrieveCmd.java ../dcm4jboss-ejb/src/java/org/dcm4chex/archive/ejb/jdbc/RetrieveCmd.java
330c330
< info.size = rs.getLong(15);

> info.size = rs.getInt(15);
443c443
< info.size = rs.getLong(21);

> info.size = rs.getInt(21);

thanks,
-Jason






[DCMEE-1962] DeleteStudyService Can't Find SonFS after a StudyDeletion Created: 07/May/13  Updated: 07/May/13

Status: Open
Project: dcm4chee
Component/s: Deleter
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Christopher Redekop Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

DeleteStudyService#deleteStudy cleans up the SonFS record after a study is deleted. When deleteStudyFromDB is true, however, a cascade-delete beats DeleteStudyService to it, and an ObjectNotFoundException is thrown:

javax.ejb.ObjectNotFoundException: No such entity!
at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:676)
at sun.reflect.GeneratedMethodAccessor179.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:136)
at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:45)
at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
at org.jboss.ejb.Container.invoke(Container.java:981)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
at $Proxy314.findByPrimaryKey(Unknown Source)
at org.dcm4chex.archive.ejb.session.FileSystemMgt2Bean.removeStudyOnFSRecord(FileSystemMgt2Bean.java:763)






[DCMEE-2013] checkForFilesToCompress crashes when there are millions of files to compress Created: 29/Oct/13  Updated: 29/Oct/13

Status: Open
Project: dcm4chee
Component/s: Compression
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Stephan Bender Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu server 64 bit,
JDK 32 bit


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

If a huge amount of files were transmitted to dcm4chee (e.g. during a PACS migration), the delayed compression service crashes with an out of memory error

See here:
https://groups.google.com/d/msg/dcm4che/JGsBCrwc-Vc/XZMCmSSrHFgJ






[DCMEE-2014] compress() method with instance UID as parameter Created: 29/Oct/13  Updated: 29/Oct/13

Status: Open
Project: dcm4chee
Component/s: CDW
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Stephan Bender Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

please include a compress() method with a UID as parameter (not only a FileDTO, which can't be used from the web interface or via twiddle.sh).

Thank you!






[DCMEE-2015] Patches 2.17.3 Created: 30/Oct/13  Updated: 30/Oct/13

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Franz Willer Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File dcm4chee-hsm-migrate-xmbean.xml     Java Archive File dcm4chee.jar    
Issue Links:
Inclusion
includes DCMEE-2007 HSM Migration Service: Migrate a UID ... Closed
Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Comments   
Comment by Franz Willer [ 30/Oct/13 ]

Apply patch:
1) Copy dcm4chee.jar to <DCM4CHEE>/server/default/lib
2) Copy dcm4chee-hsm-migrate-xmbean.xml to <DCM4CHEE>/server/default/conf/xmdesc





[DCMEE-1998] ContentEditService changes instance UIDs, what about referenced image sequence? Created: 30/Aug/13  Updated: 30/Aug/13

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Bartosz Wiklak Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Dcm4chee changes uids of instances moved from one series to another. What about instances that have a reference to this images (i.e Key Objects, Structured Reports, Presentation States, etc.)?
After move operation the referenced images have different UIDs then one in referenced image sequence.






[DCMEE-1999] Leading Space in PN Being Treated as Significant Created: 09/Sep/13  Updated: 09/Sep/13

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Chad Neller Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

To reproduce:
-Create a patient with a Patient Name attribute of " Smith" (note leading space).
-Use DcmQR to query for "Smith" (no results are returned).

PS 3.5 indicates that DICOM allows leading spaces in PN, but considers them insignificant. Therefore, I would expect a query for "Smith" to find " Smith".

Of note, queries for "*Smith" and " Smith" do find " Smith".

If this is not an issue in DCM4CHEE, then I believe the DCM4CHE2 toolkit should not trim PN attributes (see constructor for org.dcm4che2.data.PersonName).

This affects users of the DCM4CHE2 toolkit using the PersonName class. I have also seen the effect in the DCM4CHEE-web3 interface.






[DCMEE-2029] Refactor part of StoreScp to allow for extension/override of some common behaviour Created: 31/Jan/14  Updated: 31/Jan/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Michael Doris Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

In the StoreScp.doActualCStore() there are a number of tasks involving creation of the file on the filesystem that we have need to extend/override. These functions are being pulled into a common method that can be overridden without impacting the function of the underlying open source code.






[DCMEE-2057] Calculation of deletion candidates does not take into account jobs in deleter queue Created: 03/Jun/14  Updated: 03/Jun/14

Status: Open
Project: dcm4chee
Component/s: Deleter
Affects Version/s: dcm4chee-2.14.7, dcm4chee-2.14.8, dcm4chee-2.15.0, dcm4chee-2.16.0, dcm4chee-2.16.1, dcm4chee-2.16.2, dcm4chee-2.17.0, dcm4chee-2.17.1, dcm4chee-2.17.2, dcm4chee-2.17.3, dcm4chee-2.18.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Simon Schlosser Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Calculation of deletion candidates does not take into account jobs in deleter queue and might lead to exceeding DeleterThresholds.

This occurs in case of
i)low_ScheduleStudiesForDeletionInterval_
ii)high DeleterThresholds
iii)high amount of deletion candidates

Also to be taken into account is, to avoid duplicated deletion jobs due to not respecting deleter queue content.






[DCMEE-1221] Study permissions are kept in DB even after a study is deleted from the system Created: 25/Jun/09  Updated: 25/Jun/09

Status: Open
Project: dcm4chee
Component/s: DB
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: David Davies Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Deleting a study with permissions enabled does not remove the corresponding permissions from the study_permission table.



 Comments   
Comment by Gunter Zeilinger [ 25/Jun/09 ]

There are use cases where it make sense to keep Study Permissions of deleted studies; e.g. to avoid to break access to undeleted or re-received studies.





[DCMEE-252] Allow Move requests to specified AE destination without overwrite of DB content Created: 06/Feb/07  Updated: 06/Feb/07

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: scott shannon Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A feature to allow Move requests to a specificed AE destination that would not overwrite instance content from the DB.

Currently, when an instance is received the instance dataset attributes are saved in the INSTANCE ATTR column of the DB. However, if the same image is received again... the DB forces coercion of some fields (for example: Rescale Intercept) and thus the second received instance gets the same attributes.

I ran in to this when a modality was sending images twice- the first time the instance was send with wrong rescale value, the second time it was correct, but the rescale was coerced to the first received instance value.

It would be nice to somehow send these instances to a particular destination where the coercion would not happen (no overwite).






[DCMEE-1666] Make possible to delete Teaching File Structure report on export Created: 04/Mar/11  Updated: 04/Mar/11

Status: Open
Project: dcm4chee
Component/s: TCE
Affects Version/s: Wishlist
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Samuel Imriska Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the archive as teaching file exporter to a remote location, it is not necessary to preserve structure report in the archive.

Make possible to delete it after export.






[DCMEE-840] Set LD_LIBRARY_PATH in dcm4chee_init_debian.sh Created: 23/May/08  Updated: 23/May/08

Status: Open
Project: dcm4chee
Component/s: Scripts
Affects Version/s: dcm4chee-2.13.2, dcm4chee-2.13.3, dcm4chee-2.13.4, dcm4chee-2.13.5
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Phil Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian Linux



 Description   

LD_LIBRARY_PATH is not being set to include ../bin/native in dcm4chee_init_debian.sh.
RID and WADO services not starting.
See http://forums.dcm4che.org/jiveforums/thread.jspa?threadID=448



 Comments   
Comment by Gunter Zeilinger [ 23/May/08 ]

Perhaps better to drop (outdated) dcm4chee_init_debian.sh from dcm4chee archive distributions, because dcm4chee_init_redhat.sh - itself based on jboss_init_redhat.sh included in JBoss 4.2.2.GA - also works on Debian/Ubuntu.





[DCMEE-1056] C-FIND RSP always contains Other Patient ID Sequence if PIX Query is configured Created: 16/Dec/08  Updated: 16/Dec/08

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: dcm4chee-2.10.15, dcm4chee-2.11.0, dcm4chee-2.12.0, dcm4chee-2.13.0, dcm4chee-2.13.1, dcm4chee-2.13.2, dcm4chee-2.13.3, dcm4chee-2.13.4, dcm4chee-2.13.5, dcm4chee-2.13.6, dcm4chee-2.14.0, dcm4chee-2.14.1, dcm4chee-2.14.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Gunter Zeilinger Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

C-FIND RSP contains Other Patient ID Sequence if PIX Query is configured, also if the original C-FIND RQ did not contain a return key for it.
As a consequence, the client may include the Other Patient ID Sequence in created Evidence Documents (e.g. Secondary Capture images) stored to the archive, which causes the archive to append specified Other Patient IDs to the Patient Record associated with the Study, to which the Evidence Document is stored (s. DCMEE-158). Such internal stored linkage of Patient IDs may become out-of-sync with the Patient ID linkage managed by the external PIX manager.






[DCMEE-1847] CLONE -Wrong data type used for sps_status column definition in create.mssql - still true in 2.17.2 Created: 21/Jun/12  Updated: 21/Jun/12

Status: Open
Project: dcm4chee
Component/s: DB
Affects Version/s: dcm4chee-2.17.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Chris Molodo Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Microsoft SQL Server


Issue Links:
Cloners
clones DCMEE-1064 Wrong data type used for sps_status c... Closed

 Description   

The following issue is still true as of 2.17.2 - if it was fixed, that fix was rolled back.

In table mwl_item, the following:

sps_status      NUMERIC(19,0),

should be:

sps_status      INTEGER,

The current (incorrect) mapping causes errors with the dcm4chee-arc3-entities JPA mapping upon startup when the following mapping validation mechanism is turned on in persistence.xml:

<property name="hibernate.hbm2ddl.auto" value="validate"/>





[DCMEE-1848] fetchModifiedAttributes() in AttrUtils.java should not skip attributes that are empty Created: 22/Jun/12  Updated: 22/Jun/12

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: dcm4chee-2.17.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Kinson Ho Assignee: Kinson Ho
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

If an attribute is modified from some value to null, the fetchModifiedAttributes() method will skip it and not track it in the modifiedAttrs dataset.






[DCMEE-629] Decompression of JPEG Loss Less compressed Fuji CR fails Created: 09/Nov/07  Updated: 21/Nov/07

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.12.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Marco Beltrame Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File fuji_comp.dcm    

 Description   

I have a test image file, that was saved on dcm4chee. The original is a compressed image from a real modality, the stored one is the same without modifications.
When I retrieve it from a client that does not support compression, the decompressed image that I receive is completely white. The suspect is that this matter occur with that kind of image when decompressed by dcm4chee algorithm.

  • the "trouble" image results blank also when you view it via wado from the web interface of DCM4CHEE
  • the normal compressed workflow (letting OSIRIX or efilm decompress the image) works good.

Thanks

Marco Beltrame



 Comments   
Comment by Gunter Zeilinger [ 18/Nov/07 ]

Opened corresponding issue in jai-imageio Issue Tracker: https://jai-imageio-core.dev.java.net/issues/show_bug.cgi?id=164

Comment by Gunter Zeilinger [ 21/Nov/07 ]

------- Additional comments from jxc@dev.java.net Tue Nov 20 21:09:31 +0000 2007 -------
OK, I can reproduce the problem with the new jpeg-lossless.jpg.
This issue appear to be a duplicate of issue 158, as a temporary
fix for issue 158 can decode this image successfully as well.
The problem was that the clib JPEG decoder failed to honor the
RST markers in the case of lossless.





[DCMEE-1722] Make IHE MIMA option optional Created: 19/Jul/11  Updated: 13/Dec/11

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.16.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alexander Karaivanov Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

The IHE MIMA option implemented in 2.16.0 (as DCMEE-1551) has semantics incompatible with previous versions. The spec is currently released for trial implementation.

That is why it would be nice if all that behaviour can be completely switched off (by configuration).

I've set initial priority as critical because this is a regression of how patient matching works and IMHO it is sensitive piece of semantics.






[DCMEE-1446] WADO Prefetch Service blocks SeriesStored Notification handling for several minutes Created: 28/Jul/10  Updated: 28/Jul/10

Status: Open
Project: dcm4chee
Component/s: JMX
Affects Version/s: dcm4chee-2.14.8
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Franz Willer Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This occurs unpredictable from time to time on one system.






[DCMEE-1686] Add upgrade-mr.xml example file Created: 08/Apr/11  Updated: 20/Aug/12

Status: Open
Project: dcm4chee
Component/s: Configuration
Affects Version/s: dcm4chee-2.16.2
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Damien Evans Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Add an example configuration file for generating pseudo enhanced multi-frame MRs from legacy single-frame MRs.



 Comments   
Comment by Paolo Marcheschi [ 08/Jul/11 ]

In version 2.17.0 the upgrade-mr.xml, is only a dump of an MR file.
Do you forgot to put the right file ?

Paolo

Comment by Paolo Marcheschi [ 20/Aug/12 ]

Hi
Any news with this issue ?

I'm still looking for the upgrade-mr.xml file.

Ciao

Paolo





[DCMEE-1130] Retrieving images hangs w/o error Created: 03/Apr/09  Updated: 30/Sep/10

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alexander Karaivanov Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

dcm4chee-2.14, db2 9.5, jdk1.6.0_05


Attachments: GZip Archive jboss.console.sav.gz     GZip Archive server.log.sav.gz    

 Description   

The client application makes some C-Finds first. Then it opens number of C-Move associations and uses the common destination AET.
In some cases everything works find. In other cases the fetching hangs midways. There are no errors in the log file. Archive
only sends C-Move-RSP but no more images are sent.

1 study with 10 series is fetched, 220 images in total.

It looks like a dead lock problem - but that is just a guess.

I have a very detailed log file + jvm stack trace



 Comments   
Comment by Alexander Karaivanov [ 03/Apr/09 ]

stack trace





[DCMEE-1521] C-Find with specified date provides not expected study Created: 03/Nov/10  Updated: 03/Nov/10

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Simon Schlosser Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Study with study date 2010/10/31 23:10:30 (switch of daylight saving time and standard time) is not shown in querylist when C-Find-querying with specific study date (2010/10/31).






[DCMEE-1704] AE Title validation is required in updateAETitle() method Created: 30/May/11  Updated: 13/Dec/11

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Prakash Jayaraman Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

AE Title validation is required in updateAETitle() method. The store SCP service AE changed to some text with "\" character present could not be restored. The dcm4chee archive becomes inaccessible, due to this.






[DCMEE-1294] Non serializable XAResource warnings never stop Created: 28/Sep/09  Updated: 28/Sep/09

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alexander Karaivanov Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Warnings like the one below seem to be kept forever.

2009-09-28 09:53:21,305 WARN -> (Thread-5) [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.inte
rnal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 30, 28, 1-a262015:a186:4ab0b45e:94
26e0a262015:a186:4ab0b45e:9426e1^@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@^@
@@ >

See also this discussion here: http://forums.dcm4che.org/jiveforums/thread.jspa?messageID=6642&#6642
Using old transaction manager is probably not a solution in long term if that manager is deprecated?






[DCMEE-930] Change the visibility of a method sendJMXNotification in org.dcm4chex.archive.mbean.ContentEditService Created: 20/Aug/08  Updated: 20/Aug/08

Status: Open
Project: dcm4chee
Component/s: API
Affects Version/s: dcm4chee-2.13.6
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Ge Yu Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Change the visibility of a method sendJMXNotification in org.dcm4chex.archive.mbean.ContentEditService class






[DCMEE-1792] Patient Information not in sync with EMR Database Created: 30/Jan/12  Updated: 18/Mar/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.15.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: David Lawson Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.04 Lucid LTS, mysql Ver 14.14 Distrib 5.1.41, OSCAR v9.12 (EMR) using Clear Canvas (PACS)


Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

dcm4che doesn't seem to update patient information (name, date of birth, etc) every time a new worklist entry is received. It seems to re-use the patient information that was received when the the first worklist entry for the patient was created. This presents a problem if the information has changed - e.g. if the date of birth was entered wrong the first time, if the patient changes their name, etc.






[DCMEE-1824] Optimization: do not schedule new move order if one is already pending in queue Created: 19/Mar/12  Updated: 18/Mar/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Alexander Karaivanov Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

This optimization might be nice to safe some unnecessary work.






[DCMEE-1881] Image received in dcm4chee causes 100% CPU usage when an attempt is made to view or retrieve it via wado Created: 18/Sep/12  Updated: 18/Sep/12

Status: Open
Project: dcm4chee
Component/s: WADO
Affects Version/s: dcm4chee-2.17.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Jordan K Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

dcm4chee 2.17.1, pgsql, CentOS 6.3


Attachments: File wado100cpu.dcm    
Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

I received an image which was successfully received and stored in dcm4chee, as well as forwarded onto a different dcm4chee instance.

However, when I try to view the image through the dcm4chee-web3 interface, or retrieve it via wado - it causes 100% CPU usage on the system. I believe it is because the wado requests hang, and lock up in some endless loop. This is visible in the jmx-console -> Tomcat Status, where one can see the increasing number of wado requests for that image (one each time a view or retrieve attempt is made). The CPU is fully used by the dcm4chee java process, until the system becomes unusable.

The only solution is to stop and start the dcm4chee process, and to delete the image off the system.

The image imports successfully into OsiriX, but the pixel data looks to be somewhat corrupt in some way. Even if the image is corrupt (which I do believe it is), it seems that no image should be able to bring down the whole PACS, but maybe some check needs to be put in the wado service which would handle this condition, or limit the amount of resources/time that a wado service thread can run when serving up a dicom object?...



 Comments   
Comment by Jordan K [ 18/Sep/12 ]

This image is received fine into dcm4chee, but causes 100% cpu usage when retrieved via the wado service.





[DCMEE-1767] Private attributes in NM Images duplicated, and in wrong order Created: 17/Nov/11  Updated: 09/Dec/11

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.16.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: gerhard h Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

dcm4chee-2.16.2-mysql running with DefaultSettings on 32-Bit Debian, mysql 5.1.41, Compression: NONE,
dcm4che-2.0.25 toolkit for testing


Attachments: Text File dump.nm_anon_chee.txt     Text File dump.nm_anon.txt     Text File nm_anon_chee-2.17.txt     File nm_anon_chee.dcm     File nm_anon.dcm    
Issue Links:
Related
is related to DCMOLD-220 DcmObjectImpl.putAll method can incor... Resolved

 Description   

Image sent to dcm4chee, then sent with dcm4chee-web to dcmrcv.

dcmrcv is accepting the image,
other dicom-receivers (MergeToolkit) abort with:
Tags not in ascending order: (7fe0,0010) found after (7fe3,1016)

Original Image has following Private attributes: (dcm2txt)

...
528328:(0043,0010) LO #14 [SIEMENS MED NM] Private Creator Data Element
528350:(0043,1003) UN #1440 [\02\F1\E3\BE5\00\E4\BEi\0F\E4\BE\9C\1E\E4\BEX\EA\
529798:(0043,1004) UN #1440 [M*\00\BFM2\00\BFM:\00\BFMB\00\BF\1A%\00\BF\E7\07\
...
532584:(7FE0,0010) OW #262144 [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
794736:(7FE3,0010) LO #14 [SIEMENS MED NM] Private Creator Data Element
794758:(7FE3,1014) UN #8 [\00\00\00\00\00\00\00\00] ?
794774:(7FE3,1015) UN #8 [\00\00H\00\00\001\00] ?
794790:(7FE3,1016) UN #8 [\02\00\EC\83\02\00\8Fr] ?

Same Image, received and sent from dcm4chee looks like this:

...
528444:(0043,0000) UL #4 [5868] Group Length
528456:(0043,0010) LO #14 [SIEMENS MED NM] Private Creator Data Element
528478:(0043,0011) LO #16 [dcm4che/archive] Private Creator Data Element
528502:(0043,1003) UN #1440 [\02\F1\E3\BE5\00\E4\BEi\0F\E4\BE\9C\1E\E4\BEX\EA\
529950:(0043,1004) UN #1440 [M*\00\BFM2\00\BFM:\00\BFMB\00\BF\1A%\00\BF\E7\07\
531398:(0043,1103) UN #1440 [\02\F1\E3\BE5\00\E4\BEi\0F\E4\BE\9C\1E\E4\BEX\EA\
532846:(0043,1104) UN #1440 [M*\00\BFM2\00\BFM:\00\BFMB\00\BF\1A%\00\BF\E7\07\
534294:(0043,1114) UN #6 [DUMMY ] ?
534308:(0043,1115) UN #8 [LISEEXP ] ?
...
535758:(7FE3,0000) UL #4 [70] Group Length
535770:(7FE3,0010) LO #14 [SIEMENS MED NM] Private Creator Data Element
535792:(7FE3,1014) UN #8 [\00\00\00\00\00\00\00\00] ?
535808:(7FE3,1015) UN #8 [\00\00H\00\00\001\00] ?
535824:(7FE3,1016) UN #8 [\02\00\EC\83\02\00\8Fr] ?
535840:(7FE0,0010) OW #262144 [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
797992:(7FE3,0000) UL #4 [92] Group Length
798004:(7FE3,0010) LO #14 [SIEMENS MED NM] Private Creator Data Element
798026:(7FE3,1010) UN #14 [SIEMENS MED NM] ?
798048:(7FE3,1014) UN #8 [\00\00\00\00\00\00\00\00] ?
798064:(7FE3,1015) UN #8 [\00\00H\00\00\001\00] ?
798080:(7FE3,1016) UN #8 [\02\00\EC\83\02\00\8Fr] ?


 Comments   
Comment by gerhard h [ 17/Nov/11 ]

dump.nm_anon.txt dcm2txt Dump of orig Image
dump.nm_anon_chee.txt dcm2txt Dump of dcm4chee exported Image

Comment by gerhard h [ 17/Nov/11 ]

nm_anon.dcm Original image
nm_anon_chee.dcm dcm4chee exported Image

Comment by Gunter Zeilinger [ 22/Nov/11 ]

I could not reproduce the issue with current dcm4chee trunk, even without using fixed DCMOLD-220 dcm4che.jar. (see attached Dump of dcm4chee exported Image: nm_anon_chee-2.17.txt )

Comment by gerhard h [ 25/Nov/11 ]

Gunter you are right - with 2.17 the Image is exported correct.
( but only if the original image was also received with 2.17. )

Comment by Sabine Kolics [ 09/Dec/11 ]

can not be reproduced wether with 2.16 nor with 2.17





[DCMEE-826] Compression service may fail on images that don't have hex based filenames - images stored using private transfter syntax specifying Retrieve URI instead of pixel data Created: 30/Apr/08  Updated: 30/Apr/08

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.13.3
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Justin Falk Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, PostgreSQL, dcm4chee 2.13.3



 Description   

Images were migrated to dcm4chee using dcmsnd and specifying the -fileref argument to send using private transfer syntax (1.2.40.0.13.1.1.2.4.94) to only send file references rather than pixel data. The migration worked splendidly. Once complete, I marked the migrated filesystem to RW so that JLSL compression would be applied via the compression service. An error occurred because the compression service assumes the filename is in the same format as natively generated by dcm4chee (ex. 70C6B59E) where as the migrated filenames were based on sop iuid with a dcm extension (ex. 1.2.3.dcm).

2008-04-30 10:06:51,674 ERROR -> (Timer-2) [CompressionService] Can't compress file:F:\ImportedImages\HospitalA\1.2.840.111111111111111111\1.2.840.2222222222222222222\1.2.840.33333333333333333333.dcm
java.lang.NumberFormatException: For input string: "1.2.840.33333333333333333333.dcm"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
	at java.lang.Long.parseLong(Long.java:412)
	at org.dcm4chex.archive.mbean.CompressionService.doCompress(CompressionService.java:355)
	at org.dcm4chex.archive.mbean.CompressionService.checkForFilesToCompress(CompressionService.java:290)
	at org.dcm4chex.archive.mbean.CompressionService$1.handleNotification(CompressionService.java:128)
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
	at $Proxy11.handleNotification(Unknown Source)
	at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:257)
	at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:322)
	at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:307)
	at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:229)
	at javax.management.timer.Timer.sendNotification(Timer.java:1234)
	at javax.management.timer.Timer.notifyAlarmClock(Timer.java:1203)
	at javax.management.timer.TimerAlarmClock.run(Timer.java:1286)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)

The problem is the following code that attempts to generate a new filename:

destFile = FileUtils.createNewFile(srcFile.getParentFile(), (int) Long.parseLong(srcFile.getName(), 16)+1);

Could a more generic method of generating a filename be used? Or perhaps could there be a configuration that would just append some suffix to the original filename?






[DCMEE-2064] Add logging to filesystem storage deletion routines Created: 09/Aug/14  Updated: 09/Aug/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-dc
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Kevin Eagles Assignee: Kevin Eagles
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DCMEE-2067] GPI removal does not allow OrigAttrs, which prevents downstream EPR notification Created: 15/Aug/14  Updated: 15/Aug/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Christopher Archer Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Clearing GPI does not create an original attribute sequence for the affected patient, which results in EPR Notification dropping the associated study update notifications






[DCMEE-1278] Ability to listen on more than one dicom port Created: 16/Sep/09  Updated: 28/Sep/12

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.14.2
Fix Version/s: None

Type: New Feature Priority: Trivial
Reporter: Alexander Karaivanov Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I believe current version can listen to only one dicom port. I had an use case where DcmServer was needed to listen on more than one port. In this case dcm4chee should replace another pacs that had such ability and the surrounding dicom workstations/modalities were configured to use both.



 Comments   
Comment by Gunter Zeilinger [ 16/Sep/09 ]

Will not be provided before update of the DICOM library used by dcm4chee from dcm4che-1.4.x to dcm4che-2.x.

In the meantime you may deploy multiple DcmServer Service instances associated with their own Storage and QueryRetrieve SCP services (s.a. http://www.dcm4che.org/confluence/display/ee2/Deploying+multiple+archive+instances )

Comment by Alexander Karaivanov [ 16/Sep/09 ]

Thank you. I though about it today but discarded the idea immediately because it sounded I bit dangerous to me . Also I really needed same storage and q/r scp.

What I did instead was just solution at network level adding a rule to iptables to do NAT so when one (remote) client connects to 104 it will be mapped to port 11112 instead:

iptables -t nat -F
iptables -t nat -X
iptables -t nat -A PREROUTING -p tcp -d a.b.c.d --dport 104 -j DNAT --to a.b.c.d:11112

I just thought this might be useful feature and that is why this feature request.

Comment by Jordan K [ 26/Sep/12 ]

Just a note, the iptables statements that worked for me, and don't require specifying IP addresses:

iptables -t nat -A PREROUTING -p tcp --dport 104 -j REDIRECT --to-ports 11112 (handles traffic from other systems)
iptables -t nat -A OUTPUT -p tcp ! -o eth0+ -m tcp --dport 104 -j REDIRECT --to-ports 11112 (handles traffic from the system itself, if you want to be able to use the loopback)





[DCMEE-1640] install_jboss tries to copy JBOSS_HOME/server/default/deploy/management/console-mgr.sar/web-console.war/*.xml Created: 17/Feb/11  Updated: 17/Feb/11

Status: Open
Project: dcm4chee
Component/s: Scripts
Affects Version/s: dcm4chee-2.14.0, dcm4chee-2.14.1, dcm4chee-2.14.2, dcm4chee-2.14.3, dcm4chee-2.14.4, dcm4chee-2.14.5, dcm4chee-2.14.6, dcm4chee-2.14.7, dcm4chee-2.14.8, dcm4chee-2.15.0, dcm4chee-2.16.0, dcm4chee-2.16.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Gunter Zeilinger Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DCMEE-954 Upgrade to JBoss 4.2.3.GA Closed

 Description   

install_jboss.sh(.bat) tries to copy JBOSS_HOME/server/default/deploy/management/console-mgr.sar/web-console.war/*.xml, but JBoss 4.2.3 does not include such files, which results in the output of a warning message like

cp: cannot stat `/home/gunter/jboss-4.2.3.GA/server/default/deploy/management/console-mgr.sar/web-console.war/*.xml': No such file or directory

.






[DCMEE-1844] IHEDocumentList.xsl not accesible in dcm4chee-web3 Created: 05/Jun/12  Updated: 05/Jun/12

Status: Open
Project: dcm4chee
Component/s: Web
Affects Version/s: dcm4chee-2.17.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Jacques Fauquex Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

IHEDocumentList.xsl used to be found into dcm4chee-rid.war. Since dcm4chee-web3 became the default GUI, IHEDocumentList.xsl was moved to server/default/conf/dcm4chee-rid/
But unfortunately, there is no way to indicate this path while configuring service=dcm4chee-rid. This is due to the fact that the path one can write there is automatically prefixed by http://host:port/rid/

Workaround: copy back IHEDocumentList.xsl and common.xsl into dcm4chee-rid.war, in a sub folder called xsl, so that the path correspond to the default relative path, which wasn't ever modified (xsl/IHEDocumentList.xsl)






[DCMEE-2016] Allow creation of UPS from MPPS only Created: 04/Nov/13  Updated: 12/Nov/13

Status: Open
Project: dcm4chee
Component/s: Configuration, Documentation, IAN, UPS
Affects Version/s: dcm4chee-2.17.3
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: Michael Volke Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

Currently, UPS can be created from MPPS by the UPSFeed service. However the UPS are only created if the series announced in the "Performed Series" Sequence of the MPPS are actually stored in the local DCM4CHEE database. This restriction prevents UPS support in distributed environments where DCM4CHEE is used as an extension to a RIS supporting MWL, MPPS and UPS, but where the actual storage of series is dedicated to a foreign PACS.

Technical background:
Internally, IANs and the IANScu service are used to transport MPPS from the MPPSScp service to the UPSFeed Service. The problem arises in MPPSManagerBean.createIANwithPatSummaryAndStudyID() in the context of the IANScu service where the creation of the required IAN is suppressed when any of the series in the MPPS "Performed Series" sequence has another status than "SERIES_STORED".

Proposal for resolvement:
In the IANScu service manager bean, create an additional parameter "MPPSWaitForPerformedSeries", which in case of setting to "false" distributes MPPS (and only MPPS) internally and externally immediately.
Programming resources can be supplied if the issue is accepted.



 Comments   
Comment by Michael Volke [ 04/Nov/13 ]

Proposal for resovement (continued):
Position: underneath SendOneIANforEachMPPS
Access: RW
Value: True/False
Description: When receiving an MPPS, wait for all series in it's "Performed Series" sequence to gain "SERIES_STORED" status in local storage before sending IAN. When set to "False", send IAN immediately, containing only the respective MPPS instance and the series which have gained "SERIES_STORED" status so far. Ignored if SendOneIANforEachMPPS="False". Set to "False" for creation of UPS in environments where series are not locally stored.





[DCMEE-246] Support in archive for DICOM supplement 99 Created: 22/Jan/07  Updated: 25/Jan/07

Status: Open
Project: dcm4chee
Component/s: DICOM
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Enhancement
Reporter: Morten Sylvest Olsen Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on DCMOLD-20 Support User Identity Negotiation Resolved

 Description   

dcm4che toolkit seem to have support for DICOM supplement 99, but it is currently unused in dcm4chee. Would be nice to have full support (including Kerberos) for access control and auditing purposes.






[DCMEE-366] calling aet field in jmx console supports negation Created: 24/Apr/07  Updated: 24/Apr/07

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Enhancement
Reporter: Petr Kalina Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

it would be great if it was somehow possible to block specified aetitles
from certain service - other than specifying all aets that can access it in the jmx console.

the situation when this could be benefitial is for example when testing
a new communication channel for effectively temporarily disabling the
old one. often the configuration of server nodes requires support staff
and is complicated - in this way the old strategy could be easily
switched off/back on demand.. when running in private network setting
explicitly all possibly communicating aets is not necessary and is
tiresome..






[DCMEE-886] Add retry policy to media export. Created: 03/Jul/08  Updated: 03/Jul/08

Status: Open
Project: dcm4chee
Component/s: TCE
Affects Version/s: dcm4chee-2.11.0, dcm4chee-2.12.0, dcm4chee-2.13.0, dcm4chee-2.13.1, dcm4chee-2.13.2, dcm4chee-2.13.3, dcm4chee-2.13.4, dcm4chee-2.13.5, dcm4chee-2.13.6
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: Franz Willer Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

At the moment there is no retry when a media creation request fails!
Wortkaround: (manually) redo media export via Teaching File Export of dcm4chee-web.






[DCMEE-1778] Allow customization of Other PID matching algorithm Created: 09/Jan/12  Updated: 09/Jan/12

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.17.1
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: Christopher Archer Assignee: Christopher Archer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

The method used by QueryCmd to find a match in the OtherPIDSeq fails if any of the entries in that sequence is considered invalid, which is inadequate for some use cases.






[DCMEE-1774] support flexibilityon on sql query modification Created: 12/Dec/11  Updated: 12/Dec/11

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: dennis Liang Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all platform



 Description   

in order to make sql query modification easy later on, add a new factory method (createSqlBuild) in BaseDSQueryCmd.java and make SqlBuilder class public.
any child class of BaseDSQueryCmd class can override this factory method and make query modification easy.






[DCMEE-1811] remove final in setPerfMonServiceName method from QueryRetrieveScpServer class Created: 02/Mar/12  Updated: 02/Mar/12

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: dennis Liang Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

in order to provide flexibility for inheritance, remove final in setPerfMonServiceName method from QueryRetrieveScpServer class






[DCMEE-407] WADO contentType video or MPEG from multi frame images Created: 11/Jun/07  Updated: 17/Jun/07

Status: Open
Project: dcm4chee
Component/s: WADO
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: Brian Reed Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File ref_retrieveMovieInstance.java    

 Description   

Enhance WADO service to generate JPEG files for multi frame objects when MPEG has been requested. Stub out a method call to convert the JPEG files into MPEG. The community is looking at contributing a way to convert the JPEGs into an MPEG.

Other movie formats from JPEGs is also being looked into by the community for WADO enhancement.



 Comments   
Comment by Brian Reed [ 17/Jun/07 ]

Quicktime movie creation via WADO loop call for jpeg. The relics of direct bufferedImage to movie are in there, however the memory usage is too extreme. raFile is the best way. Personally Im a bit reserved about putting this into the dcm4chee code. The disk usage is high, and it can be as easy from a separate web server, which we are doing. I dont see putting such an IO intensive program into an already IO intensive unit when it can be easily outsourced to other hardware. To run in linux need headless startup properties for web server -Dawt.toolkit=sun.awt.HeadlessToolkit.





[DCMEE-421] Wado content length header set Created: 17/Jun/07  Updated: 03/Jul/07

Status: Open
Project: dcm4chee
Component/s: WADO
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: Brian Reed Assignee: Gunter Zeilinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the content length header is not set with retrieval of application/dicom object via WADO. It'd be nice if it was set, for like download timers and expected download times. =D.



 Comments   
Comment by Brian Reed [ 03/Jul/07 ]

The file length stored into pacsdb (files,file_size) is not accurate for requests made for these images in application/dicom WADO - because of the changed information by DCM4CHEE (ie administrator changes the Referring Physician or Patient Name) is written upon the request of WADO, and is not calculated in the file_size of the db or the actual physical file size in the archive. Unless stream length can be accurately determined, I don't see how this fix is possible.





[DCMEE-2062] addAE() and updateAE() in AE service restrict AETs to length of 16 Created: 30/Jul/14  Updated: 30/Jul/14

Status: Open
Project: dcm4chee
Component/s: None
Affects Version/s: dcm4chee-2.17.3, dcm4chee-2.18.0
Fix Version/s: None

Type: Improvement Priority: Enhancement
Reporter: Leandros Athanasiadis Assignee: Franz Willer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tracking Status:
Test Spec - ToReview, Risk Analysis - Todo, Test State - Not tested

 Description   

As there may be need to add AETs longer than 16 chars for MLLP destinations, this restriction should be lifted






Generated at Tue Sep 02 01:23:47 CEST 2014 using JIRA 5.1.5#784-sha1:6c729937863f5b4cf7f0dd89a7db4e505415af41.