Your Opinions For An Alternative Book Scanning System

[cemagan]

Hi Guys, (valuable members of the great diy book scanner forum!)

My name is Gem, from Turkey. I'm new here, and very interested in designing amateur book scanner systems. Because I'm a researcher in Turkish Natural Language Processing, I need Turkish texts from various kinds of books to work on. As anyone know, traditional book scanning is a very time consuming task for human and destructive task for books. So I'm trying to find a speedier and gentle to run, practical and low-cost to construct solution for book scanning.

As far as I understand, the most important sub tasks of auto book scanning;

• flipping pages automatically
• obtaining as flat as possible photos of pages
• keeping books and pages at most suitable position while photographing

* * *

I have seen the videos of some nice and intelligent amateur auto book scanner designs from enthusiasts on the web. They mostly rely on electronic hardware and mechanical parts.

For scanning pages automatically, typically a turning wheel is used to fold the paper and a thin metal arm is used to flip the folded page. The biggest difficulties of these systems are:

• contact position of the folding wheels is changing during scanning so wheel must change its touching position according to the current page to scan.
• Towards the end of the scanning the wheel fold more than one page at once because there are not enough pages under the current page to provide enough friction resistance.

For obtaining images of pages; pages are typically flattened by pressing a glass surface from top or pressing triangular flatteners from upper - lower points of the bookbinding and photographed by orthogonally positioned digital cameras. Main drawback of these designs is again the changing of the position of the contact point of flatteners. And of course some damage on the bookbinding.

For keeping pages fixed for photographing, moving page holders are used in some designs. Because while scanning first pages there is a risk for scanned pages to flip back because of the force by the other pages haven't been scanned yet.

* * *

You have probably heard about "auto page flipping book scanner" BFS-Auto developed by some researchers of a Japanese University.

They've found a high speed and gentle solution for auto book scanning. Their system mostly rely on a software they developed. This system works in this way:

• The book is fixed by a press from its binding.
• Pages to scan are hold by an arm. Arm presses pages from top with metal bars (and heavy springs around them) on it.
• Pages are flipped by releasing the arm and some air blowing. To this purpose arm is shifted out the book by turning the long screw attached to it.
• Photos of the pages are taken by high-speed cameras (500 frames per second - perhaps the most costly part of the system) at their natural positions without being flattened. An extra photograph is taken with laser lines on the pages to capture the 3d form of them.
• Pages are reconstructed to its flat forms by using their 3d form information and their actual photos with a special software before passed to OCR.

The system is more advantageous in many directions, I think:
- speedier
- simple mechanism for page flipping
- no destruction on binding

But in my opinion, the biggest drawback will be its price. Because there are prices beginning from 15 K $ on the web for high speed cameras which take minimum 500 frames per second at a reasonable resolution.

* * *

Recently I've come across some OCR software with page curvature correction feature. Some examples:

DocScanner (Mac/Iphone/Ipad/Android):
http://www.docscannerapp.com/2011/01/24 ... ture/ebook


ABBY Fine Reader(Windows):
http://www.abbyy.com/ocr_sdk_windows/ke ... amera_ocr/




And maybe If I have enough time, I can try to develop an open source automatic perspective and color correction tool for book digitization. There are some source codes for inspiration and starting point

These days these are some ideas flying in my mind about if we can build a system with:

• an auto page flipping mechanism similar to that of BFS-Auto but with lower speed (because our photographing will be much slower than that of BFS-Auto)
• two cheap compact digital cameras with macro shooting (like canon a810)
• a 3d perspective correction software

I'm just a computer engineer so I haven't enough knowledge about mechanical parts. If you share your opinions about making a similar auto page flipping mechanism to that of BFS-Auto, we can construct an alternative low-cost diy book scanner

And of course If I find or develop a free solution to page curvature correction I share here. I'm looking for it.

Finally, I'm really happy to find this Forum, there are a lot of useful information and good guys

[daniel_reetz]

There's a lot to unpack here. Thanks for your post.

We developed a laser-based scanning prototype a while back.
Scan Tailor (and others) do dewarping according to the lines of text on the page.
There are many mechanical page turner prototypes on the forum, including dtic and jck57.

I highly recommend a trawl through our R&D and New Technologies area.

[cemagan]

There's a lot to unpack here. Thanks for your post.

We developed a laser-based scanning prototype a while back.
Scan Tailor (and others) do dewarping according to the lines of text on the page.
There are many mechanical page turner prototypes on the forum, including dtic and jck57.

I highly recommend a trawl through our R&D and New Technologies area.

Thanks a lot Daniel for the links. I'm going to examine them carefully.

[daniel_reetz]

Another thing, if you're exploring automated scanning - and idea that I think is unique to this forum (and that I "claim" as my own) is that if the scanning is truly automated, it doesn't matter if you only get a page or two a DAY. Because the overwhelming majority of the life of a book is spent NOT being read. 500pages a second isn't worth nearly as much as 100% confidence that the page has been turned and captured.

[cemagan]

Another thing, if you're exploring automated scanning - and idea that I think is unique to this forum (and that I "claim" as my own) is that if the scanning is truly automated, it doesn't matter if you only get a page or two a DAY. Because the overwhelming majority of the life of a book is spent NOT being read. 500pages a second isn't worth nearly as much as 100% confidence that the page has been turned and captured.

Daniel, you're absolutely right. From my point of view the confidence is more important than speed, too. Simplicity and cost of the mechanism are the other criterion that I care.

[cemagan]

By the way on the website of BFS-Auto, the developers claim that their auto page turning machine achieved almost 100% success rate of turning pages at around 300 pages/min.

http://www.k2.t.u-tokyo.ac.jp/vision/BF ... dex-e.html

I'm not sure how much that information is true, but if It's true a great breakthrough

I wonder which electronic and mechanical components might be used to build an auto page turning machine like this...

[dpc]

... it doesn't matter if you only get a page or two a DAY.

I get your point, but one page per day is a bit unrealistic. For example, I have ~100 books in my personal library to scan. The average book in my collection is composed of 300 pages. At one page per day, I'd be looking at over 82 years just to photograph the pages of my library (which will undoubtedly grow over that time). Of course, once you have this bulletproof automated scanner, I suppose you could build more of them and increase your throughput, but is that really practical?

If one were to step back and look at the entire book scanning process and what takes the most of the"hands-on" time, it typically isn't the acquisition of images. With a dual-camera Hackerspace scanner you could easily scan a 300 page book in about 15 minutes. So there's a theoretical maximum of 15 minutes of "hands-on" time that could be saved if you completely automated the process and built a bulletproof page-turning scanner.

Now let's look at the remaining piece of the book scanning process - post-processing. This is what takes a collection of images and turns them into a searchable PDF (or whatever "readable" file type desired). How long does this stage typically take you and how much "hands-on" time does it take?

For me, this is a huge time sink. It's an order of magnitude greater than the acquisition phase, especially with books that contain a lot of photos, drawings, or diagrams (like my 100+ math or graphics programming texts I need to scan). While the computer running ScanTailor/Acrobat Pro/ABBYY is grinding away unattended for a number of its tasks, there are a number of operations that may take it 15 minutes or less that then wait and require my attention. Therefore post-processing currently isn't something I could just let run to completion unattended overnight and have a completed PDF in the morning.

So this Is why I feel that rather than chase the Holy Grail of automated page turning, the more realistic productivity gains are going to come through software that completely automates the post-processing step. The other big win in taking this route is that software automation of the post-processing phase scales incredibly well. The per-page work can be distributed across multiple cores, or even across multiple machines on a network relatively easily. Finally, it's worth mentioning that once this software is developed, it's far easier to get it into the hands of everyone to immediately reap the productivity gains compared to having them build a page-turning device from a kit to increase their throughput.

Anyway, enough rambling for the day. Thoughts?

[cemagan]

Hi dpc,

If one were to step back and look at the entire book scanning process and what takes the most of the"hands-on" time, it typically isn't the acquisition of images. With a dual-camera Hackerspace scanner you could easily scan a 300 page book in about 15 minutes. So there's a theoretical maximum of 15 minutes of "hands-on" time that could be saved if you completely automated the process and built a bulletproof page-turning scanner.

You are right for a book with 300 pages. And what about technical books or encyclopedia of more than 1000 pages. Also what about continuity and parallel working? How many books can a human scan consecutively? Because book scanning requires physical power and patience And how many friends can we convince to scan books for us? If we have book scanners with reliable page turning, we can operate them in parallel and continuously without worrying about fatigue by simply changing the books scanned.

For me, this is a huge time sink. It's an order of magnitude greater than the acquisition phase, especially with books that contain a lot of photos, drawings, or diagrams (like my 100+ math or graphics programming texts I need to scan). While the computer running ScanTailor/Acrobat Pro/ABBYY is grinding away unattended for a number of its tasks, there are a number of operations that may take it 15 minutes or less that then wait and require my attention. Therefore post-processing currently isn't something I could just let run to completion unattended overnight and have a completed PDF in the morning.

This is an important point dpc, thanks for the information. I haven't used these software yet but as you say, there are some troublesome cases at post processing phase. I think this is why Google's scanners and BFS-Auto use laser or IR line projectors to capture the 3d form information to dewarp the page images.

[daniel_reetz]

For me, this is a huge time sink. It's an order of magnitude greater than the acquisition phase, especially with books that contain a lot of photos, drawings, or diagrams (like my 100+ math or graphics programming texts I need to scan). While the computer running ScanTailor/Acrobat Pro/ABBYY is grinding away unattended for a number of its tasks, there are a number of operations that may take it 15 minutes or less that then wait and require my attention. Therefore post-processing currently isn't something I could just let run to completion unattended overnight and have a completed PDF in the morning.

So this Is why I feel that rather than chase the Holy Grail of automated page turning, the more realistic productivity gains are going to come through software that completely automates the post-processing step. The other big win in taking this route is that software automation of the post-processing phase scales incredibly well. The per-page work can be distributed across multiple cores, or even across multiple machines on a network relatively easily. Finally, it's worth mentioning that once this software is developed, it's far easier to get it into the hands of everyone to immediately reap the productivity gains compared to having them build a page-turning device from a kit to increase their throughput.

Anyway, enough rambling for the day. Thoughts?

I agree, I think for most values of "capture" the problem has been solved to death. I still think auto page turners are a great idea, BUT the biggest hit right now is in the post-processing. So... what would a good post-process workflow look like? I'm at the point that I'm ready to start offering software bounties to get work done if people are willing to go that way.

[dtic]

I think we need to separate postprocessing goals for content with only black and white text (and graphs/figures that can be handled as black and white text) and for content with color and more complex images and figures.

Here is a suggested workflow that should currently be feasible to put together for black/white text cases. Some steps involve Windows software. But some replacement script could there be made for Linux.

1. a script collects images from plugged in camera SD cards, sorts them in L/R folders, rotates and renames them in order 1,2,3,4...
2. manual step: use BookCrop to crop the L and R batches separately. Time: < 1minute.
3. A script loads images to Scan Tailor.
4. manual step: user sets DPI value (Or could this be automated reliably already?) Time: < 1 minute.
5. A script skips Scan Tailor steps 1-2 (since already done) and then processes step 3-4.
(The automatic deskew in step 3 is very reliable if the physical book scanner takes photos with fairly little skew).

6. manual step: user readjusts selections. Time: this is the most time consuming step! The number of user actions can be decreased a bit using this script. But improving Scan Tailor could save a lot of time here. I think the main problems are when (1) Scan Tailor misses content in the header/footer of pages e.g. page numbers and (2) Scan Tailor positions content incorrectly, e.g. text on a title page starts further down from the top but will be top aligned by Scan Tailor in automatic mode. Scan Tailor enhanced has some tweaks for problem 2 but doesn't fix it completely. Note that two types of improvements can be had here. First, better automation in Scan Tailor would decrease the amount of manual adjustment needed. Second, improving the GUI and functions in Scan Tailor can decrease the time and number of actions that a fixed number of manual adjustments requires. For the latter see e.g. this discussion.

7. A script does step 5 and 6. Step 6 can be sped up using multiple CPU cores
8. A script feeds the finished output to a djvu or pdf tool, including OCR. There are several working solutions here already.
9. manual step: set filename.
10. A script makes a backup of the the raw and processed images and Scan Tailor files.

Some things to aim for:
- decrease time for the manual steps
- move manual steps together so they can be done in one go. E.g. do name input now at 9 earlier.
- speed up processing in between the manual steps that can't be moved, e.g. 5.

As long as step 10 is included in the workflow then, for some actual use cases, 100% accuracy isn't necessary since flaws in the finished document discovered later on can be handled by going back and manually redoing some step.

Furthermore for some use cases, e.g. someone converting their own books to digital format for personal reading or backup, it makes most sense to for now aim only at a degree of accuracy really needed for actual, good enough use during the next few years. Because software will likely improve a lot over time and backed up images can be reprocessed in the future. Besides, more and more book content will likely be freely or inexpensively available in the future anyway, through expanding digital public libraries and/or some pay per month service. The same goes for physical capture: only spend time now on capturing what you actually need in digital format over the next few years or want to keep but don't have space to store physically.