For about 2 hours this morning I’m experiencing what I hope is a transient or service-side regression with the image generator. When TIFFs, JPEGs, or PNGs are submitted for modification. The image generator returns either a completely unrelated generated image, or returns the same image submitted without most of the modifications requested in the prompt.
This is a new occurrence since I’ve been able to get proper image generation responses daily for at least two months prior to the problems I’m experiencing today. I’m using the GPT-5.5 language model which, of course, is separate from the image editing/generation model being used.
Is anyone else experiencing this type of problem with the image generator?
Welcome to the community @rwayneshoaf
Could you share one or two examples showing the original image, the exact prompt you used and the resulting image? Without seeing those together, it’s difficult to determine what might be going wrong.
It looks like the image generator is back to working properly again – at least from my last three prompts. (Naturally, by the time one decides to post an issue, in the time it takes to type it, the problem has been fixed.)
This is the image uploaded as a TIFF, then a PNG, then a JPEG.
The prompt is “Restore photo.” I’ve previously defined that prompt with much greater detail with the language model to do such things as restoring colors in faded photos, correcting colors, selective sharpening, facial-specific instructions, cropping, hallucinations, etc.
This is one of the results.
Here’s another result.
Note that the uploaded file is a color print with extreme fading.
Thank you for taking the time to share the examples!
I’m glad it seems to be working properly again now. Hopefully it was just a temporary glitch.
Just to check, was this on ChatGPT or API?
Thanks for your response.
After some further experimentation, I see that some of the file formats are working properly again. But 48-bit TIFFs are not yet working properly. Instead the image generator creates a completely new image.
The language model response sees the problem symptoms and is recommending I keep trying periodically to see if the image generator gets fixed (for TIFFs). I’ll just continue to monitor.
Again thanks for replying so rapidly!
Thank you for the additional detail. The 48-bit TIFF may explain the remaining issue, as TIFF isn’t listed as a supported image-editing input format.
For ChatGPT, the supported image-input formats are PNG, JPEG and non-animated GIF. For the Image API’s edits endpoint, GPT Image models accept PNG, WebP or JPG files under 50 MB. I would therefore convert the TIFF to PNG or JPEG before submitting it for editing rather than wait for TIFF support.
It is still strange that an unsupported file results in a completely unrelated image instead of a clear format error.
Current API image generation models that can be used on the API have inputs that are akin to “vision” on normal GPT multimodal models - and the only guidance you will currently have on allowed input image types found in API documentation:
Image input requirements
Input images must meet the following requirements to be used in the API.
- PNG (
.png) - JPEG (.jpegand.jpg) - WEBP (.webp) - Non-animated GIF (.gif)
There’s certainly the possibility of “unsupported file types” existing, by the API backend libraries used performing some more conversions by their own support - or producing a damaged input.
You can use the “usage” in an API request for input images to see if an input image was successful - or that whatever was provided as image did result in an encoding and a token billing about 1500 tokens when large enough for a backend-side downsize (about $0.011).
Most notably, there is no pricing provided by OpenAI for what you send to the edits endpoint - I had to figure that out for myself and others. The obsolete vision pricing calculator (that stops at gpt-5.2) isn’t just ignored or now with a bad link in documentation - they recently removed gpt-image-1 from it.
In my own Python application I offer for edits API experimentation, TIFF is taken care of in client software and fault would land with me, not the API: