Oviyam2 reading images direct from filesystem?

[BRIT]

Hey all,

I've got a DCM4CHEE server with Oviyam2 installed upon it.  It looks great but of course, you have to configure a DICOM server in order to get the files into Oviyam.  I've read from Suresh that a newer version of the viewer will not have a DCM4CHEE requirement and will run without it, but does anyone know if that will mean that Oviyam will come with it's own DICOM server (and therefore effectively request images - via DICOM -  from itself), or will it have the ability to read DICOM files from the filesystem directly?

I've looked at MedDream's Flash viewer that will read a folder containing images within it and wondered if anyone knew if Oviyam would follow suit?

[Suresh Viswanathan]

The first release of Oviyam 2 required a dcm4chee server for user authentication. The latest release removes that dependency. You would still need a PACS server. Another requirement was WADO support. The latest version works with C-Move & C-Get. You would still need a DICOM server. 

There are no plans to have the viewer serve images from a folder at present. What is your use case scenario for that?

Suresh

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/groups/opt_out.

[BRIT]

Suresh,

My immediate thought is speed.  As we all know, DICOM is a great structure for medical imaging, but it's not the most "timely" when it comes to speed issues.  Therefore, (IMHO) in order to come forth with a great web viewer of DICOM images, I would put forth an statement that explains if a web based viewer can deliver those images as fast as possible, it would rank very high in the order of offerings. A lot of the issues when it comes to rapid display of images is down to the DICOM side of things, between the PACS and the viewer.  Even when deployed on the same system, the communications between the PACS and viewer, being DICOM, would be considerably slower than if (for example) the viewer was able to read DICOM images directly from the file-system.  

I wonder how many people using DCM4CHEE and Oviyam have the two residing on the same system? In this case, the files are actually already residing on the file system. Why use DICOM for Oviyam to read them?  Why not pull them directly from the file-system and remove the latency that the DICOM communications overhead would introduce to the entire process?  Perhaps those people (not unlike myself) have only got DCM4CHEE installed in order to be the "go-between" their mainline PACS and some sort of web based viewing portal.

Don't get me wrong, I like Oviyam a lot - it's a great resource for us to use and certainly the v2.0 release beats a lot of other offerings out in the marketplace.  However, IMHO, if users can devise a way of getting DICOM images onto the same server that Oviyam is installed, in a structured manner, and then allow Oviyam to read directly from that file-system, I think the speed issues related to a lot of offerings can be removed considerably: reading images from a file-system has to be considerably quicker than using DICOM negotiation protocols 

MedDream's offering isn't bad : other than the fact that it's designed completely in Flash and therefore restricts it's use somewhat with new tablet technology.

Just my two cents worth.  I'd be happy to discuss in more detail if I'm not making myself particularly clear!!

[Suresh Viswanathan]

I understand where you’re coming from. However, even when reading from the local directory, you’ll still have the overhead (time delay) of converting the DICOM image into JPEG. Also with such a system, how would you propose to query different patients? Would viewer just present the user with a file browser and display all images within a folder? The lack of any index precludes searching on any parameter.

Suresh

[BRIT]

Suresh,

I understand your comments about conversion, that's always got to be taking into consideration, all I was trying to explain was that in order to reduce any load time, it may be beneficial to use file I/O versus DICOM networking.

As for the indexing, that could be handled a number of ways.  As opposed to "searching" there is a case where I want to present to the user what studies are available to them, thereby already taking into account the authentication and permissions of who can see what.  For example, 

1. Oviyam is configured on the server to know about a default folder where all local files would reside (eg '/usr/local/oviyam2/DICOM')
   
2. My web application :
1. handles authentication 
2. sets a users personal and unique folder within the default folder (eg '/usr/local/oviyam2/DICOM/DBEAACC')
   
3. is able to pass the users personal folder to Oviyam 
3. When my user logs in, they see a list of studies that they have access to.  One of their options is an icon which calls "http://dcm4chee_ip:8080/oviyam/oviyam?studyUID=<studyUID>&userCredential=DBEAACC" 
4. Oviyam can now look for the StudyUID within a that specific  folder.

On Monday, January 6, 2014 10:12:39 AM UTC-8, BRIT wrote:

[julio moreno]

Hi Brit,

¿can you load images in Oviyam2 reading from a directory?

thank's