Adding File object option to utils.save_image

[surgan12]

closes #1299

cc : @fmassa

[pmeier]

If we add the format option, shouldn't we allow all additional parameters (dpi for .png, ...)for Image.save()? We could add a **kwargs or save_kwargs which is simply passed to im.save().

[surgan12]

Sure, they could be added based on the use cases.
IMO file option provides an interface to write as bytes and this might be used in a couple of cases .
What do you think ? @pmeier

[pmeier]

To be clear: I'm in favour of adding this as you did. I was just asking myself why we should only include the format option although Image.save() has a lot more options for the different file formats. I think if we give the user more control over the options we might as well give him all options. This of course does not need to happen in this PR. I just wanted to put it out there, so I or we don't forget it.

[surgan12]

@pmeier , I also feel the same, providing a full control over the save would be a better thing for the user.
Also the save_image in the current utils only differs in the make_grid part and there should be no harm in making the rest similar to PIL.

[fmassa]

Thanks for the PR!

I have a question: can't the user add a .name attribute to their file object, so that pillow knows which format to use? Would this work around the need of the format?

[pmeier]

Official documentation states:

format – Optional format override. If omitted, the format to use is determined from the filename extension. If a file object was used instead of a filename, this parameter should always be used.

If we go "by the book" we should include format parameter if we want to write to file objects.

That being said, I have no experience with this. Maybe @kracwarlock (author of #1299 ) can offer some insights, if this works for him.

[surgan12]

@fmassa , surely this is going to be a workaround.
The only thing that bothers me is that everytime user would have to choose a dummy name like (foo.png) which seems very inelegant to me.
However, we can add this workaround to docs if you want.

[surgan12]

@fmassa any further comments ?

[fmassa]

Sure, let's do it this way, although I think that I would like to avoid having to make the function signature more complicated.