Image saving

[FRex]

As I mentioned in 4. here: https://en.sfml-dev.org/forums/index.php?topic=24998.msg166535#msg166535

There's no way to save image to a memory buffer.

There's also no way to save image to different extension than the one given in the filename (so you can't do a custom extension since no matching extension = fail).

There's also no warning anywhere about this funny thing: https://en.sfml-dev.org/forums/index.php?topic=24996.msg166513#msg166513

[Laurent]

There's no way to save image to a memory buffer.

Yes, it should definitely be added. I think it's not hat hard to do since stb_image supports saving with custom write callbacks.

There's also no way to save image to different extension than the one given in the filename (so you can't do a custom extension since no matching extension = fail).

Could be done as well, yes. But then we'd have to support custom extensions for everything that can be saved (audio, for example).

There's also no warning anywhere about this funny thing: https://en.sfml-dev.org/forums/index.php?topic=24996.msg166513#msg166513

True. But I wonder if someone ever knew about it

[FRex]

Yes, it should definitely be added. I think it's not hat hard to do since stb_image supports saving with custom write callbacks.

Yes, it does, but the API is gonna be a problem as always.

Could be done as well, yes. But then we'd have to support custom extensions for everything that can be saved (audio, for example).

The format specifier of some kind is needed for the save-file-to-memory anyway.

True. But I wonder if someone ever knew about it

[Laurent]

Yes, it does, but the API is gonna be a problem as always.

What do you mean?

The format specifier of some kind is needed for the save-file-to-memory anyway.

Good point.

[FRex]

What do you mean?

API is always so contentious.

Do we return a vector, take a vector to fill, let user handle the callback themselves (thus having a void * in API - yay) or let them pass a memory buffer and size and fail/ignore stbi writes mid way if the space runs out?

I'd honestly not mind one of the vector ones since it's not like this would be a common operation.

[Laurent]

Or define sf::OutputStream and its File/Memory derived classes, just like sf::InputStream, and provide saveToStream instead.

[FRex]

Sure, sure. And I ask for this to close this asymmetry of "we can load from user stream or file already memory but save only to a file". This will support stuff like saving image via PhysicsFS, to SQLite or some archive, optimizing or converting the file on your own in memory before saving, sending it somewhere, etc.

[FRex]

Actually, since MemoryInputStream doesn't copy the data (why isn't that an option honestly?) it can't work the same as MemoryOutputStream because they'd have same 'what if we run out of space' problem.

[Laurent]

I would obviously offer two ways to construct an OutputMemoryStream: from external memory (with max size) or allocate its own memory dynamically. But I'm afraid lower level libraries such as stb_image won't be able to handle dynamic memory output, nor predicting how much space will be required in advance, so we'd certainly have to stick to fixed size memory stream anyway. It definitely requires more investigation.

[FRex]

No? STBI write has functions to write data to a callback. I'd not ask before checking (and it's only sane way to do this in C anyway, other than calculating memory size but that's problematic and STB had a write up about that somewhere).

typedef void stbi_write_func(void *context, void *data, int size);

STBIWDEF int stbi_write_png_to_func(stbi_write_func *func, void *context, int w, int h, int comp, const void  *data, int stride_in_bytes);
STBIWDEF int stbi_write_bmp_to_func(stbi_write_func *func, void *context, int w, int h, int comp, const void  *data);
STBIWDEF int stbi_write_tga_to_func(stbi_write_func *func, void *context, int w, int h, int comp, const void  *data);
STBIWDEF int stbi_write_hdr_to_func(stbi_write_func *func, void *context, int w, int h, int comp, const float *data);
STBIWDEF int stbi_write_jpg_to_func(stbi_write_func *func, void *context, int x, int y, int comp, const void *data, int quality);

[Laurent]

?

What I meant is that these functions can't be used with dynamic memory, as they won't allow you to allocate memory when needed, nor tell you how much memory you'll need in advance. You'll need to allocate a (probably very) big chunk of memory to be safe, and adjust afterwards.

[FRex]

You can pass a pointer to std::vector or something in the context pointer (that's your 'user data' to cast back to whatever and use in the callback that gets called with bunches of data from stbi repeatedly) and keep appending your bytes in the callback to that.

Should I write an example..?

[Laurent]

Sorry, I had something else in mind. Of course you're right.

[FRex]

Time to design an output stream then?

[Laurent]

Yes. My plan for SFML 3 was to replace our custom base classes with standard streams (std::istream and std::ostream), but I feel really bad now when I tell someone to wait for SFML 3