I was really excited to see this today:
“Core: Fixed various display.save() and display.screenCapture() bugs. Particularly iOS and landscape issues. casenum: 928”
… If that’s true and we finally get this licked, I will LOVE YOU FOREVER … and EVER and EVER! 
Can’t wait for 8/2.
~~Kenn
[import]uid: 13859 topic_id: 12957 reply_id: 312957[/import]
yes - 
fixed… but you will be the true test
c. [import]uid: 24 topic_id: 12957 reply_id: 47579[/import]
Hi Kenn,
The display.save() and display.captureScreen() fixes didn’t make it into the upcoming “trial” release version… but it will make it into the daily build (for subscribers) once they go public again. [import]uid: 32256 topic_id: 12957 reply_id: 47613[/import]
I am proudly paid 'n Pro … so that’s fine by me.
… well, fine assuming they go public again around 8/2 ?!? 
[import]uid: 13859 topic_id: 12957 reply_id: 47614[/import]
BTW @Carlos … Indeed…
Now, you wouldn’t know “Wedding Colors” was a Corona app unless I told you, so I’m telling you…
http://itunes.apple.com/us/app/wedding-colors/id424463712?mt=8
… The inspiration board is very cool, but there’s still a few bugs related to display.save() and screenCapture. I’ve still not submitted to the Corona Showcase cause even though it’s in the App Store, I don’t consider it really out of Beta.
… But, a few promo codes for the crew to, again, help prove Corona’s not just about the games – " Think outside the Box2D" is my current motto, i think i’m going to brand that. *grin*
YY3F7H6TF94A
4KMTHPAK3LL6
Y3KPEFMFFHPT
NMAMPE9NA4Y4
9TK33HM4M9NX
v1.1.1 is waiting for review which fixes one lock up and one crash bug … hopefully none of you run into them.
… I note this “not just about gaming” again – and off topically from this post – but I saw a note about “maybe” bumping the minimum from Andriod 2.2 cause of bad sound support. I gather it was a passing comment and not something planned … but please just remember, we’re not all creating crazy games, so any possible options to keep us non-gamers making apps for the widest possible audience is important.
^— In other words, the above app works best for us when a bride and her entire bridal party can install the app and share their inspirations and we don’t need any sound to keep them happy.
Sorry for the extended post!
Best wishes,
~~Kenn [import]uid: 13859 topic_id: 12957 reply_id: 47616[/import]
Thanks for sharing with us Kenn!
We’ll try to get the daily builds public again as soon as we can. [import]uid: 32256 topic_id: 12957 reply_id: 47740[/import]
So, does this mean that that if I have a group of objects, and I scale them to 1/2 or 1/4 of the screen, then save that group - the image won’t a 512K image at the full resolution of the screen?
PLEASE say yes! [import]uid: 13784 topic_id: 12957 reply_id: 49845[/import]
marble68,
You are correct. The display.save() function will save an image at the pixel size of the group that you are capturing with scaling applied, exactly how you see it onscreen. The capture image will also include whatever is in the background behind the group.
There is one limitation. The display.save() function cannot capture a display object (or group) that is not displayed onscreen. Meaning if your object is partially outside of the screen, then those parts outside of the screen will appear as black in the capture image. This is because this function is actually a screen capture of only a portion of the screen.
I hope this helps! [import]uid: 32256 topic_id: 12957 reply_id: 49963[/import]
Hello Kenn,
Our daily build system is back online. The newest build has the screen capture fixes that you need. [import]uid: 32256 topic_id: 12957 reply_id: 49965[/import]
Thanks Joshua!
I will make sure my stuff is being displayed before saving it.
But am I correct to understand, though, that unless I’m running this build it will continue to save the image at full resolution regardless of how it’s shown on the screen? [import]uid: 13784 topic_id: 12957 reply_id: 49969[/import]
marble68,
If by “full resolution” you mean that the image will be saved in pixel coordinates and not Corona’s content coordinates, then yes, that is how the image will be saved. This is the intended behavior. So, if you try to display that captured image in Corona then you’ll find that the image comes out larger on high resolution devices because it is scaled to fit Corona’s content coordinates. That said, you can work-around this by rescaling the image like how it is done in the Corona SDK’s sample app…
“Storage\ScreenCaptureToFile”
In the newest daily build, we’ve modified display.captureScreen() to automatically rescale the displayed capture image to fit the screen which should make it easier to deal with. [import]uid: 32256 topic_id: 12957 reply_id: 49978[/import]
Thanks! 900 downloaded and running…
But … Eh… Well there’s still some sort of issue.
Perhaps you guys have some example code of how you would import a photo from the camera roll, save it and then use that image in the app again. ?
When I load a photo from the camera on a 3GS, it is larger than the screen. So I have to scale it. Have you tried display.save on a scaled image? It does not work so good.
So of, that’s reasonable i guess. Thus, after that, I tried scaling the photo down and adding the photo to a group. That works EXCEPT for the 2 pixel black border at the top, all the time.
Perhaps you could consider providing some sample code on how one would accomplish the theoretically simple act of importing a photo from the camera roll and then saving it for use in an app? I think in doing that, you’d likely have a great tester for solving the display.save problems on all the devices.
[import]uid: 13859 topic_id: 12957 reply_id: 49982[/import]
Hello Kenn,
The captured image is almost always larger in pixels than it is in Corona’s content coordinates. Especially for high resolution devices. I’ve mentioned this in an earlier post today. This is the intended behavior and you have to rescale it yourself because display.save() cannot assume that the captured image will be displayed onscreen right afterwards.
That said, yes, we do have a sample app that shows you how to rescale the captured image to fit the screen. Please see sample app “Storage\ScreenCaptureToFile” included in the Corona SDK.
If you want to save the a screen capture to the photo library instead, then you should use display.captureScreen(true) since the display.save() function does not have that capability. The one difference in behavior with display.captureScreen() is that it captures everything onscree, including the letterbox bars. This is by design, but not necessarily what you want.
Oh and yes, we do appreciate you taking the time to test this and giving us feedback.
[import]uid: 32256 topic_id: 12957 reply_id: 49985[/import]
Ok, thanks Joshua… I do appreciate all the info and instructional stuff, but remember I have an app in the store that does this, so we’re getting a little “basic” in the instructional part here …
Posted above, with codes: http://itunes.apple.com/us/app/wedding-colors/id424463712?mt=8
That said …
When I load an image from the photo roll on an iPhone 3GS or iPad1 (i have no iPhone4 to try), and I scale the image to actually fit the screen – noting that not ALL images from the camera roll fit into a .5 scaling – some have to be scaled further down… I always get a 2 pixel bar at either the top or the side … as if your display.save function is just saving things offset by 2 pixels.
So, that said … while saving the screen to a file is cool, it’s not the example I’m talking about. Loading a photo from the camera roll – or taking a photo with the camera – and then using that photo within the app (by display.newImage’ing the display.save’d file) is a fairly basic thing we should be able to do without bugs.
I should note I have particular issues with landscape photos and photos that have been emailed to the device and saved to the roll. They may be not the same size as a regular photo, so scaling is different. But it’s my understanding that “display.save” should conform to any size as long as it’s all shown within the screen of the device.
Yes, it’s a step “beyond” a simple screen capture, but it should be reasonably easy.
[import]uid: 13859 topic_id: 12957 reply_id: 49989[/import]
Wait … buggy code.
… abort abort.
thisMainRect.x = display.contentHeight/2
should be
thisMainRect.y = display.contentHeight/2
i’ll be back to you.
lol.
[import]uid: 13859 topic_id: 12957 reply_id: 50003[/import]
… nope, this works fine. [import]uid: 13859 topic_id: 12957 reply_id: 49999[/import]
… [import]uid: 13859 topic_id: 12957 reply_id: 50000[/import]
… [import]uid: 13859 topic_id: 12957 reply_id: 50001[/import]
Thanks again. [import]uid: 13784 topic_id: 12957 reply_id: 50005[/import]
Ok … I’m trying to recraft this test case… but now what am I missing? This works fine in the simulator … but I just get a black box on the devices…
local baseDir = system.DocumentsDirectory
local fileName ="pic\_" .. os.time() .. ".jpg";
--[[###########################################]]--
-- white background.
local thisRect = display.newRect (-50, -50, display.contentWidth+100, display.contentHeight+100);
thisRect:setFillColor(255, 255, 255);
--[[###########################################]]--
local myGroup = display.newGroup ();
local thisMainRect = display.newRect (50,50,150, 100);
thisMainRect:setFillColor(220,200,200);
thisMainRect.x = display.contentWidth/2
thisMainRect.y = display.contentHeight/2
myGroup:insert (thisMainRect);
display.save( myGroup, fileName, baseDirectory )
myGroup:removeSelf();
--[[###########################################]]--
local newGroup = display.newGroup();
local tmpImg = display.newImage (fileName, system.DocumentsDirectory, display.contentWidth/2, display.contentHeight/2);
tmpImg.x = display.contentWidth/2;
tmpImg.y = display.contentHeight/2;
newGroup:insert(tmpImg);
display.save( newGroup, fileName, baseDirectory )
newGroup:removeSelf();
--[[###########################################]]--
-- display the final reloaded image back:
local tmpImg = display.newImage (fileName, system.DocumentsDirectory, display.contentWidth/2, display.contentHeight/2);
tmpImg.x = display.contentWidth/2;
tmpImg.y = display.contentHeight/2; ?
[import]uid: 13859 topic_id: 12957 reply_id: 50012[/import]