I Introducing Images 2.6 fremhæver OpenAI animerede GIF'er som en central nyhed for skabere og marketingfolk: animér et brands maskot eller en figur, forvandl et produktbillede til en opmærksomhedsfangende løkke, eller afprøv figurens bevægelser med animerede storyboards, før videoproduktionen går i gang. API-ændringsloggen (4. november 2026) registrerer ligeledes generering af animerede GIF'er for GPT‑Image‑2.6 Flare/Sunburst. Guiden til billedgenerering angiver, at du anmoder om animation ved at sætte output_format til "gif" på POST /v1/images/generations.

👉 Prøv GPT Image 2.6-API'et på PoYo: pris pr. billede og online playground.

Træk først produktets grænse: OpenAI positionerer GIF som et »bevægelsesformat inden for billedgenereringens forløb«, ikke som en fuld videomodel som Sora. Redigerings-endpointet (/v1/images/edits) understøtter ikke GIF-output; streaming, delvise billeder, tilpasset output_compression og prompt_rewriter kan heller ikke kombineres med GIF. At påstå, at GIF »allerede erstatter video-API'et« eller »understøtter færdige film af vilkårlig længde«, rækker ud over, hvad denne artikel kan bekræfte i dokumentationen.

Officielle eksempler på anvendelser

Retningerne på produktsiden omfatter: marketingfolk og skabere, der animerer brandmaskotter til kampagner; reaktions- og meme-GIF'er til sociale medier; afprøvning af figurbevægelser med animerede storyboards før video; og omdannelse af enkle skitser til udtryksfulde figurer til video eller spil. Tidlige brugere som OpenArt citeres for at fremhæve, at »ét enkelt prompt kan give GIF'er klar til sociale medier«. Kunder som Town beskrives som brugere af API'et til at udforske animerede figurers personlighed i arbejdssammenhænge. Det er eksempler fra annonceringen og kundecitater; resultaterne afhænger stadig af prompts og parametre og bør ikke opfattes som en ensartet kvalitetsgaranti eller et branchebenchmark.

Med hensyn til prompting foreslår guiden til billedprompts: For en jævn løkke skal du beskrive den bane, der fører figuren tilbage til startpositionen, og angive, om kameraet bevæger sig. I ét eksempel giver Sunburst med size="512x512", quality="high", standard high complexity, frame_count=9 og frame_duration_ms=200 en lanterneanimation på omkring 1,8 sekunder i en løkke. Produktsiden viser også løkker, der er promptet i sprite sheet-stil, men API-integrationen bør stadig tage udgangspunkt i output_format: "gif" og billedramme-parametrene – gå ikke ud fra, at du først skal udsende et gitterbillede og selv samle billedrammerne.

Anmodningsfelter og begrænsninger

Ifølge dokumentationen til billedgenerering er de GIF-relaterede felter:

size beskriver dimensionerne for hver færdig billedramme. Antal billedrammer, billedrammestørrelse og antal animationer skal passe inden for modellens størrelsesgrænser og anmodningens samlede pixelbudget; hvis grænsen overskrides, skal du sænke frame_count, gøre billedrammerne mindre eller reducere n. Med auto vælger API'et billedrammestørrelsen inden for modellens grænser. frame_count og frame_duration_ms gælder kun for GIF-output. Svarets b64_json skal base64-afkodes og gemmes som en .gif-fil. Både Flare og Sunburst kan generere GIF'er via Image API; modelsiderne angiver animeret GIF-output som en fælles funktion. Valget kan stadig følge den sædvanlige logik om hastighed kontra præcision: korte løkker til sociale medier kan prøve Flare først; hvis du har brug for højere figurkonsistens eller flere detaljer, kan du derefter sammenligne med Sunburst.

Forsigtige grænser for brug

For det første er GIF en funktion på generations-siden – forvent ikke, at redigerings-endpointet kan »forvandle et stillbillede til en GIF«. For det andet kan komplekse prompts stadig give høj svartid på billedmodeller (dokumentationen nævner, at komplekse prompts kan tage op til omkring to minutter); bevægelsesanmodninger er underlagt det samme. For det tredje gælder indholdsmoderering og parameteren moderation også for GIF-anmodninger; når en anmodning blokeres, skal du ikke blindt forsøge igen uden at ændre prompten. For det fjerde skal du ikke skrive GIF-funktionen som »erstatter allerede video-API'et«: OpenAI har en separat videoproduktlinje; GIF i Images 2.6 løser korte løkker, let bevægelse og deling på sociale medier – ikke fortællinger i lange optagelser eller færdige film med høj billedhastighed. For det femte følger afregningen stadig modelsidernes regler for billedtokens; flere billedrammer og højere opløsning betyder normalt større outputforbrug – mål prisen pr. enhed på repræsentative prompts før lancering.

Set fra et ingeniørmæssigt godkendelsessynspunkt bør du bygge et fast promptsæt, der dækker »løkke tilbage til startpositionen« og »stillestående kamera kontra kamerabevægelse«, og registrere udseende, filstørrelse og svartid på tværs af kombinationer af frame_count/frame_duration_ms. Dokumentationen angiver ingen enkelt »bedste billedhastighed«; ni billedrammer à to hundrede millisekunder er blot et udgangspunkt. Hvis løkkens sammensyning er synlig, så ret hellere sprogbrugen om start- og slutposition i prompten, end du hæver antallet af billedrammer i det uendelige; flere billedrammer rammer pixelbudgettet hurtigere og øger prisen for outputtokens.

Kort sagt sætter GIF-output i Images 2.6 »korte løkker med bevægelse« på Image API's formelle formatliste. Integrér med output_format: "gif" og billedramme-parametrene, respektér begrænsningerne om manglende understøttelse af redigering og streaming, og gør det til et produkt uden at overdrive funktionaliteten.