Urgent, JPG quality / compression

Solar2D General Questions/Discussion
#21

I am taking a picture with the camera, showing it onscreen and then using display.save()

Corona will save in jpg format if you give it a filename with .jpg, and it will save in png format if you use ,png in the filename.

Now, with build 1074, the png files are still pretty huge (apparently lossless or close to it, with alpha as well). So, I’ve switched back to jpgs…

The good news is that the jpg quality on iOS went way up (filesize increased pretty good too, to about the old png size). It’s ok by me - the images look great!

However, the saved jpg quality on android is not nearly as good. And the file sizes are 1/10 the size of the iOS saved jpg images – I am saving a 480x720 image on android, and the file size is only 24kb. That’s like a thumbnail filesize – but it’s almost a fullscreen image on my droid… Not the best quality…

So, when users take images on droids, and my app tries to scale them and save them using display.save… The result is not so pretty…

The final result: It looks like they vastly increased the quality of the jpg compression on iOS… Kudos on that. Maybe the Android jpg compression will get a little quality adjustment next :slight_smile:

#22

I just had a look at the code and iOS saves JPEGs at 100% compression (which is still a bit lossy) and Android saves them at 90% compression.  My memory is a bit fuzzy about this, but I think our iOS team upped the JPEG compression to 100% because they didn’t have PNG support at the time so this was the next best thing.  If you’re all happy with the 100% JPEG compression file size, then we can change Android to do the same.

Also note that when taking screenshots, PNGs are best used for things that have a lot of solid colors, such as UI screenshots.  JPEGs are best used for images that have a large mix of colors such as photos where it lossy format isn’t really noticeable.

#23

Wow, it’s just 10% difference on the setting, but it makes a factor of 10 difference on the size saved! (And a pretty big quality difference too - It is photos as you implied/recommended)

I wouldn’t be too sure that the compressor setting on iOS and android is identical though… The compressors may be implemented differently(?)

Overall, if you want to throw it to 100% on the Android side too, that would be fine by me! If you’ve got a lot of spare time, you could throw it to 95% and I could test it out for you (on either / both iOS and Droid)

:slight_smile:

#24

Oh wait… you said its about 10x file size difference between iOS and Android.  That kind of bothers me.  So are you saying that the PNG’s file size on iOS is even bigger than the JPEG file size?

I’m thinking we should either attempt to find that magic compression rate sweet spot (perhaps 95%?) or we should just make it settable.  Ideally, making it settable is the best choice, but API changes are team decisions on my end because multiple people are involved (update code on iOS/Android, updating documentation, updating sample code, involving QA, etc.).  I’m just trying to find the path of least resistance to help you guys out.

#25

Joshua, I’ll chime in here with… there is no “magic” compression sweet spot.  It is going to be different depending on the image being compressed, and different for the different use cases for all the different apps Corona devs make.  Somebody is going to want best quality, someone is going to have an equally pressing need for smallest file size.  Everyone in between will have their own sweet spot/quality trade off.  So, I vote for settable compression.  

Now, it sounds like there might actually be a problem on the Android side if it is already set at 90% and there is a huge, noticeable quality difference between that and 100% on iOS.  So maybe what’s needed now is a short term fix for the Android issue, and then a mid-term solution would be Corona-settable compression. 

-Stephen

#26

Oh bugger… I’ve discovered deep down in the bowels of our Android code where we save a JPEG at 50% compression.  It’s some old legacy code that I’ll bet is responsible for this issue that you guys are facing.  I’ll bump it up to 90% like the rest of our Android code expects.  Thanks for following up on this.  It forced me to take a deeper look at what was going on.

Note that this change won’t be made available in a daily build until hopefully next week.  We’re currently preparing a new release version of the Corona SDK which takes priority at the moment.

#27

That’s the best news I had so far this week, thanks Joshua! Woohoo!