Bruk av OCR for komplekse tekniske tegninger

Optisk tegnigenkjenning (OCR) har revolusjonert måten bedrifter automatiserer dokumentbehandling. Imidlertid er kvaliteten og nøyaktigheten av teknologien ikke tilstrekkelig for alle anvendelser. Jo mer kompleks dokumentet som behandles, jo mindre nøyaktig blir det. Dette er spesielt sant for tekniske tegninger. Selv om OCR-teknologier utenfor boksen kanskje ikke er egnet for denne oppgaven, finnes det andre måter å nå dokumentbehandlingsmålene med OCR på. I det følgende vil jeg utforske flere løsninger for å gi deg en generell idé uten å gå for dypt inn i tekniske detaljer.

Ufordringer med teknisk tegningsgjenkjenning

Når det gjelder tekniske tegninger, sliter OCR med å forstå betydningen av enkelttegn. Teknologien kan lese teksten, men den forstår ikke betydningen. Det finnes flere muligheter for ingeniører og produsenter å vurdere hvis den automatiske gjenkjenningen av det tekniske dokumentet er konfigurert riktig. Se de viktigste av dem nedenfor.

Bildkilde: Mobidev

For å oppnå kompleks teknisk dokumentanalyse, må ingeniører trene AI-modeller. Liksom mennesker, trenger AI-modeller erfaring og trening for å forstå disse tegningene.

En utfordring med blåkopier og tekniske tegningers gjenkjenning er at programvaren må forstå hvordan den skal skille de forskjellige delene av tegningen. Disse er forskjellige deler av tegningen som gir en grunnleggende idé om dens layout. Ved å skille delene og forstå hvordan de henger sammen, kan programvaren beregne begrensningsboksen.

Dette prosessen kan inkludere flere utfordringer:

• Delene kan overlappe
• Delene kan være skadet
• Etiketter kan være like langt fra to deler
• Delene kan være innbyrdes

Forholdet mellom delene er en annen mulig problem. Du må vurdere om delen er en flat del av diagrammet, en vendt del, en blokk eller noe annet. I tillegg kan det finnes andre problemer som kjede-målinger, manglende annotasjoner, implisitt definerte høyder gjennom referanse til en standard eller andre problemer.

Viktigst, kan generisk OCR ikke pålitelig forstå tekst i tegninger som er omgitt av grafiske elementer som linjer, symboler og annotasjoner. På grunn av denne fakta, må vi dykke dyptere inn i OCR med maskinlæring som vil være mer nyttig for denne anvendelsen.

Forhåndsdefinerte og tilpassede OCR-modeller

Det finnes ingen mangel på OCR-programvare på markedet, men ikke all denne programvaren kan bli trent eller modifisert av brukeren. Som vi har lært, kan trening være en nødvendighet for å analysere dine tekniske tegninger. Imidlertid finnes det OCR-verktøy for disse tegningene.

Forhåndsdefinerte OCR-verktøy

Her er noen vanlige alternativer for OCR-gjenkjenning av tekniske tegninger:

• ABBYY FineReader: denne fleksible blåkopi-tolkingsprogramvaren tilbyr OCR-teknologi med gjenkjenningsevner for tekst. Den støtter forskjellige bildeformater, layout-bevaring, data-eksport og integrasjoner.
• Adobe Acrobat Pro: i tillegg til å tilby PDF-redigering, visning og håndtering, tillater Acrobat deg å skanne OCR-dokumenter og blåkopier, trekke ut tekst og utføre søk. Den støtter forskjellige språk og tillater brukerne å konfigurere alternativer.
• Bluebeam Revu: en annen populær PDF-applikasjon, tilbyr Bluebeam Revu OCR-teknologier for teknisk tegningstekst-uttrekk.
• AutoCAD: som står for Computer Aided Design, støtter AutoCAD OCR-tillegg for å tolke blåkopier og konvertere dem til redigerbare CAD-elementer.
• PlanGrid: denne programvaren inkluderer blåkopi-OCR-tolkning ut av boksen. Med denne funksjonen kan du laste opp blåkopi-bilder og deretter trekke ut, organisere, indeksere og søke etter teksten.
• Textract: denne sky-baserte AWS-funksjonen aktiverer OCR-analyse av dokumenter og kan trekke ut elementer som tabeller fra dokumenter. Den kan også gjenkjenne elementer fra blåkopier og tilbyr API-er for integrasjon med andre applikasjoner.
• Butler OCR: som tilbyr utviklere dokument-uttrekks-API-er, kombinerer Butler OCR maskinlæring med menneskelig gjennomgang for å forbedre nøyaktigheten av dokument-gjenkjenning.

Tilpassede OCR-løsninger

Hvis du søker etter tilpassede OCR-løsninger som kan bli trent for å oppnå bedre automatisk data-uttrekk fra tekniske tegninger og tilpasse dem til din spesifikke dataformat, finnes det noen populære alternativer:

• Tesseract: denne fleksible, åpne OCR-motoren som vedlikeholdes av Google, kan bli trent på tilpassede data for å gjenkjenne blåkopi-spesifikke tegn og symboler.
• OpenCV: Open-Source Computer Vision Library kan kombineres med OCR-verktøy som Tesseract for å bygge tilpassede tolkningsløsninger. Dens bildebehandlings- og analysefunksjoner kan forbedre nøyaktigheten av OCR på tekniske tegninger når de brukes riktig.

Foruten disse verktøyene, er det også mulig å uavhengig utvikle tilpassede maskinlæringsmodeller. Ved å bruke treningsmodeller på merkte datasets, rammeverk som TensorFlow eller PyTorch, kan disse løsningene bli finjustert for å gjenkjenne spesifikke blåkopielementer og oppnå høyere nøyaktighet for organisasjonens behov.

Forhåndsdefinerte modeller tilbyr letthet og enkelhet, men kan kanskje ikke være like effektive til å tolke tekniske tegninger som tilpassede løsninger. Disse tilpassede løsningene krever også ekstra ressurser og ekspertise for å utvikle og vedlikeholde.

Tilpassede løsninger krever ekstra finansielle ressurser og arbeid for å utvikle. Jeg ville anbefale å starte med en bevis på konsept (PoC) for å validere tekniske evner og en minimum viable produkt (MVP) for å sjekke markedets oppfatning av prosjektet før du investerer for mye i en tilpasset OCR-løsning.

Prosess for implementering av en OCR-modul for å lese tekniske tegninger

Det beste stedet å starte bygging av OCR-programvare for tekniske tegninger ville være å analysere tilgjengelige åpne kildeverktøy. Hvis du uttømmer dine åpne kildealternativer, må du kanskje vende deg til lukkede kildealternativer med API-integrasjoner.

Bygging av en OCR-løsning fra scratch er upraktisk fordi den krever en enorm datasett for trening. Dette er vanskelig og dyrt å samle inn og krever mye ressurser for modelltrening. I de fleste tilfeller bør finjustering av eksisterende modeller dekke dine behov.

Prosess fra her ser ut som følger:

1. Vurdere krav: du må forstå hva slags tekniske tegninger din applikasjon skal fungere med og hva slags funksjoner og funksjonaliteter som er nødvendige for å oppnå dette målet.
2. Bildeinnsamling og forbehandling: tenk på hva slags enheter du planlegger å bruke for å innhente bildene. Ekstra forbehandlingssteg kan være nødvendige for å forbedre kvaliteten på dine resultater. Dette kan inkludere beskjæring, omstilling, støyreduksjon og mer.
3. OCR-integrasjon: vurdere OCR-motoren som vil fungere best med din applikasjon. OCR-biblioteker har API-er som tillater din applikasjon å trekke ut tekst fra innhentede bilder. Det er viktig å vurdere åpne kilde-OCR-løsninger for kostnadsbesparelse. Tredjeparts-API-er kan være ustabile med hensyn til prising over tid eller tape støtte.
4. Tekstgjenkjenning og -behandling: neste, er det tid å implementere logikk for å behandle og gjenkjenne tekst. Noen mulige oppgaver du kan vurdere å legge til i dette steget er tekstrensing, språkgjenkjenning eller andre tekniker som kan gi klarere tekstgjenkjenningresultater.
5. Brukerinterface og -opplevelse: et enkelt å bruke brukergrensesnitt for appen er viktig så brukeren kan effektivt bruke den til å innhente bilder og initiere OCR. Resultatene skal presenteres for brukeren på en måte som er enkel å forstå.
6. Testing: test appen grundig for å sikre dens nøyaktighet og brukervennlighet. Brukerfeedback er essensielt i denne prosessen.

Oppsummering

I møte med utfordringene med å lage OCR-programvare for komplekse tekniske tegninger, har organisasjonene flere alternativer tilgjengelige for å nærme seg problemet. Fra et utvalg av forhåndsdefinerte modeller og tilpassede verktøy for å skape mer personlige løsninger, kan bedrifter finne måter å effektivt analysere, indeksere og søke gjennom blåkopier og andre komplekse dokumenter. Alt det krever er litt ingeniørkunst, kreativitet og tid for å skape en løsning som møter deres behov.