Wait, but now that I think on it, the error condition is a regression in itself. We used to allow indexed images without color maps and in that case it was attributed an automatic 0-255 one.

Well, a 1-byte image without color index should work unless you give -C. no?

Perhaps need more checks. We have this:

	byte_image_no_cmap = (I && I->type == GMT_UCHAR && I->n_indexed_colors == 0);
	if (byte_image_no_cmap && !Ctrl->C.active) {
		GMT_Report (API, GMT_MSG_ERROR, "Byte image without indexed color requires a CPT via -C\n");
		Return (GMT_RUNTIME_ERROR);
	}

But perhaps if no -C then byte_image_no_cmap should be false.

Check this PR - works for ex52 and allows gray image. @joa-quim please check.

I have not yet pulled this merged PR and see that this errors

gmt grdimage rgb_image.tiff+b0 -png lixo
grdimage [ERROR]: Byte image without indexed color requires a CPT via -C

but shouldn't fail. It used to work because in those cases we provide a default color map. That is, this error check all together must be removed. Otherwise we are breaking previous behavior. The change was to allow -C, not to make it mandatory.

Sure, that is why I added the check on -C. if no -C then should not get into that branch at all and instead paint gray. Please test it

master has

byte_image_no_cmap = (I && I->type == GMT_UCHAR && I->n_indexed_colors == 0 && I->header->n_bands == 1 && Ctrl->C.active);

So that is only true if 1 band, no index map, and -C is set. Your example has no -C so not updated.

OK, but can't update right now.