Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCR for construction documents does not work, we fixed it

getanchorgrid.com

Post reply on HN
Print view View original

71–80 of 103 posts

Re: OCR for construction documents does not work, we fixed it

#71

Post by jimjimjim »

fithisux wrote: post #31
kube-system wrote: post #10

Earlier quoted context omitted.

So can any type of file -- that doesn't have any relevance to the supposed design of every file type in existence. Now, later versions of PDF do have explicit support for signatures, but what does this have to do with preventing OCR? OCR reads a file, it doesn't change the original file.

True but you can make modified copies if you reverse engineer it with OCR.

That's not really what I would call reverse engineering. If you read a pdf, and type it into word is that reverse engineering? Either way whatever you get is in no way going to convince anybody that it is the original.

Re: OCR for construction documents does not work, we fixed it

#72

Post by jimjimjim »

fithisux wrote: post #30
kube-system wrote: post #5

Earlier quoted context omitted.

Since when is tamper resistance a part of PDF or any common image format?

You can't change a PDF, it is by design to be not easy to OCRed

It is not by design! PDFs that are made from scanned documents or collections of images would require OCRing but that is true of any format that the scans/images are put into. These days the vast majority of PDFs do not need to be OCRed as the pages are just made up of text, line drawings and images. And although it can get tricky you can edit those text, line and image commands as much as you want.

For example: add this is in the contents stream for a pdf page and it'll put hello world on the page

  BT
    /myfont 50 Tf
    100 200 Td
    (Hello World) Tj
  ET
(Note: a bit more is required to select the font etc)

Re: OCR for construction documents does not work, we fixed it

#73

Post by Dylan16807 »

thaumasiotes wrote: post #69
hackcasual wrote: post #50

Earlier quoted context omitted.

JBIG2 does glyph binning, as you say not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance.

> not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance. How can we describe OCR that wouldn't match this definition exactly?

Jbig2 dynamically pulls reference chunks out of the image, which makes it more likely to have insufficient separation between the target shapes.

It also gives a false sense of security when it displays dirty pixels that still clearly show a specific digit, since you think you're basically looking at the original.

Re: OCR for construction documents does not work, we fixed it

#74

Post by thaumasiotes »

Dylan16807 wrote: post #73
thaumasiotes wrote: post #69

Earlier quoted context omitted.

> not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance. How can we describe OCR that wouldn't match this definition exactly?

Jbig2 dynamically pulls reference chunks out of the image, which makes it more likely to have insufficient separation between the target shapes. It also gives a false sense of security when it displays dirty pixels that still clearly show a specific digit, since you think you're basically looking at the original.

That's a description of Jbig2, not a description of OCR.

Jbig2 is an OCR algorithm that doesn't assume the document comes from a pre-existing alphabet.

Re: OCR for construction documents does not work, we fixed it

#75

Post by Dylan16807 »

thaumasiotes wrote: post #74
Dylan16807 wrote: post #73

Earlier quoted context omitted.

Jbig2 dynamically pulls reference chunks out of the image, which makes it more likely to have insufficient separation between the target shapes. It also gives a false sense of security when it displays dirty pixels that still clearly show a specific digit, since you think you're basically looking at the original.

That's a description of Jbig2, not a description of OCR. Jbig2 is an OCR algorithm that doesn't assume the document comes from a pre-existing alphabet.

You asked what the difference was, and I said the difference. Was it unclear that to fit the phrasing of your question, we add "OCR doesn't"? I would not personally call Jbig2 OCR.

Re: OCR for construction documents does not work, we fixed it

#76

Post by ajcp »

punnerud wrote: post #55
h317 wrote: post #51

I cannot wait for the day when tech companies become players in the construction industry because it looks like it is the only way forward to make a change. To think that everything has been digitalized a long time ago, yet contract law cannot properly deal with delineating responsibilities between GC and Architects, who are still sending 2D drawings to each other. Imagine, all this information about quantities and d…

I had a job as HVAC engineer for the upgraded Oslo Airport back in 2011; started doing HVAC work for 3 weeks the rest was programming trying to make the rest of people more efficient. Made an Excel sheet with a lot of macros to manage all the drawing of the airport. That’s why I switched to programming when I continued to study, and did not want to come back before I got more experience. They even gave me a big desk…

For what it's worth I found Oslo Airport to be one of the best airport experiences I've ever had. 5 stars.

Re: OCR for construction documents does not work, we fixed it

#77

Post by wcisco17 »

mmethodz wrote: post #70

Do that for Finnish construction documents. My parser is 30000+ lines candidate based but the lack of standards and the Finnish language...

Have you tried using it with Finnish construction documents? It should work for the detections that cover drawings.

Re: OCR for construction documents does not work, we fixed it

#78

Post by yuliyp »

thaumasiotes wrote: post #69
hackcasual wrote: post #50

Earlier quoted context omitted.

JBIG2 does glyph binning, as you say not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance.

> not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance. How can we describe OCR that wouldn't match this definition exactly?

Glyph binning looks for any chunks in the image that are similar to eachother, regardless of what they are. Letters, eyeballs, pennies, triangles, etc without caring what it is. OCR looks specifically to try and identify characters (i.e. it starts with a knowledge of an alphabet, then looks for things in the image that look like those.

If the image is actually text, both of them can end up finding things. Binning will identify "these things look almost the same", while OCR will identify "these look like the letter M"

Re: OCR for construction documents does not work, we fixed it

#79

Post by thaumasiotes »

Dylan16807 wrote: post #75
thaumasiotes wrote: post #74

Earlier quoted context omitted.

That's a description of Jbig2, not a description of OCR. Jbig2 is an OCR algorithm that doesn't assume the document comes from a pre-existing alphabet.

You asked what the difference was, and I said the difference. Was it unclear that to fit the phrasing of your question, we add "OCR doesn't"? I would not personally call Jbig2 OCR.

> You asked what the difference was, and I said the difference.

Take another look at my comment.

Post reply on HN