Page 1 of 1

Shearing for the sake of speed

Posted: Mon Mar 25, 2013 5:36 pm
by ClausFR
Greetings!

Today i downloaded the evaluation version of GdPicture 9, because we are badly in need of a well developed and fast image processing library, and GdPicture seems to include right all the needed functions.
When i tried the "Image Processing" binary from the samples folder, i noticed that rotating an image by for e.g. 3° takes quite some time, about 22 seconds. That's about the time i need, when i rotate an image in Visual Studio using the GDI+ with high quality bicubic interpolation mode. Compared to a shear function, which takes about 2 seconds and delivers quite an exceptable result for small angles, thats way too much and my boss surely would decline any investment.
There are a lot of image processing libraries, which offer an additional shear function for rotating images. Could you please think about implementing one?

With kind regards,
Claus

Re: Shearing for the sake of speed

Posted: Mon Mar 25, 2013 7:20 pm
by Loïc
Hi Claus,

I am not sure to correctly understand you need, could you clarify please?

Kind regards,

Loïc

Re: Shearing for the sake of speed

Posted: Tue Mar 26, 2013 12:38 pm
by ClausFR
Hi Loïc,

the problem is: i need to rotate 1bpp-indexed images with a size of 14664 x 10800 pixels by a small angle, because during the process of scanning the original is not always aligned correctly. That's exactly your auto-deskew function, which i have found in the "image processing.exe" in the samples folder.
An old software distribution, which my company had released a few years ago and which is not running on 64bit OSs, used to "auto-deskew" images of that size and pixelformat in about 2 seconds, by using a shear-function to rotate the image by an angle of 0° to about 3°. I need 22 seconds using auto-deskew in the "image processing.exe". Now imagine me selling an "update" for 64 bit OSs, using ten times more the time to auto-deskew. I hope you can unterstand my situation.

Here are two links about the algorithms:
http://www.ocf.berkeley.edu/~fricke/pro ... aring.html
http://www.leptonica.com/rotation.html

Kind regards,
Claus

Re: Shearing for the sake of speed

Posted: Thu Apr 04, 2013 11:13 am
by ClausFR
Hello,

i will try to explain the problem:

When i load a an image with 14664 x 10800 pixels width and height, in an 1bpp indexed format, and rotate it by 3°, then it takes about 20 to 22 seconds for the rotation.
That is the same time i need to rotate that image with 14664 x 10800 pixels in width and height, 24bpp color format in the very best quality available in the GDI+ in Visual Studio.

What i would need is something fast, which takes about 2 seconds for the rotation of that 1bpp indexed formated images.

Kind regards,
Claus

Re: Shearing for the sake of speed

Posted: Fri Apr 05, 2013 2:44 pm
by Loïc
Hello Claus,

First my apologies about the delay.

I perfectly understood what you need. And we are already working on such optimization since 6 months...

I take the opportunity to talk for the first time about our next major release. We are working intensively on a new brand Image processing/Imaging core. This one will be 100% backward compatible with the V9 and cross platform ready. Sophisticated algorithms have been implemented using all possible hardware acceleration resources (cuda, simd, hyper threading...) and by dramatically reducing memory allocation. The developer will have the possibility to customize the engine, by choosing the number of core to be used, to favor speed vs memory usage... Work is still in progress but so far I can say that Autodeskew and arbitrary angle rotation are already up to 20x faster than current versions (in quad core desktop and even in server with no GPU). Today we can't provide a date of release, work is still in progress.

With best regards,

Loïc

Re: Shearing for the sake of speed

Posted: Wed Sep 14, 2016 5:18 pm
by coloboxp
Hi

Has been achieved the hardware acceleration? (cuda, SIMD, HT)?

Re: Shearing for the sake of speed

Posted: Sun Sep 25, 2016 6:28 pm
by Loïc
Yes, this has been implemented since a long time!