Dall-e-3 output image file linked in response url is uncompressed

The images I get from Dall-e-3 API are image/png, but utilize zero compression. All files have exactly the same size of ~3MB (1024x1024), which roughly corresponds to 1024x1024x24 bit color + the PNG header.

Obviously the client can optimize the image, but this is really an unnecessary burden on client pieplines, network etc. I understand you want to provide the best quality, but it would be so much nicer to:

A. provide output format parameter to get a compressed image/jpeg instead
B. provide a thumbnail URL, so that the image can be directly shown on a client

1 Like

DALL-E-3 is lossless.

It is compressed.

PNG data:

memory size: 3145768 bytes
disk size: 1700667 bytes

PNG uses the deflate compression algorithm.

Lossy compression? Bing is thataway —> (although a jpg or webp with quality specification as you suggest certainly could have utility to some)

I created 5 sample images and all of them have the exact same disk size 3,147,861 bytes. Here’s a sample (expires in 1 hour): https://oaidalleapiprodscus.blob.core.windows.net/private/org-EYHesviYJchTKmYZLHjAFEca/user-nGqttRLxd093wNyjjteHuh3J/img-r3pYmenCLA3f843e4nAcg2CL.png?st=2023-11-23T09%3A17%3A39Z&se=2023-11-23T11%3A17%3A39Z&sp=r&sv=2021-08-06&sr=b&rscd=inline&rsct=image/png&skoid=6aaadede-4fb3-4698-a8f6-684d7786b067&sktid=a48cca56-e6da-484e-a814-9c849652bcb3&skt=2023-11-23T00%3A29%3A17Z&ske=2023-11-24T00%3A29%3A17Z&sks=b&skv=2021-08-06&sig=oGb9NE7eSw9IR8OMQHN%2BeZHwwoLgspdMDK0/5ipyQKg%3D

I understand, how PNG compression works, I am just stating the API does not use it (how is that even possible in PNG since it’s basically deflate, I don’t know).

The gist is that these images takes long as hell to download, even on the server.

1 Like

That’s the most recent dall-e-3 image that I obtained. I’m getting the b64_json, but you are correct in my oversight that in having made it into a pillow image object first, I’ve given myself the ability to save the even more bloated base64 to the disk compression that came for free - and attach metadata (or be Bing with creepy encrypted watermarking).

You can get an interesting undocumented part of the beta API return out, generation time, and compare that to response time. It would take some thinking for me to come up with a “transfer rate graph” for the 8 seconds a connection is open. My initial test reminded me that this PC is on WiFi where the download uncompressed would take 0.45 seconds.

Ha, I modified my code to request b64_json instead url and when I decode it, the result is a normally compressed image!

So let’s conclude this is a bug with PNGs saved to temporary URLs only. I modified the title to be more clear.

The b64_json image represents web/p, not png.

image.png: RIFF (little-endian) data, Web/P image, VP8 encoding, 1024x1024, Scaling: [none]x[none], YUV color, decoders should clamp

I couldn’t specify the desired format and couldn’t find out until I decoded it.

Has this changed in some way lately? I noticed that images I generated before Dec 6 were roughly 175kb in size, now they are all 3mb. What am I missing? I’ve tried compressing them with Pillow but the results are poor quality.

1 Like