proiect:descriere [Managementul Proiectelor Software]

Differences

This shows you the differences between two versions of the page.

--- proiect:descriere [2013/01/13 08:37]
andrei.tigora [Alte observații]
+++ — (current)
@@ Line 1: / Line 1: @@
-= Descrierea temelor de proiect =
-Un sistem OCR este o aplicație complexă, ce presupune interconectarea a numeroase componente ce oferă facilități variate. În mod ideal, odată realizate setările pentru rularea aplicației, imaginile document ar trebui să ruleze „batch mode”, fără nicio intervenție externă. Acest lucru este posibil, dar rezultatele, chiar și în cazul aplicațiilor performante ce costă mii de dolari, nu sunt perfecte. Așadar este adesea nevoie de a face unele corecții în ceea ce privește rezultatele obținute.
-Pe lângă această necesitate de a interveni asupra rezultatului prelucrării automate, mai rămâne și problema configurării propriu-zise. Având atâtea module disponibile, configurarea lor devine un proiect în sine, mai ales în absența unui utilitar grafic care să se asigure că fișierul de configurare respectă formatul impus.
-Proiectul la a cărui dezvoltare veți contribui a fost gândit ca un sistem OCR modular, format din executabile independente care „comunică” prin fișiere XML. Comunicarea se referă la faptul că atât configurația de rulare cât și raportul execuției, iar în unele cazuri rezultatul în sine al execuției se prezintă sub forma unor fișiere XML. Din nefericire, proiectul nu se bucură de existența unor interfețe grafice care să înleasnească utilizarea sa (ceea ce ar fi important pentru testarea lui de un număr mai mare de oameni). Scopul vostru va fi realizarea unor asemenea aplicații grafice care, pe baza modulelor(executabilelor) existente, să rezolve problemele menționate anterior.
-Pentru simplificarea explicațiilor următoare, introducem câțiva termeni specifici.
-//1. Spunem că un executabil A îndeplinește aceeași funcție ca un executabil B, dacă toate elementele execType din schemele asociate sunt identice.//
-//2. Spunem că B este alternativă pentru A, dacă A și B îndeplinesc aceeași funcție.//
-//3. Spunem că un executabil A este de tipul T, dacă schema asociată are pe T ca valoare pentru unul din elementele execType.
-//
-==Proiect 1: Document Processing Manager==
-Scopul acestui proiect este de a crea un executabil care să realizeze managementul unui workflow complet al unei procesări, pornind de la imaginea color și obținând PDF-uri bazate pe imaginile selectate.
-Tipurile de executabile pentru care le poate utiliza aplicația și ordinea lor este următoarea:
-  * preprocessing
-  * binarization
-  * layout
-  * paging
-  * OCR
-  * hierarchy
-  * PDF-exporter
-Workflow-ul tipic este următorul (complet):
-  * utilizatorul are posibilitatea  de a selecta unul sau mai multe fișiere ale căror nume sunt conforme cu o expresie regulată sau care au fost selectate individual prin explorarea ierarhiei de fișiere (printr-un window browser)
-  * pentru fiecare tip de procesare, utilizatorului i se oferă posibilitatea de a alege executabile care au acel tip; nu pot exista selectate la un moment dat două executabile care îndeplinesc aceeași funcție, dar pot exista mai multe executabile care deși au același tip, nu reprezintă alternativă unul pentru celălalt; de exemplu, se poate selecta un singur executabil ce are atât tipul preprocessing si rotate, dar este acceptată selecția concomitentă a unui executabil de tip preprocessing și blur și a unuia cu tipurile preprocessing și rotate
-  * este important de specificat că între primul și ultimul tip de procesare setat nu trebuie să existe „pași” lipsă; de exemplu, dacă s-a selectat un utilitar de tip binarization la începutși ultimul este un utilitar de tip paging, trebuie să fi fost setate și executabile de tip layout și respectiv hierarchy
-  * pentru fiecare executabil selectat, se va oferi posibilitatea specificării parametrilor de rulare, conform schemei asociate executabilului
-  * la finalul selecției, se va realiza execuția propriu-zisă dupa cum urmează:
-  - fiecare executabil selectat va fi rulat pe rezultatul rulării executabilului anterior
-  - dacă executabilul nu prelucrează decât un fișier la fiecare rulare, atunci executabilul va fi rulat pentru fiecare fișier în parte
-  - dacă executabilul prelucrează mai multe fișiere la o rulare, atunci toate fișierele obținute în faza anterioară vor fi adăugate la fișierul XML de input pentru prelucrare
-  - rularea constă în construcția fișierului XML în conformitate cu schema XML pe baza fișierelor disponibile (după cum s-a precizat la 2 și 3) si a parametrilor setați manual, urmată de execuția prorpriu-zisă și inspecția fișierului XML de raport
-  - pe bază rezultatelor din cadrul fișierului XML de raport se va decide dacă se continuă execuția cu celelalte etape sau nu (dacă să prezinte un mesaj de eroare sau nu); **Notă:** momentan acest fișier nu este generat, în versiunile viitoare se va adăuga și facilitatea asta
-==Proiect 2: Web based Document Processing Manager==
-Ca și în cazul proiectului anterior, scopul acestui proiect este de a crea un executabil care să realizeze managementul unui workflow complet al unei procesări, pornind de la imaginea color și obținând PDF-uri bazate pe imaginile selectate. Elementele prin care diferă sunt prezentate în cele ce urmează; dacă nu este prezentată explicit diferența față de proiectul anterior, atunci designul este identic cu ceea ce a fost prezentat mai sus.
-Proiectul va consta într-un server http care să ofere funcționalitățile prezentate mai sus; nu este nevoie să se implementeze un server, ci se poate Tomcat sau orice alt mecanism care să permită rularea executabilelor conform selecțiilor făcute din cadrul browserului web.
-Utilizatorul va încărca imagini pe server, urmând să înceapă procesarea acestora fie de la nivelul preprocessing, fie de la binarization. Prelucrarea se poate opri la binarizare sau poate merge până la generare de fișier PDF.
-==Proiect 3: Preprocessing Graphical User Interface==
-Scopul acestui proiect este de a crea un executabil care să permită evaluarea vizuală a rezultatelor diverselor preprocesări disponibile și a componentelor de binarizare.
-Tipurile de executabile pentru care se poate utiliza aplicația:
-  * preprocessing
-  * binarization
-Designul grafic al aplicației:
-  * imaginea originară (cu eventuale prelucrări de preprocesare) este afișată în jumătatea stângă a ferestrei aplicației
-  * în partea dreaptă, într-un scroll pane (sau o alta componentă de afișare) sunt prezentate versiuni binare ale imaginii din stânga
-Workflow-ul tipic este următorul (complet):
-  * utilizatorul selectează o singura imagine (greyscale sau color) ce va fi afișată în jumătatea stângă a ferestrei aplicației
-  * se selectează executabile de preprocesare, fără a avea două cu aceeași funcționalitate; pentru fiecare executabil, pe baza fișierului xsd asociat, se face selecția parametrilor
-  * se selectează diverse alternative de executabilele binare și sunt fixați parametrii conform fișierului xsd; este posibilă chiar selecția aceluiași executabil de 2, deoarece poate folosi parametri distincți
-  * actualizarea imaginilor se face fie explicit prin apasărea unui buton fie automat, dacă se setează un checkbox;pentru acest caz din urmă, dacă se schimbă preprocesările efectuate, toate imaginile binare vor fi actualizate instantaneu; similar, dacă se adaugă un nou modul de binarizare, rezultatul va fi adăugat instantaneu la lista de imagini (similar pentru ștergere)
-  * aplicația trebuie să ofere posibilitatea comparației prin suprapunere a două imagini binare
-==Proiect 4: Layout Analysis==
-Scopul acestui proiect este de a crea un executabil care să permită corecția erorilor în ceea ce privește gruparea caracterelor în rânduri și a rândurilor în blocuri de text, a paginării, și a conținutului text propriu-zis.
-Workflow-ul tipic este următorul:
-  * utilizatorul fie încarcă un fișier XML asupra căruia a fost executată analiza de layout, fie selectează un imagine și execută o analiză de layout rulând unul din analizoarele disponibile
-  * în acest moment, se încarcă imaginea și la nivelul acesteia pot fi ilustrate componentele imaginii document: litere, rânduri de litere și blocuri text; în funcție de selecția utilizatorului, pot fi vizualizate toate cele 3 niveluri, sau doar anumite categorii
-  * dacă asupra textului nu s-a executat analiza OCR, se poate cere analiza aceasta selectând analiza OCR, fie pe toată imaginea, fie doar pe anumite rânduri din imagine
-  * rezultatele analizei OCR pot fi corectate selectând linia dorită și modificând textul atașat care trebuie să fie atașat într-o casetă text alăturată
-  * dacă niciunul din blocurile text nu este identificat ca fiind număr de pagină, se poate fie rula modulul de numerotare a paginii, fie să se impună ca unul din blocuri să reprezinte numărul de pagină; pentru ca blocul de pagină conține rânduri (de fapt un singur rând la o detecție corectă), numărul poate fi detectat prin OCR sau introdus manual
-  * pe lângă aceste acțiuni, trebuie să fie posibilă redimensionarea unirea/spargerea blocurilor text, unirea/spargerea liniilor de litere
-  * rezultatul va fi un fișier XML care descrie layout-ul unei imaginii, conform schemei, limitându-se la blocuri cu tipul paragraph și un bloc cu tipul page_number
-==Proiect 5: Hierarchy Analysis==
-Scopul acestui proiect este de a crea un executabil care să permită corecția erorilor ce apar în urma grupării și catalogării blocurilor din cadrul mai multor imagini document.
-Workflow-ul tipic este următorul:
-  * utilizatorul încarcă unul sau mai multe fișiere XML obținute în urma rulării analizei de layout și să ruleze un analizor ierarhic pentru acestea sau să încarce un fișier XML care conține rezultatul analizei ierarhice
-  * ca și în cazul analizei anterioare, diversele tipuri de blocuri pot fi afișate, se pot uni blocuri, sparge și eventual recataloga (dacă un bloc era inițial marcat ca titlu, poate fi marcat ca subtitlu)
-  * de data aceasta însă, blocurile blocurile compuse se pot întinde pe mai multe imagini document; prin urmare, dacă se dorește gruparea tuturor paragrafelor unui articol, va fi nevoia de selecția lor din cadrul mai multor imagini
-  * dacă sunt inspectate mai multe imagini, acestea vor putea fi afișate una deasupra celeilalte ca într-un editor text
-===Schema XML de intrare===
-Un fișier xsd de input are următoarele două secțiuni:
-  * o secțiune de descriere a aplicației căreia îi este asociat
-  * o secțiune de configurare propriu-zisă a aplicație pentru rulare
-Prima secțiune va fi utilizată de componentele grafice pentru a determina ce executabile poate rula pentru a-și atinge scopul. Aceast conține:
-  * numele executabilului asociat identificat prin elementul execName
-  * unul sau mai multe elemente execType, pe baza cărora se va face selecția elementelor
-  * un element execDescription care prezintă o scurtă descriere a executabilului
-Conținutul unui execTag poate fi unul din următoarele:
-  * preprocessing
-  * binarization
-  * layout
-  * OCR
-  * PDF-exporter
-  * hierarchy
-  * paging
-Cea de-a doua secțiune reprezintă o înșiruire a parametrilor posibili pentru aplicație.
-==Detalii suplimentare==
-- toate executabilele sistemului OCR se vor afla într-un folder ce va fi specificat ulterior
-- toate schemele fișierelor XML de intrare se vor afla într-un folder ce va fi specificat ulterior (distinct de folderul anterior)
-- toate schemele ce prezintă formatele de ieșire impuse se vor afla într-un folder ce va fi specificat ulterior (distinct de folderele anterioare)
-- toate aplicațiile trebuie să prezinte posibilitatea setării într-un fișier de configurare a celor 3 foldere menționate anterior
-Formatele fișierelor XML obținute în urma analizei de layout și a celei hierarchy sunt asemănătoare. Câteva precizări suplimentare despre acestea:
-  * blocul compus ce are tipul page_number trebuie să fie unic; în mod normal, nu ar trebui să conțină decât un bloc de tip text, iar acesta la rândul lui să nu conțină decât un rând de text cu un singur string
-  * (doar hierarchy) atributul id ce identifică imaginile trebuie să fie unic în cadrul unui fișier xml; atributul refid trebuie să aibă aceeași valoare ca unul din atributele id (practic blocul text sau imagine trebuie încadrat într-una din imagini)
-  * atributul direction a fost folosit deoarece bibliotecile de prelucrare a imaginilor parcurg imaginile în sensuri diferite, de sus în jos sau de jos în sus; indiferent de direcția de parcurgere, atributul top va reprezenta linia cu contor asociat mai mic, iar bottom linia cu contor asociat mai mare
-  * prezența elementului polygon este necesară deoarece în anumite situații componentele nu au forme dreptunghiulare; așa că pentru acele situații “deosebite”, trebuie specificat pe lângă dreptunghiul încadrator și un poligon ce oferă o încadrare mai bună
-===Format fișier layout===
-Exemplu:
-  <Document image="nume_imagine.tip" direction="ascending">
-   <ImageBlock left="1" right="100" top="20" bottom="200">
-     <Polygon>
-       <Point x="1" y="20"/>
-       <Point x="1" y="200"/>
-       <Point x="100" y="200"/>
-     </Polygon>
-   </ImageBlock>
-   <TextBlock left="1" right="1" top="1" bottom="1">
-     <TextLine left="1" right="1" top="1" bottom="1">
-       <String>ceva</String>
-       <String>poate fi si un text din mai multe stringuri</String>
-     </TextLine>
-     <TextLine left="1" right="1" top="1" bottom="1">
-       <String>ceva</String>
-     </TextLine>
-   </TextBlock>
-   <ComposedBlock type="page_number" >
-     <TextBlock left="1" right="1" top="1" bottom="1">
-       <TextLine left="1" right="1" top="1" bottom="1">
-         <String>4</String>
-       </TextLine>
-     </TextBlock>
-   </ComposedBlock>
-  </Document>
-=== Format fișier hierarchy ===
-Exemplu:
-  <hierarchy>
-   <hierarchy_docs>
-    <Document image="first.jpg" direction="ascending" id="img1"/>
-    <Document image="second.tf" direction="ascending" id="img2"/>
-   </hierarchy_docs>
-   <hierarchy_blocks>
-    <ComposedBlock type="article">
-      <ImageBlock left="1" right="11" top="1" bottom="1" refid="img1">
-       <Polygon>
-        <Point x="1" y="1"/>
-        <Point x="1" y="1"/>
-        <Point x="1" y="1"/>
-       </Polygon>
-      </ImageBlock>
-      <ComposedBlock  type="title">
-       <TextBlock refid="img1" left="1" right="11" top="1" bottom="1">
-        <TextLine left="1" right="11" top="1" bottom="1">
-         <String>Title</String>
-         <String>Example</String>
-        </TextLine>
-       </TextBlock>
-      </ComposedBlock>
-      <ComposedBlock  type="body">
-       <TextBlock refid="img1" left="1" right="11" top="1" bottom="1">
-        <TextLine left="1" right="11" top="1" bottom="1">
-         <String>One</String>
-         <String>Two</String>
-        </TextLine>
-        <TextLine left="1" right="11" top="1" bottom="1">
-         <String>aaa bbbbb cccccc</String>
-         <String>d</String>
-         <String>eee</String>
-        </TextLine>
-       </TextBlock>
-       <TextBlock refid="img2" left="1" right="11" top="1" bottom="1">
-        <TextLine left="1" right="11" top="1" bottom="1">
-         <String>First</String>
-        </TextLine>
-        <TextLine left="1" right="11" top="1" bottom="1">
-         <String>Second</String>
-        </TextLine>
-        <TextLine left="1" right="11" top="1" bottom="1">
-         <String>Thied</String>
-        </TextLine>
-       </TextBlock>
-      </ComposedBlock>
-     </ComposedBlock>
-   </hierarchy_blocks>
-  </hierarchy>
-=== Executabile ===
-Puteți descărca executabilele pentru proiect de pe site-ul de cursuri: http://cs.curs.pub.ro/2012/mod/resource/view.php?id=1763
-Executabilele de analiza layout si ierarhie sunt doar niste mockuri, dar pot sa fie folosite de ca element de ancorare.
-In folderul xml_schemas sunt schemele pentru toate aplicatiile. Pe viitor, orice executabil adaugat va fi pus in radacina si schema lui in xml_schemas.
-=== Alte observații ===
-==== 18 Oct ====
-Pentru proiectele de Document Processing Manager (si simplu si web):
- * in caz ca nu am mentionat: managerul este "dumb", habar nu are ce coordoneaza; el trebuie sa imi prezinte mie utilizator o lista de optiuni conform xml-ului; cu exceptia elementelor care specifica fisiere si ar trebui eventual selectate cumva corespunzator, toate celelalte informatii trebuie sa poata fi generate independent de specificatie
- * aici se pot folosi toate executabilele
-Pentru proiectul Preprocessing Graphical User Interface:
- * aplicatia este dumb; nu trebuie sa stie decat sa imi genreze inputuri, si pe baza lor sa creeze xml-ul potrivit; nu trebuie sa fie constienta de ceea ce genereaza, deci trebuie sa mearg cu orice schema (ce respecta cerintele specificate anterior)
- * aici se folosesc utilitarele non-mock: rotate, otsu si crop
-Pentru celelalte doua proiecte:
- * aplicatia trebuie sa fie constienta de formatul de output; cel mai probabil schemele aici nu vor contine decat input si output, urmand ca "partea grea" sa fie interfata grafica in spatele careia va fi construit un xml corespunzator
- * fiecare proiect are cate un utilitar; din pacate nu se genereaza niciun continut xml propriu-zis; cea mai simpla rezolvare ar fi sa se adauge posibilitatea incarcarii directe a unei scheme, fara a se trece prin procesul de generare a schemei - in felul asta ar putea sa isi creeze o schema de mana (pe modelul celor specificate in documentatie) si apoi ar putea lucra pe ceva non-vid
-==== 20 Oct ====
-A fost adaugat executabilul tesseract_wrapper. Elementele din fisierul xml de intrare au urmatoare semnificatie:
- * inputFile - atributul name va contine numele imaginii care urmeaza a fi prelucrata
- * outputFile - atributul name va contine numele fisierului text care va contine textul interpretat; observație: Tesseract adaugă în mod automat la numele primit extensia .txt așa că numele fișierului final va fi nume_indicat.txt
- * processRectangle - indică dreptunghiul din imagine din care va fi extras conținutul (elementul a devenit obligatoriu)
- * TessPath - indică (opțional) executabilul ce urmează a fi folosit (calea completă + //tesseract.exe//); dacă acest element nu este prezent, va fi rulat executabilul //./Tesseract-OCR/tesseract.exe//
-==== 24 Oct ====
-Pentru că am observat că sunt ceva nelămuriri legate de mock-uri, o să încerc să explic aici cum stă treaba.
-Proiectul inițial conținea executabile independente, cu un controller în linie de comandă, dar fără interfețe grafice (no sugar). Când s-a hotărât crearea unor interfețe grafice, a fost nevoie să se înlocuiască vechile DTD-uri cu niște scheme care să poată fi ușor parsate cu un parser general de xml-uri (DTD-urile nu sunt în format xml). Asta a însemnat automat modificarea codului sursă. De asemenea, față de versiunile inițiale, specificațiile fișierelor de layout și hierarchy au fost ușor modificate, ceea ce înseamnă alte intervenții în cod.
-Scopul nu este să scrieți cod care să proceseze imaginile (vezi partea din descriere a fiecărui proiect //”Scopul acestui proiect este de a...”//) ci să puneți la dispoziție interfețe grafice care să prezinte în mod intuitiv unui utilizator informția necesară utilizării executabilelor de prelucrare de imagini. XML-urile sunt perfecte pentru procesare automată, dar nu sunt tocmai //A Song of Fire and Ice//. Uneori, e nevoie de ajutor în crearea și citirea lor.
-Așadar, NU (conform DEX: //adv. I. Servește la formarea formei negative a verbului, de obicei precedându-l nemijlocit//) va trebui să implementați analizor de layout, de hierarchy, sau vreuna dintre componentele care nu v-au fost puse încă la dispoziție. În schimb va trebui să puteți utiliza orice executabil al cărui tag este relevant pentru aplicația pe care o dezvoltați. Vrem ca aceste interfețe grafice să poate fi folosite chiar și cu niște componente care nu au fost dezvoltate încă, dar care care se supun convețiilor stabilite până acum.
-==== 27 Oct ====
-Pentru mai multe informatii despre ce inseamna "monstruozitatile" prezentate in diversele scheme, va rog sa cititi mai intai tutorialul urmator www.w3schools.com/schema/default.asp. Apoi, ca sa verificati ca ati inteles, folositi validatorul http://xsdvalidation.utilities-online.info/ pentru a testa continut xml creat de voi raportat la schema.
-Orice executabil pus la dispozitie se ruleaza asa: nume_executabil fisier_input_xml. Ce contine fisierul de input e specificat in scheme. Ce este rezultatul? Cu exceptia analizoarelor de layout si hierarchy, rezultatul este o imagine. Ultimele doua tipuri de executabile produc fisiere xml ce respecta schemele prezentate la [[proiect:specificatii-xsd?&#layout-format-specification|layout format specification]] si respectiv [[proiect:specificatii-xsd?&#hierarchy-format-specification|hierarchy format specification]]
-==== 13 Ian ====
-Postul anterior se referea la executabilele care au fost incarcate la data respectiva pe curs.cs.
-Lista urmatoare prezinta formatele asteptate pentru fisierele indicate prin inputFile si outputFile:
-  * preprocessing: inputFile -> imagine 8BPP, outputFile -> imagine 8BPP
-  * binarization: inputFile -> imagine 8BPP, outputFile -> imagine 1BPP
-  * layout: inputFile -> imagine 1BPP, outputFile -> XML in format layout
-  * paging: inputFile -> XML in format layout, outputFile -> XML in format layout
-  * OCR: inputFile -> XML in format layout, outputFile -> XML in format layout
-  * hierarchy: inputFile -> XML in format layout, outputFile -> XML in format hierarchy
-  * PDF-exporter: inputFile -> XML in format hierarchy, outputFile -> PDF