Visualiseren van de medische beelden op een mobile device

Transcriptie

1 owered by TCPDF ( Academiejaar Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg Gent Visualiseren van de medische beelden op een mobile device Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica Pieter-Jan VAN ROBAYS Promotoren: dr. Marleen DENERT Jan DOBBENIE (Dobco Medical Systems) Begeleider: Kristof COUCKE (Dobco Medical Systems)

2 Abstract Vandaag kunnen medische beelden niet eenvoudig gevisualiseerd worden op een mobiel toestel. Dit kan enkel door het aanspreken van een aangepaste webservice via de browser of via dure en trage fat client apps omdat de beelden bewaard worden op het PACS (Picture Archiving and Communication System) in DICOM (Digital Imaging and Communications in Medicine) formaat. In dit formaat wordt extra metadata over de patiënt bewaard bij de afbeelding. Hierdoor zijn de traditionele PACS viewers vaak fat clients die men enkel efficiënt en snel kan uitvoeren vanaf een PC. Nochtans is het intuïtief tonen, navigeren en verwerken van beelden op een mobile device vaak nodig voor een second opinion of expertise van een gespecialiseerde radioloog die niet steeds aanwezig is op de afdeling zelf, bijvoorbeeld bij spoedgevallen. Daarom wordt na onderzoek van de verschillende technologieën een mobiele app ontwikkeld die kan concurreren met de fat client programma s. In de nieuwe applicatie kunnen beelden of series op verschillende manieren gemanipuleerd worden, er kunnen metingen toegepast worden op de beelden en de beelden kunnen offline beschikbaar gesteld worden. Al de bestanden en persoonlijke gegevens worden beveiligd bewaard. Niet enkel is de applicatie heel gebruiksvriendelijk op een mobiel toestel. Ook de performantie is tot drie keer hoger dan de huidige webapplicatie. ii

3 Abstract Up until now it is not easy to visualize medical images with a mobile device. This is only possible by accessing an adapted web service with the browser or by slow and expensive fat client apps since the images are being saved on a PACS (Picture Archiving and Communication System) in DICOM (Digital Imaging and Communications in Medicine) format. With this format it is possible to save additional metadata of the patient along with every image. This is why conventional PACS viewers are often fat clients which can only be efficiently carried out from a PC. It is however frequently necessary to show, navigate and process images on a mobile device. For example when a second opinion or expertise of a specialized radiologist needs to be done who is not physically present. Therefore, after examining the various possible technologies, a mobile app is developed that can compete with these fat client applications. With this new app it is possible to manipulate, take measurements and save the images or stack of images offline on the device. All these files and personal data are being securely saved. Not only is the app very user-friendly on a mobile device. Also the performance is up to three times better than the current web application. iii

4 Woord vooraf Al sinds mijn jonge jaren ben ik naast mijn andere hobby s, gebeten door alles wat met informatica te maken heeft. Mijn eerste website maakte ik op mijn 10 jarige leeftijd samen met mijn neef. Twee jaar later begon ik via zelfstudie op het internet PHP te leren en websites te maken voor kleine ondernemingen en vzw s. Ondertussen bleef ik ook druk bezig met muziekschool en basketbal naast mijn schoolse activiteiten. Ik had echter al snel door dat er slechts met een van mijn hobby s echt geld te verdienen viel. Zo maakte ik na mijn middelbare schooltijd de logische beslissing toegepaste informatica te studeren aan de hogeschool. De opleiding informatica ging tamelijk vlot. Zonder al te veel moeite behaalde ik toch goede resultaten op school. Daarom kon ik informatica als een hobby blijven uitvoeren. Ik stapte gelijktijdig met één voet in de bedrijfswereld door vaste jobstudent te worden bij Atforma bvba als informaticus. Als stage en bachelorproef voor mijn opleiding koos ik destijds voor het project augmented reality bij RealDolmen. De opdracht bestond uit het verwezenlijken van een mobiele track & trace applicatie voor Android. Deze applicatie diende de mogelijkheid te bieden om pakketten in te scannen via het mobiele toestel en vervolgens de locatie van de bestuurder te versturen naar de server. Tijdens dit project groeide mijn liefde voor het ontwikkelen van mobiele applicaties. Eenmaal ik mijn bachelor diploma in handen had, begon ik spijt te krijgen dat ik geen uitdagendere opleiding had gekozen. Gelukkig voor mij bestond toen net het schakelprogramma tot industrieel ingenieur in de computer wetenschappen. Iets waaraan ik geen seconde twijfelde om in te stappen. Tijdens deze opleiding ging een nieuwe wereld voor mij open. Eindelijk kreeg ik antwoorden op vragen waar ik gedurende mijn ganse bachelor opleiding mee zat. Alle onderwerpen die toen oppervlakkig of zelfs niet werden behandeld, werden nu tot in de kleinste details uitgelegd. Eindelijk begon ik me te voelen als de informaticus die ik ook écht wou zijn. Toen ik te horen kreeg dat we onze masterproef mochten kiezen wou ik heel graag terug een iv

5 v praktisch mobiel project verwezenlijken. Mijn oog viel onmiddellijk op een mobiel project in de medische sector. Te meer daar ik veel vrienden en familie heb die actief zijn in deze sector. Om af te sluiten wil ik graag nog enkel mensen bedanken die een grote invloed gehad hebben bij het uitwerken van mijn masterproef. Mijn interne promotor Marleen Denert. Zij stond tijdens deze masterproef altijd klaar om te helpen of feedback te geven waar nodig. Zeker in de laatste rechte lijn wanneer dit misschien nog het meest nodig is. Daarnaast wil ik ook mijn externe promotoren Jan Dobbenie en Kristof Coucke bedanken die mij telkens met hulp en daad bijstonden. Mijn respect voor hen groeide naarmate ik meer en meer inzage kreeg in hun reeds uitgewerkte applicaties. En last but not least wil ik graag zoals het hoort, mijn ouders bedanken en in het bijzonder mijn moeder moeke. Zij steunde me steeds op welke manier dan ook, in alles wat ik deed of wou doen. Wees gerust: ik wou altijd heel veel doen! Pieter-Jan Van Robays Gent, Juni 2014

6 Inleiding Tot op vandaag worden medische beelden meestal verstuurd via een CD-ROM. Deze moet vervolgens aan de patiënt worden meegegeven of worden opgestuurd via de post, wat niet echt de meest moderne manier is om gegevens over te dragen. Daarom startte Dobco Medical Systems in 2010 met PacsOnWeb, een webapplicatie voor dokters en patiënten die de medische beelden bewaart en weergeeft vanuit de cloud. Hierdoor kunnen de beelden worden bekeken vanaf een browser, zolang men maar beschikt over een internetverbinding. Sinds de komst van mobiele toestellen kwam er meer en meer vraag naar een goede mobiele oplossing voor het bekijken van die beelden. Uiteraard was dit al mogelijk via de browser op de mobiele toestellen zelf, maar deze schoten te kort op vlak van performantie en usability. Bijgevolg was er nood aan een performante en gebruiksvriendelijke oplossing om de beelden uit de cloud te kunnen bekijken op een mobiel toestel. Ook moest het mogelijk zijn om alle verschillende soorten medische beelden te kunnen weergeven, diverse zware berekeningen en metingen toe te passen op die beelden en de beelden offline beschikbaar te stellen. De uiteindelijke applicatie maakt gebruik van de bestaande PacsOnWeb service en kan omgaan met alle verschillende soorten beelden en grote series, window level toepassen op beelden met extra grijswaarden en beelden veilig lokaal bewaren. Dit alles terwijl de performantie met ongeveer 300% verbeterd werd ten opzichte van het gebruik van de mobiele browser. In hoofdstuk 1 wordt onderzoek gevoerd naar de beste technologie voor het verwezelijken van dit project. Ook wordt dieper ingegaan op de DICOM standaard die in deze masterproef vaak aan bod zal komen. Hoofdstuk 2 beschrijft de uiteindelijke technologiën die gebruikt zullen worden in het project. In hoofdstuk 3 wordt dieper ingegaan op alle verschillende functionaliteiten van de applicatie zoals onder andere de window level en stack scroll functionaliteit. Vervolgens wordt in hoofdstuk 4 de implementatie van de belangrijkste functionaliteiten uitgeschreven met enkele codevoorbeelden. Tot slot wordt in hoofdstuk 5 het uiteindelijke resultaat van de applicatie besproken. vi

7 Inhoudsopgave 1 Onderzoek Hybride vs. Native ios Android PhoneGap HTML Conclusie DICOM Belangrijke DICOM attributen D-voorstelling van medische beelden Delen van data tussen apps Webservice Shared Keychain Aangepaste URL schema s UIPasteboard Conclusie PacsOnWeb Structuur van de gegevens Bewaren van extra grijswaarden via PNG Verdeling van de bits per kanaal Technologieën ios Objective-C Objective-C API s HTTP HTTP Requests HTTP Responses ASP.NET ASP.NET Authentication vii

8 Inhoudsopgave viii 2.4 SSL en TLS Applicatie Inloggen op secure.pacsonweb.com HTTP protocol Beveiliging van de pakketten De technologie Implementatie in ios Functies op beelden Metingen op de beelden Manipuleren van beelden Window level Stack scans Implementatie Afhandelen van gestures met zware berekeningen Main thread Operation queue Ophalen en bewaren van pixel data van een afbeelding Window level Minimale en maximale waarde berekenen voor LUT Berekening LUT bit berekenen uit RGB waarden Besluit 64 A Handleiding 66 Bibliografie 85

9 Hoofdstuk 1 Onderzoek 1.1 Hybride vs. Native In de mobiele wereld bestaan er momenteel twee soorten applicaties Native applicatie geschreven in de native taal van het operating system. Kan ook enkel gebruikt worden op toestellen die het operating system draaien. Hybride applicatie geschreven in een overkoepelende taal die verschillende operating systems kan interpreteren. Het project zal in korte tijd zware berekeningen moeten uitvoeren op beelden. De belangrijkste eis die aan de applicatie gesteld wordt, is dat deze de zware berekeningen performant en vloeiend kan uitvoeren in real time. Daarom wordt een test voorzien die de performantie van deze berekening in beeld zal brengen. De test applicatie zal de brightness of helderheid van een afbeelding aanpassen met behulp van een slider. Hierdoor is het mogelijk de framerate te analyseren van de applicatie en te controleren of deze hoog genoeg is om een vlot resultaat te bekomen. De test registreert gedurende ongeveer 20 seconden abnormaal gebruik. Met abnormaal gebruik wordt bedoeld dat de slider zo snel mogelijk heen en weer verplaatst wordt zodat de achterliggende grafische berekeningen niet kunnen volgen met het genereren van voldoende aantal frames. De applicatie wordt geschreven in twee native applicaties en twee hybride applicaties: 1. ios 2. Android 3. PhoneGap 4. HTML5 1

10 Hoofdstuk 1. Onderzoek ios User interface Om de applicatie zo eenvoudig mogelijk te houden zijn er slechts twee componenten: UIImageView: container om de afbeelding in weer te geven UISlider: interactief slider object dat dient als invoer voor de waarde van de helderheid De slider registreert de gebruikersinteractie en delegeert dit naar de ViewController die op zijn beurt de brightness filter toepast en de afbeelding in de UIImageView aanpast Image manipulation Het manipuleren van beelden gebeurt in ios via het Core Image framework. Het is een technologie die ontworpen is om in real time aanpassingen te maken op statische beelden, maar ook op videobeelden. Core Image is een laag die vlak boven de OpenGL (ES) laag is gebouwd en zo de overhead minimaal houdt, zoals te zien is op figuur 1.1. Figuur 1.1: Core Image architectuur De figuur toont hoe Core Image kan omgaan met beelden van verschillende datatypes uit de Core Graphics, Core Video en de Image I/O frameworks. De ingebouwde filters kunnen hierdoor op elk van deze datatypes worden uitgevoerd en door zowel de GPU als de CPU via de OpenGL (ES) standaard of Apple s eigen Grand Central Dispatch (GCD) framework worden uitgevoerd. Door gebruik te maken van de Core Image Context blijft het schrijven van de code kort en overzichtelijk maar blijft de performantie behouden doordat deze net boven de OpenGL Embedded System laag gebouwd is.

11 Hoofdstuk 1. Onderzoek Performantie De performantie van een ios applicatie kan worden gecontroleerd via de Developer Instruments functie van Xcode. Hiermee is het mogelijk om in real time de framerate van de OpenGL ES driver te meten. Onderstaande grafiek in figuur 1.2 geeft de resultaten weer van deze test via de native ios applicatie. Figuur 1.2: Framerate grafiek bij de ios test In de grafiek toont de lijn de gemeten resultaten. Hieruit is af te leiden dat bij abnormaal gebruik er nog steeds gemiddeld meer dan 50 frames per seconde kunnen worden berekend Android User Interface Opnieuw wordt de applicatie zo eenvoudig mogelijk gehouden. soorten views: Android kent echter twee Activity Fragment Een Activity is de hoofd-view waarop verschillende Fragments getoond kunnen worden. De Fragment toont op zijn beurt de volgende componenten: ImageView: container om de afbeelding in weer te geven SeekBar: interactief slider object die dient als invoer voor de waarde van de helderheid

12 Hoofdstuk 1. Onderzoek Image manipulation Android Graphics wordt hier gebruikt om 2D of 3D beelden te renderen via een van zijn vele beschikbare frameworks. Algemeen zijn er twee manieren voor ontwikkelaars om grafisch iets te tekenen op het scherm: Canvas OpenGL Canvas is een 2D grafische API die het vaakst gebruikt wordt door zijn eenvoud ten opzichte van OpenGL. Het wordt onder andere ook gebruikt om alle views in Android te tekenen. Voor Android 3.0 werd de onderliggende Skia 2D bibliotheek gebruikt voor het tekenen van de Canvas. Deze bibliotheek heeft als nadeel dat ze geen gebruik maakt van hardware accelerators. Vanaf Android 3.0 kon gekozen worden om onderliggende OpenGLRenderer te gebruiken, die de Canvas operaties vertaalt naar OpenGL operaties zodat deze kunnen worden uitgevoerd op de GPU. Sinds de komst van Android 4.0 is dit de standaard manier geworden en is het verplicht om een GPU die OpenGL ES ondersteunt te plaatsen in het toestel. Er kan gesteld worden dat sinds Android 4.0 de overhead minimaal wordt gehouden door de verschillende lagen zodat dit de performantie ten goede komt Performantie De performantie bepalen via de framerate van een Android applicatie is niet zo eenvoudig. Android laat enkel toe de framerate weer te geven door het toestel te rooten. Hierdoor kan de meting enkel visueel gebeuren en is er geen grafiek ter beschikking. De maximale framerate van de applicatie bedroeg bij abnormaal gebruik 46FPS PhoneGap PhoneGap is een framework om hybride applicaties te schrijven via HTML5, Cascade Style Sheet en JavaScript. Het framework converteert een webapplicatie naar een native applicatie met slechts een webview waar de webapplicatie op wordt weergegeven. De webview neemt de volledige hoogte en breedte in van het scherm waardoor de gebruiker de illusie krijgt dat hij op een native applicatie werkt, terwijl hij eigenlijk op een webapplicatie werkt. Men noemt dit ook wel een chrome-less browser. In onderstaande figuur 1.3 wordt het build process weergegeven.

13 Hoofdstuk 1. Onderzoek 5 Figuur 1.3: PhoneGap build process Zoals te zien op de figuur wordt de webapplicatie vertaald naar een PhoneGap Build. Via deze build is het mogelijk verschillende native applicaties te genereren voor de verschillende native operating systems die worden ondersteund User interface Om de applicatie zo eenvoudig mogelijk te houden zijn er opnieuw zo weinig mogelijk componenten toegevoegd. Voor deze applicatie is er slechts een component: Canvas: container om de afbeelding in weer te geven en aanpassingen te maken. Via geregistreerde touch event listeners kan de invoer opgevangen worden Image manipulation In PhoneGap gebeurt het manipuleren van de beelden via JavaScript code. Deze code wordt geïnterpreteerd en uitgevoerd in de browser waardoor er enkele lagen meer liggen tussen de geschreven code en de OpenGL ES laag, waar de uiteindelijke rendering gebeurt. Dit zorgt voor extra overhead met vermoedelijk verlies van performantie als gevolg, wat moet blijken uit de resultaten. JavaScript haalt de pixel data van de afbeelding op uit context van de canvas. Hierna kunnen via een lus alle pixels overlopen en aangepast worden. De context wordt achteraf weer opgevuld met de gemanipuleerde pixel data waardoor de gemanipuleerde afbeelding wordt weergegeven Performantie Ook hier kan de performantie gemeten worden via de Developer Instruments van Xcode.

14 Hoofdstuk 1. Onderzoek 6 De test wordt opnieuw onder abnormaal gebruik gevoerd door de vinger zo snel mogelijk heen en weer te verplaatsen. Onderstaande grafiek in figuur 1.4 geeft de test resultaten weer. Figuur 1.4: Framerate grafiek bij de PhoneGap test Uit de grafiek blijkt dat er amper een gemiddelde framerate van 5FPS wordt gehaald. Dit is 10 maal slechter dan de native oplossing HTML5 Het testen van de HTML5 applicatie is in principe wat overbodig voor het bedrijf, aangezien hun huidige applicatie hiermee is gebouwd en tekort schiet qua performantie. Voor de volledigheid van dit onderzoek werd de test toch uitgevoerd. Aangezien PhoneGap reeds gebruik maakte van een HTML5 pagina kan deze code rechtstreeks in de browser van het mobiel toestel volledig overgenomen en getest worden. Het enige wat nog moet worden opgesteld, is een kleine webserver waar de code op geplaatst kan worden en waar het mobiel toestel kan naar browsen Performantie De performantie van de HTML5 pagina wordt gemeten aan de hand van remote debugging. Dit laat toe om een geopende webpagina op het mobiele toestel, te analyseren via de computer. Ook hier wordt de test met abnormaal gebruik uitgevoerd. De resultaten worden in onderstaand cirkeldiagram weergegeven in figuur 1.5

15 Hoofdstuk 1. Onderzoek 7 Figuur 1.5: Framerate grafiek bij de HTML5 test Uit de figuur kan worden afgeleid dat tijdens de duur van de test (19.83s) er 445 frames konden berekend worden. Dit komt neer op een gemiddelde van bijna 23FPS Conclusie De native applicaties scoren zeer goed en vormen het bewijs dat real time aanpassingen aan afbeeldingen op een mobiel toestel zeker mogelijk zijn. Jammer genoeg scoren de hybride applicaties ondermaats. Voor een vloeiend en vlot gebruik van een applicatie is er een framerate van minstens 30FPS gewenst (zie 3.2.2). Via de native applicaties worden deze quota ruimschoots gehaald. Voor de hybride applicaties is dit een ander verhaal. De applicaties halen een framerate van maximaal 28FPS, voor de relatief simpele brightness test. Het bedrijf koos daarom resoluut voor een native ios applicatie. De keuze voor ios werd gemaakt op basis van het grote aandeel dat het besturingssysteem kent op de tabletmarkt. 1.2 DICOM Digital Imaging and Communications in Medicine (DICOM) is een software integratie standaard die gebruikt wordt in de medische beeldvorming. Alle moderne toestellen die medische beelden kunnen produceren, ook wel de beeldmodaliteiten genoemd, gebruiken dit uitvoerig. Beeldmodaliteiten zijn onder andere een X-ray toestel, echografie, CT (Computed Tomography) en een MRI (Magnetic Resonance Imaging). De kern van DICOM bestaat uit twee grote delen: Bestandsformaat: het bestandsformaat voor alle medische beelden met extra informatie over de patiënt, de modaliteit en andere context die gebruikt wordt om het beeld van

16 Hoofdstuk 1. Onderzoek 8 de studie te koppelen aan de medische behandeling. Netwerk protocol: het protocol voor medische toestellen om met elkaar te kunnen communiceren in het netwerk. Vaak wordt dit gebruikt om beelden op te zoeken in archieven of back-ups te nemen van beelden, maar het laat ook complexere commando s toe. Deze commando s kunnen bijvoorbeeld behandelingen volgen of controleren, onderzoeken plannen, statussen rapporteren en de werklast verdelen tussen dokters. Het grote succes van de DICOM standaard is dat het gebruikt wordt door verschillende fabricanten. Zo kan een toestel van om het even welke fabricant aangesloten worden op het netwerk en beelden, die gemaakt werden door toestellen van een andere fabricant, opvragen van het medische beeld archief (PACS). Het kan uiteraard ook zijn zelfgemaakte medische beelden doorsturen naar andere toestellen. Voor dit project is het niet nodig om rechtstreeks gegevens te onttrekken uit het DICOM bestandsformaat of te kunnen communiceren via het DICOM netwerk protocol. Dit komt doordat de applicatie niet draait in een DICOM omgeving, maar communiceert over het internet met de PacsOnWeb service. Er zal wel vaak gebruik gemaakt worden van de DICOM attributen om de gegevens en medische beelden correct weer te geven Belangrijke DICOM attributen DICOM attributen zijn een onderdeel van een DICOM object wat op zijn beurt een onderdeel is van het DICOM bestandsformaat. Elk attribuut heeft een unieke tag of naam, een data type, een lengte en een waarde. In wat volgt worden de belangrijkste attributen voor dit project verduidelijkt Pixel representation Pixel representation heeft slechts twee waarden. unsigned (0): De voorgestelde waarde zal altijd positief zijn signed (1): De voorgestelde waarde kan zowel negatief als positief zijn Rescale slope en Rescale intercept Sommige DICOM modaliteiten bewaren een toestel specifieke waarde in de pixels van de beelden. Hierdoor zijn de beelden enkel zinvol te gebruiken op het toestel zelf. Rescale slope en Rescale intercept zorgen voor de transformatie van die pixels naar betekenisvolle pixels voor elke toepassing.

17 Hoofdstuk 1. Onderzoek 9 De Rescale slope en Rescale intercept instellingen zijn dus specifiek voor een DICOM modaliteit. De originele waarde kan berekend worden via volgende formule: bruikbarewaarde = originelewaarde rescaleslope + rescaleintercept (1.1) Deze berekening moet toegepast worden op de pixels alvorens manipulaties toe te passen op de afbeelidng zoals window leveling (3.2.3, p45) LUT data Een LUT of LookUp Table is een tabel met een grootte van 2 aantalbits, die voor elke mogelijke grijswaarde een 8-bitwaarde bepaalt. Deze tabel wordt gebruikt om bijvoorbeeld alle mogelijke 16-bitwaarden, een overeenstemmende 8-bitwaarde te geven zodat deze weergegeven kan worden door een scherm. Indien een LUT lineair is, kan deze bepaald worden via het aantal bits en de window level (3.2.3, p45) instellingen. Sommige DICOM modaliteiten gebruiken echter geen lineaire LUT. In dat geval moet de LUT bewaard worden in de DICOM header Photometric interpretations Photometric interpretations bepalen de relatie tussen de gegevens in de pixels en hoe de afbeelding gepresenteerd moet worden. DICOM ondersteunt 9 fotometrische interpretaties waarvan dit de belangrijkste zijn: MONOCHROME2: normale monochrome afbeelding, hoe hoger de pixel waarde, hoe witter de kleur MONOCHROME1: omgekeerde monochrome afbeelding, hoe hoger de pixel waarde, hoe zwarter de kleur RGB: meest gebruikte formaat, heeft de mogelijkheid om kleur weer te geven in afbeeldingen D-voorstelling van medische beelden Medische beelden worden steeds van een drie dimensionaal voorwerp genomen namelijk: de patiënt. Om de plaats van de pixels van het beeld te bewaren dient de oriëntatie en positie opgeslaan te worden bij het beeld. Deze positie en oriëntatie worden benoemd in een drie dimensionaal assenstelsel. Dit assenstelsel wordt in DICOM het Reference Coordinate System of RCS genoemd en is zeer intuïtief.

18 Hoofdstuk 1. Onderzoek Reference Coordinate System De X-as van dit assenstelsel loopt van de rechterkant van de patiënt naar de linkerkant. De Y-as loopt van de voorkant van de patiënt naar de achterkant, of in medische termen van de anterior naar de posterior. De Z-as loopt van de voeten van de patiënt naar zijn hoofd. Aan elk einde van een richting of richtingszin wordt in de medische sector een naam en een letter gegeven, de anatomische posities: R - Right: de richting waarin de X-waarde afneemt L - Left: de richting waarin de X-waarde toeneemt A - Anterior: de richting waarin de Y-waarde afneemt P - Posterior: de richting waarin de Y-waarde toeneemt F - Feet: de richting waarin de Z-waarde afneemt H - Head: de richting waarin de Z-waarde toeneemt Een visuele presentatie van het assenstelsel en de letters wordt weergegeven in onderstaande figuur 1.6. Figuur 1.6: Reference Coordinate System

19 Hoofdstuk 1. Onderzoek Doorsnedes van het lichaam Om latere voorbeelen te begrijpen moeten nog enkele medische termen behandeld worden: de doorsnedes of planes. Er zijn drie basis doorsnedes: Axiale of traversale doorsnede - loodrecht op Z-as: scheidt hoofd van de voeten Saggitale doorsnede - loodrecht op X-as: loopt recht tussen de ogen en scheidt links en rechts Coronale of frontale doorsnede - loodrecht op Y-as: scheidt de voor- en achterkant De doorsnedes worden verduidelijkt in onderstaande figuur 1.7. Figuur 1.7: Doorsnedes van het lichaam Richtingsvectoren Het doel van de richtingsvectoren is om de oriëntatie van een 2D beeld te kunnen bepalen in een 3D-omgeving. Een 2D DICOM beeld krijgt daarom als oriëntatie twee vectoren mee via het Image Orientation (Patient) attribuut. Een X- en een Y-vector die de richting van het X-, Y-assenstelsel van de afbeelding zelf weergeven in het RCS. Verder wordt uiteraard ook de positie van de pixel links boven in het beeld meegegeven in millimeter, en de pixel representation ( ) die de breedte van een pixel in millimeter weergeeft. Via deze parameters kan van elke pixel in een beeld de exacte positie bepaald worden in het RCS-assenstelsel.

20 Hoofdstuk 1. Onderzoek 12 Het DICOM object Image Orientation kent steeds 6 waarden en stelt twee genormaliseerde 3D richtingsvectoren voor. De eerste drie waarden stellen respectievelijk de x, y en z component van de X vector voor (Xx, Xy, Xz). De laatste drie waarden stellen de componenten van de Y vector voor (Y x, Y y, Y z). Een medisch beeld kent een X-as en een Y-as. De oorsprong van het assenstelsel ligt steeds in de linker bovenhoek en kent bijgevolg enkel positieve waarden. De X-as loopt van links naar rechts. De Y-as loopt van boven naar onder. Dit is het assenstelsel van de patiënt. Deze twee assen kennen via het Image Orientation attribuut elk hun eigen oriëntatie in het RCS. In figuur 1.8 vind u een eenvoudig voorbeeld van een afbeelding van 512 bij 512 pixels en waarvan de X- en Y-as toevallig samenvallen met de X- en Y-as van het RCS. Aanvullend werden ook de letters van de anatomische posities toegevoegd. Figuur 1.8: Patiënt assenselsel De afbeelding bestaat aldus uit een matrix van 512 rijen en kolommen. Linksboven is pixel (0, 0) en rechtsonder pixel (512, 512). Het patiëntenassenstelsel wordt in het rood weergegeven. De X-vector heeft als x-component één, wat neer komt op een hoek van 0. De y en z component zijn nul wat een hoek van 90 voorstelt. De X-vector heeft in dit voorbeeld dus dezelfde richting als de X-as in het RCS om de berekeningen zo simpel en duidelijk mogelijk

21 Hoofdstuk 1. Onderzoek 13 te houden. Bijgevolg kunnen we de letter R plaatsen in het begin van de X-as en de letter L op het einde. Analoog is de Y-vector evenwijdig met de Y-as in het RCS. Hierdoor kan de letter A in het begin van de Y-as geplaatst worden en de letter P op het einde plaatsen. De twee andere letters kunnen niet geplaatst worden aangezien het kijkvlak loodrecht op de Z-as valt. In dit geval zou de letter F voor het scherm vallen en de letter H achter het scherm. Bijgevolg kan er met zekerheid gesteld worden dat het beeld bekeken wordt vanaf de voeten van de patiënt en niet vanaf het hoofd. Indien het beeld weergegeven wordt in het vorige RCS moet dit 180 geroteerd worden rond de X-as om te voldoen aan de richtingsvectoren. Het resultaat wordt weergeven in volgende figuur 1.9. Figuur 1.9: Voorbeeld van patiëntassenselsel in RCS De gele X- en Y-vectoren tonen de richting aan van het assenstelsel van de patiënt. Deze lopen in dit eenvoudig voorbeeld zoals eerder vernoemd, evenwijdig met de X- en Y-as van

22 Hoofdstuk 1. Onderzoek 14 het RCS. Aangezien het beeld steeds wordt weergegeven met de oorsprong in de linkerbovenhoek, kan de kijkrichting van de gebruiker niet anders zijn dan van onder aan de voeten naar boven kijkend. Het anterieur (voorkant) van de patient bevindt zich aan de bovenkant van het beeld en het posterieur (achterkant) aan de onderkant. Op de figuur 1.9 staat de kijkrichting aangeduid met het oogje. Op deze manier is het mogelijk om elk 2D beeld een ruimtelijke positie te geven in het 3D RCS. Aangezien de positie vaak relatief is ten opzichte van de DICOM modaliteit en niet van de patiënt zelf, wordt deze techniek enkel gebruikt bij studies met meerdere afbeeldingen die werden genomen met dezelfde modaliteit en waarbij de patiënt zich niet verplaatst, of bij een serie van beelden. 1.3 Delen van data tussen apps Dit project hangt nauw samen met een ander project waarin een app wordt geschreven die zorgt voor de acquisitie van een deel van de beelden. Het kan handig of soms zelfs noodzakelijk zijn dat deze beide applicaties bepaalde gegevens zoals login gegevens of beelden rechtstreeks kunnen delen. Historisch gezien heeft ios altijd geprobeerd om het delen van data tussen applicaties te verhinderen. De oorspronkelijke doelstelling was de toegang tot andere applicaties te verhinderen zodat er geen ongeoorloofde acties kunnen gebeuren. Deze visie werd sinds de recentere versies versoepeld en laten nu enkele methoden toe om gegevens te delen. Deze verschillende methoden worden verder opgesomd en verklaard Webservice De eerste en misschien ook meest logische manier om gegevens te delen tussen applicaties is het gebruik van een externe webservice. Hiervoor dienen beide applicaties uiteraard wel te beschikken over een internetverbinding. Zo kan een webservice opgestart worden in de cloud waar alle gegevens bewaard worden. Beide applicaties kunnen vervolgens gegevens aan de service leveren of opvragen. Dobco Medical Systems beschikt reeds over zo een webservice die werkt via het HTTPprotocol. Hierop worden gegevens bewaard zoals de patiënt gegevens, onderzoeksgegevens, logingegevens en de beelden. De structuur van deze gegevens en de webservice worden verder besproken in sectie 1.4.

23 Hoofdstuk 1. Onderzoek Shared Keychain De keychain in ios biedt de mogelijkheid om gegevens zoals wachtwoorden, sleutels, certificaten of andere gevoelige data beveiligd op te slaan. Een gebruiker kan via één enkel wachtwoord een keychain ontgrendelen en vervolgens bewaarde gegevens ophalen of wijzigen. Elke keychain kent een accessgroup die bepaalt tot welke groep applicaties hij behoort. Elke applicatie die zich vervolgens registreert voor deze accessgroup kan deze keychain oproepen. Deze methode kan vooral gebruikt worden voor het delen van gevoelige data tussen applicaties maar zou ook gebruikt kunnen worden voor grotere data structuren. Achterliggend werkt de keychain namelijk op basis van een SQLite database die standaard strings toelaat met een lengte van maximaal 10 9 bytes. Het exacte aantal karakters wordt nergens vernoemd in de ios-documentatie Aangepaste URL schema s Applicaties die geregistreerd staan voor het ondersteunen van een aangepast URL schema kunnen deze schema s gebruiken voor het ontvangen van berichten. Apple voorziet zelf al enkele URL schema s voor de basis handelingen zoals het openen van websites, versturen van mails, starten van telefoongesprekken en versturen van SMS en. Wanneer het besturingssysteem een aanvraag ontvangt voor een bepaalde handeling start hij de geassocieerde app op en levert hij deze actie af. Aangezien de aanvragen steeds verstuurd worden als URL is de data afhankelijk van de maximum lengte van de URL. Deze maximale lengte wordt nergens gespecifieerd en is volgens de HTTP standaard enkel gelimiteerd door de afhandelende server. In praktijk is dit vermoedelijk net zoals bij de meeste populaire browsers minder dan 2000 karakters. Hierdoor is een aangepast URL schema niet de ideale keuze voor het delen van veel data tussen applicaties. Het kan echter wel handig worden gebruikt om andere apps op te starten vanuit een app. Deze functie kan gebruikt worden samen met het UIPasteboard UIPasteboard De UIPasteboard klasse wordt gebruikt om gegevens te delen met de app zelf of andere apps. Via globale pasteboards kan data gedeeld worden met om het even welke app. Om pasteboards te delen met een andere app van dezelfde ontwikkelaar dienen aangepaste UIPasteboards te worden gebruikt. Wanneer een object wordt geschreven naar een pasteboard, wordt dit opgeslagen als een pasteboard item. Dit pastboard item bevat een of meerdere sleutel-waarde paren waar de

24 Hoofdstuk 1. Onderzoek 16 sleutel het type omschrijft van de waarde. Zo is het mogelijk om elk soort object in een of meerdere formaten te delen. Een pasteboard kan ook aangeduid staan als persistent waardoor het object zelfs na afsluiten van de applicatie of heropstarten van het toestel zal blijven bestaan. Het delen van gegevens via de UIPasteboard klasse kent geen beperkingen wat de grootte van de data betreft. Hierdoor is het de uitgewezen manier voor het delen van gegevens tussen applicaties die lokaal geinstalleerd zijn op het toestel. In samenwerking met de aangepaste URL schema s kan deze functionaliteit nog versterkt worden. Een app kan een andere app oproepen via een aangepast URL schema en hierin de naam van het pasteboard verwerken waarin de te delen data zich bevindt. Ook de eventuele actie die moet gebeuren op de data kan verwerkt worden in deze URL Conclusie In de uiteindelijke implementatie werd enkel gebruik gemaakt van een webservice voor het delen van gegevens. Dit komt doordat de enige data die moet worden gedeeld tussen de applicatie afkomstig is van de pacsonweb service. Het voorzien van een single sign-on is voor de twee applicaties niet van toepassing aangezien deze elk hun eigen gebruikersgroep kennen en er slechts in zeer uitzonderlijke gevallen een overlapping is van de gebruikersgroepen. Een eventuele uitbereiding is de mogelijkheid om beelden offline te kunnen delen tussen de apps. Zo kunnen de beelden die verkregen werden via de ene app, bekeken worden via de andere. Voor deze functionaliteit was echter geen tijd meer voorzien om deze te implementeren in de beide projecten. 1.4 PacsOnWeb PacsOnWeb is de webapplicatie gecreëerd door het bedrijf Dobco Medical Systems, die het mogelijk maakt om via de browser medische beelden te bekijken en te manipuleren. De applicatie zorgt er voor dat de beelden online beschikbaar worden gesteld en het niet meer nodig is de beelden af te drukken of te branden op een CD. Patiënten kunnen medische beelden laten nemen bij aangesloten radiologen of ziekenhuizen en daarna deze beelden zelf bekijken. De patiënt kan deze ook laten bekijken door hun arts. Dit gebeurt via een persoonlijke code en de geboortedatum van de patiënt. Artsen hebben vaak een eigen account waarmee ze toegang hebben tot al hun aangevraagde studies en de studies waartoe zij toegang hebben gekregen door de patiënt zelf. Tijdens het

25 Hoofdstuk 1. Onderzoek 17 inloggen krijgt de arts dus een lijst te zien van alle studies waar hij recht op heeft Structuur van de gegevens De structuur van het PacsOnWeb programma is hiërarchisch en kent als bovenste laag een study. Een study kan op zijn beurt verschillende series bevatten en een serie kan verschillende images of beelden bevatten. Een Study is een groepering van series met beelden van een patiënt. Het bevat volgende belangrijke attributen: ID - Identificatie van de study is enkel uniek binnen de database, niet binnen de volledige applicatie Source ID - Identificatie van de databank waarop de beelden bewaard worden. Patiënt gegevens - Alle gegevens over de patiënt zoals zijn naam, geslacht en geboortedatum Requesting Physician ID - Eventuele identificatie van de aanvragende arts van deze study Series table - Een array van serie-objecten Andere gegevens over de study zoals de aanmaak datum, de radioloog of ziekenhuis waar de beelden werden genomen en het accession number. Serie is een groepering van één of meerdere beelden van hetzelfde object. Het bevat volgende belangrijke attributen: ID - Identificatie van de serie Series Number - Ordernummer van de serie Procedure - Gegevens over de procedure en de modaliteit waarmee de beelden genomen zijn Images table - Een array van image of beeldobjecten Image is een beeld met bijhorende DICOM informatie ID - Identificatie van het beeld Filename - Bestandsnaam van het beeld Image Number - Ordernummer van het beeld

26 Hoofdstuk 1. Onderzoek 18 Width & Height - Breedte en hoogte in pixels van het beeld op zijn volledige grootte Imate Data - Een array met alle nodig DICOM headers: Pixel Spacing, Bits Stored, Pixel Representation, Window Center, Window Width, Rescale Intercept & Slope, Slice Spacing & Thickness, Photometric Interpretation, Image Position, Image Orientation en LUT-Data. Al deze gegevens zullen verder worden gebruikt en uitgelegd in hoeverre dit nog niet zou gebeurd zijn. 1.5 Bewaren van extra grijswaarden via PNG PNG (Portable Network Graphics) is een bestandsformaat voor afbeeldingen met lossless compression waardoor er geen verlies van kwaliteit plaatsvindt tijdens de compressie. PNG gebruikt vier kanalen (fig. 1.10): Rode kanaal: schaling van de rode kleur Groene kanaal: schaling van de groene kleur Blauwe kanaal: schaling van de blauwe kleur Alfa kanaal: schaling van de doorzichtbaarheid Elke pixel houdt per kanaal een 8-bit, of een byte getal bij. Zo kunnen er 2 8 = 256 verschillende tinten bijgehouden worden voor elk kanaal en is het mogelijk om 2 24 = 16, 777, 216 verschillende kleuren weer te geven. Grijswaarden kunnen via PNG weergegeven worden door de drie kleur kanalen dezelfde waarde te geven. grijstint = r = g = b Hierdoor wordt het maximaal aantal grijswaarden beperkt tot 8-bit of 256 waarden. Een DICOM modaliteit kan echter beelden maken met maximaal 16-bit grijswaarden per pixel. Bijgevolg dienen er extra gegevens per pixel opgeslaan te worden zodat het PNG-formaat kan worden blijven gebruikt. Zoals reeds aangehaald kent het PNG formaat 4 kanalen. Elke pixel bewaart voor elk van die kanalen 8-bit aan informatie. In totaal bevat een pixel 32-bit aan gegevens, waarvan 24-bit aan kleurgegevens. Aangezien de DICOM beelden met extra grijswaarden geen kleur bevat is het niet nodig om drie verschillende kleurkanalen bij te houden. De kanalen kunnen samengenomen worden tot

27 Hoofdstuk 1. Onderzoek 19 Figuur 1.10: PNG kanalen een groot grijswaarden kanaal van 24-bit. Via deze methode is het mogelijk om meer dan 8-bit grijswaarden te bewaren in het PNG-formaat. Dit uiteraard ten koste van de kleur informatie Verdeling van de bits per kanaal De verdeling van de 16-bit grijswaarden zou perfect kunnen toegepast worden over slechts twee kanalen. Bijvoorbeeld de 8 MSB (Most Significant Bits) opslaan in het rode kanaal en de 8 overige LSB (Least Significant Bits) in het groene kanaal. Het blauwe kanaal wordt dan geïnitialiseerd met nullen. Deze methode is zeer simpel, maar geeft echter makkelijk artifacts of foute pixels tijdens het veranderen van de grootte van het beeld ten gevolge van interpolatie. Interpolatie is het uitbreiden van een reeks waarden met extra waarden die tussen de reeds gekende reeks waarden liggen. Een klein voorbeeld om dit te verduideiljken. Wanneer een fietser om 8 uur vertrekt, en 2 uur later volgens zijn fietscomputer 40 kilometer heeft afgelegd. Dan kan er van uit gegaan worden dat hij om 9 uur reeds 20 kilometer had afgelegd, indien hij een constante snelheid behield. Bij beelden zijn er verschillende mogelijkheden om interpolatie toe te passen wanneer de beelden van grootte veranderen. Bij het vergroten van het beeld moeten er extra pixels berekend worden. Bij het verkleinen van het beeld moeten verschillende pixels samengenomen worden tot een pixel.

28 Hoofdstuk 1. Onderzoek 20 De precieze verdeling van de bits is know how van het bedrijf Dobco Medical Systems. Bijgevolg mag de bitverdeling niet verder verklaard worden in deze thesis.

29 Hoofdstuk 2 Technologieën 2.1 ios ios is een op unix (Darwin, BSD) gebaseerd, mobiel besturingssysteem ontworpen door Apple Inc. en wordt exclusief gedistribueerd voor mobiele Apple toestellen. De laatste versie van het besturingssysteem is ios 7.1. Het besturingssysteem laat ontwikkelaars toe applicaties te schrijven voor de toestellen via hun SDK en deze achteraf, na goedkeuring door Apple, te publiceren voor het grote publiek op de App Store. Deze applicaties dienen geschreven te worden in C, C++ of Objective-C Objective-C Objective-C is een objectgeoriënteerde programmeertaal ontworpen in 1983 en werd beroemd door NeXT, het computerbedrijf dat werd opgericht door Steve Jobs na zijn vertrek bij Apple. Vanaf de overname door Apple in 1997 werd objective-c gebruikt voor het programmeren van Apple s Mac OSX besturingssysteem en later ook voor het mobiele iphone OS en ios besturingssysteem. Objective-C is slechts een dunne laag bovenop de C -taal. Hierdoor is het geen enkel probleem om een programma geschreven in C, te compileren via een Objective-C compiler of, om C code te implementeren in een Objective-C klasse. De syntax voor operaties op objecten in Objective-C is gebaseerd op de syntax van Smalltalk en lijkt wat abnormaal voor vele ontwikkelaars. Alle andere operaties vloeien voort uit de gewone C -taal en behouden hun syntax Berichten Het Objective-C model is gebaseerd op het versturen van berichten tussen objecten of instanties van objecten. Er worden dus geen methodes opgeroepen, maar er worden berichten 21

30 Hoofdstuk 2. Technologieën 22 verstuurd. Dit is een klein nuanceverschil, maar zorgt er voor dat een methodenaam niet gekoppeld wordt aan een klasse door de compiler, maar dat at runtime het ontvangende object het bericht interpreteert. Net als in de C -taal werkt Objective-C via pointers naar objecten. Indien er een bericht moet worden gestuurd naar een object gebeurt dit via volgende syntax: [object methode:argument] Via bovenstaande syntax kan een argument worden meegegeven. Meerdere argumenten meegeven gebeurt op de volgende manier: [object methodemetargument1:arg1 enargument2:arg2 enmetdatum:date] Het versturen van een bericht gebeurt dus steeds tussen vierkante haken ([ ]). Het begint met de verwijzing naar het ontvangende object, gevolgd door de op te roepen methode. De twee delen worden gesplitst via een spatie. Ook de initialisatie van de methoden wordt aangepast: - (void)methodemetargument1:(data type)arg1 enargument2:(data type)arg2{} Hierbij wordt eerst aangegeven of de methode statisch (+) of dynamisch (-) is. Dan volgt tussen haakjes het datatype van de return waarde en, na het sluiten van de haakjes, de methodenaam. Voor elk argument komt een dubbel punt (:) gevolgd met het datatype van het argument tussen haakjes en de lokale naam van de parameter. De syntax voelt in eerste instantie wat raar aan, maar verhoogt wel de leesbaarheid van de code Constanten Enkele constanten in Objective-C worden iets anders genoemd dan in de meeste programmeertalen. Hieronder volgt een lijst van de drie constanten met een iet wat bizarre naamgeving: self: pointer naar de instantie van het huidige object. Wordt in vele talen this genoemd. YES: De boolse waarde 1 of waar NO: De boolse waarde 0 of niet waar Objective-C API s Objective-C kent twee grote Application Programming Interfaces (API): Cocoa is de API voor het OSX -besturingssysteem,

31 Hoofdstuk 2. Technologieën 23 Cocoa Touch is de API voor het mobiele besturingssysteem ios. Beiden bevatten frameworks die gebruikt kunnen worden voor het programmeren van Apple applicaties Cocoa Cocoa bevat drie frameworks: Foundation Kit: gebaseerd op Core Foundation (CF) voor cross-platform applicaties, bevat string en waarde manipulaties, containers en iteraties en nog veel meer elementen die niet gebonden zijn aan de Graphical User Interface (GUI). Alle klassen en interfaces in dit framework beginnen met de NS-prefix. Application Kit: bevat code die gebruikt kan worden om GUI s voor OSX te creëren. Core Data: is het framework dat zorgt voor de persistentie van gegevens door het opslaan van gegevens volgens een relationeel model naar een XML-, binair- of SQLite bestand. De Cocoa API kan dus enkel gebruikt worden voor OSX, toch wordt het hier vermeld aangezien het de basis vormt voor de mobiele API: Cocoa Touch Cocoa Touch Cocoa Touch is de mobiele API in objective-c die via zijn vele frameworks zorgt voor een extra abstractie voor het programmeren van mobiele applicaties voor ios. De frameworks helpen bijvoorbeeld bij de toegang tot de GPS en de camera, maar ook bij het grafische aspect, de netwerkoperaties of het afspelen van audio. Cocoa Touch is gebaseerd op de desktop API Cocoa en erft er alle frameworks van over, behalve de Application Kit die specifiek gebruikt wordt voor de GUI van OSX applicaties. Verder werden nog enkele andere frameworks toegevoegd die specifiek zijn voor de mobiele toestellen. Hieronder volgt een lijst van de belangrijkste: UIKit: bevat code die gebruikt kan worden om de verschillende User Interface (UI) elementen te creëeren Core Audio: wordt gebruikt om handelingen op geluid uit te voeren Core Animation: kan eenvoudig 2D en 3D animaties genereren tussen grafische layers Core Location: maakt het mogelijk de locatie te bepalen via WiFi, telefoonmasten of GPS

32 Hoofdstuk 2. Technologieën 24 WebKit: zorgt voor het renderen van webpagina s Via Cocoa Touch kan de ontwikkelaar zich bijgevolg meer bezighouden met het programmeren op een hoger en toegankelijker niveau. 2.2 HTTP Hypertext Transfer Protocol (HTTP) is het protocol voor de communicatie tussen een webclient en een webserver. Het protocol legt vast welke aanvragen een client kan stellen en welke antwoorden een server daarop kan geven HTTP Requests Een HTTP Request bestaat uit een request methode, een URL en een optionele inhoud. Er zijn 6 soorten HTTP request methoden: GET POST PUT DELETE HEAD OPTIONS Daarvan worden de eerste twee het meest gebruikt in browsers en ook in dit project. Een GET request doet een aanvraag aan de server via een URL voor een bepaalde resource. De URL is een hiërarchische structuur voor de server en kan ook extra invoerparameters bevatten via de QueryString. Deze komt op het einde van de URL en begint steeds met een vraagteken. Een POST request kan nog extra data bevatten in de vorm van postdata die bewaard worden in de body van zijn pakket. Deze soort van aanvraag wordt het vaakst gebruikt om extra parameters mee te sturen naar de server, zoals bijvoorbeeld bij formulieren HTTP Responses Een HTTP Response bestaat uit een resultaatcode, headervelden en een body of inhoud. Deze inhoud zal vaak bestaan uit HTML of JSON.

33 Hoofdstuk 2. Technologieën 25 De HTTP-pakketten kunnen op eenvoudig wijze bekeken worden via software zoals Wireshark. Deze software leest alle pakketten uit die verzonden en ontvangen worden via de netwerk interface van de computer. De tool is zeer handig tijdens het debuggen van applicaties die communiceren over het netwerk. 2.3 ASP.NET ASP.NET is een manier om op een webserver dynamische webpagina s aan te maken met behulp van programmacode. Hiermee kunnen vaste HTML-codes gecombineerd worden met variabele inhoud die door een programma wordt geproduceerd ASP.NET Authentication Authenticatie is het proces waarbij ontvangen credentials, bijvoorbeeld naam en wachtwoord, gevalideerd worden bij een of andere autoriteit. Indien de credentials geldig zijn, wordt de gebruiker beschouwd als geauthenticeerd en kan hij de resources waar hij toegang tot heeft opvragen. ASP.NET implementeert authenticatie via authentication providers, dit zijn de modules die de code bevatten om de credentials van de aanvrager te authenticeren Forms Authentication Provider PacsOnWeb maakt gebruik van de Forms Authentication Provider. Dit laat toe dat een gebruiker zich kan authenticeren via een gebruikersnaam en wachtwoord die hij ingeeft in een loginformulier. Niet-geauthenticeerde HTTP requests worden doorgestuurd naar de loginpagina. Hier kan de gebruiker zijn credentials invullen in het formulier en achteraf doorsturen naar de server. Indien de server de gebruiker kan authenticeren, genereert hij een token of unieke sleutel waarmee de gebruiker zich bij aanvragen kan authenticeren. De token die de gebruiker ontvangt na het inloggen moet bij iedere HTTP request meegestuurd worden naar de server. Zo kan de server de request authenticeren en de resources waar de gebruiker toegang tot heeft bepalen. In principe zou men telkens de credentials kunnen doorsturen bij elke request. Dit is echter bad practice omdat het HTTP protocol standaard geen beveiliging voorziet, zoals verder wordt uitgelegd in 2.4. Verder zou de browser de plain text van de gebruikersnaam en het wachtwoord moeten bijhouden, wat opnieuw een risico met zich mee brengt. Door te werken met een unieke sleutel dienen de credentials (master key) slechts eenmalig doorgestuurd te worden. Achteraf wordt verder gewerkt met de gegenereerde sleutel of token (session key). Indien achteraf de session key gecompromitteerd zou zijn is de master key nog

34 Hoofdstuk 2. Technologieën 26 steeds geldig en kan de session key gewoon verwijderd worden. Nu dient de gebruiker zich enkel opnieuw te authenticeren met zijn credentials om een nieuwe unieke sleutel of session key te ontvangen. ASPXAUTH De implementatie van het bewaren en doorsturen van de token of unieke sleutel in de browser gebeurt via de ASPXAUTH cookie. Een cookie is een key-value object dat client-side wordt bewaard en wordt doorgestuurd in de header van elke HTTP request. De ideale oplossing dus voor dit probleem. Een cookie kent ook een expiration date, wanneer deze bereikt is dient de browser de cookie te verwijderen uit zijn cookiestore. Ook ASP.NET zal de token verwijderen uit zijn lijst van huidige ingelogde gebruikers. Werking van Forms Authentication Zoals reeds verteld werd zal bij Forms Authentication een requester, bijvoorbeeld een browser, proberen zich te authenticeren bij een server. Het communicatieprotocol dat hier gebruikt wordt is HTTP. In onderstaande figuur 2.1 wordt de loop van de communicatie verduidelijkt. Figuur 2.1: ASP.NET Forms Authentication procedure De tabel 2.1 geeft wat meer uitleg bij de figuur 2.1.

35 Hoofdstuk 2. Technologieën 27 Tabel 2.1: ASP.NET Forms Authentication procedure Handeling van browser of andere client Aanvraag voor een beschermde resource van de server. GET /page.aspx Volgt de doorverwijzing. Gaat de loginpagina opvragen. GET /login.aspx?returnurl=/page.aspx Nadat de gebruiker zijn credentials heeft ingevuld worden deze verstuurd. POST /login.aspx?returnurl=/page.aspx Volgt terug de doorverwijzing en vraagt de originele opgevraagde pagina op. GET /page.aspx Antwoord van de server Er is nog geen authenticatiecookie of token. De server zal verwijzen naar de loginpagina zodat de gebruiker zijn credentials kan doorsturen. De originele pagina wordt bewaard in de URL. 302 Found Location: /login.aspx?returnurl=/page.aspx Antwoordt met de login pagina. 200 OK Controleert of de credentials correct zijn en verwijst de client door naar de origineel opgevraagde pagina. Standaard wordt het authenticatieticket meegestuurd als cookie, maar er kan ook gekozen worden om het via de URL door te sturen. 302 Found Location: /page.aspx Controleert de authenticatie van de gebruiker via de ontvangen authenticatiecookie. Het is nu mogelijk de cookie persistent te maken voor de client zodat hij ingelogd blijft bij volgende pagina s. 200 OK Set-Cookie: ASPXAUTH=xyz32;Path=/ Andere ASP.NET elementen In ASP.NET zijn er nog enkele andere belangrijke elementen die vaak mee verstuurd moeten worden bij aanvragen tot authenticatie. ASP.NET session state is een technologie die ontworpen is om server-side gegevens bij te

36 Hoofdstuk 2. Technologieën 28 houden over een specifieke gebruiker terwijl hij surft tussen verschillende pagina s. Een session state gebruiker wordt geïdentificeerd door een session ID. De technologie kan bijvoorbeeld gebruikt worden om gebruikersvoorkeuren of handelingen te bewaren. Het principe werkt via een cookie of querystring die de browser bij elke aanvraag meestuurt. Wanneer een gebruiker voor de eerste keer naar een pagina surft die gebruik maakt van ASP.NET session state, wordt een cookie teruggestuurd naar de browser met als naam ASP.NET SessionId en als waarde een unieke string van twintig tekens. De string bestaat enkel uit URL-safe karakters zodat er geen URL-encodering hoeft plaats te vinden. Wanneer de gebruiker later opnieuw naar een pagina surft binnen hetzelfde DNS-domein dan zal de cookie opnieuw meegestuurd worden en kan de server achterhalen wat de historiek is van deze session ID. Viewstate is een eenvoudige string met de staat van bepaalde elementen, geëncrypteerd via het Base64 encryptie algoritme. De Base64 string kan achteraf eenvoudig opnieuw gedecodeerd worden via het analoge Base64 decryptie algoritme om de originele string te bekomen. De view state wordt in ASP.NET gebruikt om de staat van de pagina persistent te houden tussen verschillende postbacks. Die komen enkel voor bij formulieren. Daarom wordt de view state bewaard in het formulier als een hidden field. De view state houdt de staat niet bij van te berekenen elementen, maar enkel van programmatische veranderingen aan de pagina. Zo kan na de postback de staat van het element opnieuw opgesteld worden door de view state te analyseren. 2.4 SSL en TLS SSL (Secure Sockets Layer) en zijn opvolger TLS (Transport Layer Security) zijn encryptieprotocollen die ontworpen zijn om beveiligde verbindigen te leggen over het internet. Het protocol maakt gebruik van X.509-certificaten om de tegenpartij van de communicatie een symmetrische sleutel te bezorgen. Deze sessiesleutel zal kortstondig gebruikt worden om alle communicatie te beveiligen tussen de eindpunten, tot het einde van de sessie. Indien verder gecommuniceerd wil worden moet er eerst een nieuwe sessiesleutel uitgewisseld worden. X.509-certificaten zijn bestanden die de authenticatie van een bepaalde instantie garanderen via publieke sleutel encryptie. Beide eindpunten moeten daarvoor eenzelfde CA (Certificaat Autoriteit) vertrouwen, zodat ze een relatie kunnen leggen tussen het ontvangen certificaat en zijn eigenaar. Indien de relatie klopt volgens de certificaat autoriteit, en de certificaat autoriteit te vertrouwen is, kan men ervan uitgaan dat het certificaat klopt en de eigenaar effectief is wie hij beweert te zijn.

37 Hoofdstuk 2. Technologieën 29 SSL of TLS werkt juist onder het applicatieniveau en bovenop de transportlaag. Hierdoor kan het onveilige protocollen als HTTP, FTP en SMTP beveiligen. Het zorgt voor de beveiliging van toepassingen zoals surfen, en, internet faxen, VoIP en nog vele anderen.

38 Hoofdstuk 3 Applicatie 3.1 Inloggen op secure.pacsonweb.com PacsOnWeb is een webapplicatie die geschreven is in ASP.NET. Alle gegevens worden daarbij opgevraagd via HTTP requests naar de server. De server antwoordt op zijn beurt via HTTP responses. Het antwoord zal in de meeste gevallen HTML terugsturen, maar het kan ook JSON-data of bestanden en beelden teruggeven HTTP protocol Wegens de eis die gesteld werd om de back-end zo weinig mogelijk aan te passen, zit er niets anders op dan een browser te imiteren via het mobiele toestel. Om dit te doen moet men via objective-c dezelfde HTTP requests creëren als een browser zou doen. Verder moet het mogelijk zijn stukken uit HTTP responses te parsen in geval er HTML of JSON teruggestuurd werd. Meer info over deze technologie werd reeds gegeven in punt 2.2 op pagina Beveiliging van de pakketten Een pijnpunt van het HTTP-protocol is de beveiliging. De HTTP requests en responses worden telkens verstuurd in HTTP-pakketten. Die bestaan altijd uit een header, soms gevolgd door de body of inhoud. De header bevat informatie over het pakket zoals de soort aanvraag, URL, cookies, gebruikte browser, antwoordstatus,.... De body bevat de uiteindelijke opgevraagde informatie of in geval van een POST request, de extra parameters. Deze verstuurde pakketten worden echter niet gecodeerd. Elk pakket kan dus onderschept worden, terug samengesteld worden en volledig uitgelezen worden. Wanneer men credentials of andere gevoelige data wil versturen naar de loginserver is de data leesbaar terug te vinden in het pakket. Voor ervaren informatici is dit zeer eenvoudig te onderscheppen. 30

39 Hoofdstuk 3. Applicatie 31 De oplossing lijkt eenvoudig: encrypteer elk HTTP pakket alvorens het te versturen over het netwerk zodat het pakket niet leesbaar is zonder de correcte encryptiesleutel te kennen. Deze beveiligingstechniek kan verwezelijkt worden met SSL (2.4, p28). Deze techniek vermengd met HTTP wordt afgekort als HTTPS De technologie De gebruikte technologie voor het controleren en beheren van de gebruikeraccounts is ASP.NET Forms Authentication. De werking van deze technologie staat reeds beschreven in 2.3 op pagina Implementatie in ios Het doel is, zoals eerder reeds vernoemd werd, om in te loggen op com. Echter niet via de browser, maar wel programmatisch via het mobiele toestel dat werkt op het ios-besturingssysteem. Objective-c gebruikt de NSURLConnection klasse, of sinds ios7 zijn opvolger NSURLSession om HTTP requests te versturen en HTTP responses te ontvangen. De klassen kunnen beiden omgaan met alle requestmethoden van het HTTP protocol en bewaren de cookies per applicatie. Ze zijn bijgevolg ideaal om een browser te immiteren NSURLConnection De NSURLConnection klasse heeft een beperkte toolset. Je kan er requests mee sturen en responses ontvangen. Connecties kunnen enkel geannuleerd worden. NSURLConnection verwijst eigenlijk naar een groep van onderling gerelateerde componenten die het Foundation URL Loading System vormen: NSURLRequest, NSURLResponse, NSURLProtocol, NSURLCache, NSHTTPCookieStorage, NSURLCredentialStorage en uiteraard NSURLConnection zelf. Om een connectie te maken wordt een NSURLRequest object doorgegeven aan een NSURL- Connection object. Die deligeert de asynchrone verwerking van het NSURLResponse object naar een klasse die de NSURLConnectionDelegate en NSURLConnectionDataDelegate protocollen implementeert. Synchroon vs. Asynchroon NSURLConnection kan aanvragen zowel in de main thread (synchroon), als in een background thread (asynchroon) verwerken. Aangezien netwerkaanvragen soms enige tijd in beslag kunnen nemen wordt slechts zelden data synchroon verstuurd of ontvangen, anders wordt de huidige

40 Hoofdstuk 3. Applicatie 32 UI geblokkeerd tijdens het wachten op een antwoord. Het voordeel is dat antwoorden niet moeten worden gedeligeerd, maar direct kunnen worden verwerkt. Bij asynchrone aanvragen kan de gebruiker gerust verder werken met de applicatie terwijl de aanvraag wordt verwerkt. Eens het antwoord is ontvangen, dient het gedeligeerd te worden naar een klasse. Antwoorden deligeren naar een klasse kan tijdens het initialisatieproces via - initwithrequest:delegate:[startimmediately] of via de statische methode + connectionwithrequest:delegate: Het antwoord kan ook rechtstreeks afgehandeld worden in een handler via de methode + sendasynchronousrequest:queue:completionhandler De gedeligeerde klasse dient de NSURLConnectionDataDelegate interface te implementeren zodat de inkomende data en de vooruitgang kan verwerkt worden. Dit gebeurt via volgende methoden - connection:didreceivedata: - connection:didsendbodydata:totalbyteswritten:totalbytesexpectedtowrite: - connectiondidfinishloading: NSURLSession Een van de grootste veranderingen bij de ios7 en OS X 10.9 Mavericks update is de opvolger van NSURLConnection: NSURLSession. Een eerste voordeel van NSURLSession is de mogelijkheid om configuraties van de connectie zoals cache, protocol, cookies en credential beleid te bepalen per sessie, in plaats van deze te delen binnen de volledige applicatie. Zo kunnen delen van de applicatie volledig op zichzelf functioneren en andere netwerkinstellingen bevatten. Dit wordt geïmplementeerd door bij de initialisatie van elk NSURLSession object een NSURLSessionConfiguration object de nodige instellingen mee te geven als parameter. Een tweede vernieuwing zijn de NSURLSessionTask s. Deze objecten handelen het ophalen of versturen van de data af tussen de client en de server. NSURLSessionTask kan het best vergeleken worden met de oude NSURLConnection aangezien die ook verantwoordelijk is voor het ophalen van de data. Het grootste verschil is dat de delegate klasse voor alle NSURLSessionTasks van een bepaalde NSURLSession dezelfde zijn. Verder is NSURLSessionTask flexibeler dan zijn voorganger. Waar het vroeger enkel mogelijk was gestarte connecties te annuleren, kunnen deze nu via session tasks gepauzeerd worden om

41 Hoofdstuk 3. Applicatie 33 later te worden voort gezet. Ook werd het wat eenvoudiger om de progressie bij te houden van een down- of upload. Voor dit project zal er dus gebruik worden gemaakt van NSURLSession aangezien er vaak grote bestanden moeten worden gedownload en het handig is deze eventueel te kunnen pauzeren en verder zetten tijdens bijvoorbeeld een eventueel verlies van de internet connectie Login procedure secure.pacsonweb.com Nu gekend is hoe de connectie met de server kan worden gemaakt, dient de loginprocedure gevolgd te worden om succesvol te kunnen inloggen. De procedure loopt analoog als de standaard authenticatie procedure van ASP.NET die eerder werd toegelicht (2.3, p25). De procedure kan echter iets vereenvoudigd worden door rechtstreeks de loginpagina op te vragen en in te vullen. Na onderzoek van de loginpagina, blijkt dat er geen view state of andere hidden input forms zijn, waardoor de loginpagina zelf niet opgevraagd moet worden, maar de credentials rechtstreeks naar de server gestuurd kunnen worden via een POST pakket. De enige voorwaarde is dat de naam van de invoerformulierelementen, waar de credentials moeten ingevoerd worden, gekend is. Volgende elementen werden na het analyseren van de pakketten gevonden: UserName: de gebruikersnaam Password: het wachtwoord van de gebruiker RememberMe: true of false veld dat de sessie langer in stand kan houden Eens de credentials naar de server zijn doorgestuurd, verwijst hij terug naar de loginpagina. Hiermee kan echter niet gecontroleerd worden of de login correct was en een geldig ASPXAUTH cookie werd meegegeven. Om dit te verifiëren probeert men een pagina op te halen die enkel zichtbaar is wanneer er een correcte authenticatie is. Bij het correct ophalen van de pagina en als er bijgevolg geen verwijzing is van de server naar de loginpagina, kan men ervan uitgaan dat de gebruiker geauthenticeerd is bij de server Authenticatie via pincode Men kan dus enkel inloggen via pacsonweb indien men over de correcte credentials beschikt. Deze credentials bestaan uit een gebruikersnaam ( adres) en wachtwoord. Via de computer is dit snel en eenvoudig in te voeren, maar met een mobiel toestel duurt dit alweer iets langer. Om de gebruiksvriendelijkheid te verbeteren moet een andere, maar nog steeds veilige, procedure bedacht worden om in te inloggen.

42 Hoofdstuk 3. Applicatie 34 Een veilige en veel gebruikte methode is een pincode. Denk maar aan de mobiele bank applicaties, die in de meeste gevallen gebruik maakt van een pincode. Een groot voordeel van deze methode is dan ook dat de veiligheid exponentieel stijgt met het aantal gebruikte cijfers. Indien men vier cijfers gebruikt voor de pincode en er voor zorgt dat er maximaal vijf mislukte pogingen mogen voorkomen alvorens het account gelocked wordt, heeft een inbreker een kans 5 van 10,000 of 1 2,000 om de code te raden. Uiteraard met voorwaarde dat de gebruikte pincode zo willekeurig mogelijk gekozen werd. Indien men echter vijf cijfers gebruikt wordt deze kans 1 20,000. Daarom opteerde het bedrijf voor de veiligste optie en een vijf-cijferige pincode te gebruiken Beveiliging Aangezien het de wens van het bedrijf was om geen aanpassingen te moeten doen aan hun authenticatiemethode kan de pincode niet rechtstreeks gebruikt worden om de gebruiker te authenticeren. Daarvoor moet gebruik gemaakt worden van lokale accounts die de PacsOn- Web gebruikersnaam en wachtwoord bevatten, maar enkel toegankelijk zijn indien de correcte pincode gebruikt werd. Opslaan van de pincode De pincode moet op een of andere manier lokaal bewaard worden, maar mag op geen enkel moment onbeveiligd zichtbaar zijn voor onbevoegde gebruikers. Een van de eenvoudigste manieren die ios biedt om gegevens op te slaan zijn SQLite databases. Deze bieden de basishandelingen van gewone databases en zijn een pak eenvoudiger te bewerken dan het rechtstreeks gebruik van files. Dit is dan ook de reden dat de pincode zal bewaard worden in de SQLite database. Zoals eerder vermeld mag een pincode niet in zijn plain text worden opgeslaan, maar moet deze achteraf wel nog te vergelijken zijn met ingevoerde pincodes. Dit is dus de perfecte omschrijving voor het gebruik van een hashalgoritme. Hashalgoritmes zijn voorop vastgelegde algoritmes die toegepast worden op een bepaalde plain text en deze omzetten naar een unieke cipher text. Achteraf is het onmogelijk om de plain text uit de cipher text te halen. Daarom wordt deze methode ook wel one-way encryption genoemd. Uiteraard zal dezelfde plain text na het uitvoeren van het hashalgoritme steeds leiden tot dezelfde cipher text. De twee meest gebruikte hashalgoritmes zijn MD5 en SHA-1. MD5 wordt tegenwoordig beschouwd als verouderd en niet volledig veilig. SHA-1 is zijn opvolger en werkt met een iets

43 Hoofdstuk 3. Applicatie 35 langere digest als zijn voorhanger (160-bits) waardoor het nog veiliger is en dus geschikt voor het encrypteren van de pincodes. Bij het registreren van een pincode wordt het SHA-1 hashalgoritme toegepast op de pincode en wordt de digest bewaard in de database. Indien de gebruiker achteraf wenst in te loggen via zijn pincode, wordt opnieuw het hashalgoritme uitgevoerd op de ingevoerde pincode en vergelijkt de applicatie deze digest met de bewaarde digest in de databank. Indien deze dezelfde zijn mag men ervan uitgaan dat de correcte pincode werd ingevoerd. Een inbreker kan nu echter nog steeds de bewaarde digest ophalen en alle mogelijke pincodes via het SHA-1 hashalgoritme vergelijken met de bewaarde digest. Een van al de mogelijke pincodes zal zeker overeenkomen en kan hij gebruiken om in te loggen. De oplossing voor dit beveiligingslek is een niet-gekende sleutel toevoegen aan elke pincode alvorens het hashalgoritme te gebruiken. Deze niet-gekende sleutel kan een willekeurige waarde zijn, specifiek voor de applicatie, die hardgecodeerd bewaard kan worden in de code. Zolang de inbreker geen kennis heeft van deze sleutel, ook wel salt genoemd, kan hij onmogelijk de pincode achterhalen. Opslaan van de pacsonweb credentials Andere delicate gegevens die opgeslagen dienen te worden zijn de PacsOnWeb gebruikersnaam en wachtwoord. Het voordeel van deze credentials is dat wanneer er slechts een van de twee gekend is, het nog steeds niet mogelijk is om in te loggen. Daarom is het voldoende om enkel het wachtwoord te encrypteren en kan de gebruikersnaam in plain text bewaard worden om achteraf te zorgen dat een gebruiker niet twee keer kan registreren onder dezelfde PacsOnWeb gebruikersnaam. Het wachtwoord dient dus in cipher text bewaard te worden, maar moet achteraf terug gedecrypteerd kunnen worden zodat het als credentials kan doorgestuurd worden naar de Pacs- OnWeb server. Er kan hier zeker geen gebruik gemaakt worden van een hashalgoritme, maar er moet een ander soort beveiligingsalgoritme gebruikt worden. Conventionele encryptie maakt gebruik van een encryptiesleutel waardoor het mogelijk is om bepaalde plain text te encrypteren en achteraf weer te decrypteren via dezelfde sleutel. Het nieuwe standaard conventioneel encryptiealgoritme AES-256, gebruikt een sleutel van 256 bits. Een goede manier om het wachtwoord te encrypteren. Als keuze van de sleutel zijn er twee mogelijkheden: 1. Een hardgecodeerde sleutel die enkel door de applicatie gekend is 2. De gebruiker vragen om een sleutel in te voeren

44 Hoofdstuk 3. Applicatie 36 Het voordeel van de eerste methode is zijn eenvoud. Iedere persoon die de hard gecodeerde sleutel kent kan echter alle wachtwoorden decrypteren. De tweede oplossing biedt een oplossing voor het nadeel van de hardgecodeerde sleutel. Door de gebruiker zelf een sleutel te laten invullen weet niemand, behalve de gebruiker zelf, hoe de cipher text gedecrypteerd moet worden. Bijgevolg krijgt deze methode de voorkeur op een hardgecodeerde sleutel. Het zou echter niet gebruiksvriendelijk zijn om de gebruiker bij elke inlogpoging een 256- bit sleutel te vragen. Gelukkig dient de gebruiker bij elke inlogpoging een pincode in te voeren. Deze pincode kan gebruikt worden als encryptiesleutel voor het wachtwoord. Nadat een gebruiker zijn pincode heeft ingevoerd kan men die controleren via de bewaarde pincode in de databank. Indien deze correct is wordt de pincode in plain text gebruikt als sleutel om het wachtwoord te decrypteren. Na de decryptie bekomt men terug de originele gebruikersnaam en wachtwoord in plain text om in te loggen op de PacsOnWeb server. De gebruiker dient bijgevolg slechts een vijfcijferige pincode in te voeren om al deze informatie op te halen en zich te authenticeren bij de pacsonweb server. Iets wat de gebruiksvriendelijkheid zeker ten goede komt. 3.2 Functies op beelden Eens de beelden opgehaald zijn moeten deze niet enkel gevisualiseerd worden, maar moet de doktor ook de mogelijkheid hebben om verschillende functies toe te passen op de beelden. Deze functies gaan van zeer logische en eenvoudige functies, zoals zoomen en verplaatsen, naar zeer complexe functies zoals window leveling. In wat volgt worden alle mogelijke functies toegelicht Metingen op de beelden Meten op de beelden is een functie die zeer handig en noodzakelijk is voor dokters. De bedoeling is om de absolute lengte te meten op de geschaalde beelden. Een direct probleem bij alle soorten metingen is de vingerdikte Vingerdikte Het meten op een mobiel toestel is het makkelijkst door het positioneren van twee vingers. Indien we echter gewoon de posities van de vingers gebruiken als begin en eindpunt van de meting, dan bevinden deze punten zich in het midden, onder de vingers. Hierdoor is het zeer moeilijk om de eindpunten precies aan te duiden.

45 Hoofdstuk 3. Applicatie 37 Indien het start- en eindpunt niet juist onder de vinger ligt, maar een vingerdikte ernaast dan zitten de punten niet verborgen onder de vingers. Hierbij ontstaan er drie nieuwe problemen: 1. Wat is de breedte van een vinger? 2. Hoeveel pixels is de breedte van een vinger? 3. Waar ligt het punt ten opzichte van de vinger? Het eerste probleem is redelijk eenvoudig en kan opgelost worden door verschillende diameters uit te proberen. Bij de test bleek dat twee centimeter diameter voor de breedste vinger, de duim, en wat extra speelruimte volstaat. Van zodra er twee vingers gedetecteerd worden, wordt bijgevolg een cirkel getekend rond beide vingers met een diameter van twee centimeter. Figuur 3.1: Voorbeeld van een meting op een beeld van een scan Om die cirkel te tekenen moet bepaald worden hoeveel pixels twee centimeter is. Dit hangt af van het toestel. Elk toestel heeft een DPI (Dots Per Inch) waarde voor zijn scherm. Meestal is dit een 160dpi, maar recentere schermen bieden tegenwoordig al makkelijk het dubbele. Eens de DPI gekend is kan hieruit het aantal pixels berekend worden. Aangezien 1 inch gelijk is aan 2.54 centimeter: pixels per centimeter = DP I 2.54 aantal pixels = 2 DP I 2.54 De DPI van het toestel wordt op het toestel als schaal bewaard en kan programmatisch opgehaald worden via de code in listing 3.1

46 Hoofdstuk 3. Applicatie 38 Listing 3.1: DPI van toestel ophalen in Objective-C float scale = 1; if([[uiscreen mainscreen] responstoselector:@selector(scale)]) { scale = [[UIScreen mainscreen] scale]; } float dpi = 160 * scale; De oriëntatie bepalen van het begin en startpunt t.o.v. de vinger is iets ingewikkelder. Eens de cirkel rond de vinger bepaald is, wordt het doel te achterhalen welk punt van die cirkel het beginpunt is (punten Z 1 en Z 2 ). Figuur 3.2 helpt bij de uitleg van de berekeningen voor deze punten. Figuur 3.2: Tekening voor de oriëntatie berekening van begin- en eindpunt Als invoer krijgen we twee touches T 1 en T 2 met elk hun x- en y-coördinaat. Deze geven elk de absolute positie van de aanrakingen binnen een bepaalde view. De straal r van de cirkel is uiteraard ook gekend, en is in dit geval 1cm.

47 Hoofdstuk 3. Applicatie 39 T 1 (T 1,x, T 1,y ) T 2 (T 2,x, T 2,y ) Gevraagd: de afstand tussen het begin- en eindpunt Z 1 en Z 2. Aangezien beide cirkels dezelfde straal hebben, zijn de driehoekjes even groot. Uit de tekening kunnen we het volgende afleiden: Z 1,x = T 1,x + x Z 1 = (3.1) Z 1,y = T 1,y + y Z 2,x = T 2,x x Z 2 = (3.2) Z 2,y = T 2,y y De twee kleine gearceerde driehoekjes zijn congruent en bovendien gelijkvormig met T 1 T 2 M. Dus is x = r cos α (3.3) y = r sin α In T 1 T 2 M kan α berekend worden cos α = T 1M T 1 T 2 ( ) Mx T 1,x α = Bgcos ( T 1 T 2 ) M x T 1,x = Bgcos (T1,x T 2,x ) 2 + (T 1,y T 2,y ) 2 (3.4) Analoog voor kan sinα berekend worden sin α = T 2M T 1 T 2 ( ) T 2,x M x α = Bgsin (T1,x T 2,x ) 2 + (T 1,y T 2,y ) 2 (3.5) Door α uit 3.4 en 3.5 te substitueren in 3.3 krijgen we de waarden x en y voor onze eindoplossingen Z 1 en Z 2 x = y = r(m x T 1,x ) (a c) 2 + (b d) 2 (3.6) r(t 2,x M x ) (a c) 2 + (b d) 2 Nu het begin- en eindpunt gekend zijn kunnen we de verschillende metingen eenvoudig berekenen.

48 Hoofdstuk 3. Applicatie Soorten metingen Er zijn twee mogelijke metingen die een arts wil uitvoeren op de beelden. De lengte meten van iets op het beeld, of de hoek meten tussen twee elementen. Het meten van een lengte wordt in het medisch milieu meestal uitgedrukt in millimeters, hoeken worden uitgedrukt in graden. Meten van lengte De mobiele app kan lengtes meten via drie verschillende functies: Lineaire lengte: meet de afstand tussen twee punten Circulaire lengte: meet de lengte van de diameter van een circel Trapsgewijze lengte: meet het verschil van de Y-componenten van twee punten Alle metingen via het mobiele toestel kunnen enkel de afstand in pixels berekenen op de zichtbare afbeelding, niet de fysische meting van het originele object. Uiteraard hangt de reëele grootte van een pixel af van de resolutie van de afbeelding. De DICOM header bevat gelukkig de grootte in milimeter van een pixel van dit object. Zo kan de reëele waarde eenvoudig berekend worden door te vermenigvuldigen met de afstand in pixels. Lineaire lengte moet enkel een lijn trekken tussen het begin- en eindpunt. De afstand tussen de twee punten kan berekend worden via de afstandsformule: d(p 1, p 2 ) = (x 1 x 2 ) 2 + (y 1 y 2 ) 2 (3.7) In Objective-C kan je een lijn tekenen door het pad van de lijn toe te voegen aan een layer zoals in listing 3.2. Eens de layer wordt toegevoegd aan een zichtbare view wordt de lijn ingekleurd. Listing 3.2: Lijn tekenen op een view in Objective-C //initialiseer een nieuwe layer CAShapeLayer *layer = [CAShapeLayer layer]; [layer setstrokecolor: [[UIColor greencolor] CGColor]]; [layer setlinewidth: 3.0f]; //Maak een nieuw path aan en teken daarop een lijn CGMutablePathRef path = CGPathCreateMutable(); CGPathMoveToPoint(path, NULL, p1.x, p1.y); CGPathAddLineToPoint(path, NULL, p2.x, p2.y); CGPathCloseSubpath(path);

49 Hoofdstuk 3. Applicatie 41 [layer setpath:path]; //voeg het path toe aan de layer CGPathRelease(path); [self.view.layer addsublayer: layer]; //voeg de layer toe aan de view Circulaire lengte berekent de diameter van de cirkel via de afstandsformule 3.7. Het middelpunt van de cirkel is het midden of het gemiddelde van het begin- en eindpunt. M x = x 1+x 2 2 M = M y = y 1+y 2 In Objective-C wordt een cirkel ook getekend op een path via de methode CGPathAddArc. Deze methode laten we een volledige boog van 2π rad tekenen zodat we een cirkel krijgen. In listing 3.3 wordt beschreven hoe dit gebeurt. Listing 3.3: Cirkel tekenen via een path in Objective-C //Maak een nieuw path aan en teken daarop een cirkel CGMutablePathRef path = CGPathCreateMutable(); CGPathAddArc(path, NULL, pcenter.x, pcenter.y, r, -M_PI_2, M_PI_2*3, NO); Het startpunt van de boog is bij π 2 en eindigt bij 3π 2 : een volledige cirkel. De laatste parameter van de methode bepaalt de cirkel al dan niet kloksgewijs getekend wordt. Trapsgewijze lengte berekent het hoogteverschil tussen het begin- en eindpunt. d(y 1, y 2 ) = abs(y 1 y 2 ) Om deze meting weer te geven in Objective-C moeten we een lijn tekenen zoals in de code van listing Meten van hoeken Het bedrijf beschouwde het meten van hoeken als uitbereiding. Er werden uiteindelijk andere prioriteiten gesteld waardoor deze functionaliteit niet geïmplementeerd werd in het eindresultaat Manipuleren van beelden Voor sommige functionaliteiten is het nodig om het beeld zelf te gaan manipuleren. Dit betekent dat er data nodig zijn van het beeld tot op het pixelniveau. Zo kan elke pixel individueel aangepast worden naar de wensen van de gebruiker. Bij het manipuleren van beelden moet het algoritme elke pixel ophalen en er een bewerking op toepassen. Dit kan vaak zeer snel gebeuren, maar moet, afhankelijk van de grootte van het

50 Hoofdstuk 3. Applicatie 42 beeld, soms zeer vaak herhaald worden. Kleinere beelden van bijvoorbeeld 100 pixels breed en 75 pixels hoog moeten de stap = 7500 keer herhalen. Voor een computer is dit snel berekend. Voor grotere beelden stijgt het aantal herhalingen kwadratisch. In realiteit zijn beelden van om en bij de 20MP (Mega Pixel) geen uitzondering. Dit vergt voor een moderne computer uiteraard enige verwerkingstijd. Bij het manipuleren van beelden wordt als parameter van de functie een schaling meegegeven die bepaalt hoeveel het beeld gemanipuleerd moet worden. Een van de meest gebruiksvriendelijke manieren voor de gebruiker om de schaling in te voeren is via de verplaatsing van zijn vinger. Uiteraard is er bij deze methode enige feedback nodig naar de gebruiker toe. Dit wil zeggen dat een voorbeeld, van wat de verplaatsing van de vinger zou teweeg brengen, visueel moet worden weergegeven. Het spreekt voor zich dat de vertraging tussen het verplaatsen van de vinger en het tonen van het resultaat op het scherm niet te groot mag zijn. Zoniet wordt dit zeer ongebruiksvriendelijk en zullen de frustraties bij de gebruiker niet lang uitblijven. Het menselijk oog kan ongeveer 10 tot 12 beelden onderscheiden per seconde. Bijgevolg is de maximale vertragingstijd, waarbij het gebruik van de functie nog vloeiend lijkt voor de gebruiker ongeveer 100 ms. Het is uiteraard gewenst om een hogere framerate te gebruiken van ongeveer 30 FPS (Frames per second) wat neer komt op een maximale delay van om en bij de 33 ms. Dit betekent dat het manipuleren van de afbeelding moet worden afgehandeld binnen die tijdspanne. Dit is perfect haalbaar voor kleinere afbeeldingen, maar wordt al snel een illusie voor grotere afbeeldingen. Hiervoor is een andere methode nodig dan de manipulatie op de volledige afbeelding toe te passen. Meestal is het echter niet nodig om de volledige afbeelding te manipuleren(fig. 3.3). Wanneer er bijvoorbeeld ingezoomd wordt op een gebied van de afbeelding, is het berekenen van het niet-zichtbare deel verloren moeite. Deze informatie zal op dat moment toch niet weergegeven worden op het scherm. Zo kan soms al een groot deel van het aantal te berekenen pixels verminderd worden. Wel moet er bij het verplaatsen of zoomen van de afbeelding een nieuwe afbeeldig berekend en weergegeven worden. De manipulatie wordt dus pas berekend op het moment dat er om deze informatie gevraagd wordt (fig. 3.4).

51 Hoofdstuk 3. Applicatie Figuur 3.3: Volledige afbeelding berekenen 43 Figuur 3.4: Enkel de view berekenen Blijft echter het probleem bestaan wanneer de afbeelding niet ingezoomd is. Alle pixels zijn in dit geval wel zichtbaar op het scherm. Hierdoor moeten nu toch alle pixels van de grote afbeelding berekend worden en kan er spijtig genoeg geen tijdswinst gemaakt worden via deze methode. Een belangrijke parameter van een beeldscherm is de resolutie. Een scherm kan altijd slechts een begrensd aantal pixels weergeven. Wanneer een afbeeldig met een grotere resolutie dan het scherm wordt weergegeven, worden sommige pixels samen genomen. Een nieuwe verbetering voor afbeeldingen met een grotere resolutie dan het scherm bestaat er in de afbeelding eerst te verkleinen naar dezelfde resolutie als die van het scherm. Achteraf kan het algoritme toegepast worden op de verkleinde afbeeldig. Dit betekent dat er op ieder moment maximum de schermresolutie aan pixels berekend dient te worden. Voor mobiele devices is het vaak geen probleem om dit sneller uit te voeren dan de maximale delay. Zo wordt voldaan aan de eis voor snelle feedback zodat de gebruiksvriendelijkheid gegarandeerd kan worden. De schermresolutie van ipads verschillen nogal qua leeftijd. De oudere ipad 2 heeft een 1024 x 768 resolutie ( 0.7MP) terwijl de nieuwere ipad retina s een 2048 x 1536 resolutie ( 3MP) heeft. Hierdoor is de winst in prestaties afhankelijk van het toestel. Oudere (en

52 Hoofdstuk 3. Applicatie 44 tragere) toestellen moeten zo maximaal slechts 2 tot 3% van het aantal pixels berekenen. Nieuwere (en snellere) toestellen moeten maximaal 12% van de pixels berekenen. Bij het implementeren van beide oplossingen wordt ervoor gezorgd dat de manipulatie enkel op de huidige zichtbare view uitgevoerd wordt. Dit betekent wel dat er opnieuw berekeningen moeten worden toegepast wanneer de view verandert. Liefst ook tijdens het verschuiven of zoomen zodat de gebruiker het beeld in de best mogelijke kwaliteit blijft zien tijdens de handelingen (fig. 3.5). Figuur 3.5: Enkel de view wordt op hoge kwaliteit gerendered Dit vraagt echter redelijk wat coördinatie van de view. Daarom kan het makkelijker zijn om de volledige afbeelding een keer te manipuleren, na de manipulatiehandeling van de gebruiker. Op dat moment is er toch iets meer tijd om die berekening in de achtergrond uit te voeren. Zodoende moeten er achteraf geen berekeningen meer uitgevoerd worden tijdens het verplaatsen en zoomen van het beeld. Oudere toestellen kunnen hierbij echter geheugen problemen vertonen waardoor deze toepassing niet op elk toestel mogelijk is Verplaatsen en zoomen Verplaatsen en zoomen in Objective-C kan zeer eenvoudig via een ScrollView. Deze ScrollView bevat een ImageView die op zijn beurt een UIImage object bevat (Listing 3.4). Zo

53 Hoofdstuk 3. Applicatie 45 zullen de UIPinchGestureRecognizer en UIPanGestureRecognizer delegates van de ScrollView resp. de zoom- en verplaatsingsacties afhandelen. Listing 3.4: Afbeelding in ScrollView laden UIScrollView *scrollview; UIImageView *imageview; - (void)viewdidload { [super viewdidload]; //afbeelding laden UIImage *image = [UIImage imagenamed: imagename]; //afbeelding toevoegen aan imageview imageview = [[UIImageView alloc] initwithimage: image]; //imageview toevoegen aan scrollview scrollview = [[UIScrollView alloc] init]; [scrollview addsubview: imageview]; } //vertel de scrollview de grootte van zijn nieuwe subview scrollview.contentsize = image.size;... De verplaatsing wordt gerealiseerd door de offset-positie van de ImageView te wijzigen via de x- en y-coördinaten van de actie. Met het zooming attribuut van de ScrollView aan te passen en het frame van de ScrollView naargelang te vergroten of te verkleinen, kan het zoomen worden uitgewerkt. Beide acties worden standaard afgehandeld door de ScrollView zelf. Er bestaan nog meerdere zooming en panning delegates die eventueel extra functionaliteit kunnen toevoegen aan de acties Window level Window level is de techniek die gebruikt wordt in de DICOM standaard om beelden met extra grijswaarden weer te geven. Het gaat de pixelwaarde van een DICOM bestand omzetten naar een pixelwaarde die het scherm kan weergeven. De pixels in een DICOM bestand kunnen tot

54 Hoofdstuk 3. Applicatie bit aan informatie bevatten, terwijl een scherm slechts 8-bit kan weergeven. Hiervoor is een transformatie van de pixel gegevens nodig. De techniek maakt gebruik van een venster (window) dat verschoven kan worden over het scala aan grijswaarden. Alle grijswaarden die binnen het venster vallen krijgen een grijstint. De waarden die erbuiten vallen zullen naargelang een witte of zwarte kleur krijgen. Om het venster te kunnen bepalen heeft het bijgevolg twee eigenschappen nodig: Center: geeft de positie aan van het midden van het venster Width: geeft de breedte van het venster weer Zoals reeds in het onderzoek besproken werd, zal er niet rechtstreeks worden gewerkt met DICOM beelden maar wordt er gebruik gemaakt van PNG-beelden met extra grijswaarden (1.5, p18). Deze beelden kunnen 10 tot 16-bit aan grijswaarden bevatten. Vooraleer window level toegepast kan worden, dient de originele 10- tot 16-bit waarde terug samengesteld te worden. Het aantal bewaarde bits wordt opgeslagen in de DICOM header en wordt mee gestuurd tijdens het ophalen van een onderzoek. Afhankelijk van het aantal bits wordt de minimale en maximale waarde berekend die een pixel kan aannemen. Deze waarden hebben we nodig om later de LUT op te stellen. Uiteraard moet er rekening gehouden worden met de DICOM headers. De minimale en maximale waardes zijn afhankelijk van pixel representation ( ), rescale slope en rescale intercept ( ). De code voor de berekeningen wordt verder uitgelegd in Eens het bereik van de waarden berekend werd, kan de LUT (LookUp Table) opgesteld worden. De tabel bepaalt voor elke mogelijke waarde van het bereik of de range (max min) de respectievelijke 8-bit grijswaarde. Dit hangt uiteraard af van de window level instellingen. Enkel de waarden binnen het venster mogen zichtbaar zijn. Alle pixels met een waarde buiten het venster worden zwart of wit weergegeven. Bijvoorbeeld een window center van 500 en een window width van 40 zal alle pixels met een waarde kleiner dan 480 (left border) als zwart weergeven en pixels met een waarde groter dan 520 (right border) als wit weergeven. Een concreet voorbeeld verduidelijkt de methode. Stel dat een 4-bit waarde moet worden omgezet naar een 2-bit waarde. Dit betekent dat de LUT tabel 2 4 = 16 groot is. Zijn minimale waarde is nul en zijn maximale waarde is 15. We nemen de center en de width van het window resp. 7 en 8. Dan wordt de tabel opgesteld als in volgende figuur 3.6.

55 Hoofdstuk 3. Applicatie 47 Figuur 3.6: voorbeeld hoe 4-bit LUT wordt omgezet naar 2-bit waardes via window level Alle LUT -waardes die buiten de window vallen krijgen de minimale of maximale waarde (resp. 0 of 3). De waarden binnen het window worden lineair verdeeld over de mogelijke 2 2 = 4 bits. Aangezien de width net twee keer zo groot is dan het aantal mogelijke bits komt elke bit ook twee keer voor in de window. Dit principe kan uitgebreid worden naar een LUT-tabel van 10- tot 16-bits en een verdeling van 8-bits. De code voor het opstellen van de LUT-tabel wordt verder uitgewerkt in punt op pagina 61. De volgende stap is het berekenen van de 10- tot 16-bit gegevens die opgeslagen zitten in de 3 RGB kanalen van de PNG-afbeelding. Zoals beschreven werd in het onderzoek (1.5, p18) dienen er enkele bitoperaties toegepast te worden op de drie kanalen om de originele 10- tot 16-bit waarde te reconstrueren: 1. Roteer het groene kanaal 8 bits naar links 2. Roteer het rode kanaal 4 bits naar links 3. Someer de 3 kanalen of in formulevorm orig data = (r << 4) + (g << 8) + b Aangezien de bits steeds in de meest significante posities worden bewaard is het bij waarden van minder dan 16-bit nodig om achteraf enkele posities naar rechts te roteren. move = 16 aantal bits orig data = (orig data >> move) Eens de pixel gegevens terug gereconstrueerd zijn, kan deze waarde ingevuld worden in de LUT en bekomt men de 8-bit grijswaarde terug die als nieuwe waarde in de pixel bewaard moeten worden. De Objective-C code wordt later verduidelijkt in punt Hoe de pixeldata uit de afbeelding werd gehaald en hoe deze achteraf weer kan worden opgeslagen in een UIImage, wordt ook verder besproken in 4.2 op pagina 59.

56 Hoofdstuk 3. Applicatie Stack scans Bepaalde DICOM modaliteiten hebben de mogelijkheid om doorsneden van de patiënt te fotograferen. De modaliteit maakt hierbij een groot aantal beelden die elk de doorsnede van een bepaalde positie weergeven. Alle beelden van het onderzoek samen noemt men een stack beelden. Het aantal beelden in een stack verschilt, maar kan meer dan 500 beelden bevatten. Deze speciale modaliteiten maken een 3D-beeld van de patiënt en kunnen bijgevolg een stack van 2D-beelden genereren vanuit verschillende standpunten. Wanneer de beelden achter elkaar geplaatst worden krijgt men de illusie door de patiënt te kunnen scrollen. Modaliteiten die deze functionaliteit kennen zijn ondermeer CT- en NMR-toestellen. De scans van deze toestellen worden vaak gebruikt bij het onderzoeken van de thorax, hersenen of gewrichten PacsOnWeb service De service die gebruikt wordt, kan enkel beeld per beeld doorsturen. Dit betekent dat er zeer veel verschillende requests naar de server dienen te gebeuren om zo elk beeld van de stack op te halen. Er zijn uiteraard nog andere methoden om een groot aantal beelden door te sturen. Volgende methoden werden onderzocht: Comprimeren van de beelden server-side, versturen over het netwerk en decomprimeren door de client, een grote mozaïek bouwen van alle beelden waardoor een zeer groot beeld verstuurd wordt met daarin alle beelden van de serie, de beelden versturen als een videostream, die op de client gedecodeerd kunnen worden, alle beelden als een grote bytestream doorsturen met in de header de byteposities van het begin en het einde van elke afbeelding. Welke van deze methoden het snelst en efficiëntst is, wordt momenteel nog onderzocht door het onderzoeksinstituut iminds. Het onderzoek wijst tot nu toe uit dat de methode om beeld per beeld te versturen via concurrente requests niet ver ligt van de optimale oplossing. Bijgevolg zal deze methode verder gebruikt worden in de mobiele applicatie. Bij deze methode kan de netwerkoperatie uiteraard enige tijd in beslag nemen bij grotere stacks. Het is echter mogelijk om concurrente of parallelle requests uit te voeren. Het maximaal aantal concurrente requests is afhankelijk van de beschikbare bandbreedte, maar na

57 Hoofdstuk 3. Applicatie 49 onderzoek bleek drie tot vier concurrente requests het meest efficiënt bij een 3G-verbinding. Dit hangt uiteraard af van verschillende factoren. Het is ook mogelijk ios zelf te laten bepalen wat op dat moment het beste aantal concurrente requests zijn. Dit gebeurt via een instelling van het sessie object. ios houdt dan rekening met het huidig aantal processen, de soort internetverbinding en nog enkel andere factoren. Via deze methode kon de snelheid om volledige stacks te downloaden soms verdubbeld worden Stack scrollen Het scrollen door de stack beelden moet voor de gebruiker zo vloeiend mogelijk gebeuren. Zoals reeds eerder werd toegelicht, komt dit neer op een framerate van minstens 30 FPS (zie 3.2.2). Om dit te verwezenlijken is het onmogelijk de beelden pas op te halen van de server op het moment dat er expliciet om gevraagd wordt. In het beste geval wordt een framerate van ongeveer 4 FPS gehaald. Bovendien worden de meeste stacks volledig bekeken door de gebruikers. Uiteraard is het op dat moment beter de stack ook lokaal te cachen, zodat bij een volgende oproep van de stack de beelden niet opnieuw moeten worden opgevraagd. De beelden op de server zullen ook nooit gewijzigd worden, daardoor moet er nooit gecontroleerd worden of een van de beelden veranderd is op de server. Hoe weet je dat een bepaalde reeks beelden zal bekeken worden, en wanneer is het beste moment om de beelden op te halen? Om deze vragen te beantwoorden dient er uiteraard rekening te worden gehouden met de hoge kosten van mobiel internet. Het zou mogelijk zijn de beelden reeds op te halen bij het selecteren van de studie, maar dan bestaat de kans nog steeds dat die serie niet bekeken wordt en is er bijgevolg te veel data opgehaald. Indien een studie slechts een serie bevat zou de serie die een stack van beelden bevat, reeds opgehaald kunnen worden. Het komt echter zeer zelden voor dat een studie van een stack scan slechts een serie bevat. Bijgevolg is het beste moment om een stack beelden op te halen, het moment waarop de stack serie geselecteerd wordt. Vanaf dat ogenblik kunnen de beelden in oplopende volgorde opgehaald worden van de server. De meest gebruiksvriendelijke manier laat de gebruiker toe te scrollen door de reeds opgehaalde beelden. Via een progress bar wordt de gebruiker dan toegelicht hoeveel beelden reeds opgehaald werden van de totale stack. Indien de gebruiker verandert van serie alvorens alle beelden opgehaald werden, moeten de overige nog niet opgehaalde beelden geannuleerd worden om dataoverdracht te beperken. Wanneer dezelfde serie later opnieuw geselecteerd wordt kan men het downloaden hervatten vanaf de positie waar gestopt werd. Doordat de beelden sowieso lokaal bewaard worden, loont het de moeite ze direct op te halen met hun extra grijswaardeninformatie. Het is extra werk om het window level algoritme toe

58 Hoofdstuk 3. Applicatie 50 te passen op elk beeld, maar het komt uiteindelijk voordeliger uit. Dit omdat de stack beelden later niet volledig opnieuw moet opgehaald worden wanneer de gebruiker de keuze maakt om de window level instellingen aan te passen. Aangezien de beelden beschikbaar zijn op het toestel kunnen deze veel sneller opgehaald worden. Tenslotte zijn geheugenoperaties veel sneller dan netwerkoperaties. Het aantal data of onderzoeken dat kan opgeslaan worden hangt af van de geheugencapaciteit van het toestel. Eens het geheugen vol zit is het niet meer mogelijk om nieuwe onderzoeken op te halen, zolang de oudere onderzoeken niet verwijderd worden. Het huidig op te halen beeld wordt gezocht in het lokaal geheugen en wordt, indien het reeds beschikbaar is, weergegeven op het scherm. Via deze methode is het mogelijk om op moderne toestellen een framerate van 30 tot 40 FPS te halen. Ook indien dat elk nieuw beeld het window level algoritme moet toepassen Beveiliging van de beelden Elke applicatie bij ios draait in zijn eigen sandbox, maar de bestanden van de applicatie zijn beschikbaar wanneer het toestel aangesloten wordt op de computer. Het is dus aangeraden om de bestanden te encrypteren. Encrypteren van de beelden gebeurt via het AES-256 algoritme, op het moment dat de beelden opgehaald werden van de server en lokaal bewaard worden. Zo zijn de beelden steeds beveiligd, ook tijdens het uitvoeren van de applicatie. Decrypteren gebeurt dus steeds wanneer een beeld vanuit het geheugen gelezen wordt. Het nadeel van deze methode is dat bij stack scans een extra vertraging optreedt om de beelden, die uit het geheugen gehaald worden, te decrypteren. Een andere mogelijkheid is om de bestanden pas te encrypteren bij het afsluiten van de applicatie en te decrypteren bij het opstarten ervan, maar wegens het mogelijks groot aantal beelden en bestanden kan dit het opstarten en afsluiten van de applicatie enorm vertragen. Deze methode was geen optie voor het bedrijf. Waar de eerste methode voor encryptie van de beelden zeer efficiënt is bij series met slechts een beeld, kan het zeer vertragend werken tijdens het scrollen door series met meerdere beelden. Zelfs via het snelle AES-256 conventioneel encryptie algoritme. Om te testen wat de impact is van de encryptie werd 10 seconden lang de maximale FPS gemeten. De test werd vier keer herhaald, eens met een oud en een nieuw toestel en eens met en zonder encryptie. In figuur 3.7 worden de resultaten weergegeven.

59 Hoofdstuk 3. Applicatie 51 Figuur 3.7: Grafieken van de framerates met en zonder encryptie Uit de test bleek er een verlies van 30 tot 50 percent in de framerate tijdens het scrollen door een stack bij de modernere toestellen. Bij de oudere toestellen kwam dit op een verlies van 40 tot 60 percent. De impact van het beveiligen van de beelden is dus zeker niet te onderschatten. Deze methode kan geoptimaliseerd worden door de reeds gedecrypteerde beelden in het RAM geheugen te bewaren. Door de grootte van de meeste stack series zou dit echter voor de oudere toestellen een crash opleveren wegens een tekort aan vrij RAM geheugen. Uiteindelijk werd door het bedrijf de beslissing genomen om de beelden niet te encrypteren. Hun reden hiervoor was dat beelden momenteel ook rechtstreeks gedownload kunnen worden en dat deze niets betekenen zonder verdere patiënt- en beeldinformatie, die uiteraard wel geëncrypteerd worden. Eventueel zou deze keuze in latere instantie wel een globale instelling kunnen worden van de applicatie. Zo kan de gebruiker zelf beslissen in welke mate hij de keuze maakt tussen performantie en beveiliging van de informatie. Dit kan bijvoorbeeld door aan de gebruiker te vragen of hij zich aanmeldt vanaf een persoonlijk of een gedeeld mobiel toestel. De implementatie voor encryptie en decryptie van de beelden is momenteel toegevoegd aan het project maar moet in de code ingeschakeld te worden Referentielijn en Scrollbar Tijdens het scrollen in een stack moet de gebruiker kunnen weten welk beeld van de serie hij momenteel bekijkt. Het rangnummer weergeven in de serie is voldoende, maar om de gebruiksvriendelijkheid te verbeteren worden nog extra functionaliteiten toegevoegd.

60 Hoofdstuk 3. Applicatie 52 Scrollbar Een eerste verbetering voor de gebruiksvriendelijkheid is visualisatie van de relatieve positie van het huidige beeld in de serie met een soort scrollbar. zo ziet de gebruiker ook wanneer hij aan het einde van een stack zit en dus niet meer verder kan scrollen. Figuur 3.8: De scrollbar in actie Deze positie is zeer eenvoudig te berekenen via het rangnummer van het huidige beeld en het aantal beelden in de serie, informatie die wordt meegegeven bij elke serie. Referentielijnen Sommige series starten of eindigen met een beeld die in een andere oriëntatie ligt dan al de andere. Dit beeld toont dan waar de volledige stack zal door scrollen. Bijvoorbeeld één coronaal beeld en een stack van axiale beelden. Op dit eerste beeld is het mogelijk om referentielijnen te tekenen gedurende de ganse scroll door de stack. Deze tonen de positie van het huidige beeld, in het eerste beeld. In de vereenvoudigde gevallen staat het vlak dat het eerste beeld beschrijft loodrecht op het vlak van de resterende beelden. Daardoor vertegenwoordigen de andere stack beelden elk een doorsnede van het eerste beeld, elk genomen op een andere positie. In het complexer geval snijden de twee vlakken niet loodrecht en zal de referentielijn weergegeven worden als een vierhoek. Hierdoor zullen de berekeningen uitgevoerd moeten worden op de vier hoekpunten van het huidige stack beeld. Deze hoekpunten moeten achteraf gemapt worden op het eerste beeld. Om de hoekpunten van de bronafbeelding te mappen op het doelbeeld wordt elk hoekpunt bepaald in het 3D RCS (zie ). Eens de posities gekend zijn, mappen we deze posities in een nieuw 3D-assenstelsel dat zijn oorsprong (punt d in figuur 3.9) kent in de oorsprong van het 2D-assenstelsel (patiënt assenstelsel, zie ) van het doelbeeld. Hierna dient enkel nog de mapping te worden gedaan van de punten in het nieuwe 3D-assenstelsel op het 2D

61 Hoofdstuk 3. Applicatie 53 doelbeeld, wat neer komt op het behouden van de x en y waarden van de punten. Hieronder volgt een voorbeeld voor het berekenen van de referentielijnen. In dit voorbeeld nemen we als bronbeeld een traversale doorsnede, en als doelbeeld een coronale doorsnede zoals weergegeven in figuur 3.9. Figuur 3.9: Voorbeeld voor berekenen referentielijnen De bedoeling is de coördinaten van de vier hoekpunten van het bronbeeld te mappen op het assenstelsel van het doelbeeld. De referentielijn is de verbindingslijn tussen de vier punten. Voor de eenvoud zal slechts een hoekpunt s berekend worden. Gegeven voor deze afbeelding is de oorsprong s van het bronbeeld in het RCS s(1, 5, 5)

62 Hoofdstuk 3. Applicatie 54 Alsook de oriëntatie en oorsprong d van het assenstelsel X Y Z van het doelbeeld in het RCS d(1, 0, 7) e x = e x = {1, 0, 0} e y = e z = {0, 0, 1} Het hoekpunt s van de bron dient gemapt te worden in het assenstelsel van het doelbeeld. Er wordt dus gezocht naar punt p die punt s weergeeft in het 2D-assenstelsel van het doelbeeld. Eerst wordt de richtingsvector van de Z -as berekend, die loodrecht staat op de vectoren e x en e y. e z = e x e y e x e y e z e x e y e z = X x X y X z = Y x Y y Y z = {0, 1, 0} = e y (3.8) Alle nodige vectoren zijn nu gekend om de coördinaten van s in het 3D-assenstelsel te berekenen. Verder dient er een translatie te gebeuren om het RCS te verplaatsen naar oorsprong d. Deze translatie-vector T is bijgevolg: 1 T = 0 (3.9) Om de mapping te doen van de positie in het nieuwe 3D-assenstelsel wordt een rotatiematrix gebruikt. Die rotatiematrix R wordt bepaald door de drie vectoren e x, e y en e z : R = = 7 X x Y x Z x X y Y y Z y X z Y z Z z (3.10) De transformatie van het XY Z-assenstelsel naar het X Y Z -assenstelsel wordt beschreven door: x y = R z x y z + T (3.11) De coördinaten x, y, z van punt s in het XY Z-assenstelsel zijn gekend en kunnen ingevuld

63 Hoofdstuk 3. Applicatie 55 worden. 1 5 = 5 = x 1 z + 0 y 7 (x, y, z ) = (0, 2, 5) x y z (3.12) Om de gevonden positie (x, y, z ) te plaatsen in het 2D doelbeeld dient enkel de z-component te worden weggelaten aangezien deze loodrecht staat op het beeld. Bijgevolg wordt de correcte positie verkregen van het punt: p = (0, 2) (3.13) Wanneer deze methode gebruikt wordt om alle vier de hoekpunten te berekenen, en een lijn wordt getekend tussen deze punten wordt de referentielijn bekomen. Figuur 3.10 toont een voorbeeld van een referentielijn die getekend wordt op het beeld. In dit geval wordt een coronaal beeld afgebeeld op het kleinere axiale beeld. De referentielijn wordt in het groen weergegeven. Figuur 3.10: De referentielijn in actie OpenGL 3D simulatie Aangezien de stack beelden een 3D object voorstellen en van elk beeld de positie gekend is, zou het theoretisch mogelijk moeten zijn om van de beelden een 3D model te genereren. In medische termen heet dit multiplanar reconstruction (MPR). Een volume wordt dan opnieuw opgebouwd door het stapelen van de axiale doorsnedes. Achteraf kan het programma doorsnedes maken vanuit elke andere hoek. Na onderzoek bleek dit enigszins mogelijk te zijn via OpenGL, wat ook ondersteund wordt door ios. Dit is echter zeer intensief werk en er is maar weinig vraag naar van de mobiele

64 Hoofdstuk 3. Applicatie 56 gebruikers. Daarom werd besloten deze extra functionaliteit niet verder te onderzoeken of te implementeren.

65 Hoofdstuk 4 Implementatie 4.1 Afhandelen van gestures met zware berekeningen Tijdens het weergeven van een afbeelding kan de gebruiker handelingen (gestures) op het beeld zelf uitvoeren. De applicatie luistert naar een bepaalde gesture. Wanneer deze gesture uitgevoerd wordt, roept deze de overeenstemmende actie of methode op. Een gesture moet, zelfs bij de kleinste verplaatsting van een pixel zo snel mogelijk opnieuw worden opgeroepen. Hierdoor moet rekening gehouden worden met wat precies uitgevoerd wordt in de gekoppelde actie, maar ook waar dit precies wordt uitgevoerd Main thread Elk proces of applicatie in ios bestaat uit een of meerdere threads. Elk vertegenwoordigen ze een blok code die lineair dient te worden uitgevoerd. De applicatie start met een thread die de main functie uitvoert van de code. Dit wordt de main thread genoemd. Deze main thread is verantwoordelijk voor de afhandeling van alle user interface-elementen van de applicatie. Indien de main thread te veel werk heeft met bepaalde berekeningen kan het gebeuren dat de processor de thread blokkeert. Hierdoor is het mogelijk dat ook de UI blokkeert, waardoor de gebruiker op dat moment geen mogelijkheid heeft om nieuwe invoer te doen, of dat bepaalde animaties vastlopen of blokkeren. Een applicatie kan echter op elk moment een nieuwe thread aanmaken. Deze thread wordt dan een onafhankelijke entiteit binnen de applicatie. De kernel bepaalt achteraf welke thread op dat moment processortijd krijgt om zijn code uit te voeren. Een programmeur heeft er dus alle baat bij zware berekeningen asynchroon uit te voeren in aparte threads. 57

66 Hoofdstuk 4. Implementatie Operation queue Een handige klasse voor het organiseren van threads in het Apple Foundations framework is de NSOperationQueue klasse. Deze klasse bevat een verzameling NSOperations. Een NSOperation zorgt voor de afhandeling van een blok code. De NSOperationQueue kan elke taak onmiddellijk uitvoeren via een nieuwe thread ofwel even uitstellen via het Grand Central Dispatch systeem. Aangezien vele gestures op korte tijd kunnen afgevuurd worden, is dit systeem handig om alle operaties te organiseren. Elke taak wordt aan de operation queue toegevoegd, deze handelt de operaties dan een voor een of enkele tegelijk af, afhankelijk van het processorgebruik. Een belangrijk nadeel van dit systeem is dat de organisatie soms wat moeizaam verloopt. Het kan voorvallen dat een taak die later gestart werd, toch eerder uigevoerd wordt. Iets wat meestal verboden is. Dit probleem wordt verholpen door een timing toe te voegen aan de taken. Het kan ook gebeuren dat er teveel taken worden opgestart door de gesture, die vaak ook nog eens zeer zwaar zijn. Hierdoor kan de operation queue en de vertraging voor de gebruiker te groot worden. De oplossing hiervoor is de queue te beperken zodat het maximaal enkele taken kan bevatten. Hierdoor kan de vertraging nooit te groot worden. Wanneer de queue vol zit en er een nieuwe taak dient te worden toegevoegd, is het best om de nieuwe taak niet uit te voeren. Daardoor worden de taken die worden verwerkt in de queue niet onderbroken. Eens een oude taak beëindigd is kan pas een nieuwe taak worden toegevoegd. Door het willekeurig negeren van bepaalde nieuwe taken ontstaat een nieuw probleem wanneer het verplicht is bepaalde taken uit te voeren. Bijvoorbeeld de laatste actie van een gesture, net voor de gebruiker zijn vinger los laat, moet sowieso uitgevoerd worden. Dit probleem is makkelijk te verhelpen door een controle uit te voeren op het loslaten van de vinger en deze taak als nog toe te voegen aan de queue. Na het uitproberen op zowel modernere als oudere toestellen bleek de snelste en vloeiendste methode maximaal slechts een of twee parallele taken toe te laten in de operation queue. Zelfs met de moderne multi-core processoren die de toestellen bevatten. Door het goed organiseren van de zware acties achter al de handelingen is het mogelijk om de applicatie toch vloeiend en performant te houden.

67 Hoofdstuk 4. Implementatie Ophalen en bewaren van pixel data van een afbeelding In ios is de eenvoudigste manier om de pixel data van een afbeelding op te halen via de methode CGBitmapContextCreate. Deze methode haalt de RGBA waarden van een afbeelding op en plaatst ze in een byte array. Onderstaande code in listing 4.1 toont hoe deze array kan worden opgesteld via een UIImage object. Listing 4.1: haal pixeldata uit een UIImage in Objective-C UIImage source* =...; CGImageRef imageref = [source CGImage]; NSUInteger width = CGImageGetWidth(imageRef); NSUInteger height = CGImageGetHeight(imageRef); CGColorSpaceRef colorspace = CGColorSpaceCreateDeviceRGB(); byte *rawdata = malloc(height * width * 4); NSUInteger bytesperpixel = 4; NSUInteger bytesperrow = bytesperpixel * width; NSUInteger bitspercomponent = 8; CGContextRef context = CGBitmapContextCreate(rawData, width, height, bitspercomponent, bytesperrow, colorspace, kcgimagealphapremultipliedlast kcgbitmapbyteorder32big); // 1 CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageref); // 2 CGContextRelease(context); De code wordt verder verduidelijkt: 1. Aanmaken van een bitmapcontext met een referentie naar de byte array. 2. Opvullen van de context met de afbeelding om zo de byte array te initialiseren. De pixeldata achteraf bewaren naar een nieuw UIImage gebeurt op analoge manier (Listing 4.2). Listing 4.2: bewaar pixeldata in een UIImage in Objective-C CGContextRef ctx = CGBitmapContextCreate(rawData, CGImageGetWidth( imageref ), CGImageGetHeight( imageref ), bitspercomponent, bytesperrow, colorspace, kcgimagealphapremultipliedlast ); // 1 imageref = CGBitmapContextCreateImage (ctx); // 2 UIImage* rawimage = [UIImage imagewithcgimage:imageref]; //3 Ook hier wordt de code verder verduidelijkt:

68 Hoofdstuk 4. Implementatie Aanmaken van een bitmapcontext met als invoer onder andere de aangepaste byte array. 2. een CGImageRef object die een referentie naar de nieuwe afbeelding bevat. 3. Omzetten van de referentie naar de afbeelding in een bruikbaar UIImage object. 4.3 Window level Minimale en maximale waarde berekenen voor LUT Voor het berekenen van de LUT dient eerst de minimale en maximale waarde bepaald te worden. Deze waardes hangen enkel af van het aantal gebruikte bits en de DICOM headers. Voor het berekenen van de waardes wordt vaak een beroep gedaan op de functie maxval. Deze neemt een aantal bits als parameter en bepaalt de maximale waarde die mogelijk is met dit aantal bits. Voor bijvoorbeeld 8-bit zal de functie 255 terug geven. De korte code wordt hieronder weergegeven in listing 4.3. Listing 4.3: maxval hulpfunctie in Objective-C - (int)maxval:(int)bits { return (1 << bits) - 1; } Via de maxval functie is het zeer eenvoudig om het maxima, het minima en de range te bepalen. Uiteraard moet ook rekening gehouden worden met de verschillende DICOM headers (zie 1.2.1). Listing 4.4: Minimale en maximale waardeberekeningen in Objective-C - (int)getabsmin { int min; if(pixelrepresentation == 1) // 1 min = - ([self maxval:bitsstored-1]+1); else min = 0; if(rescaleintercept && rescaleslope) // 2 min = min * rescaleslope + rescaleintercept; } return min; - (int)getabsmax {

69 Hoofdstuk 4. Implementatie 61 int max; if(pixelrepresentation == 1) // 3 max = [self maxval:bitsstored-1]; else max = [self maxval:bitsstored]; if(rescaleintercept && rescaleslope) // 2 max = max * rescaleslope + rescaleintercept; } return max; - (int)getabsmaxrange { return [self getabsmax] - [self getabsmin] + 1; // 4 } Bovenstaande code wordt nog even verduidelijkt. 1. Indien de pixel representation waar is moet de minimale waarde het grooste mogelijke negatieve getal zijn. Anders is de kleinste waarde nul. 2. Eens de minimale of maximale waarde gekend is, moet rekening gehouden worden met de rescale slope en rescale intercept (zie ). De formule uit de DICOM standaard wordt hier toegepast. 3. Net zoals bij de minimale waarde moet ook rekening gehouden worden met de pixel representation van de maximale waarde. Bij signed integers is dit uiteraard een bit minder, aangezien die gebruikt wordt voor het teken. 4. De range of het bereik wordt berekend door het maximum te verminderen met het minimum en op te tellen met een, aangezien de nul niet mag worden vergeten Berekening LUT Onderstaande code (listing 4.5) berekent de LUT via de window level parameters en houdt rekening met de photometric interpretation ( ). Listing 4.5: LUT berekenen via window level parameters in Objective-C int low = 0; // laagste grijswaarde (zwart) int high = 255; // hoogste grijswaarde (wit) int c = windowlevel.y; // y coördinaat past center aan

70 Hoofdstuk 4. Implementatie 62 int w = windowlevel.x; // x coördinaat past width aan // MONOCHROME1 wordt zwart, wit en wit, zwart if([photometricinterpretation isequaltostring:@"monochrome1"] && haslutdata == YES) { int tmp = high; high = low; low = tmp; } int absmin = [self getabsmin]; int width_1 = w - 1; int leftborder = c width_1 / 2; int rightborder = c width_1 / 2; int outrange = high - low; int ocnt = [self getabsmaxrange]; float offset = (width_1 == 0)?.0f : (high - ((c - 0.5) / width_ ) * outrange); float gradient = (width_1 == 0)?.0f : ((float)outrange / (float)width_1); //LUT opstellen int lut[ocnt]; for (int i = 0; i < ocnt; i++) { int val = i + absmin; if(val <= leftborder) { //valt links buiten -> zwart maken val = low; } else if(val > rightborder) { //valt rechts buiten -> wit maken val = high; } else { val = offset + val * gradient; } lut[i] = val; } De code berekent een offset en een gradient of factor waarmee elke oorspronkelijke waarde van de LUT bewerkt wordt. Zo kan een mapping van alle 10- tot 16-bit waardes op zijn respectievelijke 8-bit waarde bekomen worden. Deze tabel zal achteraf voor elke pixel geraadpleegd

71 Hoofdstuk 4. Implementatie 63 worden bit berekenen uit RGB waarden In onderstaande code 4.6 wordt weergegeven hoe men de verschillende 10- tot 16-bit waarden kan berekenen uit de RGB-waarden van de verschillende pixels. Achteraf wordt de LUT gebruikt om de berekende 10- tot 16-bit waarde zijn respectievelijke 8-bit waarde te geven. Listing 4.6: 16-bit reconstrueren en nieuwe grijswaarden bewaren in Objective-C int byte = 0; //index van de huidige byte for (int ii = 0 ; ii < width * height ; ++ii) { // 1 int bit16 =...; int move = 16 - bitsstored; // 2 int bits = (bit16 >> move) & [self maxval:bitsstored]; // 3 rawdata[byte] = rawdata[byte+1] = rawdata[byte+2] = lut[bits]; // 4 rawdata[byte+3] = 255; // 5 } byte += 4; // 6 Bovenstaande code wordt nog wat verduidelijkt: 1. De 16-bit waarde uit de verschillende kleurenbytes worden opgesteld. 2. Indien er minder dan 16-bits gebruikt worden zal move dit compenseren. 3. Er wordt gezorgd dat de integer maximaal 16 bits kan bevatten 4. De nieuwe grijswaarden worden opgeslaan in elk kleurenkanaal 5. Het alfakanaal dient zichtbaar te zijn dus krijgt de hoogste waarde 6. Bij elke doorgang door de lus dient er over vier posities opgeschoven te worden aangezien men over vier kanalen beschikt. Het uiteindelijke resultaat van de lus is een bitmap met de nieuwe waarden voor de afbeelding.

72 Hoofdstuk 5 Besluit De bedoeling van deze masterproef was om een mobiele applicatie te realiseren waarvan de gebruiksvriendelijkheid en performantie hoger of minstens even goed lagen dan het gebruik van de bestaande webapplicatie op een mobiel toestel. Er werd gestart met een onderzoek naar de beste technologie om dit te verwezelijken. Na dit uitgebreid onderzoek werd de keuze gemaakt om de applicatie te implementeren in het mobiele ios-besturingssysteem. Hybride applicaties bleken te kort te schieten op vlak van performantie. De volgende stap bestond uit nog meer onderzoek. Enerzijds onderzoek om de bestaande service te begrijpen, en hoe deze precies gebruikt kon worden in de mobiele technologie. Anderzijds ondezoek in de uitgebreide en ingewikkelde DICOM standaard voor het begrijpen van de metadata bij de beelden. Het eerste deel van de implementatie bestond vooral uit het performant maken van de zware berekeningen op beelden. Veel trail and error van verschillende methoden resulteerde uiteindelijk in de meest performante methode voor het toepassen van bewerkingen op beelden in real time. De uiteindelijke methode bleek sneller te zijn dan de reeds bestaande DICOM viewers op de app-markt en drie keer sneller dan de webapplicatie. Het volgende deel moest het eenvoudig maken voor de gebruiker om tussen de verschillende studies te wisselen. Er werd vooral gelet op de gebruiksvriendelijkheid en onderzocht welke UI elementen het best gebruikt werden voor het weergeven van bepaalde data. Zo werd de grote structuur van de applicatie duidelijk. In het derde deel van de implementatie werden alle verschillende functionaliteiten op de beelden toegevoegd. Een zoom en pan functie, window level, stack scroll, verschillende soorten metingen toepassen en het lokaal beschikbaar maken van de beelden en de patiëntinformatie. 64

73 Hoofdstuk 5. Besluit 65 Tot slot bestond het laatste deel uit het verbeteren en debuggen van alle bestaande functies, alsook het aanpassen van de layout naar de look and feel van PacsOnWeb. Al dit werk resulteerde in een vlotte en zeer gebruiksvriendelijke mobiele applicatie die gebruikt kan worden op de diverse ipads van Apple die ios7 ondersteunen. De applicatie werd getest en goed bevonden door enkele radiologen. Zij waren zeer enthousiast en zagen direct het gemak er van in voor het vragen van o.a. tweede opinies of het bekijken van de beelden samen met de patiënt. Er mag besloten worden dat de eis van gebruiksvriendelijkheid zeker voldaan is. Ook de performantie eis van de applicatie, die tot drie keer beter is dan de webapplicatie, is zeker voldaan. Bijgevolg mag er dus gerust teruggeblikt worden op een geslaagde masterproef.

74 Bijlage A Handleiding 66

75 Bijlage A. Handleiding 67 IPACSONWEB HANDLEIDING By Dobco Medical Systems Pieter-Jan Van Robays