cc @nigeltao

However, it has no check for color.Grey16, leading to that format being encoded incorrectly (the least significant 8 bits are discarded silently).

At the wire format level, Extended or Progressive (as opposed to Baseline) JPEG can still only represent 12 bit depth, not the full 16. Would you still consider that "encoded incorrectly" if the least significant 4 bits are still discarded silently?

Specifying the number of color components and their size in the encoder options would allow the implementation to be used for e.g. medical imaging & scientific instrument data.

An alternative to adding encoder options is to detect case *image.Gray16 near to where it already detects case *image.Gray and treat that as another special case along the same lines. This admittedly changes the behavior (compared to previous Go stdlib versions) when encoding an *image.Gray16. More subtly, it would mean that jpeg.Encode would now potentially emit Extended JPEGs (SOF1), not just Baseline JPEGs (SOF0). Perhaps the new jpeg.Options field, if any, should be an opt-in to emitting Extended JPEGs.

Having said all that, if you're talking about medical imaging, you're probably talking about Lossless JPEG (which does allow 16 bit depth). Go's image/jpeg decoder (let alone its encoder) currently does not support LJPEG. I'll copy/paste here in full what I wrote on the #22535 "support LJPEG" feature request:

As a feature request, I suppose it's a valid feature request.

Whether or not it lives in image or x/image depends on how much code it would share or not share with the existing image/jpeg package. You mention the JPEG parser (which is trivial) and the Huffman coding (less trivial), but on a quick skim, the https://en.wikipedia.org/wiki/Lossless_JPEG page says that "Lossless JPEG... [uses] a completely different technique from the lossy JPEG standard".

Either way, though, I really don't have any spare time to work on this myself. If you want to try doing this yourself, I would suggest starting by forking the standard library's image/jpeg code. It'd be easier to make the image vs x/image decision after we have at least a rough proof of concept implementation to look at.

Back to this issue (encoding, not decoding), the same applies: "it's a valid feature request... [but] I really don't have any spare time to work on this myself."