omp-fabric 1.26.4 → 1.26.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +6 -0
- package/docs/image.md +1 -1
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,11 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 1.26.5
|
|
4
|
+
|
|
5
|
+
### Fixed
|
|
6
|
+
|
|
7
|
+
- The docs said a `16:9` request "becomes `1536x1024`" without saying that `1536x1024` is 3:2. The hosted image tool accepts three pixel sizes only, so a ratio outside those is approximated, and `requestedSize` reports the resolved pixel size rather than the ratio. Measured: a `16:9` call returned 1536x1024 through that path, and a separate `responses` call on a panoramic prompt returned 2172x724 with `requestedSize` matching the sent value, which is what `sizeHonoured: false` reports.
|
|
8
|
+
|
|
3
9
|
## 1.26.4
|
|
4
10
|
|
|
5
11
|
### Fixed
|
package/docs/image.md
CHANGED
|
@@ -23,7 +23,7 @@ Written files stay on disk, and the image is attached to the `fabric_exec` resul
|
|
|
23
23
|
|
|
24
24
|
`options` accepts `model` (try this entry first), `aspectRatio`, `size` (`1024x1024`, `1536x1024`, `1024x1536`), `count` (images API only, capped at 4), and `saveTo` (file path for a single image).
|
|
25
25
|
|
|
26
|
-
`aspectRatio` and `size` reach the backend only where the wire has a field for them. The `images` dialect sends `size`/`aspect_ratio`, `gemini` sends `imageConfig`, and `responses` maps the ratio onto the image tool's `size` (`1:1` becomes `1024x1024`, `16:9` becomes `1536x1024`). The `chat` dialect has neither field, so a successful call through it reports `ignored: ["aspectRatio", "size"]` and never implies the request was honoured. An unrecognised ratio on `responses` is reported the same way. `count` is honoured by the `images` dialect alone, so asking for more than one image anywhere else reports `count`, and a `saveTo` that cannot apply because several images came back reports `saveTo`.
|
|
26
|
+
`aspectRatio` and `size` reach the backend only where the wire has a field for them. The `images` dialect sends `size`/`aspect_ratio`, `gemini` sends `imageConfig`, and `responses` maps the ratio onto the image tool's `size` (`1:1` becomes `1024x1024`, `16:9` becomes `1536x1024`). The hosted image tool accepts three pixel sizes only, so a `16:9` request is approximated to `1536x1024`, which is 3:2: `requestedSize` reports the resolved pixel size, never the ratio you asked for. The `chat` dialect has neither field, so a successful call through it reports `ignored: ["aspectRatio", "size"]` and never implies the request was honoured. An unrecognised ratio on `responses` is reported the same way. `count` is honoured by the `images` dialect alone, so asking for more than one image anywhere else reports `count`, and a `saveTo` that cannot apply because several images came back reports `saveTo`.
|
|
27
27
|
|
|
28
28
|
Each entry in `images` carries the pixel `width` and `height` read from the file header, and a call that asked for a size reports the `requestedSize` it resolved. When the backend returns something else, the result carries `sizeHonoured: false`. `ignored` covers parameters the wire cannot carry; `sizeHonoured` covers a parameter that was sent and then not obeyed, which is a different failure and a gateway can produce it.
|
|
29
29
|
|