Skip to content

images.edit not working when submitting image files (mime type and other issues) #147

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wdewind opened this issue May 23, 2025 · 3 comments

Comments

@wdewind
Copy link

wdewind commented May 23, 2025

Hi,

I've been trying to use the images.edit api and having issues. When I submit a single file like this:

    response = openai.images.edit(
        prompt: prompt,
        model: MODEL,
        size: "1024x1024",
        image: open("test_image.jpeg"),
      )

I get the error:

Invalid file 'image': unsupported mimetype ('application/octet-stream'). Supported file formats are 'image/jpeg', 'image/png', and 'image/webp',

If I wrap it in an array:

response = openai.images.edit(
        prompt: prompt,
        model: MODEL,
        size: "1024x1024",
        image: [open("test_image.jpeg")],
      )

I get

Invalid type for 'image': expected one of an array of files or file, but got a string instead.

What am I doing incorrectly here?

I've searched around and it seems others are having similar issues with different libraries, so this may be an open ai api issue not a ruby library issue. Ex: openai/openai-python#2341

@wdewind
Copy link
Author

wdewind commented May 23, 2025

Playing around with the CLI a little and I found that the API complains about jpegs but allows me to use PNGs. The same PNG does not work from the ruby library though. This code works:

curl -s -D >(grep -i x-request-id >&2) 
  -X POST "https://api.openai.com/v1/images/edits" 
  -H "Authorization: Bearer $OPENAI_API_KEY" 
  -F "model=dall-e-2" 
  -F "image=@test_image.png"

@ms-jpq
Copy link
Collaborator

ms-jpq commented May 23, 2025

hi @wdewind, sorry for the bug! I was able to reproduce it.

It has to do with how we were encoding the content-type here:

content_type ||= "application/octet-stream"

We relied too much on "application/octet-stream" when the service requires "text/plain" & the JPG's content_type.

I will have to check with a colleague to identify a fix for this, since I do not want to accidentally break other endpoints when I change the encoding behaviour. Please expect a fix early next week 👍

Cheers!

@ms-jpq
Copy link
Collaborator

ms-jpq commented Jun 4, 2025

should be closed by #154

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants