proposal: image/gif: support writing comment extensions

[abergmeier]

Proposal Details

When reading, currently Golang ignores Comment Extensions.
I have a fork of image/gif in https://github.com/abergmeier/gitwriter https://github.com/abergmeier/gifwriter which allows for writing Comment Extensions.

If there would be some guidance I could try to integrate that into standard library.

[ianlancetaylor]

CC @nigeltao

[jfrech]

Did you mean to link to https://github.com/abergmeier/gifwriter?

[abergmeier]

Did you mean to link to https://github.com/abergmeier/gifwriter?

Indeed. Yeah sorry for that mistake.

[jfrech]

If you want to follow through with your proposal, I would advise you to a) rebase your fork so the top commit represents your diff to the standard library and b) write some documentation comments and integration tests decoding an entire image file.

[seankhliao]

It'd be more important to reference the appropriate specs and demonstrate why this is an important addition to the standard library.

[nigeltao]

The OP mentions both reading and writing GIF comments. It's not clear whether you are proposing to add reading, writing or both to image/gif.

For reading, the PNG image file format also allows for comments but image/png does not surface them, and we haven't had many (or any??) complaints about that. It's not clear that there's enough demand for being able to read GIF comments. And even if there was, go get github.com/you/yourgiflibrary is easy and idiomatic. It's not like people can't do this at all. They just can't do it with the standard library.

For writing, similarly, I don't see evidence of overwhelming demand for this feature. But also, you may be able to do this without stdlib changes: https://nigeltao.github.io/blog/2021/from-jpeg-to-jfif.html

Also, as I recently said on #67050 (comment)

anything in the standard library has to be supported forever and, once released, its API is frozen forever. There's a high bar for adding anything to the stdlib at this point.

[abergmeier]

@nigeltao Fair enough. For future transparency though, IMO it would be good to state the limitation/scope of the current stdlib implementation explicitly in the docs.