Exported images >> original file size?

Hi Dave!

The original images were inserted with the
original image properties shown as a snapshot
into the pdf-page. xtracting the image with the
original properties build the original image
again - so it's bigger?
You should use the RenderPage-functions
dealing with the dpi-values... this should
result in smaller files.

Cheers and welcome here,
Ingo



Edited by Ingo - 15 Feb 12 at 7:41PM

Hi Dave,

with 43KB is your PDF indeed rather small, so that images inside would (I guess) be high compressable and have high resolution too.

For easy rendering look at this and use the right box (cropbox or trimbox at most)
http://www.quickpdf.org/forum/size-reduction-and-dpi_topic2146.html

The rendering-idea is no solution, if you need the images in original dimensions.

Cheers,
Werner

Hi,

if we calculate without compression and headerinformations, one pixel in a b/w-image uses one bit. But in a fullcolor-format every pixel has four bytes. This is a (uncompressed) factor of 8*32=256! So 43KB grows up to approx. 11MB. So it's clear where the size comes.

But the question is why.

You should try to make your tests around getting your knowledge about the image inside. You may ask for imagetype, resolution and sizes. I guess, that QuickPDF is thinking, the embedded image is a jpg, but I guess only...

May be that the scanning app. is drawing the image into the PDF and wrong saying it is color?

You may figure out something if you make a list of all image properties QuickPDF is giving. Then this is to compare with the (if so) known data of the image source for building your test-PDF.

No real help, but a step?

Werner

Hi Dave,

FYI LibTiff .net port http://bitmiracle.com/libtiff/

Confirmed in my environment too with 8.14b5. Also tried with a TIFF LZW, PNG, GIF, and JPG files and only the JPG was returned in it's original format.  Going to streams instead of files doesn't help either.

I think the issue has to deal with the way the PDF files handle images as edvoigt was getting at.  PDF files store image data, but not image files.  If you open your created PDF with notepad, you can see your image data after the "stream" keyword.  Notice that the image data is missing the typical file type header bytes "II" to signify that it's a TIFF and just starts with the image contents.  The PDF does store the compression algorithm "/Filter /CCITFAXDECODE" so it knows how to interpret it for rendering, but it doesn't know or care that it was a "TIF" image.

So, unfortunately, returning image data is a bit more complicated than just pulling the data from the stream section, and QuickPDF obviously doesn't handle all cases as expected.

One other issue that you may run into with TIFs.  One of the properties of a TIF is rowsperstrip.  Say you have an image 100 pixels tall and rowsperstrip set to 10.  If you add that image to a PDF (with QuickPDF at least, not sure if this is a universal problem), it will actually add 10 images of 10 pixels high each.  If you go to retrieve those images, you will have to retrieve all 10 strips and merge them together (with libtif). 
I believe that the default behavior in GDI+ for windows XP is to set the rowsperstrip to the full image height, but in Windows 7 the default behavior is to set it to some set value (25?).
The only other way around this is to set the rowsperstrip property to the full height of the image.  And of course, you can't do this directly with GDI+.  LibTiff.Net has an example of doing it though.

GDI+ is also going to give you headaches trying to edit those images (standard Graphics operations wont work against images with indexed pixel types such as black and white).

So, because of the quirks with PDF, QuickPDF's and GDI+, I've found it easier to only give and retrieve Bitmap images to QuickPDF and just let it handle compression (it appears to use Flate for black and white, which is not as small as G4, but not terrible).  With .Net it's easy enough to compress an bitmap to send it across the network, then turn it back into a bitmap before dumping it in the next PDF.  This will obviously add some processing time, but at least it works. 

byte[] compressedimagedata; byte[] imagedata = QuickPDF.SaveImageDataToString(...) using (MemoryStream imagedatastream = new MemoryStream(imagedata)) {      Image image = Image.FromStream(imagedatastream);      using (MemoryStream compressedimagedatastream = new MemoryStream())      {           image.Save(compressedimagedatastream, ImageFormat.PNG);           compressedimagedata = commpressedimagedatastream.ToArray();      } }

Edited by samb - 22 Feb 12 at 5:48PM