Initial implementation of float16 support

[eschnett]

This continues #10342. Most problems should now be remedied.

[eschnett]

I think this error https://github.com/OSGeo/gdal/actions/runs/11652629851/job/32444055840?pr=11180 is a false positive. Is there a way to disable the error?

[rouault]

I think this error https://github.com/OSGeo/gdal/actions/runs/11652629851/job/32444055840?pr=11180 is a false positive

yes, looks also like a FP to me.

Perhaps try to modify gdalmultim.cpp line 1705-1706 to be something like:

const GFloat16 *src = static_cast<const GFloat16 *>(pSrc);
GFloat16 srcTab[2];
memcpy(srcTab, src, sizeof(srcTab));
str = CPLSPrintf("%.5g+%.5gj", double(srcTab[0]), double(srcTab[1]));

but CSA might be smart enough to not be confused by that trick.
Otherwise you'll likely need to write some jq magick in ci/travis/csa_common/script.sh to skip the false positive

[eschnett]

I tried something similar but without the memcpy, std::complex<GFloat16> val = .... That was accepted, and the error was still reported while (presumably) evaluating the CPLSPrintf arguments. I'll try jq magic.

[rouault]

I'll try jq magic.

if too complicated, you may also add a "#if !defined(CSA_BUILD)" protection (with a code comment explaining why it is needed). This macro is set specifically for this build, so won't hurt production builds

[eschnett]

I checked that using Ubuntu 24.04 (instead of 22.04) for this test does not report an error for cpl_float.h, confirming it's a false positive.

[eschnett]

@rouault The error for Ubuntu 24.04 looks ephemeral. Can you restart that CI build?

[rouault]

I gave a local try at this pull request, both with a compiler that supports Float16 and one that doesn't, and managed to convert from/to Zarr Float16. Great job !

https://gdal.org/en/latest/user/raster_data_model.html#raster-band will need to be edited to mention Float16.

The RFC text in #10146 may (didn't check closely) need a few adjustments to reflect the implementation. Once we're happy with the RFC text, we should proceed to make the GDAL PSC adopt it.
Implementation wise, the scope of this pull request (core changes + Zarr changes) is probably big enough. Changes in other driver (HDF5, GTiff) may be better handled by follow-up pull requests once this one is merged.

[eschnett]

I updated the documentation and the RFC.

[rouault]

I updated the documentation and the RFC.

cool, when ready, you may respond to your gdal-dev mailing list thread of June 6th with a title like "Call for discussion on RFC 100: Adding Float16 support to GDAL" to draw more attention on it, and ask for last comments before putting it to vote. Note: I've doumented our RFC process in https://gdal.org/en/latest/development/rfc_process.html

[github-actions]

The GDAL project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 28 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular link
  to any issues which this pull request fixes

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in 2 weeks.

[github-actions]

While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 6 weeks. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the GDAL project can do to help push this PR forward please let us know how we can assist.