trufanov-nok
commented
4 years ago Historically, as i understand, there were original ST, and 1st wave forks - Plus, Enhanced etc. which active development had been stopped at some point. The idea to combine 1st wave forks features to a single fork was obvious. Also I already had for a few months a PR to ST with so called "color layer" feature that I've implemented for myself and some other bugfixes for ST. So I forked ST to STU early Sep 2017 and created a discussion thread for it on http://publ.lib.ru. At this point I didn't know about Advanced (STA) fork at all. When I was told about it I decided that this is just one more 1st wave fork which is dead as there were no any commits for 1 year. And when STA development continued I've decided to just keep going in parallel as I had a lot of feature requests from pub.lib.ru that apparently were not addressed by STA before. Also nothing forbids copying features from one fork to another so I didn't worried about making same work twice. But this unfortunately happened as according to STA author:
STA hasn't any original STU features adapted, all the similar features, that you can see, had another implementations and was developed from scratch. Nevertheless STU gave me the ideas of those, but I rejected to adapt those features and implemented them in another way, so they even worked differently at that time.
And as my code require adaptation or even re-implementation I decided that it will be too difficult for me to contribute to STA. Also I'm finding out STU/STA little competition quite positive for community. And after some time realized that they ideologically different and target different user groups.
Original ST is a genius product. It simple and allows with a few clicks on bulk processing buttons to get nearly acceptable result for even a newbie. Then user can say - hey, that's almost exactly what I want, let's check how I can tweak text alignment to make it exactly what i need. And then he starts checking the functionality. The problem is that although ST can address 90% of tasks it still lacks some enhanced functionality and flexibility. But addition of this functionality will make ST too complicated for a newbie.
From my point of few - STA is following ST ideas (in my opinion).
In ST Universal fork (btw - "Universal", is a title proposed by users) I decided to add all features from 1st wave forks, even those that make ST overcomplicated. But hide them until they are enabled in Settings menu. Some processing parameters that were hardcoded in code I made accessible in Settings menu or just via settings.ini file. The idea was to turn ST into a Swiss knife which should be almost simple as ST (which is impossible, i guess) when closed but could be opened to a professional tool when user will be ready for it. That's why STU has quite big and verbose self-documented Settings menu.
For example, year ago I was ready to integrate optional DjVu generation by separate text/image encoding method as a new processing step after Output. Example
Another ideological difference is that Linux - is the main STU platform. If something isn't working on Linux - I don't need it at all. For this reason I almost cancelled the DjVu idea as there were no good enough native open multipage DjVu encoder for this platform. But this summer I made a small research, experimented and found out that minidjvu is not worse than documenttodjvum.exe in spite russian djvu community titled it as a "toy" encoder, it just slow as hell and it has some speed optimizations that make it 25% faster (still slow as hell) but produce documents with 25% bigger filesize. Some details in Eng and discussion with minidjvu's author Ilya Mezhirov and Leon Bottou could about my findings be found here: https://sourceforge.net/p/djvu/discussion/103286/thread/1b0de7aa93/?limit=25 Original discussion in russian is here. You may try the forked and optimized encoder for Win here. So, one day I hope to implement this DjVu feature with opensource minidjvu as default cross-platform multipage document encoder.
As STU's roadmap includes some functionality and feature requests that will be quite difficult to implement - I consider STU as a some kind of beta state and it will be so for years (or forever) as I have no possibility to spend much time on its development. I also can't react to all user requests in a feasible time. Thus I decided to not intentionally promote STU among new, ST's or STA's users. Anyway, only advanced users will find any benefits from this fork.
Another idea behind STU is to try to minimize the time user spend working with it. That's why I implement some hotkeys rather than multithreading page processing in bulk mode. I don't care much how long STU works in bulk mode as I'm drinking tea and watching youtube during that. I care a lot about how many pages I have to manually tweak before I start bulk processing.
Thus STU has many features that might seems to be useless for other users as these are my own "know how"'s representing the way I process pages. For example there is a hotkey that allows you to jump to N (default is 5) pages forward or backward. That's because I often scanning opened books with 2 pages per scan. So I can go to page 5 in ST (after split) and jump to page 10, 15 etc, checking that page number on image is 0 or 5. That's enough to make sure you aren't miss any page during scanning of a book or get numbers of missing pages if it's so. Or I'm quite often use different types of page sorting. For ex STU has Sorting by color mode of original scan. That allows to group pages which were originally scanned in grayscale and color pages. That's because I've implemented a hotkey support in KDE's skanlite and can fast switch between profiles of of scanning without opening application (I made 4 profiles: color/grayscale + 300/600 dpi.) And I scan text-only pages in grayscale and pages that contain images in color. So I can easily group color scans and change processing mode to all selected pages to Mixed. Or I can sort pages by height of content zone and check only pages in beginning and end of the list. As abnormal pages content zone will be too short or too big and the pages in the middle are normal. Which is a quite fast way to process simple text-only book. I'm using plenty of sorting techniques and even made a video and post about proper use of all these features (in russian of couse). The feature I'm proud of is a spacebar that shows you corresponding piece of original scan instead of currently processed image at output stage while pressed. This allows to estimate how bad binarization and smoothing affected the quality of original text. Or sometimes at Fill zones tab at output page to cut out letter that turned to just a black spot because of spot of coffee on paper.
And finally, I'm not tracking changes in STA except for brief look on titles in its list of commits so I just don't know and can't list the differences between our forks. Still STA has at least one feature that I'll sooner or later copy from it (it's just not the first thing in a current roadmap) - it's image pasteurization that works better than my own foreground layer mask in many cases. The list of STU features is better to grab from titles of its commits too. But it's usually a small UX tweaks.
ylluminarious
I see from your remark here that you're aware of @4lex4's ScanTailor Advanced fork and I'm curious because their repo seems possibly more featureful than this one. I'm curious about what specific things cause these two forks to differ.