Scan Tailor "Experimental"

[xerum]

It works well however I am not sure if it is just me but the "Page Layout" section when selecting "apply to all pages" does not seem to work or take effect.

That was indeed a bug. I fixed it and made a new release.
Most of the changes in the new version have to do with OpenCL support (check the Settings dialog). Don't expect any miracles from it though.

Thank You Tulon. Much appreciated.

[xerum]

Most of the changes in the new version have to do with OpenCL support (check the Settings dialog). Don't expect any miracles from it though.

I have GTX gamer card and just checked the settings - changed to use my GTX rather than default onboard graphics. All i can say is WOW!!

I heavily use 9.11.1 and this Tulon's STexperimental is approx 4 times faster using the above CLI set to my GTX.

[xerum]

Some feedback. I processed a scanned book 179 pages. I processed it twice - ST9.11.164bit and STexp latest by Tulon.

Scanned pages were 200 dpi (1137 x 1740 pixels).

ST9.11.1 vs STexp

Output setting = 300dpi vs 1x

Output page dpi = 300dpi vs 96dpi

scanned pages pixel specs = 1548 x 2484 vs 1049 x 1667

Resulting PDF size (no OCR) = 2,245kb vs 3,449kb << this would be due to Output page dpi

Output process speed = 187 seconds vs 49 seconds

[xerum]

i just encountered the same problem as Shinomura.

if a page only has small bit of text. e.g. "i dedicate this book to my wife and children"

STexperimental will select the content. However in the output stage it is a white page.

[dpc]

Some feedback. I processed a scanned book 179 pages. I processed it twice - ST9.11.164bit and STexp latest by Tulon.
...
scanned pages pixel specs = 1548 x 2484 vs 1049 x 1667
...
Output process speed = 187 seconds vs 49 seconds

What is "scanned pages pixel specs"? Is that the output image size? If so you've got over twice the pixels when using the 9.11.1 version of ScanTailor. Is there some way to make an apples-to-apples comparison and get these values closer to the same (possibly change output DPI?)?

Tulon, was the OpenCL accelerated work mainly focused on the improving the performance of the Output stage?

[Tulon]

Tulon, was the OpenCL accelerated work mainly focused on the improving the performance of the Output stage?

Only a few operations are accelerated by OpenCL. It shouldn't make that much of a difference. There was another source of speed-up though. In 32-bit builds of all previous official releases, inlining was disabled. This can slow things down significantly.

i just encountered the same problem as Shinomura.

if a page only has small bit of text. e.g. "i dedicate this book to my wife and children"

I finally managed to reproduce it. I'll fix it in the next few days.

[xerum]

Some feedback. I processed a scanned book 179 pages. I processed it twice - ST9.11.164bit and STexp latest by Tulon.
...
scanned pages pixel specs = 1548 x 2484 vs 1049 x 1667
...
Output process speed = 187 seconds vs 49 seconds

What is "scanned pages pixel specs"? Is that the output image size? If so you've got over twice the pixels when using the 9.11.1 version of ScanTailor. Is there some way to make an apples-to-apples comparison and get these values closer to the same (possibly change output DPI?)?

yes this was the output page specs. also the PDF out put size was meant to be the other way around. ST9.11.1 the larger size.

i'm not sure how to make them apples for apples as STexperimental no longer allows you to set DPI. It is always 96 DPI no matter whether i set 1x, 1.5x or 2x it is always 96 DPI, the only thing that increases is the output width and length pixels

one thing i do to compare PDF out put to the hard copy book is i take the width and length of the book page and i compare it to the page specs that is outputted. I'll give you examples.

width is 1548 pixels / 300 dpi = 5.16 inches
length is 2484 pixels / 300 dpi = 8.28 inches
which is about the same as the real book page just scanned

however when using the output from STexperimental it no longer conforms to this

width is 1049 pixels / 96 dpi = 10.92 inches
length is 1667 pixels / 96 dpi = 17.36 inches
these are not the same as the real book page

i'm not good with the maths of things so i maybe have the wrong thoughts with how the above should be.

[Tulon]

xerum,

Scan Tailor experimental doesn't output 96 DPI images. It's just what your software shows when DPI information is missing. If there was no dewarping / de-keystoning performed and the "Match size by scaling" option wasn't used, the real output DPI is the input DPI times the resolution enhancement factor.

Therefore it's certainly possible to do apples-to-apples comparison. You mentioned your input images are 200 DPI. If you set the output DPI to 400 in ST 0.9.11 and set the resolution enhancement in ST experimental to 2x, you'll get more or less identical output. In both cases the real output DPI is 400. ST 0.9.11 will put that value into the output images while ST experimental won't (because it doesn't know it).

[xerum]

ok - i did another test between ST9.11.1 64bit and STexperimental

this time to measure speed/performance using Tulon's new OpenCL setting to use my GTX gaming card.

165 pages scanned at 300 dpi

i processed this book identical settings using both ST versions above
ST9.11.1 was set to 300 DPI output
STexp was set to 1x output

According to Tulon this is apples for apples.

ST9.11.1 processed in 4 minutes,41 seconds
STexperi processed in 3 minutes,18 seconds

one thing i found strange this time is STexp had question mark on the right-hand thumbnails through all 6 stages making it difficult to see what the output thumbnail looked like especially as it processed output.

[0kelvin]

I see a checkbox to activate hardware acceleration for the interface, but no opencl anywhere.

either way, HD3000 doesn't support OpenCL. The only option to speed things up in my case is either multithreading and/or SSE2.