announcements

SVG-eksport i Images 2.6: grenser for vektorgrafikk til nett, apper og trykk

PoYo Team
5 min read
Share:

SVG-eksport i Images 2.6: grenser for vektorgrafikk til nett, apper og trykk

I Introducing Images 2.6 skriver OpenAI at SVG-eksport lar design gå rett inn i nettsteder, apper og trykk. Changelog for API-et (4. november 2026) oppgir SVG-generering som en offisiell funksjon i GPT‑Image‑2.6 Flare og Sunburst. Veiledningen for bildegenerering angir at du ber om vektorutdata ved å sette output_format til "svg" på POST /v1/images/generations. Bruksområdene oppsummeres som grafikk som trenger redigerbare baner, former og farger – for eksempel ikoner og illustrasjoner. Denne artikkelen holder seg til dokumenterte grenser – ingen påfunne garantier for trykkoppløsning eller kompatibilitetsscorer på tvers av leverandører.

👉 Prøv GPT Image 2.6 API på PoYo: pris per bilde og nettbasert playground.

Felt i forespørselen og harde grenser

Ifølge veiledningen for bildegenerering og prompting-veiledningen for bilder må SVG-forespørsler følge disse kravene. For det første må n være 1 – du kan ikke få flere vektorfiler tilbake i én batch. For det andre støttes ikke strømming, delvise bilder, output_compression eller prompt_rewriter. For det tredje støtter ikke redigeringsendepunktet SVG-utdata, og SVG er heller ikke godkjent som rasterinndata til redigeringer, så «lag SVG og rediger deretter banene» er ingen offisiell vei. For det fjerde genererer API-et først et referansebilde og utleder SVG fra det. quality-nivået gjelder for referansebildet. b64_json i responsen bør base64-dekodes og lagres som UTF-8-XML med filendelsen .svg. For det femte er det returnerte dokumentet statisk vektorinnhold – uten skript, eksterne ressurser eller innebygde rasterbilder. SVG støtter også background="transparent", slik at merker kan plasseres på hvilken som helst bakgrunn.

Både Flare og Sunburst kan generere SVG. Prompting-veiledningen sammenligner begge nivåene med den samme prompten for logoen til bakeriet «Field & Flour», og viser at valget fortsatt kan følge den vanlige avveiningen mellom hastighet og presisjon i stedet for å anta at ett nivå er «mer vektor». Faktureringen følger reglene for bildetokens på modellsiden, og endringer i kompleksitet koster ikke noe ekstra. Mål kostnaden per element på representative prompter for logoer og ikoner før lansering.

Egnede bruksområder: nett, apper og trykk

Produktkunngjøringen posisjonerer SVG som en eksport som «lar design gå videre til neste fase av et prosjekt». Kombinert med formuleringene i dokumentasjonen kan følgende egnede bruksområder trygt nevnes: logoer og ikoner som trenger redigering på banenivå, flate illustrasjoner som må skaleres uten tap på nett og i klienter, merkevaresymboler som trenger transparent bakgrunn for fargelegging, og vektorutkast før trykk som fortsatt skal kunne få endret farger og strøk i designverktøy. Når det gjelder prompting, legger de offisielle eksemplene vekt på rene konturer, tydelige silhuetter, balansert luft og få gradienter, slik at merkene forblir lesbare i både små og store størrelser – i tråd med vanlige krav til trykk og appikoner, men ikke en påstand om at det er «testet på en bestemt trykkpresse».

I pipelines for nett og apper kan den returnerte XML-en sendes videre til opprydding i frontend eller designsystem. Dokumentasjonen påstår ikke at SVG-en alltid oppfyller kravene til en bestemt optimaliserer eller tilgjengelighetsprofil – integratører bør selv kjøre strukturkontroller, slå sammen baner og rense filene. I arbeidsflyter som ender i trykk, unngår vektorer taggete kanter fra oppskalering av raster, men fargestyring, spotfarger, utfallende og innebygging av fonter er fortsatt oppgaver for produksjonssystemet og ligger utenfor dokumentasjonen for Image API. Hvis sluttresultatet må være redigerbart raster eller bevegelse, bytter du til PNG/WebP/GIF i stedet for å tvinge SVG inn som en universalbeholder.

Grenser du ikke bør overdrive

For det første er SVG en funksjon på genereringssiden – ikke forvent at redigeringer eller markup leverer vektorer direkte. For det andre inneholder svarene ingen skript eller eksterne ressurser – ikke beskriv dem som «interaktive SVG-apper». For det tredje tillater dokumentasjonen eksplisitt ikke SVG som inndata til redigering, så iterasjon på merkevaren bør skje i rasterfasen med referanser, markup eller mask, og SVG-eksporten bør bestilles separat etter at designet er låst. For det fjerde gjelder fortsatt de generelle begrensningene: Komplekse prompter kan ta opptil rundt to minutter, og tekstgjengivelse og strukturert komposisjon kan fortsatt komme til kort. For det femte gjelder innholdsmoderering og parameteren moderation også for SVG-forespørsler.

For teknisk godkjenning bør du bygge et fast sett med prompter: monokrome logoer, flerfargede ikoner, logooppsett som krever transparent bakgrunn, og merker med litt nødvendig tekst. Etter dekoding sjekker du at rotelementet og banene er komplette, at skript eller eksterne lenker ikke er tatt med ved en feil, og at transparente områder faktisk er hule. Kjør din egen flyt for SVG-optimalisering og -rensing for nett og apper, og overlat fargeprofiler, utfallende og spotfarger til forhåndstrykksystemene i stedet for å forvente at Image API gjør den jobben. Kvalitetsnivået påvirker referanserasteret og kan dermed indirekte påvirke hvor oppstykkede vektorbanene blir. Hvis banene er for oppstykkede eller for grove, øker eller senker du kvaliteten mens alt annet holdes likt, i stedet for å endre prompt og nivå samtidig. Flare passer for raske formforsøk, mens Sunburst passer for vurderinger før ferdigstilling der kravene til konturer og detaljer er strengere. Begge kan levere SVG.

Konklusjon: Images 2.6 setter statisk SVG på den offisielle listen over utdataformater i Image API, for gjenbruk som vektor før nett, apper og trykk. Integrer med output_format: "svg", n=1 og den harde regelen «bare generering, ingen utdata fra redigeringer», og fullfør godkjenning av baner og forhåndstrykk i din egen verktøykjede uten å overdrive hva funksjonen kan.

Share: