Scan Tailor "Experimental"

[mrelg]

Any chance of incorporating some features from Tulon's ScanTailor "Experimental" in the near future?

I think ones like margin matching by scaling instead of growing, and moving geometrical distortion to the deskew panel.

https://diybookscanner.org/forum/viewtopic.php?t=3195
https://github.com/Tulon/scantailor/tree/EXPERIMENTAL_2015_06_20

[zvezdochiot]

Hi @mrelg .

See also https://github.com/ImageProcessing-ElectronicPublications/scantailor-experimental

[mara004]

and moving geometrical distortion to the deskew panel.

I suppose you mean the other way round, moving the output stage's Deskew panel to a Geometric Distortions stage before content selection?

[mrelg]

Hi @mrelg .

See also https://github.com/ImageProcessing-ElectronicPublications/scantailor-experimental

Thank I'll check it out!

I simply can't keep track of so many repos of Scantailor, and both Google and GitHub searches ain't helping.

I hope someone will make a comprehensive list of currently active development branches.

[mrelg]

Hi @mrelg .

See also https://github.com/ImageProcessing-ElectronicPublications/scantailor-experimental

Yeah, not quite what I was looking for.
It's nice to see that development of scantailor-experimental isn't dead but altho the feature is "almost" exactly what I need, it comes with the great disadvantage of not having the rest of the features of scantailor-advanced

What I'm hoping for is a merger of the two ST forks!

My last book workflow included one pass through each of them and was a great pain to do.

[zvezdochiot]

@mrelg say:

I hope someone will make a comprehensive list of currently active development branches.

• Scan Tailor Advanced
• Scan Tailor Experimental
• Scan Tailor Universal by @trufanov-nok

@mrelg say:

What I'm hoping for is a merger of the two ST forks!

Such a merger is impossible, since STEX is fundamentally different from all other STs. In STEX, the direct order of actions and code, in the rest of ST - wrapped (STEX has one exit procedure, the rest have 2.). Because of this (direct staging), STEX consumes more memory, while the rest work with the original image until the very end. But due to the fact that the other STs work with the original image at almost all stages, they are inconvenient. Such are the things.

[mrelg]

Such a merger is impossible.

Ok I get why it is infeasible to integrate STEX into STA, but then I must ask are there any plans of enriching the STEX feature set?

[mara004]

What I'm hoping for is a merger of the two ST forks!

Such a merger is impossible, since STEX is fundamentally different from all other STs.

I believe @mrelg's point is that, in principle, combining the relevant features of both should be logically possible.
Only it's not a simple code merge because STEX is built with a fundamentally different pipeline and library framework, as @zvezdochiot says. So not actually impossible, but maybe hard.

As a lay, I would guess that re-implementing the STEX changes in question in STA, like earlier stage dewarping, would be the most reasonable approach from a user perspective.
Enriching STEX would be the other option, but I expect it'd take more effort to port all STA features to STEX than changing STA to follow the STEX order of operations.

Apart from the select usage improvements, I believe STEX is otherwise mostly of developer perspective interest because it's rewritten with Eigen lib and OpenCL.

[zvezdochiot]

@mrelg , see comment @mara004 .

[zvezdochiot]

Hi all.

STEX: 0.2023.09.13: Build for Windows by @Нубий-IV.

[zvezdochiot]

Hi all.

@noobie-iv released the first pre-release Scan Tailor Deviant (STD) v2023.11.27-alpha. This is the ScanTailor family based on STU with dewarping from STEX. The pre-release is still quite raw, but those who are curious can please familiarize themselves with the results already achieved.

[mara004]

Interesting. May I ask why you used STU and not STA as base, though?

[zvezdochiot]

@mara say:

May I ask why you used STU and not STA as base, though?

Not me, but @noobie-iv . But like me, @noobie-iv, based on the code, had the worst opinion about STA. The STU code is much more suitable for development, especially taking into account the event itself, namely the isolation of one code and the implementation of another. In STA, this task becomes an order of magnitude more difficult.

PS: If I understood correctly the idea of ​​the “deviation” of this ST family is that in the future it will be aimed at photographic material, and not at scanned material. And for such purposes, STU as a basis is much more suitable than STA.

[mara004]

If I understood correctly the idea of ​​the “deviation” of this ST family is that in the future it will be aimed at photographic material, and not at scanned material. And for such purposes, STU as a basis is much more suitable than STA.

I've already been using the various STs (and lately BookRestorer) for photographed documents. I understand the part about the perceived unsuitability of STA code, but can you, rsp. @noobie-iv, elaborate why STU should be better for photographic material than STA?

[zvezdochiot]

@mara004 say:

elaborate why STU should be better for photographic material than STA?

The STU code is much easier to modify to suit a new development vector. The STA code is tightly tied to its own functionality and is difficult to modify. (IMHO)

[mara004]

Another question: Given the renaming, it looks like this (STD) will become an independent fork. Why, though? Wouldn't it be better to target eventually merging the dewarp stage change back into STU?
I don't think good support for both scans and photographed documents were mutually exclusive - couldn't it be handled within a single program? The correction tasks seem quite similar after all: scans may also have distorted geometry, e.g. if you scan a book in a flatbed scanner (in two-page mode) there will be warp at the binding.

[zvezdochiot]

@mara004 say:

Given the renaming, it looks like this (STD) will become an independent fork. Why, though?

Because incompatibility arose already at the stage of assembly cmake files. There is no way to simultaneously protect the interests of @trufanov-nok and @noobie-iv .

[mara004]

Sorry for being so inquisitive, but could you elaborate on how this incompatibility looks like, and why it couldn't be coped with by other means?
FWIW I don't mean the short term, where the STD changes are experimental, but rather the long term.
Are this really inherently conflicting designs, or rather just different preferences in the details?

[noobie-iv]

I'm not a programmer, just a little hobbyst in a big c++ world. And forced ST user. I'm trying to add some missing features but but most likely programmers will not like the result to accept PR. For me it's easier to port the code from STEX to STU than to STA. Although maybe I'm wrong, this is just a first try. I may not even have the strength to finish the job.

I'm missing in ST:

• Multiple page sizes (Cover/page, A4/A3 e.t.c).
• Some image edit possibilities.
• Multiple image types (Text/Palette/Photo) on one page.
  

Multi-images and edit possibilities requires reworking of the program zones logic to something like this:

where page type is just a preset defining a set of typical zones and actions, but user can add/remove them. These changes will break compatibility with any other ST forks, that's why the name was changed.

But if anyone needs it, I can restore the full commit history (from original STU to STD) in the original repository (https://github.com/noobie-iv/scantailor-universal). Now it breaks in one repository and continues in another.

[trufanov-nok]

STA codebase is more solid than STU as 4lex4 put a lot of efforts to refactor it and bring it to a next level. STU codebase is worse in that sense and looks like a salad of pieces of other ST* projects mixed in without bothering to unify them. But this makes STU a bit close to original ST (not sure about STEX). So it may have a sense that STEX easier to port to STU considering that noobie-iv isn't experienced in c++.
As the STU maintainer I can state that currently project is on hold and I can't put any efforts to develop it further for at least next 1-2 years. And if I could I would continue with development of features I introduced in STU's djvu branch (*). I'm not much interested in processing stages changing etc. Keeping this in mind it's obvious that STD shall be a separate fork, so it's core developers no need to align their vision of better ST with old maintainers. Even if I would have something to contribute, I would contribute it to both STU and STD anyway due to similar codebase.

(*)

[ewguo]

Would anyone be interested in a paid project to implement the Experimental margin matching by scaling feature in Advanced? Let me know! @zvezdochiot @vigri

[zvezdochiot]

@ewguo say:

Would anyone be interested in a paid project to implement the Experimental margin matching by scaling feature in Advanced?

Not.