Remote rendering of medical imaging
looking at game networking in the Cloud
SUBMITTED IN PARTIAL FULLFILLMENT FOR THE DEGREE OF MASTER
OF SCIENCE
V
IKTOR
B
ENSCH
11392789
M
ASTER
I
NFORMATION
S
TUDIES
G
AME
S
TUDIES
F
ACULTY OF
S
CIENCE
U
NIVERSITY OF
A
MSTERDAM
July 17, 2017
1st Supervisor 2nd Supervisor
Dr. Frank Nack Daniel Buzzo MA
Remote rendering of medical imaging
looking at game inspired networking in the Cloud
Viktor Bensch (11392789) University of Amsterdam
Science Park 904
1012WX, Amsterdam, The Netherlands viktorenmartijn@gmail.com ABSTRACT
By using medical imaging, doctors can get a better insight in the diagnosis of patients. If these images would be dis-played more realistically, doctors would not need a com-plete training to interpret the visual imagery. VPI Reveal created software that can enhance body scans into realis-tic 3D models, using rendering techniques normally used in games. To make this software more accessible, a Cloud solution is proposed in this paper, based on the current ren-dering architectures found in Cloud gaming and medical imaging. There seems to be a range of different solutions for remote rendering, varying from well integrated with the Cloud, to plain drag and drop to a virtual machine. The latter already giving a sufficient user experience. There does not seem to be a golden rule for remote rendering, apart from some similarities among architectures.
CCS CONCEPTS
• Networks → Cloud computing; Network experimenta-tion; • Information systems → Computing platforms; • Software and its engineering→ Software prototyping; GENERAL TERMS
Documentation, proof of technology, Cloud rendering. KEYWORDS
Game technology, Cloud, Azure, Medical Imaging, VPI Re-veal.
1 INTRODUCTION
Rendering computer graphics has vastly improved over the last 35 years[18]. The development of better graphical hard-ware has created a difference between the performance of computers, because not all systems use the latest graphics cards. Visual computations that are too heavy for a computer with an older graphics card, can be computed on a remote system. This notion is called remote rendering. By render-ing on a server, rather than usrender-ing the native hardware, a computer can run more complicated software, but becomes
reliable on a stable internet connection. This type of render-ing is currently berender-ing used by video games and animation studios, but other fields can benefit from it as well.
An example of a different field that could benefit from remote rendering is the field of medical imaging. Hospitals in the Netherlands performed around 941.000 MRI- and PET scans in 2014[16]. These scans give doctors an insight into what is wrong with a patient and therefore are vital for treatment. When looking at the current visualization of these scans, the doctor can only browse through them as black and white slices. Medical personnel scroll through the images to get an idea of the realistic situation. To enhance the workflow of doctors, the scans can be visualized using game rendering to look more like the realistic situation. This visualization gives a different insight, compared to looking at the slices one by one.
This research is performed in collaboration with VPI re-veal1and Xpirit2. VPI is currently developing software
writ-ten in C++ and OpenGL, that uses volume rendering to give a better insight into medical images. This means, the scans can be visualized in 3D without any loss of data. An exam-ple of a visualization that is currently being used and the visualization as proposed by VPI can be seen in figure 1. The added value of the newly proposed visualization is that there is more data on the screen, in a more realistic setting. Because the software relies on an advanced graphical pro-cessing unit (currently an NVIDIA Quadro FX 48003is being
used), the software is hardware dependent. VPI wants to explore the possibility of using remote rendering to make the software hardware independent. This would make the software more accessible, for it would run on any device. To make this transition possible, VPI contacted Xpirit, which provides IT solutions based on Microsoft technology.
1VPI Reveal. http://www.vpireveal.com/. (Accessed on 04/25/2017). 2Xpirit - Experts in new Microsoft technology. https://www.xpirit.com/.
(Accessed on 04/25/2017).
3NVIDIA Quadro FX 4800 provides professionals with visual computing
from their desktops delivering results that push the realms of visualization. http://www.nvidia.com/object/product_quadro_fx_4800_us.html. (Accessed on 07/12/2017).
Game studies - Information Studies, 2017, University of Amsterdam Viktor Bensch (11392789)
Figure 1: A: Shows the standard way of looking at a data set. B: An example of the visualization that is currently possible through volume rendering, made by VPI Reveal.
This specific software is an example of an application that can benefit from a remote rendering architecture. To explore the added value of this architecture, the following research questions were formulated:
Research question:
• How can technology that is currently being used to generate graphics for games, be applied to enhance 3D visual computations in a Cloud environment? Subquestions:
• What architectures are used for remote rendering of games?
• What problems does creating a server based system pose?
To answer these questions, this thesis explores the current status of remote rendering in games and game networking architectures. An understanding is gained for the conditions in which the software of VPI is to be used by assessing the current status of hospitals. Furthermore, a practical insight is gained by prototyping different architectures that were found in the field of Cloud gaming.
2 RELATED WORK
First off, a grounding is established within the field of med-ical imaging to discover what the current status is within hospitals. This explores the setting in which the software from VPI is to be used. Thereafter an insight is gathered in what has already been researched in the field of remote rendering by looking at current research. Then, four archi-tectures of current remote rendering solutions are reviewed to gain a better insight into the field of remote rendering. This concludes with a framework in which the discussed ar-chitectures are compared to one another over the following parameters: effort, optimization, render quality and hard-ware independence.
These parameters were chosen in collaboration with Alex Thissen, a professional in the field of cloud applications and a consultant at Xpirit.
The amount of effort needed to create a system should be considered to make sure the effort put into creating the new architecture, is feasible and profitable. If the effort needed to create a specific architecture is deemed too high, the ar-chitecture is not suitable for this scenario i.e. transitioning a client based application towards a server based application. Optimizationof the data that needs to be transferred be-tween the client- and the server side, should be considered, for all Cloud services use a pay per usage model.[14] By using the server side as little as possible, maintaining the application would be less expensive, which is beneficial for the creators of the software.
The render quality is essential in a good portrayal of the data. When the render quality is less than the quality seen in the original software from VPI, the added value of the new architecture becomes arguable. For this reason, the render quality should be taken into account when looking at the different architectures.
One of the advantages a server sided architecture poses is hardware independence. This means that the hardware on the client side becomes irrelevant. Users can run the application on any device, making it more accessible. Therefore, a higher hardware independence is favourable.
Medical field
All of the information from patients is stored in Electronic Health Records, EHR[11]. This means that doctors are al-ready familiar with a digital environment to browse the infor-mation surrounding the patients history. Only prescriptions that are handed out to the patient are in paper, everything else is digital. These EHR’s are accessible through a private network, to guarantee the secrecy of the information.
The system that currently manages all medical imaging within a hospital is called PACS, Picture Archiving and Com-munication System[8]. This system focuses on the storage, security and distribution of the images. A Cloud implemen-tation of PACS was suggested by Kagadis et al.[15], which would mean that there may already be a private Cloud in place in some hospitals. An EHR can refer to this system for specific imagery. The reason why not every hospital already has this system implemented is the privacy- and security issues a Cloud system poses with the centralization of the data.
Not all doctors work directly with PACS. This is mostly done by radiologists, which interpret the imagery to put the outcomes in a report in the EHR. However, sometimes images are made before surgery, as a preparation for surgeons. In that case surgeons interpret the imagery themselves.
There is no standard for internet connections in hospitals, which means that the speed of the connection may vary. Most hospitals in the Netherlands have an internet speed that is fast enough to stream video without difficulties[13], around 17 Mbps[5]. This should be sufficient for all remote rendering solutions. To account for variable speed of the connection, scalability in data transfer is suggested. This could be achieved by lowering the resolution of the visual imagery or lowering the frame rate[12].
Remote rendering
One prototype that uses volume rendering of medical imag-ing in a remote settimag-ing is described by Parsonson et al.[20]. The difference with the application that is created by VPI is that Parsonsons prototype is uses CPU instead of GPU. Because CPU is slower for these kinds of computations, the prototype uses Cloud computing to account for more com-putational power. The use of multiple CPUs instead of one GPU could be considered if the virtual GPU proves itself to be too expensive to use.
A second prototype that focuses more on pre-rendering and the compression of the data set on the Cloud is proposed by Hachaj[12]. This is one of the more applicable tests that take into account the latency during the interaction. This prototype adjusts the image resolution to account for better usability.
Thin client application
Cloud gaming provides customers with high-end graphics without the need of specific hardware. Currently, major com-panies are supporting this kind of gaming on the Cloud456.
The client side functions as a hub, that receives all the input and sends it to the server. The server then renders the visuals and encodes them as a video stream. The video stream is picked up by the client side that shows the visuals on the monitor. This means that the client side becomes a sort of hub that merely sends and receives data. Figure 2 resembles the architecture of GeFORCE NOW[2].
The code of the VPI software would have to be altered to account for streaming and remote controls. Furthermore a client application would need to be built that interacts with the server side. This would take a lot of effort. The system would be somewhat optimized in the sense that the server only runs the software. Because the system encodes the video stream with a h.264 codec, the quality loss is close to none[9].
4PlayStation Now.
https://www.playstation.com/en-us/explore/playstationnow/. (Accessed on 05/12/2017).
5NVIDIA GeForce NOW. https://www.nvidia.com/nl-nl/shield/games/.
(Ac-cessed on 05/12/2017).
6Vortex. https://vortex.gg/. (Accessed on 05/12/2017).
Figure 2: Visual representation of the architecture from the server based solution as seen in most GaaS environments, specifically the architecture from GeFORCE NOW[2].
VM implementation
LiquidSky7uses an architecture, revolving around a Virtual
Machine, VM. In this architecture software can be directly im-plemented on the virtual machine in the Cloud. This means the Cloud emulates a computer, that runs an operating sys-tem on which any program could run. The input and output are exchanged through Remote Desktop Procedure(RDP). For a visual representation of the architecture see figure 3.
This would be the least effort since the software from VPI would not need to be altered, but merely moved on to the virtual machine. All computations would be done on the Cloud, but because there is an operating system running in the background, this means the costs are higher to maintain the system. At the same time this means the system is com-pletely hardware independent. This architecture brings in the necessity for the client to set up an RDP connection. The virtual machine does not have to be limited to just running one type of software, but can be used for different appli-cations, as a normal computer. Because RDP uses a video stream to see what happens on the VM, the quality is down scaled. However, Windows now supports an improved video codec that generates a closer resemblance to the original[3]. Rich client application
In the overview of Cloud gaming by Cai et al.[6], the concept of a rich client is mentioned as one of the solutions for a remote rendering architecture. This would mean that the application takes advantage of the client side to reduce the amount of computational force needed on a server. Because the Cloud employs a pay-per-use model[14], down-scaling the amount of usage can proof to be a lucrative choice that needs to be taken into consideration.
Game studies - Information Studies, 2017, University of Amsterdam Viktor Bensch (11392789)
Figure 3: Visual representation of the architecture of the re-mote desktop to virtual machine.
Figure 4: Visual representation of the architecture of a rich viewer solution.
The code of the VPI software would need to be changed drastically to account for this hybrid version, pulling apart the functionalities from the rendering. An application on the client side would send all the button presses to the server, where the image would be created and encoded and sent as a video stream. As discussed in previous solutions, this has a minor influence on the quality of the rendering. Look at figure 4 for a schematic diagram depicting the architecture of a rich client application.
Send model to model viewer
By analyzing the data, 3D models can be created that show the features of the scan by using the contrast within the data[21]. By optimizing these models, the client side does not need a lot of computational power, but can easily show the scans and relevant data. This solution is based on the notion coined by Chen et al.[7] to integrate games into the Cloud gaming platform, rather then the other way around. As a solution this is the least favourable, since a lot of data is lost in the process, making the quality of the imaging low. A vertex model viewer would need to run on the client side and the
Figure 5: Visual representation of the architecture of a 3d model translation system.
Table 1: A summary of the different solutions with the parameters on an ordinal scale: the effort needed to create them, the optimization of Cloud resources, the render quality and the hardware independence.
Effort Optimization Render
Quality
Indep
endence
Solution 1 Medium Medium High High Solution 2 Low Low High High Solution 3 High Medium High Medium Solution 4 High High Low Low Preferred Low High High High
software from VPI would need to be altered to translate the data sets into 3D models. A visual representation is provided, see figure 5.
The 3D models could be generated by using the marching cube algorithm, which is already available within the soft-ware of VPI. This model would need to be sent to the client, after which the system could shut down again, creating a very optimized system on the server side. Because the client side would need to be able to run a model viewer, a better cpu is needed than for the other solutions.
An overview of all four solutions is found in table 1 with the information provided as written within the related work section. Based on this overview, there is not one best solution. All these solutions have their strengths and weaknesses. 3 PROTOTYPING
To gain insight into the design of remote rendering solu-tions, 2 prototypes were created. These were built using an
iterative process as suggested by design science. Design sci-ence is coined by Pfeffers et al.[22] to be used as a standard methodology in information systems research. Afterwards, the prototypes were tested on frame rate, using different data samples.
This section focuses on the process of making a proof of technology with the software provided by VPI. In doing so, an insight is gained in the design decisions and boundaries of creating a Cloud application. This insight answers part of the second subquestion: What problems does creating a server based system pose?To compare the performance of the prototype and the VPI application, Quality of service tests were looked at. These tests normally look at the latency a specific system generates, but because latency is too variable to say anything about the prototype, the tests performed in this research focused on frame rate.
VM implementation
The primary goal was to create a proof of technology that shows that the software from VPI can run in a Cloud environ-ment. With feasibility in mind, the first prototype follows the architecture of solution 2, the VM implementation. Achieving this was more difficult than expected, mainly due to specific dependencies of the software from VPI. This software was built in Microsoft Visual Studio 2005 and needed a specific runtime system(included in Service pack 1, team suite) to work. Although there were some difficulties, the amount of effort was reasonably small.
The server used for this implementation was an Azure N6V VM8. When looking at the different corporations that
provide Cloud services, there is not a major difference on a practical level. Microsoft Azure was chosen because it was provided through the collaboration with Xpirit. The NV6 was chosen because of the strong graphical card that is pro-vided within the server. This graphical card is needed for the computational heavy visualization of the scans. Considering that the technology for graphical cards on servers is still novice, they are currently only implemented on servers in east America. This creates a latency of around 160 ms to reach the server[1]. In the near future the possibility to use virtual GPU will be wider available. The prototype was tested on its frame rate to compare the two systems. To capture the frame rate FRAPS9was used. The program was run with
two different data sets, one consisting of 140 images(1.4 MB) and one with 400 images(302 MB). The results are shown in table 2.
8Azure VM N-series.
https://azure.microsoft.com/en-us/pricing/details/virtual-machines/series/#n-series. (Accessed on 05/22/2017).
9FRAPS game capture video recorder fps viewer. http://www.fraps.com/.
(Accessed on 05/22/2017).
Table 2: Results of frame rate testing in which 1.4MB is a small data set and 302MB is the large data set. All values are in frames per second.
1.4 MB 302 MB Offline - Geforce 940M 25 FPS 14 FPS VM - Tesla M60 25 FPS 25 FPS
This is in accordance with the computational power of the graphics cards, which means the VM is set up properly. Rich client implementation
To dive further into the design of a remote rendering applica-tion and gain an insight into the problem areas for creating a Cloud based solution, a second prototype was created based on solution 3, the rich client application. For this prototype the code had to be altered, to account for data transfer be-tween the client side and the server side. The previous pro-totype was used as a starting point on which an additional framework was implemented. This framework should take care of the interaction between client and server side. On top of that, a video encoder should be used to encode the images generated on the server side. This generates the need for a video decoder on the client side to generate the appro-priate imagery. By encoding the video stream, the quality of the imagery is preserved, while the data that needs to be transferred, is down scaled.
Connection setup. Creating a connection between two computers had proven itself to be more difficult than ex-pected. There are 6 points within the system that need to be checked, because these are normally closed for security reasons. In figure 6 the points are schematically shown for the specific connection that was set up. From left to right: the firewall on the client side only needs to open a port if the con-nection is two sided, some routers block specific ports, Azure makes use of network security groups that manage all the in- and out coming data, a port in the firewall on the server side needs to be opened for the program to listen to, and in this case, the Visual Studio needs to be run in administrator mode or else it won’t open a port. Because opening a port in any of these places poses security threats, the system should account for counter measures if it were to be implemented. Secure sockets layer (SSL) or transport layer security(TLS) could be used to provide a secure connection.[23].
UDP/TCP implementation.When choosing the protocol for data transfer, research was done into the protocols used in games. The protocol chosen for data transfer was UDP (User Datagram Protocol) because of the lower latency. This creates a less reliable connection, in which packets can get lost. A logical solution for this would be to combine this connection
Game studies - Information Studies, 2017, University of Amsterdam Viktor Bensch (11392789)
Figure 6: Visual representation of the security points be-tween a computer connected to the internet and an Azure VM.
with a TCP (Transmission Control Protocol) connection for the more important data. Although the combination would work better, it would have a negative impact on the UDP connection according to Sawashima et al.[24]. However, the internet has changed a lot since 1997 and has become more steady. More practical information would be needed to see how the prototype behaves using the different protocols.
The framework used for the setup of the connection be-tween the client and server was RakNet10. When looking
for a framework that was also applied in the field of games, RakNet stood out because it has been used widely in games and game oriented services, and the code is written in C++. The Remote Procedure Call 3 solution within this framework was used to connect the software on both sides. After setting up this connection, further implementation of the software could not be achieved, because this would require the code to be rewritten into two systems. This might be feasible for small projects, but the prototype from VPI was too elaborate to achieve this within 4 weeks.
Video Encoding.The next step would have been to use a video encoder on the server side. Video encoding can be done through the graphics card[4], which would also be preferred for low latency. A video decoder would need to be implemented on the client side, to interpret the imagery and create a videostream. An NVIDIA Video Codec SDK11was
found, but it lacked the documentation to implement into the rich client application. In the end, also this aspect of the prototype was deemed unfeasible.
4 METHOD
Because the perceived experience has a greater impact on the opinion from the user, a semi-structured interview was conducted. This interview was inspired by research done by Egger et al.[10], but uses only a qualitative approach,
10RakNet. https://www.raknet.com/. (Accessed on 06/05/2017).
11NVIDIA VIDEO CODEC SDK.
https://developer.nvidia.com/nvidia-video-codec-sdk. (Accessed on 07/16/2017).
for a more exploratory outcome. This outcome creates an insight into whether a server based system actually enhances the field of 3D visual computations and contributes to the second subquestion: What problems does creating a server based system pose?.
Looking at Mason[19], there is not a standard for sam-ple size. Because of the exploratory nature of the research, only three people were selected with largely varying back-grounds(medical examiner: p1, radiographer: p2, student: p3) to get a broad and quick understanding.
This interview focused on the validation of a smooth in-teraction with the prototype. The inin-teraction consisted of scaling, translating and rotating a 3D model within the pro-totype. These specific interactions were chosen because they form the basis of gaining insight into the data.
Software from VPI and a VM prototype were used to gather this information. First an understanding of the relationship the interviewee had with medical imaging was established. After this the interviewee was asked to perform a task within the software from VPI that revolved around interacting with a 3D model. Notes were taken during the interaction of the interviewee with the VPI prototype. After the task was com-pleted and the interviewee stopped browsing, the intervie-wee was asked for his or her opinion on the interaction and the quality of the images. This was followed with the question to compare this to what s/he was familiar with.
After that, the VM prototype was started with the same data set and the interviewee was asked to interact with it. Again, notes were taken to describe the interaction of the interviewee with the VM prototype. When the interviewee was finished, s/he was asked for his/her opinion on the in-teraction and the quality of the images. In the end, the inter-viewee was asked to compare the two prototypes based on their experience.
All interviews were recorded. The interviews were con-ducted in Dutch, because the sample consisted only of Dutch native speakers. Speaking English could have had a bad in-fluence on how the interviewees expressed their experience. All the answers were written down and combined with notes that were made during the interview. This data was then analyzed and compared between the different participants.
5 RESULTS
When looking at the interaction, all 3 participants were pos-itive about the interaction with both prototypes. P1 had a slower internet connection (around 10Mbps while the other 2 were around 20Mbps) which resulted in a lower frame rate and a higher latency during the VM test. However, the la-tency did not seem to bother the interviewee’s interaction with the 3D model. P1 was very impressed by the visual-ization saying: "I really want to show my coworkers this",
and could really see the added value of the prototype. This seemed to be the overall opinion of all the interviewees: the added value of the new visualization seemed to have a positive influence on the perceived usability. This is to be be-lieved, because sometimes the interviewees complained dur-ing their exploration, e.g. "The movement is very quick"(P3), while stating afterwards that everything was good, "I think I just need to practice more."(P3).
When asking about the visualization itself, none of the interviewees could see a difference between the two. The interviewees were very enthusiastic about the visualization, calling it "beautiful"(p1), "clear"(p3), and saying "this works fine"(p2). Both p1 and p3 seemed to experience a feeling of wonder, based on how often they were complimenting the visualization, and tone of voice. P2 had explained that he had already worked with this type of software before. All three interviewees pointed out different reasons why the software was an added value to the field. These all had to do with creating new insights from the data set, which were easier to diagnose than with the previous slice view. No one mentioned the same insight, this is probably because of their different backgrounds.
Only p2 had an understanding of the back end of the cur-rent situation at a hospital. P2 described his job as "the inter-face between the clinical world and the technical world". This created the opportunity to discuss more practical matters surrounding the prototype. One of the things he mentioned was "Using an RDP solution is really a ’no go’."(p2). Accord-ing to him, this had nothAccord-ing to do with the performance, but it was purely based on the security.
A different topic that was discussed was integration. In or-der for the product to be successful, the application should be integrated into the workflow. "A radiologist only has around 3 to 4 minutes to diagnose a CT-scan. If it takes him 2 minutes to send the scan over and import it to a different computer, he will simply not do it."(p2)
6 DISCUSSION
Looking at the found architectures for remote rendering as written in this research, there does not seem to be one best solution for all the proposed parameters. The research might have not been extensive enough, or the field of games does not propose the best solution for remote rendering. One logi-cal reason might be that Cloud gaming is not evolved enough yet. The field of Cloud gaming is still rather young and is in full development[7], which makes the field interesting, but not a good example to look at.
From the results, the difference between a remote rendered application and a native rendering application goes nearly unnoticeable. There were some remarks on the interaction with the prototype, but these were neglected during the
reflection. This might have to do with the novelty of the program, that positively influences the perceived usability. Furthermore, a better integration is suggested, which would mean a good overview of the current situation is needed for all the involved parties. When creating a remote rendering solution, also for other areas, a good integration within the workflow of a target audience should be considered from the start.
If remote rendering would be applied to other fields, such as simulations or video rendering, a better framework for the transition should be created. For example: supplying a basic video encoder and decoder that can easily be implemented, or improving the ease of creating a secure connection between client and server. This would reduce the amount of effort needed to create a remote rendering application. At this point, this will be one of the hurdles that will hold people back from rendering on the Cloud.
A different approach would be to start the project on the server, making it Cloud native. By embedding the server based computations into the design of the application, the developers can take into account the amount of data that is being used on the server side. This would probably pro-vide the best integration with the Cloud, because the sys-tem would be designed to function on the Cloud, instead of making a transition for software that was not made for this purpose.
So far the VM solution can be seen as the easiest transition to the Cloud. However, a different approach is suggested, keeping in mind the security of the system. RDP is not the most secure connection. This was also mentioned during the semi-structured interviews. Although these other solutions take a lot of effort, a better optimized system is created when going for a better implementation with the server side. This would in the long run be beneficial, because it creates a lower amount of usage, which results in less expenses.
Furthermore the VM solution does not account for multi view: multiple people watching the same video on multiple computers. This could be a nice feature for doctors who want to discuss something while they are not in the same room. For example, a doctor wants to consult a famous specialist, but s/he lives on the other side of the country. Through multi view this consultation could be made easy. Unfortunately, RDP does not account for multiple users to access the same VM.
When transitioning software into the Cloud, the impact the new system has on a social level needs to be consid-ered as well. Most of the Cloud providers use a pay-per-use model[14], which makes most Cloud application use a sub-scription based license to account for the reoccurring costs. Therefore software that runs on the Cloud, is never really owned by the user. This means that the user can be denied
Game studies - Information Studies, 2017, University of Amsterdam Viktor Bensch (11392789) access to the service at any given time. But as long as the
user pays, s/he should be provided with the service with an acceptable quality.
At the same time the user is now dependent on the qual-ity of the internet connection. As seen with p1, this has a direct influence on the quality of experience from the user. However, this can be tackled by using wired internet instead of wireless, and the potential coming of 5G[17] could have a positive influence on the internet quality overall.
The main focus of this research was exploration, meaning the results could be backed up with more concise research. When looking at the sample, only three people from different fields participated, giving a broad but incomplete image of the target audience. A more quantitative approach on the actual added value of the application should be considered be-fore the prototype is to be implemented, taking in mind also the integration of the application into the current workflow.
7 CONCLUSION
By looking at Cloud gaming, there are multiple possible ar-chitectures that can be considered when creating a remote rendering solution for specific software. A lot of the appli-cations can be copied to the Cloud without any alterations of the software. They can run on a VM creating a seamless transition. But different architectures should be considered, so that it runs smoothly and does not generate extra costs on the server side. However, this is time expensive.
When looking at the experience of the user, the difference between native rendering and remote rendering goes almost unnoticeable. However, the system creates a bad experience when exposed to a slow internet connection, causing latency, lag and lower image quality, but this is to be expected of all remote rendering solutions.
Although the VM method works, it is not recommended when using secretive or otherwise vulnerable information. Specifically the field of medical imaging would be better off using a more secure connection because of the sensitivity of the data. Most Cloud gaming services use a thin client architecture, meaning they handle everything on the server side and use the client side merely as a video player. This architecture has more control over the security. The problem with using a thin client- and a rich client architecture lies within the amount of effort needed to make this transition. There is no standard for implementing these architectures, which influences the amount of effort needed to transition to the Cloud. Overall this means that game technology can be looked at for insights into remote rendering, but does not put forth a best possible solution.
This research could be repeated after the more global im-plementation of graphic cards in server settings, to see what the impact will be when more people have access to GPU on
the Cloud. Based on the semi-structured interview, research into the security of the systems would be recommended. Also, a better insight based on quantitative research into the per-ceived usability could give more insight into the experience of the user.
8 ACKNOWLEDGMENTS
This thesis was made in collaboration with Xpirit and VPI Reveal. Special thanks to Alex Thissen, who helped me out a lot at Xpirit, Dr. Gino van den Bergen, who made me under-stand the software from VPI, Pascal Greuter, who believed in me from the start, Frank Nack, who guided me through all this, Daniel Buzzo, who helped me along the way and pointed me into the right direction, and all the interviewees who where kind enough to spare some time.
REFERENCES
[1] Azure latency test - azure speed test. http://azurespeed.com/. (Accessed on 07/15/2017).
[2] Gdc vault - cloud architectures, onboarding, and game streaming with nvidia grid (presented by nvidia). http://www.gdcvault.com/play/1020661/ Cloud-Architectures-Onboarding-and-Game. (Accessed on 07/12/2017). [3] Remote desktop protocol (rdp) 10 avc/h.264
improve-ments in windows 10 and windows server 2016 tech-nical preview - enterprise mobility and security blog. https://blogs.technet.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10 -and-windows-server-2016-technical-preview/. (Accessed on 07/15/2017). [4] Video encode and decode gpu support matrix | nvidia developer. https: //developer.nvidia.com/video-encode-decode-gpu-support-matrix. (Ac-cessed on 07/16/2017).
[5] Akamai (2017). State of the internet connectiv-ity visualization | akamai. https://www.akamai.com/ us/en/about/our-thinking/state-of-the-internet-report/
state-of-the-internet-connectivity-visualization.jsp. (Accessed on 08/03/2017).
[6] Cai, W., Chen, M., and Leung, V. C. (2014). Toward gaming as a service. IEEE Internet Computing, 18(3):12–18.
[7] Chen, K.-T., Huang, C.-Y., and Hsu, C.-H. (2014). Cloud gaming onward: Research opportunities and outlook. In Multimedia and Expo Workshops (ICMEW), 2014 IEEE International Conference on, pages 1–4. IEEE. [8] Choplin, R. H., Boehme 2nd, J., and Maynard, C. (1992). Picture
archiv-ing and communication systems: an overview. Radiographics, 12(1):127– 129.
[9] De Cock, J., Mavlankar, A., Moorthy, A., and Aaron, A. (2016). A large-scale video codec comparison of x264, x265 and libvpx for practical vod applications. In SPIE Optical Engineering+ Applications, pages 997116– 997116. International Society for Optics and Photonics.
[10] Egger, S., Ries, M., and Reichl, P. (2010). Quality-of-experience beyond mos: experiences with a holistic user test methodology for interactive video services. In 21st ITC Specialist Seminar on Multimedia Applications-Traffic, Performance and QoE, pages 13–18.
[11] Gunter, T. D. and Terry, N. P. (2005). The emergence of national electronic health record architectures in the united states and australia: models, costs, and questions. Journal of medical Internet research, 7(1). [12] Hachaj, T. (2014). Real time exploration and management of large
medical volumetric datasets on small mobile devices - evaluation of re-mote volume rendering approach. International Journal of Information Management, 34(3):336–343.
[13] Huygens, M. W., Vermeulen, J., Friele, R. D., van Schayck, O. C., de Jong, J. D., and de Witte, L. P. (2015). Internet services for communicating with the general practice: barely noticed and used by patients. Interactive journal of medical research, 4(4).
[14] Jadeja, Y. and Modi, K. (2012). Cloud computing-concepts, architec-ture and challenges. In Computing, Electronics and Electrical Technologies (ICCEET), 2012 International Conference on, pages 877–880. IEEE. [15] Kagadis, G. C., Kloukinas, C., Moore, K., Philbin, J., Papadimitroulas,
P., Alexakos, C., Nagy, P. G., Visvikis, D., and Hendee, W. R. (2013). Cloud computing in medical imaging. Medical physics, 40(7).
[16] Lahti, L., Huovari, J., Kainu, M., and Biecek, P. (2017). eurostat r package. R package version 3.1.1.
[17] Ma, Z., Zhang, Z., Ding, Z., Fan, P., and Li, H. (2015). Key techniques for 5g wireless communications: network architecture, physical layer, and mac layer perspectives. Science China Information Sciences, 58(4):1–20. [18] Marschner, S. and Shirley, P. (2015). Fundamentals of computer graphics.
CRC Press.
[19] Mason, M. (2010). Sample size and saturation in phd studies using qual-itative interviews. In Forum qualqual-itative Sozialforschung/Forum: qualqual-itative social research, volume 11.
[20] Parsonson, L., Grimm, S., Bajwa, A., Bourn, L., and Bai, L. (2012). A cloud computing medical image analysis and collaboration platform. In Cloud Computing and Services Science, pages 207–224. Springer. [21] Patel, A. and Mehta, K. (2012). 3d modeling and rendering of 2d medical
image. In Communication Systems and Network Technologies (CSNT), 2012 International Conference on, pages 149–152. IEEE.
[22] Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of management information systems, 24(3):45–77.
[23] Rescorla, E. (2001). SSL and TLS: designing and building secure systems, volume 1. Addison-Wesley Reading.
[24] Sawashima, H., Hori, Y., Sunahara, H., and Oie, Y. (1997). Characteris-tics of udp packet loss: Effect of tcp traffic. In Proceedings of INETâĂŹ97: The Seventh Annual Conference of the Internet Society.
