My code is just this:
<img src="uploads/619671548171334115-961656431.jpg" alt="a">
You can see this here yourself:
https://moviesre.com/ogb/addtestimonial/testtt.php
This is the image: https://moviesre.com/ogb/addtestimonial/uploads/619671548171334115-961656431.jpg
See it is not flipped, but in the web page it is displaying flipped. What's up?
Edit: Not all images are getting roated on this server. Some images with smaller file size (in pixel not memory) are displaying normal
Maybe your uploaded image is rotated, but is being corrected because it contains rotation data in its EXIF ('Exchangeable Image File Format' is all the information that is automatically embedded into an image file when a photo is taken using a modern digital camera) section.
You can see EXIF data of your local file from exifdata.com and also you can see EXIF data of your uploaded file (that server is providing to the browser) by using php function exif_read_data()
You can get full explanation this answer of #matt-gibson
Related
For many images, this code works fine to convert a PNG image to JPG:
Thumbnails.of(pngIn)
.outputFormat("jpg")
.scale(1.0)
.toFile(jpgOut);
But for this specific image:
the code results in an all-white JPG image. If someone can point me to the right way of doing things in Thumbnailator, I would very much appreciate it. Cheers!
EDIT: Well, something in the image upload / download process makes things work for the attached image! (The downloaded image is 50K while the original image is 41K, so clearly there's some funkiness going on there.) But I promise that the original PNG really does not work.
EDIT 2: This link to Google images can be used to download the 920x900 PNGWing image (41K) on the right side of the page.
The above syntax seems to be correct for converting PNG to JPG. The problem is that when the referenced image is read into a BufferedImage object, the image's type is BufferedImage.TYPE_BYTE_BINARY. While such images can be 1, 2, or 4-bit images, Thumbnailator doesn't handle 2- or 4-bit images correctly, essentially assuming that the image is a 1-bit image.
In short: the syntax is correct, but there appears to be a Thumbnailator bug that hinders successful processing of some PNG files.
my server getting too slow due magento's resize image. i am using following code for display image
echo $this->helper('catalog/image')->init($_product, 'small_image')->resize(250,250)
This is load actual image (if i upload havy image like 2mb,3mb ) if i am not using resize function but if i use this function then its always resize it to 250x250 that makes server extra work of resizing image which can be done once at uploading image
i just want to avoid this resize process so every time image will not resize it should be resized when we uploading in magento when create a product. please give me solution
just skip the resizing. Everything is done in __toString() so if you remove the resize() there is no resizing and the file is only copied to the cache.
EDIT
It is important that you have the right small image uploaded in the backend. You can upload multiple images. And set three (in standard installation image, small_image and thumbnail) in the backend. These images can be access via
$this->helper('catalog/image')->init($_product, 'IMAGE_TYPE')
So if you upload a 250x250px image, mark it as thumbnail then you can remove the resize and everything works fine.
What you can do - but don't ask me how - is to put the resized images into the cache. But there are a lot of problems, after inserting them, e.g. flush the image cache -> all images are deleted
I'm trying to get the cropped version of an image that's pulled using ALAsset. Specifically, I'm selecting items from the user's Photo Library and then uploading them. The issue is that in the library thumbnail view, iOS is showing us the cropped version. When you select that thumbnail and pull that image's asset using ALAsset, I get the full resolution version.
I did some research and couldn't find anything that helps in getting a second coordinate system of where the cropping happens.
To test it, you need iOS5 to edit the image in your library. Select an image in your image library, select "Edit", and crop the image. When you get the ALAsset you'll get the full image, and if you sync using iPhoto, iPhoto also pulls the full image. Also, you can re-edit the image and undo your crop.
This is how I'm getting the image:
UIImage *tmpImage = [UIImage imageWithCGImage:[[asset defaultRepresentation] fullResolutionImage]];
That gives me the full resolution image, obviously. There's a fullScreenImage flag which scales the full resolution image to the size of the screen. That's not what I want.
The ALAssetRepresenation class has a scale field, but that's a float value, which is also what I don't want.
If anyone can tell me where this cropped coordinate system can be found, I'd appreciate it.
Your Options:
Option 1 (ALAssetLibrary)
Use the - (CGImageRef)fullScreenImage method of AlAssetRepresentation.
Pros:
All the hard work is done for you, you get an image that looks just like the one in the Photos app. This includes cropping, and other changes. Easy.
Cons:
The resolution is "screen size", only as big as the device you are using, not the full possible resolution of the cropped image. If this doesn't concern you, then this is the perfect option.
Option 2 (ALAssetLibrary)
Extract the cropping data using the AdjustmentXMP key in the image's metadata (what #tom is referring to). Apply the crop.
Benefit:
It is possible to get a cropped image at the best possible resolution
Cons
You only get the cropping edits, not any other adjustments (like red-eye)
Who knows what Apple will support in the future in "Edit" mode, you may have to apply more edits in the future.
It's complicated, you first have to parse the XML data to read the crop rectangle, crop the unrotated image, and then apply the rotation.
Option 3 (Wishful Thinking)
Beg Apple to include a method like fullResolutionEditedImage which gives you the best possible quality photo, with all edits applied.
Pros:
Everything magically solved.
Cons:
Apple may never add this method.
Option 4 (UIImagePickerController)
This option only applies if you are using the image picker, you can't use it directly with the asset library
In the NSDictionary returned by -(void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info
You can extract the full sized, adjusted image from the UIImagePickerControllerOriginalImage key. Save this image somewhere. Then, instead of retrieving the image from the asset library, load the copy you made.
Pros:
You get the full size image, with adjustments
This is the only option Apple gives us for getting the full size image with all adjustments (like red-eye, etc), and not just the crop. This is particularly important in iOS 7 with the introduction of filters that can drastically alter the image.
Cons:
Can only be used with the image picker (not ALAssetRepresentation)
You must keep around a full-sized copy of the image. Depending on the number of such images, the disk usage by your app could grow substantially.
Update for iOS 7: you may wish to consider Option 4, or Option 1, as iOS 7 supports many operations now like filters, and your users will probably notice if they are missing. These two options support filters (and other edits), with Option 4 giving you a higher resolution result.
When a photo has been cropped with the iOS Photos App, the cropping coordinates can be found in the ALAssetRepresentation's metadata dictionary. fullResolutionImage will give you the uncropped photo, you have to perform the cropping yourself.
The AdjustmentXMP metadata contains not only the cropping coordinates but also indicates if auto-enhance or remove-red-eyes has been applied.
As of iOS 6.0 CIFilter provides filterArrayFromSerializedXMP:inputImageExtent:error: Probably you can use the ALAssetRepresentation's AdjustmentXMP metadata here and apply the CIFilter onto the ALAssetRepresentation's fullResolutionImage to recreate the modified image.
Be aware that the iOS Photos App handles JPG and RAW images differently. For JPG images a new ALAsset with the XMP metadata is stored in the Camera Roll. For RAW images an ALAssetRepresentation is added to the original ALAsset. I'm not sure if this additional ALAssetRepresentation is the modified image and if it has the AdjustmentXMP metadata. In addition to JPG and RAW images you should also test the behaviour for RAW+JPG images.
For example, I can convert the second image into NSData and then place it inside metadata inside the first image and then when I open the first image and read the metadata I can get the NSData and turn it into an UIImage.
How would I go about doing this? All the metadata tags I see are not large enough to support another picture. I know picture in picture is quite common on desktop apps so I'm interested in getting it to work on the iPhone.
Is metadata the correct way to do this or is there another way?
Is it possible, in an iPhone app, to extract location information (geocode, I suppose it's called) from a photo taken with the iPhone camera?
If there is no API call to do it, is there any known way to parse the bytes of data to extract the information? Something I can roll on my own?
Unfortunately no.
The problem is thus;
A jpeg file consists of several parts. For this question the ones we are interested in are the image data and the exif data. The image data is the picture and the exif data are where things like geocoding, shutter speed, camera type and so on are stored.
A UIImage (and CGImage) only contain image data, no tags.
When the image picker selects an image (either from the library or the camera) it returns a UIImage, not a jpeg. This UIImage is created from the jpeg image data, but the exif data in the jpeg is discarded.
This means this data is not in the UIImage at all and thus is not accessible.
I think the selected answer is wrong, actually. Well, not wrong. Everything it said is correct, but there is a way around that limitation.
UIImagePickerController passes a dictionary along with the UIImage it returns. One of the keys is UIImagePickerControllerMediaURL which is "the filesystem URL for the movie". However, as noted here in newer iOS versions it returns a url for images as well. Couple that with the exif library mentioned by #Jasper and you might be able to pull geotags out of photos.
I haven't tried this method, but as #tomtaylor mentioned, this has to be possible somehow, as there are a few apps that do it. (e.g. Lab).