Grayscale PNG larger file size than RGB

[Michael22641303ojdu]

I'm running some tests in Photoshop to see how we can get the smallest file size for a grayscale PNG, but I noticed the performance is highly unusual with the latest version of Photoshop. Here are the file sizes using various export options for a standard 4096x4096 clouds filter:

RGB Save As Slowest - 3.86 MB

Grayscale Save As Slowest - 4.39 MB

RGB Save For Web - 6.87 MB

Grayscale Export As (no transparency) - 7.42 MB

RGB Export As (8-bit) - 7.51 MB

Grayscale Export As (8-bit) - 7.72 MB

Grayscale Save for Web - 7.75 MB

RGB  Export As (no transparency) - 8.16 MB

Grayscale Save for Web (8-bit) - 9.09 MB

Some takeaways:

• The grayscale format does NOT improve file saves unilaterally. The fastest method is actually an RGB format.
• Export As is actually the least efficient saving method, with Save As Slowest being the most efficient.
• 8-bit increases file sizes using Save for Web, which is unexpected.

This behavior is not consistent with past releases of Photoshop. I'm very confused why the file export standards and efficiencies are changing. Export As seems to have gotten significantly worse, and I can no longer recommend it in our production. The file size is practically double the Save As RGB option. Windows, I imagine this unusual behavior would be the same on macOS as well.

[D Fosse]

The first thing to note here is that Export and Save For Web do not support grayscale. It will always output to three channels even if the original is single channel. So if you want true grayscale, Save is your only option.

Other than that I haven't had time to check actual numbers.

(just for the record, "8 bit" in Export / SFW is 8 bits total, not 8 bits per channel - IOW indexed color at max 256 values).

[Stephen_A_Marsh]

Agreed, you beat me to the post while I was knocking up the following image:

I didn't try to match the settings between sfw vs. export, the test wasn't about their size/settings, it was about single vs. 3 channels.

[Michael22641303ojdu]

Thank you. This answers some of the bigger problems with Export As and Save for Web, but still doesn't explain how an RGB image has a smaller filesize than grayscale using Save As. I am also familiar with the 8-bit color index option, in past PS experiences it did reduce file sizes even moreso than grayscale, perhaps by lossy compression (in this case, fewer than 256 colors). I wouldn't want to save this type of file as an indexed 8-bit anyways, but when I did in some cases the file size went up by a significant margin, not down.

[Brad @ Roaring Mouse]

"how an RGB image has a smaller filesize than grayscale using Save As"

It's the compression. With the greyscale, which is already in 8-bit mode with 256 "colours", the file will not get much smaller no matter what level of compression you use, whereas with the RGB with higher compression, your colour table is being adapted, and particularly with less than 256 colours, there's more opportunity to find adjacent pixels that are identical which can be compressed. It doesn't take much to make a dent. See, the first stage of PNG compression looks at how variant adjacent pixel colors are to each other. If you start reducing the colours you reduce variation in adjacent pixels. As a result, the next compression stage (deflate) will find more duplicate values, and be able to compress better, hence your RGB is smaller than your greyscale.

All of this changes depending on what your image is. Like I said, your specific example is not that compressible. If you even add a 2 pixel radius gaussian blur to your image, your files will be smaller!

[Michael22641303ojdu]

Unfortunately, blur is not an option, and the image being "compressable" is not the issue. I am not at liberty to explain what exactly this is being used for. But it's become clear people are not looking at the results and are unable to give a full explanation why this is happening.

24-bit RGB has to handle two extra 8-bit channels than Grayscale, and 8-bit only needs a marginal color palette to support a larger range of colors. It seems like the Save As filters for RGB are just better than Grayscale. That's the only good explanation why the file size would be 53KB smaller when adding 2 @ 8-bit channels and expanding to a broader format. Again, we're looking for lossless data storage, here, and my test used the same image across all formats, so any issues on "compressability" and lossy compression do not come into play at all. Save As RGB 24-bit is almost 3x smaller than Save for Web 8-bit Grayscale, and half the size of Export As 8-bit. I'd like to know why, because this will have huge ramifications on the technical specs I'm sharing with engineers. This doesn't make any sense.

[Brad @ Roaring Mouse]

Part of your issue is your content. Your generated cloud formation is so random that there are very few opportunties for the zlib compression to reduce the size.

I tried a similarly sized real world photo (Color, Monochrome RGB, Greyscale) and the results were as expected. The Color was almost double the size of the Monochrome RGB, with Greyscale less than half that again.  (Mac v23)

e.g. Instead of a cloud, create two Greyscale files with a simple Black->White gradation from top to bottom. In one, check the dither box, in the other don't check the dither box. Save each of these and althought they look pretty much the same on screen (except for slight banding on the non-dithered one), the file sizes will be dramatically different; More opportunity for zlib compression in the non-dithered one.

[Michael22641303ojdu]

Regardless of content, it doesn't make sense why 24-bit total RGB saves better than 8-bit Grayscale, even when using Save As to guarantee the correct output. The final use case of this is closer to the grayscale clouds than an actual colored photo. The image needs to be uncompressed, and we want the lowest file size possible. We won't have to worry about dithering because the source will always be Grayscale. If this type of file saves better as RGB, then that will need to be compatible.

[Brad @ Roaring Mouse]

You are under the misconecption that the PNG format is uncompressed. It is very much a compressed format. At its best (largest), it's a quick lossless compression, but at its worst (smallest), you lose time, as it doing far more work and analyzing the image in different ways to make the file smaller.

Based on a quick search, there are some PNG Optimizers with plugins for PS that will attain smaller files (eg. TinyPNG), but they accomplish this by basically doing multiple rounds of different compression to the file. How well that works with greyscale, I do not know, but worth trying out.

As for the difference between sizes, Greyscale images do not have a CLUT, so they remain at 256 levels, whereas an RGB saved at the smallest setting in PS may have less, sometimes far less depending on the image content. This actually increases the chance of a smaller RGB file as it has less colors to have to deflate, so an jncreased possibility of more duplicate pixels next to each other, hence more compression. For your image, your sample file has 239 colours at 8 bit. Regardless, both seem to be down around the practical limit of the export settings in PS.

[Michael22641303ojdu]

Once again, I am fully aware of all this. This file is being used for a technical purpose: we need an 8-bit grayscale image with lossless encoding, with the option for 16-bit if needed. JPG is out of the question. An 8-bit PNG or Grayscale is perfect for our needs. But both have larger file sizes than the same image as RGB, which makes no sense. And depending on which export method is being used, the file size could be 3X larger.

IF Photoshop RGB is truly the best way to save a file, then our system needs to be engineered to support it that way. But Save As RGB does not give any indication of saving as an 8-bit format, it seems to save files as 8-bit 3-channels and has a smaller file size than other single-channeled indexed 8-bit and Grayscale options, which makes no sense. All of the formats I listed were totally lossless. It just seems the Grayscale export options simply aren't as efficient as the RGB Save As, which is the crux of all the issues I'm finding.

[D Fosse]

Forget Export or Save For Web. We already established that they don't support grayscale.

If you want a single channel file, as PNG, "Save As" (or "Save A Copy") is your only option.

And given that, I can't understand your results and I have no idea how you get them. A grayscale PNG is significantly smaller than an RGB PNG.

What am I missing here?

[Michael22641303ojdu]

What you're missing is I'm not getting the same results. Try compressing the image I posted, using Save As. It compresses better as an RGB Save As 24-bit format than a single-channel Grayscale 8-bit format. RGB saves over 50KB vs the grayscale format. Which makes no sense.

I'm really tired of repeating myself... The answer to this question is the Grayscale format simply doesn't compress as well as RGB, even when we ignore the 256-color indexed options and go straight to a lossless 24-bit image. For whatever reason, that seems to compress a lot better in Photoshop than anything else. Likely the encoding filters for saving as Grayscale aren't as advanced.

[D Fosse]

I'm still not seeing what you're apparently seeing.

Here's two compressed PNGs; an RGB at 5.14 MB, and a grayscale at 1.99 MB. I used Save A Copy here.

(Indexed color is sort of moot here. It will still cover all 256 values of a single gray channel, so no saving there. The saving in going to Indexed will only apply to RGB.)

[Michael22641303ojdu · Accepted solution]

The images that I compressed using Save As Slowest yeilded all the results in my original post. The RGB 8-bit saved at a smaller file size.

Everyone claiming user error here is not helping. All of my results are posted, as well as the entire procedure, which can be replicated by anyone to the same exact results. All we care about it what's most efficient. A compressed RGB works better than Grayscale. When I received the actual files from the contractor, I tried compressing those and this was consistently the case. So it's not just this particular image. Grayscale PNGs are not as well optimized as their RGB counterparts. So until 8-bit indexing or grayscale yeilds better results, the spec will be written for RGB.

[D Fosse]

I'm not claiming user error. I'm just puzzled.

Could there be a huge amount of metadata in your file? No, don't shrug that off. There's something called DocumentAncestors, which is a complete history of copy/paste operations. If the file has been used as a template - or comes from a file used as a template! - this can amount to a lot of megabytes. 100 000 lines of code has been reported.

[D Fosse]

I need to repeat this: 8 bit/index color is moot for grayscale. It still contains all 256 values of the single channel. So there's no size reduction there. But there will be for RGB - in fact, it should be reduced to the same size as the grayscale file.

[Brad @ Roaring Mouse]

Never was i saying "user error" in my responses. i was merely pointing out the possibilities based on YOUR SPECIFIC image. So, again, your VERY SPECIFIC IMAGE is causing an anomoly in the compression. When I suggested you add a 2 pixel blur earlier, I just wanted to demonstrate how little it takes to change the compression results; I was not saying "this is what you should do".

PNG compression happens in two stages.

1. Pre-compression: re-arranges the image data so that it will be more compressible (normally by zlib).
2. Compression: the zlib alogorithm searches for duplicate byte-sequences and replacing them with shorter phrase. Compression happens on a scale of 1-9... this is not unique to PS. 1=largest/fastest while  9=smallest/ridiculously slow CPU intensive.

So once again, why would your RGB image be smaller?? Your RGB image, as rendered, literally only has 239 colours in it, so it is analyzed and reordered in the pre-compression stage in a way that, yes, the compression stage may find more duplicates... enough to cause a smaller file. If your RGB had 256 shades or or more, your files would be either pretty equal or the sizes would be reversed. So as an example of that: I took your image and added a gradition from 0-255 in the centre (basically to force a larger amount of colours). When you save this out as PNG in all settings in both RGB and Greyscale, the numbers ARE higher on the RGB file.

Largest RGB - 7.2 MB compared to Grey 4.9MB

Smallest RGB = 6 MB compared to Grey 4.1MB

Regardless, if you need to talk specific engineering questions about the PNG format, as no answer you are going to get here seems to help, I suggest you contact someone with the W3C:

https://www.w3.org/TR/2003/REC-PNG-20031110/

 

[Michael22641303ojdu]

This would make sense if it wasn't for the fact that the smallest file is 24-bit PNG that reports in Windows as a 24-bit PNG and opens in Photoshop as a 24-bit PNG. Not an 8-bit index. I've stated this numerous times, and numerous times you refuse to accept this fact. I'm not interested in repeating myself.

There are actually hundreds of different filters used to compress a PNG, not just run-length encoding. Most PNG encoders don't support all the various filters because it would take forever to save an image if it had to test all of them and select the best one. Photoshop's slowest option does exactly that.

I have tried this test image and the actual image we'd use for production, and in both cases 24-bit RGB was a smaller size than Grayscale. I'm sorry, but for our purposes, the files we're using, this is what we should do to save 10-15% on file sizes without making any other change. This flies in the face of normal convention, but this is what works right now in practice.

[Earth Oliver]

>Export As seems to have gotten significantly worse, and I can no longer recommend it in our production.

Yes, that's correct. Six years after its introduction, Export As is still essentially a beta and i would never recommend its use.

[Michael22641303ojdu]

Export As 8-Bit indexed is actually our recommended workflow for colored overlays based on previous testing years ago. But Save As has overtaken it for sure. I think the brute force check of filters has to do with this. The bit depth and color format aren't the only things controlling file sizes, here. Save As RGB is much better fit for production.

I wish I could get that same efficiency using 8-bit color, but this is remarkable.