General Discussion - Slow RenderPageToFile for TIFF

Print Page | Close Window

Slow RenderPageToFile for TIFF

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: General Discussion
Forum Description: Discussion board for Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=3871
Printed Date: 22 Nov 24 at 7:26PM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: Slow RenderPageToFile for TIFF

Posted By: Michi91
Subject: Slow RenderPageToFile for TIFF
Date Posted: 20 Dec 20 at 2:59PM

Hello QuickPDF community.

I use QuickPDF 1811 x64 to extract TIFF pages from PDF, then process them with tesseract

and merge the PDF FullText Only Document again with the orignal PDF.

That works well, my Problem is just that the RenderPageToFile and RenderDocToFile seems quite slow for big Documents and TIFF

Here is my Sample Document:

https://www.file-upload.net/download-14402446/LoreIpsum106Pages.pdf.html

With both TiffLzw and TiffG4 and with RenderPageToFile to individual pages and RenderDocToFile to a single file they both take arround 44 Seconds when converted with 300 dpi.

I would prefer to render every page to an indivdual file (RenderPageToFile).

If I use Ghostscript 9.53.3 with -r300x300 -sDEVICE=tiffg4 (so the same) it takes 5,8 seconds.

Can I accerate that?

For example is RenderPageToFile Multi Threading Capable? Could I load the document and call RenderPageToFile in different worker threads?

I am using C# + net5.0 and the x64 DLL Version DebenuPDFLibrary64DLL1811.dll

Thank you for your help and Merry Christmas

Replies:

Posted By: Ingo
Date Posted: 20 Dec 20 at 11:11PM

Hi Michi :)

is it necessary to render a page which has originally 72 dpi with 300 dpi?
Quality won't be better i think ;-)
Making 106 image files out of 1 document needs time.
If the results will be still okay for you i would try to render with 150 or less dpi...

Another option is to select another render engine like cairo for example, AGG or PDFium for better results -> https://www.debenu.com/docs/pdf_library_reference/SelectRenderer.php

Here you'll find the developer guide and much more:
http://www.quickpdf.org/

Cheers and welcome here,
Ingo

-------------
Cheers,
Ingo

Posted By: tfrost
Date Posted: 21 Dec 20 at 8:48AM

I tried rendering your file with our application which converts to monochrome 200dpi multi-page TIF, and it took about 30 seconds. It was not much different with PDFIUM. Of course a proportion of this time was spent dithering to bi-level; a color TIF should be faster, although there is more data to write. And there are doubtless many other variables which differ between your environment and mine.

The only reliable way to determine whether it is better to render pages in different threads is to try it.

Posted By: Michi91
Date Posted: 21 Dec 20 at 6:05PM

Hello Ingo and tfrost,

thank you for your quick answers.

Ingo: I guess it is not required ;) But can I quickly check what is the max dpi used in an document?

Checking all images in the file won't make it quicker?

http://www.quickpdf.org/forum/renderpage-dpi-from-current-pdf_topic2893.html

I was just suprised that Quickpdf takes 44 seconds and ghostscript COMMANDLINE 5,8 seconds for 300 dpi and the same document.

@tfrost: I think I will try multithreading, if that doesn't work I think about a way with Ghostscript.

Merry Christmas, I would come back to you both in January. :)

Posted By: Ingo
Date Posted: 22 Dec 20 at 11:53AM

Hi Michi,

render page to file doesn't mean image extraction - due to this a din a4-page you can render with 72 dpi. You can use more dpi but this won't raise the quality of the image.
Rendering only paint the pdf-page onto an image file - that's all.
QuickPDF offers real functions to extract embedded image files out of a pdf but that's another thing.
Real multi threading won't work so i think you should start trying Ghostscript.

-------------
Cheers,
Ingo