In my cocoa application , I need to save each page of the pdf as a jpg .. How can i proceeed using Objective C
Using pure Objective-C (Cocoa and PDF Kit), iterate on the pages of your PDF document, and for each one, create an NSImage whose size is that of the media box of the page, lock focus on it, tell the page to draw, create an NSBitmapImageRep with the focused view (the image), unlock focus on the image, then ask the bitmap image rep for the JPEG data and write that data to the file. (This solution sucks; don't use it.)
Another way is Core Graphics and ImageIO. Create a bitmap context matching the media box and color space of the document, then for each page, create an image destination for the JPEG file, get the page from the document, draw the page in the context, create a CGImage from the context, clear the context using CGContextClearRect, add the image to the destination, and finalize the destination.
Related
I'm updating an existing macOS app with new images.
One of them is a vector image in PDF format. When I add the PDF to an image set, Xcode determined a size for it:
The existing dialog has a larger image, so this new one renders smaller. However, I should be able to scale it to whatever size I like as it's a vector image.
It seems the size comes from metadata in the PDF file. The Inspector in Preview shows:
Are there tools I can use to tweak those values? I don't want to resample the PDF or use tools like ImageMagick - as I said, this is a vector image.
I'm working on a photo viewer. In this context, I wrote a small class to be able to read and use some EXIF data, as e.g. image orientation. This class works well for reading.
However, I would add a new option to rotate photos. I want to rotate and write the photo data itself, not just rewrite the orientation tag. I already wrote the code to rotate and save the primary JPEG image, and it works well. But I also need to rotate the thumbnail contained in the EXIF data, if any, to keep the image coherent. For this reason I need to write in the EXIF data, to replace the existing thumbnail.
But this raises some questions, that I've some trouble answering, namely:
Can the EXIF data contains more than 1 thumbnail, and if yes, what is the maximum thumbnail count that an image can contain?
What are the supported formats for thumbnails? (I found JPEG and TIFF, are there other?)
Is there any guarantee in the EXIF standards that the thumbnails are always written in the late EXIF data, just before the primary image?
If not, then each tags containing an offset that points to a location beyond the thumbnail to replace should be updated. So, is there a standard way to iterate through all tags and sub-directories, to recognize which EXIF tags contain offsets, and to update them if needed? Or the only way is to read a maximum of tags and rewrite only that are known?
Or is there a way to guarantee that the size of the newly rotated thumbnail will be smaller or equal to previous thumbnail size to replace with?
Regards
Here are some answers for your questions:
1) The EXIF data is laid out like a TIFF file with 2 pages. The first page is the camera information and the second page is the thumbnail. If you add more pages (with thumbnails), 99.99% of the applications probably won't notice since you'll be doing it differently than the "standard" way. As far as "maximum count", you have 64k of data that can be stored in any JFIF tag. You can put what you want in that 64k.
2) There is only 1 supported EXIF thumbnail format: TIFF. Inside the TIFF there can be compressed (JPEG) or uncompressed data. Again, you're welcome to stick LZW-compressed data in there, but most apps probably won't be prepared to display it properly.
3) The JFIF container format allows for tags with metadata to appear before the main image. The APPx tags contain metadata that can follow the standard or not. You're welcome to stick multiple EXIF APP1 tags into your files, but again, most apps won't be able to properly handle that situation. So the simple answer is that the EXIF data (including thumbnail) must come before the main image and if you put more than 1 thumbnail it will most likely be ignored.
4) If you are modifying a JFIF (including the metadata), you must rewrite the metadata. It's actually quite simple because each tag is independent and has a simple length value instead of relative offsets.
5) You can do anything you want with the size/orientation of your thumbnail as long as you make the EXIF APP1 tag data total size fit within 64k.
Here's what you need to do...
1) Read the source image (and thumbnail if present).
2) Prepare your rotated image (and thumbnail).
3) Write the new metadata with the new thumbnail image.
4) Write the new main image.
If you want to preserve the original metadata along with your new thumbnail, it's pretty easy. Just read the original tags and hold on to them, then write them in the new image. Each JFIF tag is just a 2 byte identifier (FFxx) followed by a 2 byte length and then the data. They can be packed in almost any order and there's no hard limit on how many total tags can appear before the main image.
IKImageBrowserView does create thumbnails (show images in the browser view as opposed to an empty rectangle) for certain image formats, but also for PDFs and certain movie formats.
For which file types does IKImageBrowserView create thumbnails by default?
I could nowhere find any information about this in the Apple documentation.
this question is in close relation to Firefox 3.5 color correction hack?
The situation I have is that there's a canvas game of mine, and the images that are used in it carry additional information about their shape, connection points etc. This information is stored in the PNG image itself, using meaningful colours (eg RGB(255,255,0) for connection point).
Loading element and painting on the canvas creates Image object, img.src is set, and in img.load function I preprocess image data reading the sensitive information (and removing sensitive pixels from the image data before painting to canvas).
The problem: In FF, the pixel which was supposed to be 255,255,0 is actually 255,254,0. I don't have problems with FF color correction (I don't care if the displayed image has right colors, or slightly modified), but I'd expect that getting image data gives me uncorrected data. I'm looking for a solution which would not involve changing images on the server. Is there some way? Eg.
img.setColorProfile(), or
img.disableColorCorrection(), or
img.getImageData(disableColorCorrection) or img.getImageData(colorProfile)?
The problem might have do more with image loading than image drawing.
I think the proper solution is to strip out color profile information from the images (which you seem to want to aovid). If possible server another image resources for Firefox if you cannot need to have the original data intact.
http://f6design.com/journal/2006/12/01/fixing-png-gamma/
Also, you could decode PNG immages in pure Javascript if the server is co-operate and allows CORS and AJAX loading of the images. You decode the image in Javascript using png.js and create a source <canvas> from the image data (instead of <img>). This way it's you in the control what RGB values comes out from each PNG pixel.
https://github.com/devongovett/png.js
I am a bit confused about what the best approach is to resize a JPEG file on disk and save the resized JPEG as a new file to disk (on Mac OS X with Cocoa). There are a number of threads about resizing, but I am wondering what approach to use. Do I need to use Core Graphics for this or is this framework "too much" for a simple operation as a resize? Any pointers are welcome as I am a bit lost.
Core Graphics isn't “too much”; it's the right way to do it.
There is a Cocoa solution:
Create an image of the desired size (the destination image).
Lock focus on it.
Draw the source image into it.
Unlock focus on it.
Export it to desired file format.
Write that data somewhere.
But that destroys metadata.
The Core Graphics solution is not a whole lot different:
Use an image source to load the image and its metadata.
Create a bitmap context of the desired size with the source image's color space. (The hard part here is making sure that the destination context matches the source image as closely as possible while still being in one of the supported pixel formats.)
Draw the source image into it.
Capture the contents of the context.
Use an image destination to write the image and metadata to a file.
And the Core Graphics solution ensures that as little information as possible is lost along the way. (You may want to adjust the DPI metadata, if present.)
Install and use ImageMagick.