Announcement for Developers: Scan Tailor Plus

[daniel_reetz]

I'm on the ST developer's mailinglist, and Tulon recently announced his intention to give other developers control of a more "feature rich" branch of Scan Tailor. If you are a developer interested in making contributions to this new branch, please sign up for the list (you can find it at the Scan Tailor site) and make arrangements with Tulon.

Here's what Tulon himself had to say (on the mailinglist):

Hi everyone,

As some of you may know, my attitude to options can be summarized as
"options are evil and therefore get introduced only when absolutely
necessary". I do understand some users and developers don't share this
attitude and would prefer more options rather than less.

For this reason, I am introducing a new branch called "plus". You can
get access to it like this:
git checkout --track -b plus origin/plus

New features should always go there first. Some of them will eventually
be merged to the main branch, others won't.

The idea is for the "plus" branch to have independent releases under the
name of "Scan Tailor Plus" or maybe "Scan Tailor+". It's also going to
have independent maintainers. I am going to give them the appropriate
extra permissions on SourceForge and on Scan Tailor's website. Any
volunteers?

Although this doesn't necessarily change how we interact with Tulon here on the forums (he is and has been very generous with time and attention and I don't think we should expect that to change), it does change how the developers here interact with ST itself and how "difficult" it is for them to get changes included. Developers looking for more information can post here or go through the mailinglist - I asked Tulon specifically if I should announce here and his response was positive.

To the developers working here who are not on the mailinglist, I recommend signing up to listen to non-DIYBookScanner based progress. For example, recently one dev started working on a command-line version of ST - something we've wanted to use here for quite a while. In general, the mailinglist is low-traffic and zero-noise, and it's informative to watch progress outside the bounds of this forum.

Cheers all, and thanks to everyone for their hard work.

[spamsickle]

Great, now what am I supposed to do with that "Scan Janitor" namespace I reserved on SourceForge? I paid thousands of dollars to a graphic designer for a "Scan Jan" logo, which had Janus gazing backward at moldy yellow tomes and forward at e-readers which would make Kindles and iPads wail in shame. The IPO was set for sometime this coming Nevermber.

Nothing to do now but see if I can get those build problems on my end resolved, and go volunteer, I guess...

[Anonymous1]

Heh, now I can finally figure out how to hack things together. The algorithms are simple to do, but the GUI is such a pain. So...many...files!

[JonEP]

As a humble enduser, may I just say that for my purposes, the manual select content is brilliant. Other tweaks I'd like to see:


1. A de-keystoning feature integrated into select content. You could select the four corners of the content, which would give you the "keystone" -- and you could apply that setting to carry on through the entire series, as in the current manual select content process. Then you press play, and the result is rectangular pages.

2. An output feature that would allow you to set the size of the output image. Currently, I run ST on the rights and then on the lefts, because the dpi is often different for each camera (my rig does not allow me to get perfectly uniform camera placement or zooming for each side). Five lines of text shot with one camera may contain 200 dots, while that shot from the other may contain 180; this means that when ST outputs images, they often vary, and the resultant pdf, once the L's and R's are combined, will alternate between wider and narrower pages. I'd love to be able to tell ST that this page is 5 inches wide by 8 inches high, and have ST do a transformation to fit the output image to that page-size.

I recognize that developers may see different needs and opportunities. So please count this as just my two cents and thanks to everyone for all the great work they're doing.

[Anonymous1]

I've almost got the image size problem integrated into Bindery, but I usually just run ImageMagick through the folders once to make the pages have equal sizes.

I think it would be better to do the de-keystoning as a separate step between "Select Content" and "Deskew", as keystoning completely screws up the content box selection. Just a though that I'm never going to follow up with

[jimboh]

Just don't turn ST into something as complicated and inscrutable as ScanKromsator!

[Anonymous1]

I can't even bear to read that documentation. Maybe ST could feature a config option which allows you to do de-keystoning before selecting content? ST has a hidden "Options" menu, but it's really bare and is turned off by default.

[Tulon]

Maybe ST could feature a config option which allows you to do de-keystoning before selecting content? ST has a hidden "Options" menu, but it's really bare and is turned off by default.

I don't see it ever happening. Having a non-linear transformation in the middle of a chain would be a royal pain. I think it would actually be easier to make a separate program for page splitting and dewarping.

[Anonymous1]

Good point. I tried using that other scanning program, and I threw up on my keyboard. SO MANY BUTTONS!