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 MBGrayscale Save As Slowest - 4.39 MBRGB Save For Web - 6.87 MBGrayscale Export As (no transparency) - 7.42 MBRGB Export As (8-bit) - 7.51 MBGrayscale Export As (8-bit) - 7.72 MBGrayscale Save for Web - 7.75 MBRGB Export As (no transparency) - 8.16 MBGrayscale 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.

Inspiring

Answered

Grayscale PNG larger file size than RGB

Forum|Forum|4 years ago
January 13, 2022
3 replies
6466 views

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.

Windows

This topic has been closed for replies.

Correct answer Michael22641303ojdu

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

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.

Earth Oliver

Legend

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

M

Michael22641303ojduAuthor

Inspiring

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.

Brad @ Roaring Mouse

Community Expert

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.

M

Michael22641303ojduAuthor

Inspiring

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.

M

Michael22641303ojduAuthor

Inspiring

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.

Pre-compression: re-arranges the image data so that it will be more compressible (normally by zlib).
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/

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.

D Fosse

Community Expert

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