@nitida/sdk 0.36.2 → 0.36.3

package/README.md

@@ -608,7 +608,7 @@ this table from the source, so it can't have the wrong one.
 | `sm`      | `s`  | 640                | mobile thumbs, list cards |
 | `md`      | `m`  | 1280               | desktop cards, modal previews |
 | `lg`      | `l`  | 1920 (≈2K)         | hero, full-bleed |
-| `xl`      | `x`  | 3840 (4K)          | print, 4K screens |
+| `xl`      | `x`  | 3840 (4K)          | print, 4K screens · a clean WebP base ≤ 3840 is reused as-is |
 
 **Defaults — what actually runs:**
 
@@ -644,6 +644,16 @@ the full responsive ladder ≈ 4× source bytes.
 (3840) yields a 1080×720 `xl` variant, not a blurry 3840-wide stretch.
 The preset is a **ceiling**, not a target.
 
+**`xl` reuses a ≤ 4K base byte-for-byte.** 4K is the cap for listing
+photos. When the uploaded base is a clean WebP no larger than 3840 px
+(single frame, no EXIF orientation, no EXIF/XMP), the server stores it
+as `xl` unchanged: same sha256, no second lossy pass. Anything else (a
+larger base, JPEG/PNG/HEIC, animated or EXIF-bearing WebP) is re-encoded
+to WebP q82 as before. The default `compressImage` output (3840 px WebP)
+qualifies. URLs, keys and response shapes do not change; `xl` is still
+its own object, the same size as the base. Already-stored assets keep
+their existing `xl`.
+
 ### Non-image / passthrough
 
 | Preset    | Code | Purpose |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nitida/sdk",
-  "version": "0.36.2",
+  "version": "0.36.3",
   "description": "nitida — the media SDK: browser and mobile upload with resume, client-side compression, on-the-fly transforms behind a CDN, video transcode, HLS ladders and AI proxies. Multi-tenant.",
   "private": false,
   "publishConfig": {
@@ -73,7 +73,7 @@
   },
   "peerDependencies": {
     "react": ">=18",
-    "@nitida/asset-client": "^0.24.0",
+    "@nitida/asset-client": "^0.24.1",
     "@nitida/asset-compressor-web": "^0.6.1",
     "@nitida/asset-compressor-native": "^0.2.1"
   },

package/skills/nitida-sdk/SKILL.md

@@ -186,6 +186,26 @@ everyone, and the ladder buys you nothing.
 - ⚠️ The **first** request of each width is generated cold, then cached at the
   edge immutably. Warm them after upload if the first visitor matters.
 
+### `xl` is the base itself when the base is already ≤ 4K
+
+4K (3840 px long side) is the cap for listing photos, and a base inside it is
+already final. So at upload the server stores a **clean WebP base ≤ 3840 px**
+(single frame, no EXIF orientation, no EXIF/XMP block) as `xl`
+**byte-identical**: same sha256, no decode, no second lossy pass. Anything else
+is re-encoded to WebP q82 as before: a base larger than 3840 px (resized to
+3840), a JPEG/PNG/HEIC, an animated WebP, or a WebP carrying EXIF/XMP (the
+re-encode strips metadata, so GPS never reaches a public URL).
+
+- The default browser compressor (`compressImage`, 3840 px WebP via canvas,
+  which writes no EXIF) produces exactly such a base. Upload with `"xl"` in
+  `presets` and `xl` costs no quality.
+- URLs, keys (`…/x/<sha>.webp`), `presets` and response shapes are unchanged.
+  `xl` is still its own stored object (a copy of the base's bytes), so it
+  weighs the same as the base, not less.
+- This applies to uploads processed on or after the server change. Assets
+  already stored keep the `xl` they have. `regenerate(id, { presets: ["xl"] })`
+  applies the new rule.
+
 ### ⚠️⚠️ On a LADDERED asset, an explicit `quality` compresses the image TWICE
 
 > Full measurements, with the method: <https://nitida.gofuture.space/guides/transform-benchmark/>