I've noticed that there are differences between GD\IM\GM rotations when importing and non seem to get the thumbnails accurate.
Seems all but GM seems to mess up the aspect ratio in the slide show since the EXIF data isn't cleared.
Would like to see the Originals left alone and thumbnails and slideshows auto rotated based on EXIF data or UI controls. Also Would like to stress that the EXIF and X*Y data be accurate so no other viewers try to re-rotate the images again.
Testing with Umbuntu using the current SVN (pre Beta3)
Regards,
Mike
Posts: 7985
I havent been able to reproduce this. Can you provide us with a link to your gallery where we can see the problem happening?
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git | help! vote!
Posts: 12
I Will create a two galley with some samples switching from GD to IM between to see the difference and post a link asap.
To further the discussion, I think the root of the problem isn't either graphics library but more a problem with most windows photo editors including Explorers simple Rotate Left\Right Function.
Seems most editors don’t wipe the EXIF rotation bits in the metadata nor do they swap the X and Y axis for 90 or 270 rotates. After these products rotate the image it's now dependant on the viewer to decide if it's going to rotate it again. Seems like all Cooliris (BTW Great product) viewers will examine the exif and then re-rotate accordingly. All the thumbs and resizes within gallery don’t rotate based upon the EXIF data, but will display the metadata (if option enabled) so an unedited image appears wrong in Gallery but then correct in Cooliris. If I then rotate them using windows explorer, they will then be correct in Gallery but wrong in Cooliris unless I wipe the exif data. I’ve even seen circumstances in cooliris where the photo rotation was correct, but still using the wrong aspect ratio.
My latest half fix is to just wipe the exif headers off any existing edited photos with jhead.exe. This will force no futeher rotation and will use the X*Y of the physical image.
For current shoots, prior to uploading I use an auto-lossless rotator to fix the images. http://www.annystudio.com/software/jpeglosslessrotator/ Thankfully that tool fixes the exif correctly.
As a programmer I see a few options
1) We need to exif auto-rotate our images the same as cooliris does. This is going to exacerbate the problem within gallery but at least won’t leave users wondering why the slideshow is messed up.
2) We import and build our thumbs and resizes (auto rotating a possible option), but then strip the exif from the jpg so no further rotation is possible but we do keep the exif data in the database for display if user has exif option enabled.
Also this scope of this problem isn’t limited to Gallery, there are people all over the web especially Ebay and PhotoBucket contending with the same dilama all because of sloppy photo editors.
As a simple test take a JPG from an SLR rotated 90 left or right and right-click rotate it in windows and add it to gallery with Image Magic enabled then try it again GD. Look at it in Gallery and Cooliris 3D.
Regards,
Mike Pisano
Posts: 12
Ok I created a test account and uploaded some images to show the problem
My Rotates using windows seem to be working now although I used vista instead of XP so that might also be a factor.
My Imports with IM active failed to show correct aspect ratio
Example Photo attached:
Also My Rotates using Corel\PSP failed when viewed in Cooliris
Gallery is public at www_CasaPisano_com/Gallery3
User: test
Pass: test
Thanks Again
Mike
Posts: 7985
Awesome, thanks for the info. I've created this ticket: http://sourceforge.net/apps/trac/gallery/ticket/615
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git | help! vote!
Posts: 42
Is there any way to move the target for this bug from 3.1 to 3.0? I can try to help out with the code if needed. 3.0 is a non-starter with this bug for me because I have to import 10000 pictures from gallery2. I don't want to manually rotate - it's just going to take too long.
Posts: 569
i've updated this ticket. i have modified the autorotate module on my install to modify the Exif data on the rotated image to reflect a non-rotated image, so that external applications won't re-rotate. I haven't committed it to git yet, as i'm not sure whether we want to limit this functionality to just the autorotate module, or include it in the g2import module as well. it relies on an external library, so to avoid having duplicates in the system, it would be best to implement this system-wide as opposed to on a module-by-module basis.
--

For PHPNuke, phpBB2, and phpBB3 integration help, please visit NukedGallery.net.
Posts: 7985
It's too risky to put this into 3.0. If we keep adding big stuff, we'll never get stability and put out a real release.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git