Posts by qcor

  • printer_files folder

    Hi,


    I just realized that my printer_files is full of files... I mean hundreds of thousands of files, all .jpg
    From what I understand this folder is used as a tmp for compression process, am I right?
    So it looks like those jpgs are not deleted after compression.. maybe... no idea. I use j2 as a compression method.


    Do you know what may be causing this kind of behavior? Unfortunately this node was not updated for a looong time and is still 1.4.17beta3. Is that a known bug in this version? If so, can I safely delete those files? (already upgraded to latest version)

  • Bulk study move between storage devices

    I see.. well, if it is a known problem then it's OK.


    About name changes - I didn't have a choice. Basically I was forced to create a view of this table because of some bad design of 3rd party software which was killing PG with poorly optimized query of this table.


    So the bottom line is that "dgate -v --amMAG0.Archiving,MAG1" will just NOT work with changed table name, am I right? Any workaround maybe?

  • Windows GUI taking very long to open

    Nope, I use PG and like I said - it does NOT look like a database problem. I'm constantly logging all queries which take longer than 500ms to execute and I don't see any from conquest.


    It is probably the fault of windows not being able to handle so much directories/files in my MAG0 directory. There are about 100.000 dirs with 35.000.000 files in them.
    When you open the GUI, you are listing all of those directories and probably this is the problem.

  • Windows GUI taking very long to open

    As in the topic - when I try to open ConquestDICOMServer.exe it takes a looong time to show up. I mean like 10minutes.
    The tray icon shows up instantly but the main GUI takes forever.


    I checked the database logs, nothing special there, so it doesn't look like a database problem (as in long query etc).


    I suspect that the cause lies in the number of catalogs that are in the main data folder. GUI lists them in one of the tabs.
    I have about 100.000 catalogs there and it normaly takes about the same amout of time to just enter this catalog using windows explorer/totalcommande etc


    Sooo.. if that is the case, any workaround to speed up GUI loading time?

  • Bulk study move between storage devices

    Thank you for help.


    As I was trying this I ran into a small problem, maybe even potential bug.


    Command that you gave me produces this querry:


    As you can see the name of the table is correct in the first instance because of my dicom.ini entry:

    Quote


    # Names of the database tables
    PatientTableName = DICOMPatients
    StudyTableName = DICOMStudies_view


    However the second and third are not. No idea where it came from.. (hardcoded?)


    [edit]
    Also, as a side note or just a warning to anyone who would want to do that - check if you have an index on 'devicename' in dicomimages table or you will kill your database with this query :) Otherwise it will do a sequential scan of whole table.. 35.000.000 rows (13Gb) in my case sooo. yea.. that's bad :)
    [/edit]

  • Bulk study move between storage devices

    Hello,


    I have a problem and I'm not sure what is the best way to aproach it.
    What I have now is all studies are on 1 device: MAG0
    What I'd like to do is to create 2nd device: MAG1 (that part is easy) and move certain studies there then remove them from MAG0.


    Moving all that in one go would probably kill my network and/or server so I'd like to split the process.
    Someone told me that there is a way to FLAG an image/study in the database - something like adding ".Archival" to device name? he wasn't sure and I can't find it anywhere in the manual.
    That would be easy enough and would also allow me to split the process.


    So the question is: is this true? Can I just flag them in postgress? If so then I assume that after that I'd have to invoke some command to force archivization process?


    Bonus question: I guess it is possible to automate this process after that initial move. Any hints?

  • strange things with j2 compression

    Hi


    I tried to launch "dgate --debuglevel:4" from command line but it closes almost immediately (1-2sec) with no error.
    Then I tried to launch it as a service using:

    Quote

    sc create debugtest binPath= "c:/test/DgateServ.exe /process dgate.exe --debuglevel:4"


    but it also almost immediately stopped working. In system log I see it stopped with error:

    Quote

    The debugtest service terminated with the following error:
    Access is denied.


    I honestly have no idea what it is about.. access TO WHAT? All file permissions looks fine.


    Isn't it the same as setting DebugLevel to "4" in dicom.ini ? (which also didn't work :( )

  • strange things with j2 compression

    Sorry for delay.. beginning of new year means a TON of work for me :(


    I'm not sure if that's what you want but I set DebugLevel to "4" in dicom.ini and then tried to retrieve images from Conquest using Efilm. Here is what I got in .log


    "Host 'efilm' will not accept image" - this was probably some "SR" and thats why efilm rejected it.

  • strange things with j2 compression

    oh, I just forgot to change it back. My initial tests were conducted with this option UNcommented.
    Then I thought I might try to comment it out in an attempt to force different type of syntax but it didn't work... result was the same in both cases.


    So far it looks like no matter what settings are set and no matter who is the recipient (conquest->conquest or conquest->efilm) the resulting images are always 1.2.840.10008.1.2


    It there a chance it's a bug or am I doing sth wrong here..? :(

  • strange things with j2 compression

    Sure thing. All 3 files included:
    (sorry I didnt upload them as attachments but forum gives me this error: "Could not upload attachment to ./files/51731_7b574bf1bd2fe3e21ab7202ce77a10b3.")

    Code
    PACZK			127.0.0.1	2020	j2efilm4			192.1.1.52	104	    j2efilm2			192.1.1.54	4006	j2


    Code
    # This file contains configuration information for the DICOM server# Do not edit unless you know what you are doing[sscscp]MicroPACS                = sscscpEdition                  = Personal# Network configuration: server name and TCP/IP port#MyACRNema                = PACZKTCPPort                  = 2020# Reference to other files: known dicom servers; database layout; sopsACRNemaMap               = acrnema.mapkFactorFile              = dicom.sqlSOPClassList             = dgatesop.lst# Host(ignored), name, username and password for ODBC data sourceSQLHost                  = localhostSQLServer                =mpacs1Username                 =mpacs1Password                 =mpacs1Postgres                 = 1BrowseThroughDBF         = 1DoubleBackSlashToDB      =1UseEscapeStringConstants = 1# Configure databaseTruncateFieldNames       = 10MaxFieldLength           = 254MaxFileNameLength        = 255FixPhilips               = 0FixKodak                 = 0KeepAlive                = 0LargeFileSizeKB          = 4096PrintSquareLandscape     = 0UseKpacsDecompression    = 1ZipTime                  = 05:UIDPrefix                =1.2.826.0.1.3680043.2.1326.9EnableReadAheadThread    = 1PatientQuerySortOrder    = StudyQuerySortOrder      = SeriesQuerySortOrder     = ImageQuerySortOrder      = EnableComputedFields     = 1IndexDBF                 = 1PackDBF                  = 0LongQueryDBF             = 1000TCPIPTimeOut             = 300FailHoldOff              = 60RetryDelay               = 100RetryForwardFailed       = 0ImportExportDragAndDrop  = 1QueueSize                = 128WorkListMode             = 0WorkListReturnsISO_IR_100 = 1DebugLevel               = 0Prefetcher               = 0LRUSort                  = AllowTruncate            = DecompressNon16BitsJpeg  = 1UseBuiltInJPEG           = 1LossyQuality             = 95IgnoreOutOfMemoryErrors  = 0NoDICOMCheck             = 0PadAEWithZeros           = 0FileNameSyntax           =4# Configuration of compression for incoming images and archivalDroppedFileCompression   = j2IncomingCompression      = j2ArchiveCompression       = j2# Names of the database tablesPatientTableName         = DICOMPatientsStudyTableName           = DICOMStudiesSeriesTableName          = DICOMSeriesImageTableName           = DICOMImagesDMarkTableName           = DICOMAccessUpdatesRegisteredMOPDeviceTable = RegisteredMOPIDsUIDToMOPIDTable          = UIDToMOPIDUIDToCDRIDTable          = UIDToCDRID# Banner and host for debug informationPACSName                 =ARPACS1OperatorConsole          = 127.0.0.1# Configure email of error messagesMailHost                 = MailPort                 = smtpMailSignon               = MailFromName             = MailRcptName1            = MailCollectTime          = 1MailWaitTime             = 10# Configuration of disk(s) to store imagesMAGDeviceThreshhold      = 0MAGDeviceFullThreshHold  = 30IgnoreMAGDeviceThreshold = 0MAGDevices               = 1MAGDevice0               = f:\Data\NightlyCleanThreshhold   = 0


  • strange things with j2 compression

    Hi again.


    2 more tests:


    In both tests images used are j2 compressed (but with wrong tag)


    1) ( j2 -> j2)
    sending from server to Efilm using j2 setting in arcnema


    2) (j2 -> j3)
    sending from server to Efilm using j3 setting in arcnema


    In both cases all I got was garbage (black & white dots).
    In both cases tags were set to 1.2.840.10008.1.2
    Also in both cases serverstatus.log shows that accepted compression was "ui"

    Code
    20131212 14:20:53 Accepted compression: ui

    20131212 14:20:53 Sending file : f:\Data\.....


    What that even means? I don't see 'ui' listed as possible types in the manual :(


    --------------


    For issue 1 - I changed UIDPrefixes to be unique for all servers and so far (after 2 days) it looks like the problem disappeared... so thanks again :)

  • strange things with j2 compression

    Hi,


    I'm back with some test results.


    I used one of recent studies, so it was already compressed with j2 (but with wrong tag).


    1) j2 -> un
    I changed .ini to "IncomingCompression = un" and resend it to myself (I mean directly from server to server by loopback interface) using "dgate --movestudy" command
    As a result I got 2 times bigger files, as expected, and the tag remained the same.


    2) un -> j3
    Then after it was decompressed I changed incomingcompression to j3 and sent it again. And again I got about half sized images but the tag remained the same (1.2.840.10008.1.2.1_)

  • strange things with j2 compression

    First of all - THANK YOU.. big time.


    1st issue - it looks like this is the case. If by "tempDir" you mean the system %temp% folder then yes - all 3 share the same one... and the UIDPrefix is indeed the same in all 3.
    I will change UIDPrefix then test it and let you know if that helped.



    2nd issue
    I was testing this on a study which was about 1y old. I compressed it few days ago by resending images with "IncomingCompression = j2" set in dicom.ini. (1.4.17c)


    As for the tags:
    (0002,0010) UI # 20 [1.2.840.10008.1.2.1_]


    In fact ALL images that were compressed have this tag (I guess it should end with .70 instead ?)
    It looks like they are compressed (about 50% of original size) but the tags remains unchanged. Tag is exactly the same before and after compression.

  • strange things with j2 compression

    Hi.


    Few days ago I was forced to introduce compression of images due to dwindling free space on our HDDs.
    So far I ran into 2 issues and after 2 days of debugging attempts I just ran out of ideas and decided to ask smarter people for help... hence this post.
    ____________________
    Lets start with some environment details:


    - 5 diagnostic machines ( 2x MRI, 2x CT, 1x USG), all sending images to 3 dgates (on 3 different ports) on one server.
    - soft version 1.4.17c
    - all incoming images are compressed using j2 ( dicom.ini: "IncomingCompression = j2")
    _____________________


    Issue nr 1:


    MOST of studies an just fine... but sadly few of them are not :( and by "few" I mean 3 out of 100ish.
    In 1st study there are 2 images (different series) which look like there was some problem in the middle of compression.. upper part of image is fine but lower is garbage.
    In 2nd study there are 4 images (same series) of which 2 look like 'compression went wrong' and 2 look like they do not belong to this study.
    In 3rd study there is 1 image that just does not belong there. This study was of a HEAD.. and 1 of images shows CHEST.
    How an image from completely different study landed inside another study is a mystery I just cant solve.


    Those 'alien' images have all tags of the study they landed in (I mean patient name/machine name, date etc.. all).
    Resending the study to the server fixes the issue, so the study itself is OK.
    No log entries indicate any problems. I looked everywhere.. dicom logs, system logs, database logs. Everything looks fine.


    Code
    20131206 09:18:47 Written file: f:\Data\50082507638\1.3.12.2.1107.5.1.4.54058.30000013120907061896800003599_0008_000043_1386577127073c.dcm

    20131206 09:18:47 [recompress]: recompressed with mode = j2 (strip=0)


    And that's it... no errors.


    Please help. I have absolutely no idea how this is happening. I suspect it might be related to the amount of incoming images at the same time... but the amount of devices sending them did NOT change. All I did was turning on the j2 compression.


    ____________________


    Issue nr 2 (unrelated to nr 1, or at least I think so)


    I was experimenting with how the dicom viewer ( Merge EFILM in this case) will handle compressed images.
    Images are already compressed on the server (with j2).
    When I use the 'un' for outgoing images everything is fine, so decompressing on the fly works.
    When I use 'j2' for outgoing images (by setting it in a arcnema.map) all I get on EFILM is garbage. Every single image looks like random black and white pixels.
    At first I thought it's a bug in the viewer but then I consulted their support team and they told me something like this:


    Quote

    There was a problem with transfer syntax UID - it was set to IMPLICIT_LE, but the incoming pixels were compressed. We edited it manually to .70 and then the study was displayed just fine. To put it simply - it looks like the server told us that images will be uncompressed but sent us compressed ones (with wrong tag)


    ____________________


    For me 2nd one is minor.. It's just a slight performance issue on server side (decompressing on the fly).. but the first one just kills me :(