A pixel format is twenty-four names, not an int

vendor/raylib/bindings

@@ -136,6 +136,15 @@ exclude DrawSphereWires
 exclude DrawRay
 exclude GetScreenToWorldRay
 
+# The third batch, and one line for one reason. ImageFormat's `int newFormat`
+# is a PixelFormat in fact — twenty-four codes of which exactly one is what a
+# texture upload needs — so its Flan face is the defenum and not the C
+# signature, the same trade SetTextureFilter makes one block up.
+# examples/textures-image-processing.flan is what wanted it: the C's
+# `PIXELFORMAT_UNCOMPRESSED_R8G8B8A8` is a name there and would have been a 7
+# here.
+exclude ImageFormat
+
 # ── The idiomatic layer, which is what these last two blocks are for ──
 #
 # Three kinds of C signature get a Flan face in raylib.flan rather than the
@@ -216,12 +225,20 @@ enum GamepadAxis      GAMEPAD_AXIS_
 enum Gesture          GESTURE_
 enum MouseCursor      MOUSE_CURSOR_
 enum TextureFilter    TEXTURE_FILTER_
+enum PixelFormat      PIXELFORMAT_
 
 # raylib writes GESTURE_DOUBLETAP as one word where every other member of that
 # enum is underscored. This is the narrow exception and not a general escape
 # hatch: one name the prefix rule gets wrong, said once.
 constant Gesture/double-tap GESTURE_DOUBLETAP
 
+# And the second such pair, for the same kind of reason. The rule uppercases
+# the Flan member name, and raylib spells the two ASTC block sizes with a
+# lowercase `x` — PIXELFORMAT_COMPRESSED_ASTC_4x4_RGBA — where every other
+# letter in that enum is upper. Two names the rule gets wrong, said once each.
+constant PixelFormat/compressed-astc-4x4-rgba PIXELFORMAT_COMPRESSED_ASTC_4x4_RGBA
+constant PixelFormat/compressed-astc-8x8-rgba PIXELFORMAT_COMPRESSED_ASTC_8x8_RGBA
+
 # The 16 ConfigFlags bits. These are the values sand.flan and the ported
 # window-flags example pass to set-config-flags, set-window-state and
 # clear-window-state, and each is a single bit read off raylib.h by hand —

vendor/raylib/generated.flan

@@ -153,7 +153,6 @@
 (declare-c image-from-channel [image Image  selected-channel i32] Image "ImageFromChannel")
 (declare-c image-text [text string  font-size i32  color Color] Image "ImageText")
 (declare-c image-text-ex [font Font  text string  font-size f32  spacing f32  tint Color] Image "ImageTextEx")
-(declare-c image-format [image (Ptr Image)  new-format i32] "ImageFormat")
 (declare-c image-to-pot [image (Ptr Image)  fill Color] "ImageToPOT")
 (declare-c image-alpha-crop [image (Ptr Image)  threshold f32] "ImageAlphaCrop")
 (declare-c image-alpha-clear [image (Ptr Image)  color Color  threshold f32] "ImageAlphaClear")

vendor/raylib/raylib.flan

@@ -660,6 +660,59 @@
 ;; level too, so a caller can see which ones change what they are given.
 (defstruct Image [data (Ptr u8)  width i32  height i32  mipmaps i32  format i32])
 
+;; The codes that `format` field carries, named. The header says `int format`
+;; everywhere one is passed, and there is nothing in an `int` to say that 7 is
+;; the one a texture upload requires — which is exactly the trade
+;; TextureFilter and MouseCursor already made, and the reason this is a
+;; defenum rather than a row of defconsts.
+;;
+;; The set is closed and is here whole, compressed members included, because a
+;; subset would put the hole where the next caller looks: `format` is a field
+;; programs *read* off an Image they did not make, and a loaded .ktx or .dds
+;; answers with one of the compressed codes. Nothing here converts to one —
+;; raylib's own ImageFormat only moves between the uncompressed formats — so
+;; the compressed half is for reading rather than for asking.
+;;
+;; `uncompressed-r8g8b8a8` is 7, the one GenImageColor makes and the one
+;; LoadTextureFromImage and UpdateTexture want. The `x` in the two ASTC names
+;; is lowercase in raylib.h where every other letter in that enum is upper, so
+;; those two are mapped by name in `bindings` — the same narrow exception
+;; GESTURE_DOUBLETAP already has, and for the same reason.
+(defenum PixelFormat
+  [uncompressed-grayscale     1
+   uncompressed-gray-alpha    2
+   uncompressed-r5g6b5        3
+   uncompressed-r8g8b8        4
+   uncompressed-r5g5b5a1      5
+   uncompressed-r4g4b4a4      6
+   uncompressed-r8g8b8a8      7
+   uncompressed-r32           8
+   uncompressed-r32g32b32     9
+   uncompressed-r32g32b32a32 10
+   uncompressed-r16          11
+   uncompressed-r16g16b16    12
+   uncompressed-r16g16b16a16 13
+   compressed-dxt1-rgb       14
+   compressed-dxt1-rgba      15
+   compressed-dxt3-rgba      16
+   compressed-dxt5-rgba      17
+   compressed-etc1-rgb       18
+   compressed-etc2-rgb       19
+   compressed-etc2-eac-rgba  20
+   compressed-pvrt-rgb       21
+   compressed-pvrt-rgba      22
+   compressed-astc-4x4-rgba  23
+   compressed-astc-8x8-rgba  24])
+
+;; Reformats the pixels in place, reallocating the buffer, so the Image's
+;; `data`, `format` and — for a compressed source — its size all change under
+;; the caller. Hand-written rather than generated for the enum: the header's
+;; `int newFormat` takes any integer at all and only one of twenty-four is the
+;; conversion a given program meant.
+(declare-c image-format
+  [image (Ptr Image)  new-format PixelFormat]
+  "ImageFormat")
+
 (declare-c load-image [path string] Image "LoadImage")
 
 ;; raylib 5.5 spells this IsImageValid. IsImageReady, which older code calls,
@@ -726,8 +779,11 @@
 ;; The non-mutating form of the line above, and the reason it is worth having
 ;; both: image-crop changes the image it is given, so carving a sheet into
 ;; twenty tiles with it destroys the sheet on the first one. This returns a
-;; fresh Image and leaves the original alone. There is no ImageCopy in 5.5, so
-;; this is also how a whole image is duplicated — a rec covering all of it.
+;; fresh Image and leaves the original alone. A rec covering the whole image
+;; duplicates it, which is what this was originally reached for — though
+;; image-copy in the generated half says that in one argument and is the
+;; better call for it. (An earlier comment here said 5.5 had no ImageCopy. It
+;; does — raylib-5.5.h line 1348 — and generated.flan has bound it all along.)
 ;;
 ;; The result owns its own buffer: unload-image it, like anything else that
 ;; allocated.