Daniel Reetz, the founder of the DIY Book Scanner community, has recently started making videos of prototyping and shop tips. If you are tinkering with a book scanner (or any other project) in your home shop, these tips will come in handy. https://www.youtube.com/channel/UCn0gq8 ... g_8K1nfInQ

Scan Tailor "Experimental"

Scan Tailor specific announcements, releases, workflows, tips, etc. NO FEATURE REQUESTS IN THIS FORUM, please.
Tulon
Posts: 687
Joined: 03 Oct 2009, 06:13
Number of books owned: 0
Location: London, UK
Contact:

Re: Scan Tailor "Experimental"

Post by Tulon » 18 Jul 2015, 09:42

xerum wrote: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.
If you selected "No distortion" on the Geometric Distortions stage, then it's a known bug which I recently fixed.
0kelvin wrote:either way, HD3000 doesn't support OpenCL. The only option to speed things up in my case is either multithreading and/or SSE2.

The next experimental version will have multithreaded processing (several pages at a time) but only the 64-bit build.
Scan Tailor experimental doesn't output 96 DPI images. It's just what your software shows when DPI information is missing. Usually what you get is input DPI times the resolution enhancement factor.

xerum
Posts: 41
Joined: 12 Jul 2015, 04:23
Number of books owned: 0
Country: australia

Re: Scan Tailor "Experimental"

Post by xerum » 18 Jul 2015, 10:02

Thank you Tulon. I'm glad you are back. I had thought ST was discarded by new owner.

I wish to ask if it is possible at all in the "Margin" stage to program the following. I'm not a programmer so don't know the difficulty involved but will ask in any case.

The "select content" stage will have automatically/manually selected the content.

However in the "margin" stage it takes the widest/longest page scanned
It then aligns for each page the selected content horizontally
and vertically keeps the content selected as it is.

And this is what is used as the margin settings. i would call this "Auto Margin".

The intent behind this is to maintain same page content alignment as the scanned page as much as possible.

I hope i making sense.

Tulon
Posts: 687
Joined: 03 Oct 2009, 06:13
Number of books owned: 0
Location: London, UK
Contact:

Re: Scan Tailor "Experimental"

Post by Tulon » 18 Jul 2015, 16:09

xerum wrote:Thank you Tulon. I'm glad you are back. I had thought ST was discarded by new owner.
Well, I haven't returned in full capacity. These days I feel like writing some code in my free time, but I am only doing the fun parts. For instance, don't expect me to fix the command-line mode in ST experimental any time soon, as that's just not fun. The same goes for your feature request.

I am not surprised the new maintainer got tired and is not doing any maintenance these days. It's a very unrewarding role after all. And no, I don't want it back :)
Scan Tailor experimental doesn't output 96 DPI images. It's just what your software shows when DPI information is missing. Usually what you get is input DPI times the resolution enhancement factor.

xerum
Posts: 41
Joined: 12 Jul 2015, 04:23
Number of books owned: 0
Country: australia

Re: Scan Tailor "Experimental"

Post by xerum » 18 Jul 2015, 21:01

Hi Tulon,

Sometimes, when i quickly jump between stages 2 and 4, or 2 and 6 whilst i make fine tune adjustments, STexp will crash.

Xe

Tulon
Posts: 687
Joined: 03 Oct 2009, 06:13
Number of books owned: 0
Location: London, UK
Contact:

Re: Scan Tailor "Experimental"

Post by Tulon » 19 Jul 2015, 03:36

xerum wrote:Hi Tulon,

Sometimes, when i quickly jump between stages 2 and 4, or 2 and 6 whilst i make fine tune adjustments, STexp will crash.

Xe
There is little I can do unless I can reproduce it. So far I wasn't able to.
Scan Tailor experimental doesn't output 96 DPI images. It's just what your software shows when DPI information is missing. Usually what you get is input DPI times the resolution enhancement factor.

Tulon
Posts: 687
Joined: 03 Oct 2009, 06:13
Number of books owned: 0
Location: London, UK
Contact:

Re: Scan Tailor "Experimental"

Post by Tulon » 19 Jul 2015, 09:18

Here is a new experimental release: https://github.com/Tulon/scantailor/rel ... 2015_07_19

This one supports multi-threaded batch processing, only the 64-bit version though.
Scan Tailor experimental doesn't output 96 DPI images. It's just what your software shows when DPI information is missing. Usually what you get is input DPI times the resolution enhancement factor.

xerum
Posts: 41
Joined: 12 Jul 2015, 04:23
Number of books owned: 0
Country: australia

Re: Scan Tailor "Experimental"

Post by xerum » 19 Jul 2015, 10:01

WOW!!! Tulon. What have you done.

i processed 108 scanned pages (300 dpi)

ST9.11.1 64bit
output at 300 dpi
took 2min:08sec

STExp 64bit (latest)
output at 1x
took just 16 seconds
yes 16 seconds

I am using a GTX465 GPU and Intel i7-3770k CPU

xerum
Posts: 41
Joined: 12 Jul 2015, 04:23
Number of books owned: 0
Country: australia

Re: Scan Tailor "Experimental"

Post by xerum » 19 Jul 2015, 10:19

i just processed another scanned book

186 pages at 300 dpi scanned

all stages identical settings

ST9.11.1 64bit
output at 300 dpi
took 2min:29sec

STExp 64bit (latest)
output at 1x
took 22 seconds

WOW!! thank you so much for this Tulon. A few years in the waiting has been worth the wait

xerum
Posts: 41
Joined: 12 Jul 2015, 04:23
Number of books owned: 0
Country: australia

Re: Scan Tailor "Experimental"

Post by xerum » 20 Jul 2015, 06:53

More feedback for Tulon. I don't want to boast about the huge increase in performance. 600+ scanned paged books processed all less than 2 minutes each. It is surreal - i can now have 4 scanned books on the go at the same time all within minutes.

I did lots of testing with Stage3 - Geometric Distortions using Keystone and Curved Lines functions.
Not sure if it is the performance or not but am finding the curved line function performs more accurately and produces better results than ST911.
However i could not find much difference if any at all when testing bent page books between keystone and curved lines function.
All up i find the logic of putting GD at stage3 is far better for workflow than where it is in ST911.

I am finding however that Stage 4 select content seems to be less sensitive than ST911.
i.e. the content selected kept missing the page numbers at the bottom of the page for 4 of the 6 scanned books.
It would be great if at this stage 4 if there could be a feature to dial up or down the sensitiveness of the content box much like the output stage where one can dial up or down the thickness

i cannot say enough about the performance of STexp. e.g. Geometric Distortion stage where ST911 struggles to process a curved/distorted page and so painfully slow that i would normally go without this stage. STexp just whips through the pages as if they were thin air of nothing.

THANK YOU TULON

dtic
Posts: 464
Joined: 06 Mar 2010, 18:03

Re: Scan Tailor "Experimental"

Post by dtic » 20 Jul 2015, 09:08

@Xerum, Wow those are some impressive speedup stats! Could you do a speed comparison with and without GPU (OpenCL) support?

I don't know much about OpenCL so did some more digging. Here are lists of AMD/Nvidia/Intel GPUs (internal and external) with a column on OpenCL support:
https://en.wikipedia.org/wiki/List_of_N ... sing_units
https://en.wikipedia.org/wiki/List_of_A ... sing_units
https://en.wikipedia.org/wiki/List_of_I ... sing_units
I'm not sure if a specific version of OpenCL is needed (1.1 , 1.2 , ... ?) or would make a difference in terms of speed.

@Tulon, What a comeback man! This looks really great. I'll test it out as soon as I have time, will have to borrow a GPU first.
Tulon wrote:Well, I haven't returned in full capacity. These days I feel like writing some code in my free time, but I am only doing the fun parts. For instance, don't expect me to fix the command-line mode in ST experimental any time soon, as that's just not fun.
I get it and I only hope that you keep having fun! :) That said hopefully someone else tries to take a stab at getting the command line processing back with these new builds. To aid anyone capable of doing that who might be reading this, do you think it would be a matter of updating stuff here and there in the old command line code or does the new features you've added mean that the command line parts would have to be redone from scratch?

Post Reply