I'm rendering a PDF file on my iPad using a graphics PDF context. The PDFs vary in size but may be up to 90 pages. I need a background image on each page but if I simply draw it the PDF file size will be way larger. Is there a way to kinda only add it once and 'share' it somehow across pages?
Thanks
The PDF format specification enables you to re-use objects "by reference". You can re-use any object multiple times that is defined only once. Usually that happens with fonts, logos, background images, watermarks, ICC profiles, ....
I did a test where I repeated a background image behind each PDF page. Surprisingly, the file size increased by a single and constant amount, regardless of the number of pages with repeated backgrounds.
The verdict: The drawing to PDF context libraries are smarter than you might think.
Related
I've read many of the png vs. jpg threads here and elsewhere. I didn't find this aspect covered for small images that are downloaded from a server.
A short recap:
Xcode optimizes png images that are delivered with the app bundle in a way that they are optimized for the iOS hardware ("png magic")
png images support transparency (which I don't need)
png is the better choice from graphics, jpg for pictures (we have pictures)
I'm building an app that periodically downloads feeds that contain links to thumbnail images (size 80x80). These images are presented side by side the text content in a tableview. I can influence which format is used (jpg, png) on the server side.
If I use an uncompressed png format, it will have about 17k size for one image. This is quite large. And since this png doesn't use the "png magic" of Xcode, the iPhone still might need quite some cpu to get them into the table view compared to an "Xcode prepared" png.
The same image as a compressed jpg is only 3k which is great.
Question: are there lab comparisons that show the real world performance of these 2 formats?
Another one: has anyone used jpgs of a similar size (80x80, 3k) successfully in a table-view?
Many thanks in advance
What do you mean "lab comparisons"? PNG is going to do better with flat colors -- it uses variations on run-length and dictionary encoding as I understand. JPEG will be better with images containing subtle gradients, and loses data mostly in jumps in luminosity which are hard for the human eye to see. "Better" here refers only to file size. It sounds like you would want JPEGs here.
I'm looking for a way to reduce PDF size that I generate with Quartz. I'm drawing images with CGContextDrawImage in a CGPDFContext. What I'm afraid of is that the images are saved as Bitmap and not JPEG. Is there a way to check for that and a way to control that when writing the PDF?
I also tried reducing downscaling the image before writing it to the PDF context but I end up with an even larger file (although the page size in pixels is smaller).
Thanks!
There is no public API for setting CGPDFContext's image compression settings.
I'm not sur if you need to reduce PDF on the iPhone or if it's acceptable for you to reduce them on a PC/Mac.
On PC/Mac, Adobe Acrobat Pro (a commercial product not to be mistaken with Adobe Reader) has a PDF optimizer. Menu "Adavanced" > "PDF Optimizer...". This can downscale images, fonts, etc. As there is also a command-line interface (using AutoBatch). It isn't cheap but it's probably the best PDF compressor out there.
I have a PDF reader that displays pages of the document. What I want to do is allow the user to draw over the PDF in a transparent view. Then I want to save the drawing (UIImage) to disk. If at all possible, I don't want to have the documents folder filled with files like documentName_page01.png, documentName_page02.png for every page that is drawn over.
However, I can't figure out how to store these UIImages into a single file without it becoming unwieldy and memory intensive.
Any ideas appreciated.
What is the user drawing, just lines, rectangles, circles and so on? Maybe store colors and paths of what needs to be drawn, put all of that into an NSArray and serialise that. That might be easier than trying to put multiple UIImages into a file, will use up less space on the device, and might be faster to load. Then just recreate the drawings.
Use Core Data to store your images in Binary Data fields and retrieve them from there. This way, you won't fill your Documents folder with images, no matter how many PDFs of how many pages you have. Here's a tutorial showing you how to do this.
What is the best way to use the custom UI graphics on the iPhone?
I have come across CGContextDrawPDFPage and Panic's Shrinkit. Should I be using PDF's to store my vector ui graphics and loading them using CGContextDrawPDFPage to draw them.
Previously I asked what way Apple store their UI graphics and was answered crushed png. The options are I can think of are below, but I'm also interested in any other techniques...
PNG (bitmapped image)
Custom UIView drawing code (generated from Opacity)
PDF (I've not used this method, is it with CGContextDrawPDFPage?)
This question is for vector graphics only (but I guess some people may only use bitmapped?). Looking for what is standard / most effective / most efficient.
Edit: Bounty added, I'm interested to hear the process of anyone who works with UI designers, or are themselves a UI designer. And pointers on resolution independence i.e. for iPad / iPhone HD future proofing.
Many thanks
Ross
I can suggest 3 different ways, 2 of which you already mentioned:
Creating custom UIView.
Drawing in a CGLayer.
loading from PDF.
Each have their advantages, depending on what you want to do:
UIView vs CGLayer
In terms of performance (for one-time drawing) and ease of use there shouldn't be much difference between the two (there are minor differences, but nothing serious). Apparently Opacity can export source code for both (I haven't personally used it). That said, there are things you should consider before choosing:
If you have a fixed image (which your question suggests so), use CGLayer. CGLayer objects will be cached on the graphics device, so re-using them is much faster. Even if the cache is cleared, you're still using the same object for redrawing, meaning there's no need for re-creating it.
On the other hand, if you need to change your drawing as the user interacts with the app, UIView could be faster, as you have the flexibility of updating just one part of the image instead of the whole view.
CGLayer is independent of the UI. So the same code works fine for Mac/iPhone/iPad, or even for saving to files.
Conclusion: Use CGLayer, unless it's a special case.
CGLayer (In code drawing) vs PDF (loading from file)
I don't have any benchmark for this, but I expect CGLayer to be slightly faster: (1) there's no need to read a file. (2) the pdf commands should be converted to system's graphic elements, which is more or less the same as creating a CGLayer. (3) I'm not sure about how pdf pages are cached, but I don't expect it to be faster than CGLayer. Anyway, all this shouldn't make much difference unless you want optimization till the last millisec. Again, the choice should be based on your use case:
CGLayer gives you more flexibility in the code. Your only access to a pdf page is through CGContextDrawPDFPage, which means even simple tasks such as scaling/transforming the drawing will be harder.
Using PDFs on the other hand, is more flexible after finishing the code. You can simply update the pdf file with a new whenever you want, load it from the web, etc. .
Creating a pdf could be easier than coding the drawing. You can use any app you want, you don't need to worry about the API and system resources. After all, the code can output a pdf file, not the other way around.
Conclusion: If you don't need to do much with the drawing (just want to show an icon or something), go with the pdf. if you need to work on it in the app, consider CGLayer.
Of course you could always mix the approaches as you see fit: e.g. Load a pdf file, put it in a CGLayer to adjust it, draw it with a UIView where you can put a badge on it!
I stumbled over this question because I have a question about PDFs too. I'm working together with a UI designer and we are succesfully using PDFs to create UI elements. For example: For a button we have 3 PDFs for ON, OFF and the shadow. I wrote a piece of code that transformes a PDF into a UIImage. It can scale the resulting image and even colorize it to have one template for many styles of buttons. It works pretty good :)
Our problem is that we can't scale up the vector graphics without quality loss. That's why we decided to use graphics that are big enough and we only have to scale them down. But I still wonder if there's a way to scale up a PDF before drawing it to a context and create a UIImage. Here's my post.
I have an iPhone application that downloads images from the internet and saves them for display later.
The user can select the images to view from a UITableView, the table view has custom cells which display thumbnails of the original images in varying sizes.
When the large image is first downloaded it is scaled to thumbnail size and the thumbnail is saved using UIImagePNGRepresentation.
What I would like to do is save the thumbnail in the optimized iPhone PNG format. How can I do that? does it happen magically just by loading the original large image into memory and saving it? Do I have to do any further processing on the thumbnail before saving?
Chances are the UIImagePNGRepresentation does not create the images, as they are non-comformant PNGs, and can't be read by anything else. If they API generated PNGs that could not be read I think it would document that, and anyone who uploads PNGs from the phone would notice that they did not work.
The optimization is useful, but most of the optimized PNGs are part of the UI where the optimization is done as part of the build process. Chances are the cost of performing the optimization will offset any gains you get from it.
So it turns out that the RGB565 colorspace used in the optimized format is simply not available in a CGGraphicsContext, which is the rendering class used by all the UIwhatever components.
So if I DID write some code to change the color space of the image before saving it, I couldn't get the texture back into a UI class. The only way to use it is to load it directly into the OpenGL innards and use OpenGL in my app.
Don't worry about the "optimized PNG" format, as it isn't making any significant difference.
It does not affect rendering speed at all, and loading speed is dictated by file size more than file format.
So simply save it in a format that will give you smallest files. If you're not using transparency, then it might be JPEG.
If you need transparency, and can spend more CPU time when saving images, then include pngquant in your program (it's under BSD-like license) and shrink those PNGs to 8-bit palette.