Quick question about display.save()

@Rob Miracle: I know this is an older thread, but does your comment apply to graphics 2.0 builds? If so, how do you save .PNG files with transparency using display.save() on iOS? Is there a special flag that needs to be passed? It’s not mentioned in the docs.

I’m not 100% sure, but I think you just give it a .png extension.

Rob

Yup, .png saving is definitely working. Why do colors come out completely different (darker and dull) when pixels are partially transparent though? To see what I’m talking about, create an image in photoshop and draw some strokes at like 50% opacity and then do display.save on that image… you’ll see exactly what I’m talking about.

It could be a color space issue.  What color space are you using to create the image in Photoshop?  If say you’re using AdobeRGB, it may be saving it in sRGB which can affect the vibrance of some colors.

Rob

I don’t think that’s the issue Rob, because to test your theory, I created a vector object (circle), set its fill color to (0, 1.0, 1.0, 1.0 - light blue) and set its alpha to 0.25. Then I called display.save() on it.

The color of the circle came out dull as if it was being mixed with black or gray (just as the images did). If it was a color space issue, then it should be safe to assume that the objects created and colored in corona should not be affected.

Also keep in mind that this affects *only* pixels that are partially transparent (which is why I set the alpha to 0.25). Fully transparent and fully opaque pixels don’t seem to be affected by this issue. The problem is that when creating an app with painting functionality, brush strokes are often almost never fully opaque so this issue makes it hard to “save” the user’s progress and load it back accurately.

It sounds like you have a simple enough test case.  I would invite you to file a bug report on this.  I know there are some other alpha issues that engineering is looking at and it could be related.  Use the “Report a bug” feature above and please post the bug number back to this thread as a reference.  It will also be helpful to include the URL for this post in the bug report so the engineers can reference back here.

Thanks

Rob

I’ve been using the image filters, applying them to an image and display.save() the result. Had some odd results, until I realized some of the filters end up leaving transparency in the final image. My solution was to draw a dark grey rectangle first, behind the image before I captured it. It turns out that since my image was partial transparent, what was onscreen at the time of the save showed through.

You could try drawing a white rectangle behind your image first, before your capture, to see if this bleed through is your issue. In my case, neither black nor white looked so good, so I went with a rectangle 0.25, 0.25, 0.25.

@mpappas - Thanks for the suggestion, I’ll definitely give it a shot. I did try setting the stage background (via display.setDefault) to white and got the same results but maybe it’ll be different with a rect behind.

@Rob - I have filed a bug report prior to discussing this with you on this thread, but I didn’t get a casenum when I filed the bug report. I just got a page that was basically a “thank you for filing a bug report” message.

I found the casenum in an email, it is: 28844