Support image width and height larger than 32767

[stweil]

Signed-off-by: Stefan Weil [email protected]

[stweil]

Please don't merge until these changes were better tested.

[stweil]

The modifications here allow processing of large images which fixes issue #3184. I only tested the example in that issue and did not run performance tests or measure the increased memory usage.

[stweil]

Known issues: code setting x / y / width / height to INT16_MAX or -INT16_MAX needs modifications, too.

[amitdo]

Please don't merge until these changes were better tested.

This pull request is still a work in progress Draft pull requests cannot be merged.

[amitdo]

I wonder about the impact on regular size images.

How much more memory (in percents) will be consumed with this patch?

[stweil]

How much more memory (in percents) will be consumed with this patch?

I don't have numbers up to now.

[lgtm-com[bot]]

This pull request introduces 3 alerts when merging eb8f13bea8adba3319413e78a6b67a8afb90b48b into 93348a83a324a479978d9dd399b34d15ec6c5d83 - view on LGTM.com

new alerts:

• 3 for Comparison of narrow type with wide type in loop condition

[egorpugin]

You changed int16->int32 a lot. That must be a typedef (using) for possible future changes?

[stweil]

That must be a typedef (using) for possible future changes?

Yes, the current Tesseract code uses int16_t which I replaced by int32_t for image dimensions.

I considered using a typedef, but don't think that there will be a future change for which a typedef would help. What kind of possible change do you think of?

[egorpugin]

What kind of possible change do you think of?

I agree, this may be subtle. But from programmer point of view seeing coord_t (or something like that) instead of just int32_t annotate code much better. You may note that in tess we have a lot of int vars which are hard to understand when navigating code here and there.

[stweil]

But from programmer point of view seeing coord_t (or something like that) instead of just int32_t annotate code much better.

coord_t would violate the standards which reserve types ending with "_t". I now use TDimension.

[egorpugin]

violate the standards

What standards?

[stweil]

What standards?

ISO C, see https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html.

[stweil]

Should we make support for large images an optional feature in release 5.0.0 by adding a configure option, for example --enable-large-images?

[egorpugin]

Or just ignore them. If something big does not fit into 5.0.0 soon enough, just postpone.

[amitdo]

If you choose to do it for 5.0.0, I suggest to add to the help message that explains this option:

Experimental feature (use it only for testing purpose)

and in a comment in the code itself:

For package builders: We recommend not to enable this option because the feature is unstable/untested.

[stweil]

Most parts of the initial pull requests are now in main, so support for larger images is prepared.

[monotone]

@stweil Hi, Is this feat merged to main branched? Why i just see this not changed at the tag 5.3.0 source code :

[stweil]

No, it isn't merged. This pull request is still a draft.

[monotone]

it seems some years already, what‘s the reason?