display.save and resolution

Audio and Graphics
#1

Is there any way to use display.save() and have it generate an image with a *specific* resolution?  I was trying an experiment, making a dynamic image to use for a jigsaw puzzle.

I wanted to do this:

* Create a dynamic, composite image from two different images (using display.newImageRect)

* Save the new image to the system.TemporaryDirectory

* Use that new image as the source for an imagesheet.

Unfortunately, display.save() seems to be saving it at an odd resolution.  I have isFullResolution set to true, and according to the docs:

If true, the image is  not  cropped to the size of the screen of the device.

But how is it getting its resolution, then? I have 3 different sized images: 1x, 2x, and 4x. My test 288x288 (1x) image became 720x720 in the system.TemporaryDirectory.

Also, it seems like it would be awesome if you could just pass in a display object instead of a filename as the source to the newImageSheet. Then I could skip saving to the temporary directory completely.

Thanks,

Dave

#2

If you’re using content scaling, you may get unexpected results - the save is done in native resolution (NOT content resolution, see the display.save docs - http://docs.coronalabs.com/api/library/display/save.html ).

To compensate, you will need to adjust your capture area based on display.contentScaleX and display.contentScaleY (which is the ratio of your virtual pixels to current device pixels, which of course changes on different device types).

So you are saving all of the real device pixels in your display.save(), which apparently is about 720x720 on your test device (a function of your virtual content size vs. actual device pixels). Try it on a different size/format device to check for yourself. Something like an iPad 3 should produce even bigger images - given it’s large, high density screen.

There’s probably many ways to deal with it, based on what your saving/how it’s grouped etc. One technique would be something like this

[lua]

     capGroup.xScale = display.contentScaleX   – Set the groups scaling down to device pixels for capturing

     capGroup.yScale = display.contentScaleY

    local capBounds = this.CapGroup.contentBounds   – lets do a nice capture first based on the bounds, scaled down to device pix
    
    local capture = display.captureBounds( capBounds )            
    capture.anchorX = 0.0
    capture.anchorY = 0.0                  
    capture.x = 0
    capture.y = 0  
   
    display.save(capture, CaptureName, system.TemporaryDirectory)   – ok, got it. Now save it to the drive.

     capGroup.xScale = 1    – set the scale back to normal content scaling

     capGroup.yScale = 1

[/lua]

Now one might think that scaling your pretty graphics down to something like 0.48513 scale could lose resolution. But the fantastic news is that the SDK will continue to draw all of your pixels at these lower scales (sub 1:1 content scale) as long as the native resolution can hold up…

So if you take a photo for example, scale it to 50x50 *content* pixels, then display.save, you’ll end up with something like a 100x100 image, with all the pixels unique (potentially), NOT a 100x100 with duplicate pixels next to each other, etc… Anyways – this sub-pixel drawing (sub content pixel, if the device supports it), is a pretty “nifty” thing, IMHO.

#3

Thanks for the help, but I can’t get it to work properly, no matter what I do.

#4

If you’re using content scaling, you may get unexpected results - the save is done in native resolution (NOT content resolution, see the display.save docs - http://docs.coronalabs.com/api/library/display/save.html ).

To compensate, you will need to adjust your capture area based on display.contentScaleX and display.contentScaleY (which is the ratio of your virtual pixels to current device pixels, which of course changes on different device types).

So you are saving all of the real device pixels in your display.save(), which apparently is about 720x720 on your test device (a function of your virtual content size vs. actual device pixels). Try it on a different size/format device to check for yourself. Something like an iPad 3 should produce even bigger images - given it’s large, high density screen.

There’s probably many ways to deal with it, based on what your saving/how it’s grouped etc. One technique would be something like this

[lua]

     capGroup.xScale = display.contentScaleX   – Set the groups scaling down to device pixels for capturing

     capGroup.yScale = display.contentScaleY

    local capBounds = this.CapGroup.contentBounds   – lets do a nice capture first based on the bounds, scaled down to device pix
    
    local capture = display.captureBounds( capBounds )            
    capture.anchorX = 0.0
    capture.anchorY = 0.0                  
    capture.x = 0
    capture.y = 0  
   
    display.save(capture, CaptureName, system.TemporaryDirectory)   – ok, got it. Now save it to the drive.

     capGroup.xScale = 1    – set the scale back to normal content scaling

     capGroup.yScale = 1

[/lua]

Now one might think that scaling your pretty graphics down to something like 0.48513 scale could lose resolution. But the fantastic news is that the SDK will continue to draw all of your pixels at these lower scales (sub 1:1 content scale) as long as the native resolution can hold up…

So if you take a photo for example, scale it to 50x50 *content* pixels, then display.save, you’ll end up with something like a 100x100 image, with all the pixels unique (potentially), NOT a 100x100 with duplicate pixels next to each other, etc… Anyways – this sub-pixel drawing (sub content pixel, if the device supports it), is a pretty “nifty” thing, IMHO.

#5

Thanks for the help, but I can’t get it to work properly, no matter what I do.