pdf to very large image....

[FOLTZ James]

I need to turn a PDF file  into an image file ( jpeg, png or Tiff)  at high density.

This obviously may require a very large bit map to image the PDF before moving it to the image file.

I  (naïvely ?) tried this

src= CGImageSourceCreateWithURL(PDFUrl, NULL);

imageDestination = CGImageDestinationCreateWithURL( JPEGUrl, kUTTypeJPEG , 1, NULL);

CGImageDestinationAddImageFromSource (imageDestination, src, 0, JpegPropertiesDic )
CGImageDestinationFinalize (imageDestination);

expecting that quartz would automatically create an imaging stream from file to file to honor the request.

This produces no runtime error , but does absolutely nothing ! the JPEG output is empty, despite the fact that the JpegPropertiesDic dictionary

properly describes the image density..

Obviously , the following code

src= CGImageSourceCreateWithURL(PDFUrl, NULL);

imageDestination = CGImageDestinationCreateWithURL( JPEGUrl, kUTTypeJPEG , 1, NULL);

ImageRef = CGImageSourceCreateThumbnailAtIndex(src,0,DataOptionsDict);

CGImageDestinationAddImage(imageDestination, ThumbImageRef, NULL);
CGImageDestinationFinalize (imageDestination);

does the job, but uses an CGImageRef which holds an incore bitmap, hence fails with large images or densities.

Is there a proper way to image a PDF file into an jpeg (or png,tiff,..) file ( jpeg,..) without going through the memory ?

Sincely

James

[David Duncan]

On Sep 25, 2011, at 4:00 PM, FOLTZ James wrote:

Is there a proper way to image a PDF file into an jpeg (or png,tiff,..) file ( jpeg,..) without going through the memory ?

Not really, but unless your on iOS, the memory probably isn't that big a deal. If you are on iOS, you can create a memory mapped temporary file, use that mapping as the backing of a bitmap context and then draw to it (and later convert to your final format).

--

Reality is what, when you stop believing in it, doesn't go away.

Failure is not an option. It is a privilege reserved for those who try.

David Duncan

[FOLTZ James]

We are under OSX... our app generates pdf file of technical drawings on  very large page sizes. Customers wants to image these drafts for communication purpose, with good quality

which means 300 to 600 dpi... 

So a 2 meters x meters pdf pages @ 300 dpi  is 2.23 GB.  the allocation fails at drawing context creation... ....   @600 dpi we explode the memory ...

James

---

From: David Duncan <rinc...@mac.com>
To: FOLTZ James <foltz...@yahoo.com>
Cc: "quart...@lists.apple.com" <quart...@lists.apple.com>
Sent: Monday, September 26, 2011 2:17 AM
Subject: Re: pdf to very large image....

[David Duncan]

On Sep 27, 2011, at 5:36 PM, FOLTZ James wrote:

> We are under OSX... our app generates pdf file of technical drawings on very large page sizes. Customers wants to image these drafts for communication purpose, with good quality
> which means 300 to 600 dpi...
> So a 2 meters x meters pdf pages @ 300 dpi is 2.23 GB. the allocation fails at drawing context creation... .... @600 dpi we explode the memory ...

Are you a 32-bit application then? Does this happen if you make your app 64-bit?

--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.

David Duncan

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (Quart...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/quartz-dev-garchive-50095%40googlegroups.com

This email sent to quartz-dev-g...@googlegroups.com

[FOLTZ James]

What if the machine have only 4 GB of RAM ? . Will the Virtual memory mechanism allow for allocations of those very big buffers which might be far larger than the availble memory ?

thx

James

----- Original Message -----
From: Yoshiaki Katayanagi <ka...@hh.iij4u.or.jp>
To: FOLTZ James <foltz...@yahoo.com>
Cc:
Sent: Wednesday, September 28, 2011 3:25 AM
Subject: Re: pdf to very large image....

Hi, James.

>We are under OSX... our app generates pdf file of technical drawings on very large page sizes. Customers wants to image these drafts for communication purpose, with good quality
>which means 300 to 600 dpi...
>So a 2 meters x meters pdf pages @ 300 dpi is 2.23 GB. the allocation fails at drawing context creation... ....  @600 dpi we explode the memory ...
>James

You cannot allocate large bitmap buffer more than 2GB under 32 bits programing mode. You can do it in 64 bits mode, up to 65500 pixels for each width and height. You can allocate more than that, but some drawing api will fail. I did create 40000 x 40000 NSBitmapImageRep, draw into it, and save as jpeg, tiff, png and others, tested on Mac OS X 10.6.

Yoshiaki Katayanagi
http://www.jizoh.jp/english.html

[David Duncan]

On Sep 28, 2011, at 3:03 PM, FOLTZ James wrote:

What if the machine have only 4 GB of RAM ? . Will the Virtual memory mechanism allow for allocations of those very big buffers which might be far larger than the availble memory ?

Yes, although performance will likely suffer if you need to go significantly beyond physical memory (depending on access patterns etc).

--

David Duncan