Honestly I think EXIF parsing and handlign might be best put elsewhere.

/cc @nigeltao

Agreed.
But this is more like a bridge (or a hook). No EXIF specific logic is involved here. APP1 is like APP0 except it is widely used to store EXIF data.

I don't want to commit to a []byte-typed Options.App1Data field if it rules out having a more structured Go representation of EXIF inside the image/jpeg package itself (see also #4341). I think some bigger thinking is required around EXIF in general, for reading, modifying, and writing, before adding an incremental patch like the OP suggestion to fix one very specific use case.

For your immediate problem, it seems straightforward to me to encode to a bytes.Buffer instead of an os.File directly, and insert the APP1 data after the first 2 bytes of the buffered []byte.

Or, you can fork the image/jpeg package to encode exactly what you want.

Neither of these seem particularly difficult to me, and they don't constrain (under the Go 1.x backwards compat promise) any more general approach to the standard image/jpeg library.

Wrapping up with bytes.Buffer loses the efficiency (e.g., memory consumption) and elegance of io.Writer. os.File is just one example, it could also be http.ResponseWriter.

Another possibly less intrusive (but still hacky) workaround would be adding a SkipSOI (start of image) flag in the Options struct. So that it allows people to manipulate/output all the APP segments (e.g., JFIF/APP0, EXIF/APP1 and other customized segments) without the need of holding all the data in memory or other sorts of post processing.

+ if o == nil || !o.SkipSOI {
    e.buf[0] = 0xff
    e.buf[1] = 0xd8
    e.write(e.buf[:2])
+ }

If you really want to avoid the memory cost of buffering the entire output, you could always implement your own io.Writer that wraps another io.Writer, and runs your own callback or otherwise inserts your data after the first two bytes (the "\xff\xd8" SOI marker). Again, no change to the standard library is needed.

The Options.SkipSOI proposal has the same fundamental problem as the original Options.App1Data proposal: any hacky workaround added to the standard library has to be kept for the lifetime of Go 1.x. I don't see the need for a hacky workaround in the standard library when you can just as easily hack a workaround outside the standard library.

any update on this?

+1

Any update here ?

Any updates here?

No update to the standard library. However, as I said above:

If you really want to avoid the memory cost of buffering the entire output, you could always implement your own io.Writer that wraps another io.Writer... Again, no change to the standard library is needed.

I wrote more detail on that technique here:
https://nigeltao.github.io/blog/2021/from-jpeg-to-jfif.html