Err no. 
Just brought in an image that’s 147x220 … and I get a black line down the right side … using the main.lua you sent me. [import]uid: 13859 topic_id: 12957 reply_id: 70738[/import]
… And just some updated info:
It happens in the iPhone 4 simulator and does happen on my iPhone 4S.
It does NOT happen in the “old” iPhone (3GS) simulator.
Definitely something with scaling and rounding somehow. Evil evil bug. [import]uid: 13859 topic_id: 12957 reply_id: 70741[/import]
Well, this really bums me out. I’ll leave the bug report open and up the priority. We need this to be fixed on our end too because our new storyboard API uses it for screen transitions. [import]uid: 32256 topic_id: 12957 reply_id: 70949[/import]
@Larry: Facebook photo uploading functionality has been added as of Daily Build 2011.707.
Here’s a tutorial on how to do it:
http://blog.anscamobile.com/2011/12/uploading-photos-to-facebook-in-corona/
NOTE: The tutorial includes important information regarding build.settings for any iOS app using the Facebook API in build 2011.707 and later, regardless if you intend to upload photos or not. [import]uid: 52430 topic_id: 12957 reply_id: 74246[/import]
Quoting the title of the article.
and that’s why I will love ANSCA FOREVER 
thanks much
Larry
www.DoubleSlashDesign.com [import]uid: 11860 topic_id: 12957 reply_id: 74251[/import]
Note to self and others (cause I just spent forever looking for it), media.show now has the ability to directly save a photo from the library to a file as of daily build 724.
CoronaSDK 2012.724
Post date: Wed, 2012-01-11 06:50
Release notes for build 2012.723 through 2012.724
iOS: adds ability to save photos from camera/photo picker to disk in media.show( source, listener [, file] ). The ‘file’ parameter is an optional table, similar to how file attachments are specified for e-mail in native.showPopup, e.g. {baseDir=, filename=}. If the ‘file’ parameter is present, there will *not* be a display object created.
Core: fixes bug in table file path conversion
Android: Modified media.show() to allow you to write the selected image to a path\file of your choosing at full resolution instead of displaying it onscreen.
Core: Added boolean property “event.completed” to media.show() event. Set true if an image was successfully selected. Set false if user canceled out, if an error occurred, or the platform does not have the request media source such as a camera.
[import]uid: 13859 topic_id: 12957 reply_id: 96145[/import]
Ermmm Ok… Always so close, but ya know. 
media.show( source, listener [, file] ) does NOT save photos from the library in the correct orientation.
Assumably corona in some way knows the orientation because if it shows the image on screen, a porttrait pic is shown in portrait.
If it’s saved directly to a file, the file loaded in via newImage does NOT maintain portrait orientation. As far as I can tell everything comes back landscape.
I’m hopefully this is a simple fix that will magically appear in a daily build soon after pointing it out. 
Thanks for the ongoing efforts … the saved files are gorgeous. (Aside from the orientation issue.)
~~Kenn [import]uid: 13859 topic_id: 12957 reply_id: 96222[/import]
Kenn,
Images taken from your device’s camera typically are not saved upright. The orientation is usually saved as metadata in the EXIF section of the file. Corona is supposed to read this orientation setting and reorientate it for you when you load the image, but I’ve seen it fail before in the past with low-end devices such as the original Droid due to low memory issues.
If you run “adb logcat” on your device, are you seeing any low memory warnings? Specifically, the following message…
“Not enough memory to rotate image”
[import]uid: 32256 topic_id: 12957 reply_id: 96374[/import]
Hi Josh,
Thanks for the quick response.
Unfortunately, it fails on my iPhone 4S running 5.1 … opening only 1 image … no other apps running. It really shouldn’t be an issue with device resources…
If I choose to not save to a file, Corona shows the correct portrait orientation on screen.
I just downloaded the data from the device and can confirm that actually the pic is showing as portrait in the files when I view them in Finder and Preview. Indeed, this seems to NOT be a media.show issue.
But then any thoughts on what do to about the EXIF data being ignored and/or lost with display.newImage?
I had considered that I could keep the height / width from the object and figure it out based on that… BUT if you choose to save media.show to a file, you don’t get an object back. *poke*
Best,
~~Kenn [import]uid: 13859 topic_id: 12957 reply_id: 96382[/import]
Hi Kenn,
This sounds like a bug in the iOS version of Corona. It’s Corona’s job to read the EXIF and rotate it. I’ll have someone on our side re-test it.
So just to verify, you have not tested this on Android, right? It should work correctly on that device… not that it does you any good if the iOS version is not working right.
And by the way, I was partially thinking of you when I recommended that this API change be made. We just need one more API that allows you to save a local image file to the photo library without doing a screen capture and then we should be golden. [import]uid: 32256 topic_id: 12957 reply_id: 96384[/import]
Yes, you are correct – iOS tested only.
And yes, we’re getting there with these API’s!
Notes:
I posted in the daily build forum, but I can’t get display.capture to do anything I’d expect it to… and I need that to save images found on web pages to one’s camera roll. (Since they are different sizes, etc.) Currently, I’m dropping them on a white background and display.captureScreen’ing them – it’s awful.
My last big request would be a way to resize them an image file. IE; I don’t exactly need a full size pic from an iPhone 4S camera. I’d love to be able to scale that based on custom dimensions or something. OR I don’t know if there’s anything to tap into, but the sizes iOS gives when you email a photo to someone (like small, medium, large, full size) would be ideal.
Just some more thoughts.
Thanks and best,
~~Kenn [import]uid: 13859 topic_id: 12957 reply_id: 96393[/import]
… And one last note/thought – It seems the Mac Simulator ignores the save to file in media.show … is that known/expected?
Thanks,
~~Kenn [import]uid: 13859 topic_id: 12957 reply_id: 96396[/import]
Hi Kenn,
I have confirmed that this is an iOS bug only (does not occur on Android). I’ll write up a bug report for this issue. I’m guessing (have not confirmed) that the EXIF metadata is not being saved to file. I don’t think there is any work-around for this issue unfortunately. We’ll have to fix it on our end.
The Corona Simulator (Mac and Windows) does not support this save-to-file feature yet… they ignore the 3rd argument. This is why we haven’t documented this API change. We were trying to keep it on the down low until we were ready to finish it. We’ll get to it. We just have some higher priority tasks to take care of first.
You can size the photo to the exact proportions that you want via the display.newImageRect() function. That’s the easiest method. Please see the following API documentation…
http://developer.anscamobile.com/content/displaynewimagerect
[import]uid: 32256 topic_id: 12957 reply_id: 96407[/import]
Oh wait. I take back what I said about using the display.newImageRect() function. That function may stretch the photo if you do not know original dimensions of the image. The trick is to downscale it proportionally after loading it. Have a look at this…
[lua]-- Downscale the photo proportionally to fit the display’s bounds, with a bit of margin.
local image = display.newImage(“myPhoto.jpg”)
local xScale = (display.contentWidth * 0.75) / image.contentWidth
local yScale = (display.contentHeight * 0.75) / image.contentHeight
local scale
if (xScale < yScale) then
scale = xScale
else
scale = yScale
end
if (scale < 1) then
image:scale(scale, scale)
end[/lua] [import]uid: 32256 topic_id: 12957 reply_id: 96412[/import]
Thanks Josh – note my note about having downloaded the image files stored from the app – it DOES appear that the EXIF data is saved since Finder and Preview both rotate the photo the correct way… it’s display.newImage which seems to ignore the EXIF data. *shrug* ?
Also, right on the scaling thing for onscreen SIZE – but the problem isn’t that, it’s the FILE size. There’s a large overhead / delay in loading full size iPhone 4S images cause the quality is amazingly high. I don’t need them in “full glory” per se.
If I give someone a board and they add 20 pictures from their photo library to it, the system still has to load 20 one meg JPG files… meanwhile, I would probably only need files with a 300kb “quality”. Thus the system is loading and managing 20 megs of photos when I really only need 6 megs of photos in this example.
(err… i’m probably underestimating file size with 1 meg… I think raw iPhone 4S files are closer to 2 megs?)
Hope that makes sense.
[import]uid: 13859 topic_id: 12957 reply_id: 96421[/import]
Thanks for the info. I’ve noted the EXIF issue with the display.newImage() function.
Okay, so you want the photo that you’re saving to file to have reduced quality and size to minimize the space it takes on storage… or at least speed up how fast it write to file, right? I don’t really see us implementing something like that anytime soon. Perhaps when we make Corona more extendable so that you can write your own Lua API extensions via Objective-C and Java then that would be the solution. Hmm… [import]uid: 32256 topic_id: 12957 reply_id: 96430[/import]
Yes … More worry about reading the files. Think scrapbook page with lots of photos on it that one can move around. None of the photos use the whole screen, they can two finger shrink/enlarge them to show many.
So, aside from just reading the files, I don’t know if there’s a point that I worry about having too much image memory used? It does take about 10 seconds to open a “page” with about 6 or so full size iPhone 4S pics on it, which is getting a little on the “that’s too long” side.
Indeed, the Lua thought for handling the resize is good. I would be fine to do it via any means. I will look around and see if there’s any Lua functions for resizing an image from a file without anything “extra” … A quick search makes some references to GD and the like which I assume we don’t actually have access to? Haven’t tried.
Thanks again,
~~Kenn
[import]uid: 13859 topic_id: 12957 reply_id: 96487[/import]