After studying the JPEG-2000 specification and looking at the hexdump for these files:

https://github.com/uclouvain/openjpeg-data/blob/master/input/conformance/p0_05.j2k
https://github.com/uclouvain/openjpeg-data/blob/master/input/conformance/p0_08.j2k

I can see that it consists of a plain J2K codestream without any JP2 wrapper. This means that there is no way for a decoder to determine the colorspace from the file itself as far as I understand it. (In the JP2 wrapper you have the Colour Specification Box that states the colorspace to be used). The only piece of information you get is the Csiz field in the SIZ marker which states the number of components, the bit depth per component and its signedness. I have been unable find in the specification what default colorspaces a decoder ought to assume.

So the decoder library has to make an assumption of what colorspace to report to the client application, likely based on the number of components stated in the SIZ marker.

When looking at the SIZ markers you can see that p0_05.j2k indicates 4 components while p0_08.j2k indicates 3 components. Yet when I decode this with the Luratech JPX decoder the colorspace is reported as being grayscale(!) and having only one color component (the rest being marked undef). I have been unable

This seems wrong to me. I'd expect the default to be CMYK for 4 color components and RGB for 3 color components. Unless there are compelling reason to choose some other default colorspace (maybe LAB is a viable _default_ 3 component colorspace?). Or the decoder library could explicitly indicate that the colorspace is unknown and leave it up to the application to take the decision of what colorspace to use based on the number of components. This latter option actually implements less policy in the library itself.