Which type of data is returned by the following function?
CFDataRef CreateDatafromImage(UIImage *image)
{
return CGDataProvidercopyData(CGImageGetDataProvider(image.CGImage));
}
Binary image data
Raw pixel data
Compressed image data
ASCII image data
I guess the closest answer would be 2) Raw pixel data. Though, to be honest, I don't really see what the difference would be between Binary image data, and Raw pixel data. As for the third choice, Compressed image data, I suppose I could imagine how that could be referring to whether the NS/CFData object returned represents the compressed JPEG data (say, 100 KB) as it exists in the file, or whether it represents the data in its uncompressed form (say, 24 bit RGB, which might be 280 KB). In that case, I guess you could say that it represents the data in its "uncompressed" form.
But then, how exactly are you defining "compressed"? For example, say you have an image that is saved and has the following layout: 16 bits per pixel RGB, kCGImageAlphaNoneSkipFirst, like in the last example in this image:
Compared to the other layouts pictured, you could think of this layout as being "compressed" in some sense. (See Color Spaces and Bitmap Layout).
So, to sum up, by the time you've obtained a CGImageRef, the image is in a "native representation" that Quartz understands. The data returned from that method is the raw pixel data; the data isn't in "JPEG format", or "PNG format", or "TIFF format", etc. You can use the inquiry functions to gather information about what combination of image channels, alpha channels, and bit depth the image has: CGImageGetBitmapInfo(), CGImageGetBitsPerComponent(), CGImageGetBitsPerPixel(), etc.
Dealing with the image formats like JPEG, PNG, TIFF, etc. are abstracted into other APIs and types such as CGImageSourceRef, CGDataProviderRef, CGImageDestinationRef, and CGDataConsumerRef. See Moving Data Into Quartz 2D and Moving Data Out Of Quartz 2D.
Uh... A CFDataRef object?
The documentation is here: http://developer.apple.com/library/ios/#documentation/CoreFoundation/Reference/CFDataRef/Reference/reference.html
It's an object you can use as NSData or CFData interchangeably.
Internally a CFData is created (With the CGDataProvidercopyData) from the return value of the CGImageGetDataProvider call.
Good luck :)
It is covered in the docs (which is one of the first hits in Google).
This particular technical note covers it in detail.
http://developer.apple.com/library/mac/#qa/qa2007/qa1509.html
Related
I need to display the DICOM images in a browser. This requires, the DICOM to be converted to PNG (or any other compatible) format.
I also need to calculate some overlay pixels based on dynamic input from the user. On conversion to PNG, I am getting 4 values (Alpha, R, G, B). But I can not use these values for my calculations. I need the original HU values from the DICOM images.
Is there any way that, PNG can contain the original DICOM values. I heard that using monochromatic 16 bit PNG format it is possible. How do we do that?
Alternatively, how to load DICOM pixel data in browser preserving HU values?
When you convert DICOM pixel data to other non-DICOM format like PNG, BMP, JPG, J2K etc., the data you are looking for is lost. You may further research for TIF format whether it preserves the data and it loads in browser. I guess it will not.
I will recommend to avoid this way. Instead, I will suggest using DICOM pixel data as-is in browser. This can be achieved by involving some java-script DICOM toolkit for browsers like cornerstone. You may also look for other toolkit if available and suits you.
Note that this involves learning curve. It will be too broad here to explain its working.
Given a png image and a set of data to write to it, is it possible to overwrite pixels in the existing png in a particular area of interest? For example, If I have a block of data in a rectangle between pixels (0,0) (5,10) would it be possible to write this data as a block into a 10X10 png without any concern for the area not being overwritten? My use case is that I have map tiles where half the data will be in one tile and half in the other, with the blank pixels being white squares. I would like to combine them by simply writing the non-white pixels directly to the existing png in a block without having to open, combine, then re-write the entire png. Does the structure of a png allow this?
I'm loath to claim that this is impossible, but it is certainly complicated.
First of all, pixels of a PNG are (sometimes) interlaced, so you'd have to calculate the locations of your target pixels based on the Adam7 scheme.
Furthermore each row is independently filtered, so you'd have to transform each row of your source using the filter of the target row. Depending on the filter you'd also have to adjust additional bytes on the border of the updated target bytes. Straight from the horse's mouth:
Though the concept is simple, there are quite a few subtleties in the actual mechanics of filtering.
Finally, all the filtered bytes are compressed using a generic compression algorithm called "deflate." Unless you want to decompress the whole thing beforehand, you need to make sure both that (1) your source data can be properly decoded and (2) the bytes near the border of the target bytes are properly compressed in the context of their new neighbors.
I'm not a compression expert, so I won't argue in more detail. One piece of good news is that the algorithm seems to preserve independence between distant regions due to its sliding window scheme: data are only compressed based on data in some preceding range, say 13,000 bytes.
If this seems at all easy to you, give it a try. If you're like me, though, you'll just decode the whole thing, overwrite the pixels as bitmap data, and encode the result.
This is practically impossible because the pixels data (after a row-by-row "filtering") is compressed with ZLIB. And it's practically impossible to change part of a compressed stream.
I am trying to understand the basics behind Pixbuf and its factory methods new_from_data and new_from_stream.
new_from_data requires a string of bytes containing the image data, and other information such as bits per sample, with and height of image.
What I don't understand is why new_from_stream does not require those additional image information. Then, how can the Pixbuf know how to render the image new_from_stream does not provide any additional information other than the Gio.InputStream ?
new_from_stream() expects to get a stream of a supported image file, equivalent to new_from_file(). All the image formats contain metadata like height and width.
new_from_data() on the other hand expects a pixel buffer, which is essentially just an array of pixels without any metadata.
I used CGImageGetDataProvider and CGDataProviderCopyData and then get a pointer to the data. The first image I tested was a bmp and this method worked great. However, I changed my image to a JPG because I had read something about the Data Provider possibly being relative to the type of image. The length of that data returned indicates that it is 4 when it should be some large number representing the rows and columns of the image.
What I need is I can ask for the Data Provider to be for a bitmap so I can walk through the data uncompressed?
The data you get out of the data provider will be the data that went into creating the image. For instance, if the image was created using CGImageCreateWithJPEGDataProvider, it would be JPEG data. If you want bitmap data, you will need to make a bitmap, perhaps using CGBitmapContextCreate, and draw the image into the bitmap.
There is an app on the app store called active photo (http://itunes.apple.com/us/app/active-photo/id366798464?mt=8) that allows you to embed a hidden image or .exe file inside of an image. I would like to know how to do this regrading adding images to images, kinda like sub images in the original image.
I've been looking into metadata but no tag seems to be big enough to hold an NSData representation of the second picture.
How would one go about adding any type of file to an image, either through embedding or metadata, that would allow the image to be sent though email and or text message and still retain the data?
Thank you.
This is known as steganography.
I would imagine the simplest way of hiding a file inside a JPEG image is just to alter its pixel data in such a way that the compression doesn't damage it but is subtle enough that an interceptor can't detect the hidden data.
I don't think it is possible with JPEG because it's a lossy compression so you would end up corrupting the embedded file. But PNG uses a compression method similar to Deflate, which is loseless.
I have started writing a program like this. The idea was to hide bytes of data by splitting them into the least significant bits of pixels' color channels. Let me do some examples.
An RGB-8 image represents a pixel with 3 bytes, one for red, one for green and one for blue. I store 3 bits into red channel, two into green (human eye is more sensitive to green color) and 3 into blue. So I embed one byte per pixel. Similarly with RGBA-8 image I do 2-2-2-2. This of course involves some bitwise operations.
Things become more interesting with RGB(A)-16 images, where there are two bytes per channel. I use the entire least significant byte of every channel with minimal distortion (worst case 255 / 65535 = ~3.9%) and store up to 3 or 4 bytes of data per pixel. Not bad!!
Moreover there are no complex bitwise operations in this case, a single assignement does the job.
There are lot of improvement to it. I thought to ask the user a password, hash it and seed a secure pseudo random number generator, then no longer move pixel by pixel but instead asking the generator for a new random index.
The drawback of this solution is that the more data has already been embedded, the slower it becomes, because the generator will give more and more occupied indices. But it is much more secure in this way. To make it even more safer I thought to introduce noise data in the untouched pixels, in order to hide the positions of the true data.
As you can see you can do a lot with PNG images! If you are interested I can give the code I wrote so far.