Hi,
I have commissioned 10 images at 640 x 960 resolution (iPhone 4S resolution) and have the option to receive them in either a JPG or a PNG format.
Without getting into too much heavy technical detail, is one format better than the other for a cross platform Corona based mobile app targetted for phones rather than tablets?
The images will be downloaded the first time the app is run and will then be displayed sequentially full screen every 5 seconds controlled by a timer.
Thanks in advance
It very much comes down to the nature of the image and how they will be used.
JPG is compressed using a ‘lossy’ method, so the image is degraded (though maybe not noticeably).
PNG is lossless.
If you can only receive one format, I would go with PNG and have the option to convert it to JPG later if required.
Jules.
Hi,
I have just this second received them and was actually sent both formats.
Visually, I can’t see much difference (if any) between the png and the jpg.
There is however quite a significant size difference in that the jpg’s are typically 200k and the png’s are 340k - so the jpg’s would be much quicker to download to the phone.
If I go with the jpg’s will they scale ok to the higher resolution phones out there or will the pngs scale better?
Thanks
At the end of the day, it really depends of what is the intended usage of the image. In our case, for our app its a case per case. When we need transparency, then its a no brainer, its png. When its background image it depends of the image itself and how it will scale for various devices.
Something to look at also is tool like tinyPng where they transform your png to 8-bit indexed color images. In 90% in our case we use it for all UI elements that needs transparency.
I hope this help you a little bit.
Have them delivered as PNGs and in the future if you want to use them as JPGs convert a copy. If you get them delivered as JPGs you’ll never get back the detail you lost from the original conversion/save as JPG.
If the image needs transparency, it will need to be a .png file. But if it doesn’t and you’re going to be downloading the images, it would kinder on the user to use JPEGs since they can be smaller. JPEGs are typically compressed using a percentage value. For instance a JPEG at 100% has no loss. 10% is pretty lossy but it’s tiny.
Let me explain lossy and why it’s more scary sounding than it really is. Let’s say you have an image that a red to slightly darker red. To the eye, the change may be subtle and hard to see. Let’s consider a 4x4 set of the pixels from the image (and focus on the red channel). It might be:
255 255 254 253
252 254 255 253
251 253 252 254
252 252 255 254
The colors are call close in value. To get the image smaller, JPEG says make similar colors the same. At a compression of say 80 it might convert the values to:
255 255 255 255
253 253 253 253
253 253 253 253
252 252 254 254
In this case all the 255’s can be stores in much smaller amounts of data using a technique called Run Length Encoding. If you crank the compression to say 50% then all 16 values might become 253 allowing the file to become even smaller. So the more you compress the larger the array of pixels that will be averaged out and the more aggressive color merging.
For photos or pics with lots of detail, you can compress quite aggressive without impacting the visual. If it’s solid colors, JPEG will compress it very well without loosing much at all. If a large block is already a single color, no need to average it out. Where JPEG is weaker is with gradients and will be less smooth the more you compress it. The colors will “block” up.
I would not hesitate to use JPEG’s for background images. They are the largest you have to deal with, they never need transparency and you can end up with a 10:1 savings in image size without much damage to the visuals in the JPEGs.
Rob
Rob,
Thanks for that - I am going with the JPG as I don’t need the transparency as they are background images and also they are much smaller than the PNG files.
It very much comes down to the nature of the image and how they will be used.
JPG is compressed using a ‘lossy’ method, so the image is degraded (though maybe not noticeably).
PNG is lossless.
If you can only receive one format, I would go with PNG and have the option to convert it to JPG later if required.
Jules.
Hi,
I have just this second received them and was actually sent both formats.
Visually, I can’t see much difference (if any) between the png and the jpg.
There is however quite a significant size difference in that the jpg’s are typically 200k and the png’s are 340k - so the jpg’s would be much quicker to download to the phone.
If I go with the jpg’s will they scale ok to the higher resolution phones out there or will the pngs scale better?
Thanks
At the end of the day, it really depends of what is the intended usage of the image. In our case, for our app its a case per case. When we need transparency, then its a no brainer, its png. When its background image it depends of the image itself and how it will scale for various devices.
Something to look at also is tool like tinyPng where they transform your png to 8-bit indexed color images. In 90% in our case we use it for all UI elements that needs transparency.
I hope this help you a little bit.
Have them delivered as PNGs and in the future if you want to use them as JPGs convert a copy. If you get them delivered as JPGs you’ll never get back the detail you lost from the original conversion/save as JPG.
If the image needs transparency, it will need to be a .png file. But if it doesn’t and you’re going to be downloading the images, it would kinder on the user to use JPEGs since they can be smaller. JPEGs are typically compressed using a percentage value. For instance a JPEG at 100% has no loss. 10% is pretty lossy but it’s tiny.
Let me explain lossy and why it’s more scary sounding than it really is. Let’s say you have an image that a red to slightly darker red. To the eye, the change may be subtle and hard to see. Let’s consider a 4x4 set of the pixels from the image (and focus on the red channel). It might be:
255 255 254 253
252 254 255 253
251 253 252 254
252 252 255 254
The colors are call close in value. To get the image smaller, JPEG says make similar colors the same. At a compression of say 80 it might convert the values to:
255 255 255 255
253 253 253 253
253 253 253 253
252 252 254 254
In this case all the 255’s can be stores in much smaller amounts of data using a technique called Run Length Encoding. If you crank the compression to say 50% then all 16 values might become 253 allowing the file to become even smaller. So the more you compress the larger the array of pixels that will be averaged out and the more aggressive color merging.
For photos or pics with lots of detail, you can compress quite aggressive without impacting the visual. If it’s solid colors, JPEG will compress it very well without loosing much at all. If a large block is already a single color, no need to average it out. Where JPEG is weaker is with gradients and will be less smooth the more you compress it. The colors will “block” up.
I would not hesitate to use JPEG’s for background images. They are the largest you have to deal with, they never need transparency and you can end up with a 10:1 savings in image size without much damage to the visuals in the JPEGs.
Rob
Rob,
Thanks for that - I am going with the JPG as I don’t need the transparency as they are background images and also they are much smaller than the PNG files.