Handling of images in GMT

[PaulWessel]

Description of the desired feature

This issue tries to summarize the status of how GMT deals with image i/o and what we may wish to have. I think these statements are true - to be vetted by @joa-quim:

1. The exact arrangement of r,g,b,a values in the image array I->data depends on the chosen setting via API_IMAGE_LAYOUT. The default in GMT is TRPa [RGBARGBARGBA...]. Modules can thus set the format most suitable for their use.
2. We support (T|B)(R|C)(B|P). First letter says image is top down or bottom up, second letter says we go by rows or column, and third letter says the r,g,b is interleaved by bands (all R first, followed by all G, then B, then optionally A) or pixel (rgb).
3. Images either have a header->n_bands value or 1 (gray), 3 (rgb) or 4 (rgba, for transparency).
4. For GMT modules that wish to read images, do some manipulation, and write out a modified image, it is important that whatever layout we use we must be able to both read and write that layout. My experience with grdmix suggest we can read TRB but not write it, or write TRP but not read it.
5. The GMT_IMAGE structure has a separate pointer for an alpha array. It looks like it is not filled at all when an image is read. The A bytes remain interspersed in I->data per the layout.

Seems to me we need to put in some work on the image front to reach at least these minimum goals so that basic image handling can be implemented:

1. Ability to read and write at least some of the image layouts we wish to support, such as TRB and TRP.
2. Ability to add or remove I->alpha before writing and have the alpha channel be added or removed in the final image. Alternatively, remove the alpha array stuff from the GMT_IMAGE struct (backwards incompatible but nobody is using alpha anyway since not fully implemented) and have a mode to accomplish this directly on I->data and n_bands.

[joa-quim]

Regarding point 2. I think we also support (or intended to) L(ine) interleaving (row of rrrrr, row of gggg, row of bbbb). That is, last char is either of B|P|L

The GMT_IMAGE is used in Julia.

[PaulWessel]

OK, leaving GMT_IMAGE as is. Working on TRB->TRP for now, and maybe if inspired enough we can do more of these.

[PaulWessel]

See other post, got GMT_Change_Layout to working so left gmt_gdalwrite.c alone for now.

[joa-quim]

Won't have time to continuing discuss this before night but the I->alpha is bothering me. I think the idea was to to have the fourth char A|a mean have|not-have alpha channel. When we have an alpha channel two.5 situations can arise:

1a. We want the the alpha channel as separate layer. This is the case when passing data to Matlab where the alpha goes into a separate slot. The advantage of having it separate is to avoid potentially large data copies.

1b. We want to put it after the RGB, that is as a RGBA. This would get 'A' as 4rth char.

2. For other than Band interleaving it makes no sense to store the alpha band in a separate layer, so for them (P(ixel) | L(ine)) interleaving the presence of an alpha layer should imply interspersing the alphas in the I->data array. This would also get 'A' as 4rth char.

[PaulWessel]

OK, seems like we may want to have a function that strips A from the image and places it in I->alpha, and maybe the other way as well (although for writing the I->alpha works fine). May need a GMT_Image_Alpha () function to do the two operations.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[joa-quim]

For bad or for worst this had been addressed in the work at November 2023 for transparencies. Not all is working but this is now obsolete.