Need help saving images, and sharing a tip I discovered

Solar2D Daily Builds and Public Releases
#1

In brief:

  • landscape mode using zoomEven
  • specifically for tablets
  • have display object smaller than screen where user draws a picture
  • saving to drive, reloading image, and placing it on a ‘desktop’ as an icon

I’m using the new captureBounds feature to grab that section where this display object containing the drawing resized (reason to not save display group: when being drawn on, can change width or height dynamically if someone draws to close to the edge and needs to be cropped before saving to keep all images the same size)

This all works, BUT, the image is somehow getting stretched during save. It looks fine on the screen, saves out, gets pulled back in fine, but the bottom is cropped off a bit and it’s a tad taller than it should be. If I pull it up and edit it again, and save it again, it stretches a little more. Here’s the save function:

local contentBounds = {xMin = 10,yMin = 10,xMax = display.contentWidth-offsetWidth,yMax = display.contentHeight-offsetHeight} local capture = display.captureBounds(contentBounds, false) display.save(capture, fileName, system.DocumentsDirectory)
Like I said, it works and I can tell by the pulled in image that the crop is the right size. Why oh why is my display object stretching out under this crop as it’s being saved??? The display object is just like any display object… nothing unusual about it – just has some vectors in the group.

Also, I came up with a hack for something lacking in Corona. If you’re using storyboard, and saving images that needs to be refreshed in the UI. Make a separate storyboard scene to go to from the screen you need to refresh. On save, send the scene you want to return to as a var like storyboard.returnScene = “scenename” and use it in the goto in the dummy scene. It will go there, pause, then come back ( I have a delay as that seemed to work best). This forces the texture memory to dump, apparently. Anyway, it’s working for me so far. If someone has a better way I would bow before you in worship!

By the way, I was having stretch issues before I discovered this storyboard trick. I’ve never NOT had stretch issues.

Thanks for looking. [import]uid: 169520 topic_id: 30199 reply_id: 330199[/import]

#2

Additionally, the same thing happens on my tablet so it’s not just the sim. [import]uid: 169520 topic_id: 30199 reply_id: 120941[/import]

#3

I saw Mr. Quick suggest a couple of things here:
http://developer.coronalabs.com/forum/2012/03/24/build-772-displaycapture-image-warped-some-andriod-devices

I’ll try:

  • Make sure width/height is multiple of 4
  • Use scale instead of setting width and height

[import]uid: 169520 topic_id: 30199 reply_id: 121027[/import]

#4

Additionally, the same thing happens on my tablet so it’s not just the sim. [import]uid: 169520 topic_id: 30199 reply_id: 120941[/import]

#5

I saw Mr. Quick suggest a couple of things here:
http://developer.coronalabs.com/forum/2012/03/24/build-772-displaycapture-image-warped-some-andriod-devices

I’ll try:

  • Make sure width/height is multiple of 4
  • Use scale instead of setting width and height

[import]uid: 169520 topic_id: 30199 reply_id: 121027[/import]

#6

Nothing seems to be working for me with this. I tried using just display.save on a display group that was sized to 500x305 and when I brought it back in, it was 800x508.

This 800x508 makes NO sense to me. It’s not even a multiple of my screen rez as far as I can tell. Frustrating!

Anybody have any ideas on what is going on here? I tried the multiples of 4 and that didn’t help either. The above 500x305 is due to the size being dynamic based on screen. This is what I need, and I just don’t get what’s going on here.

Please advise. [import]uid: 169520 topic_id: 30199 reply_id: 121848[/import]

#7

So, continuing this conversation with myself, I’m no longer using the new captureBounds. I’ve reverted to display.save since they both have the same issue. It not only saves the image a different size than what it reports it should save, it also stretches per my original post. It’s always longer and cut off the bottom, and the x/y will always be off.

My display object is x:10/y:10 so here’s what I did as a stop-gap. This isn’t going to fly in the long run, but it’s working for the moment on the one tablet I’m testing on.

I set the height again before saving… squishing the image down a few pixels. In this case I found it to be stretched 11.5 pixels. then I put it BACK on the x/y 10 as it’s suppose to be so it wouldn’t put black bars. The kicker on this is that I’m having to go BACK 10, as it seems to have pushed it another 10 in the + direction.

I don’t know why I’m having to do this, but editing and saving the image over and over is working to some degree. After a few edit saves, you’ll start to see some drift.

If anyone can explain why this is happening, I would be forever grateful.

Maybe I should be reporting it as a bug? [import]uid: 169520 topic_id: 30199 reply_id: 121868[/import]

#8

Regarding [lua]display.save()[/lua] saving the image larger than how it appears onscreen, that is not a bug. What is happening is that function is doing a screen capture of your object exactly how it appears onscreen in “pixels”, so the resulting image file will likely be larger on higher resolution displays. The higher the resolution, the larger the image file will be in pixels. Does that make sense?

Now, to reload the caputred image that you saved to file, I recommend that you use the [lua]display.newImageRect()[/lua] function and specify what the width and height of that image should be in content coordinates. This way Corona will automatically scale it to match the content coordinates that you specified in your “config.lua” file and will come out pixel perfect, just like the original image. [import]uid: 32256 topic_id: 30199 reply_id: 122061[/import]

#9

Yes, the save being different size makes since. The stretch and cut off doesn’t.

I will try newImageRect. But until then, here’s some screenshots on the save portion that isn’t related to newImageRect or otherwise.

One is what the sim sees, the other is what is saved out. This is display.save on a full screen display group. It saves it out stretched and cut off on the bottom. I have tried MANY things and it’s always this problem.
hmmm. no ability to put in screenshots? Oh well, if you’d like to see them, let me know and I’ll email them to you. The bottom line is, the display group is now width and height of display (after doing many things, decided to be as simple as possible for troubleshooting). On the screen, and in the code, I’m taking this display group and saving it out using display.save. I can see by looking that the display group is complete and on the screen for saving.

The resulting image on the harddrive is stretched anywhere for 5 to 20 pixels in the Y direction. The image appears to be the “right” height as far as aspect ratio is concerned, but the resulting image cuts off at the bottom.

It’s like display.save is creating a rect at the right size, then dumping the image in for a save, but stretching it inside the correct size rect as it saves it.

Makes sense?
[import]uid: 169520 topic_id: 30199 reply_id: 122067[/import]

#10

Just to be doublely clear… I’m looking at the saved image on the harddrive… in photoshop, and not just reloading it in the sim and seeing the stretch. It is actually stretched before I ever have a chance to even apply newImageRect on a reloaded image. [import]uid: 169520 topic_id: 30199 reply_id: 122068[/import]

#11

I found the problem. It’s the sizing I had in config.lua. I’m still trying to wrap my head around how this works after reading some articles…

it’s still not sinking in for me yet, but at least I know where the problem is now.

Thanks for taking the time - Tim [import]uid: 169520 topic_id: 30199 reply_id: 122089[/import]

#12

FYI. I narrowed it down to the zoomEven. I can’t use zoomEven with any w/h numbers… even 320/480 and expect display.save to not stretch.

I’d say this is a bug. zoomEven causes saved images to be stretched and cut-off based on the bounds.

Switched to tablet numbers with zoomStretch and it’s working fine now. [import]uid: 169520 topic_id: 30199 reply_id: 122152[/import]

#13

Nothing seems to be working for me with this. I tried using just display.save on a display group that was sized to 500x305 and when I brought it back in, it was 800x508.

This 800x508 makes NO sense to me. It’s not even a multiple of my screen rez as far as I can tell. Frustrating!

Anybody have any ideas on what is going on here? I tried the multiples of 4 and that didn’t help either. The above 500x305 is due to the size being dynamic based on screen. This is what I need, and I just don’t get what’s going on here.

Please advise. [import]uid: 169520 topic_id: 30199 reply_id: 121848[/import]

#14

So, continuing this conversation with myself, I’m no longer using the new captureBounds. I’ve reverted to display.save since they both have the same issue. It not only saves the image a different size than what it reports it should save, it also stretches per my original post. It’s always longer and cut off the bottom, and the x/y will always be off.

My display object is x:10/y:10 so here’s what I did as a stop-gap. This isn’t going to fly in the long run, but it’s working for the moment on the one tablet I’m testing on.

I set the height again before saving… squishing the image down a few pixels. In this case I found it to be stretched 11.5 pixels. then I put it BACK on the x/y 10 as it’s suppose to be so it wouldn’t put black bars. The kicker on this is that I’m having to go BACK 10, as it seems to have pushed it another 10 in the + direction.

I don’t know why I’m having to do this, but editing and saving the image over and over is working to some degree. After a few edit saves, you’ll start to see some drift.

If anyone can explain why this is happening, I would be forever grateful.

Maybe I should be reporting it as a bug? [import]uid: 169520 topic_id: 30199 reply_id: 121868[/import]

#15

Regarding [lua]display.save()[/lua] saving the image larger than how it appears onscreen, that is not a bug. What is happening is that function is doing a screen capture of your object exactly how it appears onscreen in “pixels”, so the resulting image file will likely be larger on higher resolution displays. The higher the resolution, the larger the image file will be in pixels. Does that make sense?

Now, to reload the caputred image that you saved to file, I recommend that you use the [lua]display.newImageRect()[/lua] function and specify what the width and height of that image should be in content coordinates. This way Corona will automatically scale it to match the content coordinates that you specified in your “config.lua” file and will come out pixel perfect, just like the original image. [import]uid: 32256 topic_id: 30199 reply_id: 122061[/import]

#16

Yes, the save being different size makes since. The stretch and cut off doesn’t.

I will try newImageRect. But until then, here’s some screenshots on the save portion that isn’t related to newImageRect or otherwise.

One is what the sim sees, the other is what is saved out. This is display.save on a full screen display group. It saves it out stretched and cut off on the bottom. I have tried MANY things and it’s always this problem.
hmmm. no ability to put in screenshots? Oh well, if you’d like to see them, let me know and I’ll email them to you. The bottom line is, the display group is now width and height of display (after doing many things, decided to be as simple as possible for troubleshooting). On the screen, and in the code, I’m taking this display group and saving it out using display.save. I can see by looking that the display group is complete and on the screen for saving.

The resulting image on the harddrive is stretched anywhere for 5 to 20 pixels in the Y direction. The image appears to be the “right” height as far as aspect ratio is concerned, but the resulting image cuts off at the bottom.

It’s like display.save is creating a rect at the right size, then dumping the image in for a save, but stretching it inside the correct size rect as it saves it.

Makes sense?
[import]uid: 169520 topic_id: 30199 reply_id: 122067[/import]

#17

Just to be doublely clear… I’m looking at the saved image on the harddrive… in photoshop, and not just reloading it in the sim and seeing the stretch. It is actually stretched before I ever have a chance to even apply newImageRect on a reloaded image. [import]uid: 169520 topic_id: 30199 reply_id: 122068[/import]

#18

I found the problem. It’s the sizing I had in config.lua. I’m still trying to wrap my head around how this works after reading some articles…

it’s still not sinking in for me yet, but at least I know where the problem is now.

Thanks for taking the time - Tim [import]uid: 169520 topic_id: 30199 reply_id: 122089[/import]

#19

FYI. I narrowed it down to the zoomEven. I can’t use zoomEven with any w/h numbers… even 320/480 and expect display.save to not stretch.

I’d say this is a bug. zoomEven causes saved images to be stretched and cut-off based on the bounds.

Switched to tablet numbers with zoomStretch and it’s working fine now. [import]uid: 169520 topic_id: 30199 reply_id: 122152[/import]

#20

Our capture APIs don’t have problems with zoomEven. But… you cannot capture objects that are offscreen. If your object is partially offscreen, then it will be trimmed. This is because our capture APIs can only capture the pixels that you see onscreen. This is by design. We don’t consider this a bug, because, there’s no way to capture that content. So, capturing the entire background of a zoomEven app will always have its sides trimmed because its sides are always offscreen. [import]uid: 32256 topic_id: 30199 reply_id: 122875[/import]