(tekstfelt er max 25 chars og tidkode1 og tidskode2 altid 11 chars med kolon'er).
Listen er variabel fra (mindst) 1 til (ofte) flere 10-tals (oftest 35 - 100).
Jeg skal bruge disse data til tekst- og tids-verifikation i forhold til en anden SQL-base. (Jeg har IKKE adgang til original SQL-data (den base som danner listerne)).
Problemet er at programmet ikke skriver det i kopier-bart format (Windows CTL-A - CTL-C og CTL-V) til skærmen (er det direkte tilgang ?).
Er der nogen som kender en DELPHI-7 komponent (alternativt et gratis program), som kan læse GRAFIK-hukommelsen og omdanne dette bitmøster til læsbart tekst ?
(Jeg kunne gemme bitmønsteret (CTL + PRT-SCR, gemme i Paint, udskrive og SCANNE med OCR men da der er ca. 5000 lister LIGE NU ... (jeg vil gerne pensioneres når jeg bliver 70 --- )..)
Listerne genereres fra en SQL-base på en server langt herfra (centralbasen) og sendes via intra-nettet til local-serveren som dirigerer data videre til min(e) PC('ere). Og ledelsen (centralt) har besluttet (sikkerhed) at externe servere IKKE har central adgang.. (det sker via XML-scripts)...
DET ENESTE jeg kan med data er at jeg kan tage et screen-dump (CTL PRT-SCR), gemme 10 liste-elementer som et picture (JPEG/BMP/TIF) i PAINT , udskrive til local-printer og siden scanne med OCR-option (og håbe at scanneren og OCR-programmet kan læse teksten korrekt.)
Derefter sreeen-dumpe de næste 10 liste elementer, gemme, scanne OCr - osv..
Derefter sreeen-dumpe de næste 10 liste elementer, gemme, scanne OCR - osv..
til alle liste elementer er taget. (10 gange ved 100 liste elementer).
Det jeg håbede var at jeg kunne springe hele PRT-SCR , gemme, printe, scanne OCR + + + + + procedurerne over og hente tekten direkte via en Delphi-/ program - Komponent (eller et andet).
At jeg skal hente teksten 10 gange ( ved 100 listelementer) er uomtvisteligt.
Eller jeg kan manuelt taste dem ind som ren tekst ... (og det gider jeg ikke .. !)
Vi er ganske enige. En JPEG fil er jo egentlig et screendump med lidt kontrolinfo foran. Men det er heller ikke der mit problem reelt er, det er at finde ud af hvilken byte (pixel-start) hvorfra den aktuelle tekst begynder og siden fortolke/ oversætte dette bit-mønster til Delphi forståelig tekst (ISO / ASCII ). (også kendt som OCR... ).
Men jeg tror jeg har fundet noget kode (efter intens søgen på nettet - pyha ), som kan klare en del af problemet. Skal prøve det på job i morgen og må så arbejde videre derfra ...
Jeg skal her lidt mere detaljeret prøve at forklare hvad dette her går ud på:
Jeg arbejder i Arkiv afdelingen i en større media-hus, hvor jeg arbejder med gamle video-tapes (BetaMax typen). Vi er i færd med at digitalisere disse analog-tapes og til det har vi CENTRALT en SQL-base, som vi almindelige dødelige ikke på nogen måde har adgang til. Skal vi arkivere de nye digitaliserede video-sekvenser (kaldet Clips) sker dette via lokalt genererede XML-filer, som sendes via intranettet til denne server.
Denne Centrale SQL-base indeholder så en masse tabeller. Hver tabel har et variabelt antal records, hvor hver record repræsenterer hvert clip på den aktuelle tape. (Tittel, fotograf, start-tidskode, sluttidskode, opdagedato, etc. etc. etc.)
Disse data sendes via intranettet til min PC (eller den i organisationen, som skal bruge disse data) via den lokale server.
På min PC er et program, som kommunikerer med samme SQL-base på ren præsentations-niveau. Det kører under Windows, men bruger IKKE windows skærm-driver (de har deres egen,) og det gør at windows CLIPBOARD-funktionerne (CTL-A, CTL-C og CTL-V) IKKE fungerer.
Grundet en BUG i samme software er der adskillige tabeller, hvor data ikke er konstistente og det er min (forbaskede (undskyld jeg bander !)) opgave at rette dette op. Men uden direkte SQL-adgang (fordi jeg arbejder på et lokal-kontor og ikke dirkete ved siden af serveren (spørg mig ikke hvorfor, sådan er det bare !)) .
Jeg kan få samtlige tabellers SQL-tittel (som er det samme som CLIP-tittel), deres tidskoder (clip-start og clip-slut) and THATS 'it. Men kun som visning på skærmen (SOM IKKE TILLADER CTL-A- CTL-C ... ).
Jeg skal bruge disse data til fysisk at finde det pgl. clip på den fysiske tape, derefter kan jeg så hente de andre data for dettet clip (se ovenfor), generere en ny XML-fil (indholdende de data, som ikke er tilgængelige pga bug'en) og så returnere / skrive XML-filen tilbage og dermed rette/ ophæve bug'en.
Hvis der var tale om et par hundrede kunne jeg vælge at gøre det manuelt, men her taler vi om 1000'er (måske 10.000'er eller flere ?) Jeg gider ikke taste 10.000 (* 16 pr. tape), når det kan gøres intelligent, hurtigere og (sikrere) under program-kontrol. (jeg er programmør - ikke terminal-abe..)
(Det program, som genererer og overfører XML-filen er NATURLIGVIS (hva ellers (he he)) skrevet i Delphi-7 og fungerer som en drøm).
KR
(håber det forklarer hvorfor jeg har brug for en VIDEO-OCR - GRAPPER ?
Var jeg dig ville jeg - såfremt man faktisk havde mulighed for det - lave lidt reverse engineering mht. hvordan programmet kommunikere (packet sniffer, evt.) og så lave mit eget tilsvarende program der klarede opgaven ordenligt.
Kan du ikke det, så kan du vidst nok udnytte Microsoft Office's "Document Imaging" objekt i Delphi. Det gøres via ActiveX og burde være lige til. Et konkret eksempel - der er testet og virker - kan jeg ikke give dig nu (det bliver nok først i morgen), men indtil videre kan du jo se om det her virker:
// Husk at importere ActiveX objektet Microsoft Office Document Imaging og tilføje ComObj og MODI_TLB til uses function OCRTest(const AFileName: String): String; var Doc: IDocument; Img: IImage; Layout: ILayout; begin Result := '';
Doc := IDispatch(CreateOleObject("MODI.Document")) as IDocument; try Doc.Create(AFileName); Doc.OCR(miLANG_ENGLISH, True, True);
Img := IDispatch(Doc.Images[0]) as IImage; Layout := IDispatch(Img.Layout) as ILayout; Result := Layout.Text; except on E:Exception do Result := Format('Error: %s (%s)', [E.Message, E.ClassName]); end; Img := nil; LayOut := nil; Doc.Close(False); end;
Preppydude: Det kodeeksempel vil jeg straks kaste mig over. Jeg har masser af tekstskanninger i mine databaser. Det må kunne bruges hos en eller anden kunde (håber det virker)
En gang i mellem er det godt at være programmør - andre gange ikke. I går var det. Løste en parallel haste-opgave uden om tids-kodeproblematikken, og så var chefen bare lykkelig...
Men det var på bekostning af samme tidskode-problem.
Jeg vil se på det i dag - her i formiddag hvis der ikke kommer andre forstyrrelser eller hasteopgaver.
Via COM, MODI provides an object model based on 'document' and 'image' (page) objects. One feature that has elicited particular interest on the Web is MODI's ability to convert scanned images to text under program control, using its built-in OCR engine.
The MODI object model is accessible from development tools that support the Component Object Model (COM) by using a reference to the Microsoft Office Document Imaging 11.0 Type Library. The MODI Viewer control is accessible from any development tool that supports ActiveX controls by adding Microsoft Office Document Imaging Viewer Control 11.0 or 12.0 (MDIVWCTL.DLL) to the application project. These folders are usually located in C:\Program Files\Common Files\Microsoft Shared\MODI.
The MODI control became accessible in the Office 2003 release; while the associated programs were included in earlier Office XP, the object model was not exposed to programmatic control.
Prøvede derefter at indlæse MDIVWCTL.DLL som import, men jeg har den overhovedet ikke på PC'en.
Fandt senere ud af at det er fordi den er i forbindelse med Word 2003 (og senere). Jeg "kører" Word 2000 og der er 'Dll'en ikke tilgængelig under programkontrol.
Jeg skal ikke kunne sige, om jeg har lavet en fejl, mne jeg kopierede hele blokken fra dit indlæg # 11 (se ovenfor), satte det ind i min (test-)kode som en function og kompilerede .
Det gav den fejl, som jeg beskrev i indlæg # 17 .
Jeg har siden søgt efter den beskrevne DLL'er men har endnu ikke fundet den nogen steder. (Mmen måske har jeg ledt de forkerte steder..)
Jeg finder IKKE MODI_TLB nogen steder. Har som sagt prøvet om jeg kunne TYPE_IMPORTERE den, men det har ikke lykkedes. Har du nogen anelse om hvilket TYPE-BIB den (kan) ligge(r) i ?
Da jeg testede importerede jeg et Type Library kaldet "Microsoft Office Document Imaging". Alt fungerede som det skulle, udover at jeg skulle omdøbe en class kaldet "TImage" til "TModiImage" i stedet. Jeg kan uploade en package med det hvis det er. :)
Noget godt er der imidlertid kommet ud af dette. Chefen har fået øjnene op for denne problemstilling og vil rette en henvendelse op i systemet således at vi "dødelige" kan få det vi har brug for i vores job-funktioner. Hvordan det bliver vil tiden vise, men det skulle være maskinlæsbart og så kan vi bare skille det ikke ønskede fra via software.
Under alle omstændigheder siger jeg dig tak for hjælpen. Den har være uvurderlig (på flere planer).
Jeg arbejder i hvertfald videre med MODI_TLB her på jobben og ser hvad det kan udvikle sig til. Også mange tak for det ini'tiv. I samme åndedrag er en opgradering til MS-Off 2003 under kraftig vurdering på hjemmefronten.
Og så vender jeg frygtelig tilbage ..
("I'll be back." Citat Arnold Schwartzenegger / Terminator )..
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
