png Vs. jpg

Discussion and feedback on Construct 2

Post » Sun Dec 11, 2011 12:15 pm

I noticed that all my files in the images directory are converted into PNG.

When creating a project I use PNG when delicate transparency is needed and Jpeg when big backgrounds are used.

I use each exploiting the specific format's advantages.

Is there a way C2 will export images based on the original source file?
This will save tons of space in the images directory and speedup upload times.

A 600K png file can be easily turned into a 150K-200K file. 5 such files will generate a 1MB space saved.
B
35
S
12
G
6
Posts: 111
Reputation: 7,087

Post » Sun Dec 11, 2011 1:27 pm

JPG is a lossy format, meaning that whenever you compress to JPG, you lose some of image's quality. It is best used for photographs and other images that use a lot of colors and are more diverse.

PNG is lossless format (no quality loss) and is best used for images with fewer and more uniform, best used for graphics such as web buttons.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Sun Dec 11, 2011 2:28 pm

:) I've been in this business since the invention of Jpg...

I know what's the difference between these two formats and I think it would be wise to leave the control at the designer hands.

If one uses jpg and png than he might know what he's doing.

I prefer having 3 different background 150K each than having one 600K png image.

All I'm asking is for some control over the final file sizes.

As mentioned I do use PNG when I want to enjoy the benefits of a PNG file format but I also recognize the file size advantages of a good old Jpeg.
B
35
S
12
G
6
Posts: 111
Reputation: 7,087

Post » Sun Dec 11, 2011 2:58 pm

This raises a question I've been thinking about for a while. How does C2 deal with indexed PNG's? If you're using indexed png's then yes, you have a much more limited color palette to work with, but it's really size efficient (I tested making a 150kb image indexed and it got around 10-15kb after I did). It's probably more useful for pixel graphics though.
B
73
S
20
G
10
Posts: 524
Reputation: 9,896

Post » Sun Dec 11, 2011 3:12 pm

Most game engines use PNGs, I highly suggest that you use PNGs as well.
B
69
S
11
G
6
Posts: 324
Reputation: 8,321

Post » Sun Dec 11, 2011 3:15 pm

When JPG gets loaded, it is decompressed within memory and becomes essentially the same as PNG. The only advantage of JPG is that it saves disk space.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Sun Dec 11, 2011 3:15 pm

Why do you suggest that? I tried to explain why I prefer using 3 150Kb jpegs (in some cases, i.e. backgrounds) over 1 600Kb Png.
B
35
S
12
G
6
Posts: 111
Reputation: 7,087

Post » Sun Dec 11, 2011 3:26 pm

Assuming the image is 600Kb in PNG format and 150Kb in JPG format, the JPG still takes the same amount of memory as PNG image.

Of course, it would be nice to be able to load JPGs in Construct 2, I'm just repeating arguments that were thrown around. Besides, Construct 2 compresses PNGs. The savings may not be that great, though.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Sun Dec 11, 2011 3:32 pm

[QUOTE=Mipey] Assuming the image is 600Kb in PNG format and 150Kb in JPG format, the JPG still takes the same amount of memory as PNG image.

Of course, it would be nice to be able to load JPGs in Construct 2, I'm just repeating arguments that were thrown around. Besides, Construct 2 compresses PNGs. The savings may not be that great, though.[/QUOTE]

I know about the memory decompression. I'm not trying to save memory.
All I'm saying is that leaving the option in the hands of the game designer is an important thing.

Having 5 different backgrounds saved in Jpeg < 1MB
The same in PNG will be 3MB and more.

In a web application environment the difference between 1MB and 3MB in huge. With higher uploading time you're reducing the number of potential players and increasing the potential of getting bad feedback due to long loading times.

In some cases it would be even wise to use gif as the saved file but solving the Jpg/Png option will solve this issue too.
B
35
S
12
G
6
Posts: 111
Reputation: 7,087

Post » Sun Dec 11, 2011 5:28 pm

Well, being a professional graphic designer I understand very well the difference between these formats and I must agree with HotGod that would be really handy if C2 could deal with JPGs besides just PNGs. The download time for intensive graphics games could be dramatically reduced.

Indexed PNGs may seem like a good solution but they are only more efficient than JPEGs when the image has few details and lots of flat colors. When an image has lots of gradients and details a 24-bit PNG will be a lot heavier, and an indexed PNG yields poor results due to compression caused by the limited palette.

The benefits of JPEG are not related with video memory. Consider the amount of hosting space, download time, and the user's disk space after downloading. Think that a lot of potential audience for web games have poor internet connections, or consider the emerging mobile market where the devices have low storage space.

PNGs and JPGS are complementary RGB raster formats. Both have their strengths and weakness, but alone they don't cover all the ground. Supporting both would be a wise decision, specially for an application that is headed at web content.

I wish C2 could load separated JPGs for the image and the alpha channel, then would be feasible to use large images with transparency. This way the alpha could have a very high compression, and not add a lot to the size of the image like an 24-bit PNG does.

Scirra Employee
B
129
S
45
G
15
Posts: 705
Reputation: 15,413

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 8 guests