Pulse's PNG Palette Ponderings (split)

[Sonarpulse 1]

...I wonder if PNG could ever sniff out the game's pallet automatically

Edited July 18, 2012 by Sonarpulse

[Nyerguds 100]

What? A screenshot saved with ctrl+s ingame has the correct palette anyway. It just saves the actual screen buffer, which still is 256 colour.

 

It's not because MS paint can only save high-colour png, that the format itself can't handle it

[Sonarpulse 1]

I mean, is your average PNG implementation able to detect a limited number of colors and make a pallet accordingly? PNG supports 8-bit palette-based bitmaps just like GIF. Alternatively it doesn't and does 24 bit or whatever but do to PNG's superior compression the resulting file is still smaller.

Edited July 20, 2012 by Sonarpulse

[Nyerguds 100]

PNG is a format, NOT a system. If your image editor is reducing colours without you asking for it, it's doing something wrong, since that should be a user choice. It's also 100% unrelated to the format you finally save the image in. Well, unless you save in GIF, of course, which is paletted by design, and, thus, requires a colour reduction if the input image is high colour.

 

On that note, a PrintScreen clipboard paste is normally the same colour depth as your desktop is at that moment, which means that it's normally in full 32 bit true colours on modern PCs.

[Sonarpulse 1]

I think we agree. PNG is a format that supports a number of colorspaces, including 8-bit palleted. I am just wondering whether a good loss-less saving routine might detect that the image to be saved (be it from a screenshot or whatever else) only contains 256 unique colors, and therefore could use PNG's 8-bit palleted colorspace instead of the usual 24-bit RBG or 32-bit RGBA modes. Were the routine to accurately ascertain this, I would expect it to use that colorspace without prompting the user.

 

The fact that you found the PNGs of the screenshot to be smaller leads me to believe the PNGs tested were in fact 8-bit palleted. This surprised me as that I didn't think most programs were that smart.

 

Anyways this is terribly off topic. Sorry to bring it up.

[Nmenth 290]

I probably shouldn't throw this even further off topic, but I don't think you understand how PNG works. PNG doesn't care what your image's palette is, but a smaller palette will result in a smaller file size due to how PNG works.

 

If you have an image with a 256 palette compared to one with 257, the 257 one isn't going to bump up to a file size equivalent to 512 or something, it will be almost identical to the one with a 256 palette.

 

PNG compresses by sampling pixels adjacent to other pixels, comparing their RGB, hue, saturation, value, and transparency. The closer pixels are to one another in these aspects, the smaller the image file can be compressed. So an image that only has a 256 palette simply has more similar pixels than a photograph-quality 32-bit image.

 

[pichorra 4]

Maybe it is better explain how bitmap works 1st.

 

Bitmap will store every pixel of the image by it's color. That mean not a huge file for 2-bits or 8-bits image, but yes for a 24-bits image, since it will store 3 bytes per pixel. Worst for 32-bits (4 bytes), first because most monitors, even nowdays do not support all 32-bits colors, and it is just a 24-bits with 8-bits alpha chanels. Remember that your monitor can't get transparent

 

There are 2 advantages about using bitmap:

 

- Perfect precision.

- Low-requirements cost for opening and loading it. (if it is in your harddrive, of course).

[Sonarpulse 1]

https://en.wikipedia.org/wiki/Portable_Network_Graphics#Color_depth

[Nyerguds 100]

I think we agree. PNG is a format that supports a number of colorspaces, including 8-bit palleted. I am just wondering whether a good loss-less saving routine might detect that the image to be saved (be it from a screenshot or whatever else) only contains 256 unique colors, and therefore could use PNG's 8-bit palleted colorspace instead of the usual 24-bit RBG or 32-bit RGBA modes. Were the routine to accurately ascertain this, I would expect it to use that colorspace without prompting the user.

I understand exactly what you mean, but I still think colour reduction should be 100% user choice. I personally hate overzealous automagical systems that do assumptions for their users. Oedi's screenshots weren't made from strictly 256-colour in content anyway, since they contained the window header and borders.

 

On that note, since they were gif, they were reduced to 256-colour anyway. But, as you clearly see in his screenshots, Paint does a piss-poor job at that reduction. The fact they take more space than png is simply because png compresses 8-bit images better than gif. It's a more recent, more versatile and overall superior fomat.

 

The fact that you found the PNGs of the screenshot to be smaller leads me to believe the PNGs tested were in fact 8-bit palleted. This surprised me as that I didn't think most programs were that smart.

My screenshots weren't saved from print screen pastes. They were saved with CnC-DDraw by pressing ctrl+s ingame. Since CnC-DDraw gets the original 8-bit image data straight from the game, it's obvious it saves the png in 8-bit from that original data. There's no colour reduction involved.

 

Anyways this is terribly off topic. Sorry to bring it up.

On that note... I split it. But I still think it's a silly discussion.

 

The png implementation itself doesn't do anything automatically for the user, and that's a damn good thing too, because with your logic, it could utterly mess up deliberately-paletted images (like, converted sprites, like C&C graphics) by automagically saving them in 2-colour mode just because they only contain black and white.

 

The png saving algorithm just saves with the parameters and colour mode the editor asks it to save in. What you ask is 100% editor based, and unrelated to the png format itself.

[Oedi 1]

what the hell did i start with my screenshots

[Nyerguds 100]

Nothing... just someone confusing image saving algorithms with editor automatisation

[Sonarpulse 1]

My screenshots weren't saved from print screen pastes....

Oh ok, now it makes sense.

[Nyerguds 100]

Oh ok, now it makes sense.

 

I kinda said that from the start, you know:

 

Incidentally, you can let cnc-ddraw save png game screenshots simply by pressing [ctrl]+ ingame

What? A screenshot saved with ctrl+s ingame has the correct palette anyway. It just saves the actual screen buffer, which still is 256 colour.

[Sonarpulse 1]

I forgot a ctrl-s screenshot can be PNG

[Nyerguds 100]

"can be?" hifi programmed cnc-ddraw to save it that way. It's ALWAYS a PNG. It can't be anything else.

[Chimas 7]

Hi,

I'm bumping this up because it is PNG format related.

 

I've started using PSP9 some months ago for other stuff.

Today I've tried to generate frames for SHP files, but I wasn't successful.

The other time I've done with this was in my older PC with GIMP, I guess.

 

I'd like to know what are the file specs for PNG format in relation to SHP files.

I've searched around for a tutorial but I didn't find anything or didn't use the right keywords.

Thanks

[Nyerguds 100]

Quite simple... 8-bit paletted (256 colour), without alpha channel. That's all. And the palette has to be one of the ones from the game (or derived ones, like my purple palettes). It's not even specifically related to png... as this entire thread already said

 

As far as I know, the specific png saving options don't matter at all for xcc. If it has no alpha, and is 8-bit paletted, it can convert it.

[Chimas 7]

All that is set and no result. Could it be XCC set up somehow?

I have to ask for more basic stuff cause I've changed everything here some months ago - hard & soft.

Now, I'm having the time to deal with it.

[Nyerguds 100]

No result, or a bad result?

 

"Copy As" makes the result end up in the location of the other file browser XCC has, and fails if that other file browser has a mix file opened.

 

It may give a bad result if you have the "View" -> "Palet" -> "Use for conversion" option enabled, since that'll match the input image to the currently selected colour palette rather than doing a simple SHP convert of the image's indexes.