Scan Tailor "Experimental"

[shinomura]

today, i just get crash with out of memory error after auto process select content.

[xerum]

today, i just get crash with out of memory error after auto process select content.

try changing the setting for "accelerate image with OpenCL" You can either
1. switch it off
2. select your CPU instead of GFX card

I found the latter - by selecting my CPU instead of my GFX card i still get good performance but have not had any crashes since.

[xerum]

Hi Tulon,

I know you said no feature requests however the below is not feature request but just a more logic way for laying out the GUI.

1. is it possible in the output stage to make buttons for mode selection instead of dropdown list. eg. Black and White / Colour Greyscale / Mixed.
Similar to how you have it for resolution enhancement 1x 1.5x 2x or the despeckling buttons.

2. Is it possible to make a setting/config where i can choose to swap the thumbnail pages that appear on the right to appear on the left and the control stages section appear on the right. i.e. swap them.
i find my workflow better if these were swapped. However appreciate others may not thus why if it could be a setting option.

3. Is it possible to make the thumbnail pages a little larger. perhaps this could be a setting also where on could set the size of thumbnails. On my screen they are so tiny.

4. This is a feature request but i will put it here and have mentioned it before. Can the select content stage be made to add and minus its sensitiveness to selecting content. much like the slider for making text thicker or thinner. But here one can make the sensitiveness more or less sensitive.

I appreciate your creation ST and am glad you came back to make the multi threading performance and geometric distortions improvements. The latter is the ultimate for my workflow. After now processing countless scans, not having to select DPI settings and the resolution multiplier is also a big bonus and am having no issues as i first thought i would with the 96dpi.

Thank you
Xe

[Tulon]

xerum,

Someone smart said the following about software development:

Developing software is a great way to have fun or to make money, but not both.

If I start working on feature requests or even start discussing them, that will kill of the fun while still not making me any money. It's a lose-lose situation. Therefore sorry, no feature requests.

[xerum]

If I start working on feature requests or even start discussing them, that will kill of the fun while still not making me any money. It's a lose-lose situation. Therefore sorry, no feature requests.

Thanks Tulon, i understand, thought i'd just try ask. I appreciate all that you have done with ST.

[d14b0ll0s]

First of all, many thanks for going back to developing ScanTailor, I couldn't stress enough how the previous version helped me in academic work.
I do enjoy using the new beta, but there seems to be one crucial issue, although perhaps I didn't get something right -- the TIF output images are not recognized by either Adobe Acrobat Pro or DjVu Editor as 'OCR'able'; what do you think might be the cause?

[Tulon]

the TIF output images are not recognized by either Adobe Acrobat Pro or DjVu Editor as 'OCR'able'; what do you think might be the cause?

They probably don't like the fact that DPI is unspecified in those. There should be some utility to set those DPIs. I would rather not bring back the output DPI setting, as most users are just not qualified to select (ideally calculate) the correct DPI. Scan Tailor doesn't know the actual output DPI either.

[xerum]

First of all, many thanks for going back to developing ScanTailor, I couldn't stress enough how the previous version helped me in academic work.
I do enjoy using the new beta, but there seems to be one crucial issue, although perhaps I didn't get something right -- the TIF output images are not recognized by either Adobe Acrobat Pro or DjVu Editor as 'OCR'able'; what do you think might be the cause?

Adobe has an issue OCRing any files that are greater than 45inches x 45 inches.

The above can occur if you are processing a large scans where the width and height pixels per page is large. As STexp outputs it at 96DPI it causes Adobe to think that the page is greater than 45x45 inches.

Simply just reduce the height/width so Adobe will accept it.

OR

Process the output files with another tool making them 300DPI.

I scan at 300Pdpi and i never use anything greater than 1x in STEXP and thus i never have any of the problems you are experiencing.
If i did use 2x or even 1.5x i would get the same issues you did.

[xerum]

i failed to mentioned that the way Adobe does it calculations is it takes the height/width in pixels and divides it by the DPI.

eg. Scanned Width = 4000 pixels
DPI = 96 DPI
therefore inches = 4000/96 = 41 inches width
Height would obviously be more. (could exceed 45inch limit)

Now if you use STEXP default resolution at 2x
It will keep the output DPI at 96dpi but double the resolution i.e. 8000 pixels wide. (you have now exceeded 45 inches limit for adobe)
IMHO there is no need for 2x if you knowingly scanned at 300dpi or more.
1x is more than sufficient.

I use to think DPI was the end all be all but as Tulon explained it many posts earlier it actually isn't as long as you knowingly scanned it at 300dpi or more). I have not found any quality issues with STEXP it is the same if not better than ST9.11.1

The fact we don't have to worry about setting/calculating DPI is a bonus. Many times i would get this wrong and end up having small/tiny pages in my ST output which i would then need to go and redo painstakingly.

Hope this helps.

[d14b0ll0s]

Thank you very much for your helpful replies, Tulon and xerum, they are much appreciated.
In fact, the easy solution worked for me -- I simply set the DPI to 600 using 'Batch conversion' in IrfanView, which is how I do final stage post-processing most of the time.

600 is the value I usually used for output TIFFs in ST911, since it gave the best results in Adobe for me, both in terms of smoothness of curves in fonts, and -- to a lesser extent -- the actual OCRed output.

I used to follow the '8 lines' rule in the past, by the use of which I ended up simply defaulting to 300 DPI with 7-8Mpix shots of book pages (double-page shots), 400 for 14Mpix, and 450 for 16. I'm sure this wasn't exactly correct, but it has worked well for me with the 600 DPI final output that I converted to PDFs with Adobe.

Thanks again. Now I'm really curious how a 4-core (8-thread) CPU that I should have at hand next week will deal with those files using STE with multi-core support (deskewing and converting to TIFFs combined, I'm getting similar results on my 2-core (4-thread) i7-3537 / HD4000 with ST911 and STE so far, since deskewing now seems to be longer as a separate process, but this may be the observer's bias, since it's separate). I wonder if the sources will compile well under OS X.