png Vs. jpg

  • 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.

  • 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.

  • :) 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.

  • 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.

  • Most game engines use PNGs, I highly suggest that you use PNGs as well.

  • 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.

  • 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.

  • 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.

  • 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.

    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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • I think a good question would be is there any difference in how well canvas handles different formats?

    You might save some disk space using jpg, but if it's much slower than png you might not want to use it.

  • I asked for this feature a while ago and if I recall correctly, Ashley put it on his to do list.

  • I haven't tested it for the moment, but isn't it possible to let C2 use dummy PNG files when you are working with it, and then, when exporting the final project, you switch the png file with your jpeg files. You can rename your png files and give them the name of the png files. For example, FF is intelligent enough to load and display an image with the wrong extension, because the image lib is reading the magic number at the beginning of the file.

    It's quick and dirty, but it should work..

  • Yeah but don't JPEGs get a lot of ugly ass artifacts in them over time?

  • I agree, multiple formats should be used.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)