Zum Hauptinhalt springen

Celebrity Look-Alike nimmt ein Porträt und liefert ein erzeugtes Bild des ähnlichsten Prominenten, ohne Prompt und ohne Parameter. Das Foto muss ein einzelnes, klares, annähernd frontales Gesicht zeigen; das Ergebnis nennt weder Namen noch Score.

Ab $0.05/Bild

Playground

Eingabe

Bildbearbeitung
1/1

Dateien oder Medienlinks ablegen, einfügen oder auswählen · 1 Datei · Max. 10 MB · JPG · PNG · WEBP · GIF

  • 1
1 / 1 Dateien
Ein klares, weitgehend frontales Porträt mit einem einzigen sichtbaren Gesicht. Bei Gruppenaufnahmen, Profilen, Sonnenbrillen und Bewegungsunschärfe wird die Zuordnung schlechter oder der Aufruf scheitert. Schicken Sie nur Fotos von Personen, die dieser Verwendung zugestimmt haben. mindestens 1 Zeichen
SicherheitsfilterAus

SpicyAPI führt bei diesem Modell keinen Sicherheitsfilter aus. Prompt und Material gehen unverändert an das Modell, und das Modell selbst entscheidet über das Ergebnis.

Wir prüfen Ihr Konto, bevor Absenden und Preisberechnung freigeschaltet werden.

Ausgabe

Bereit für einen neuen Lauf
passport-frontal-maleBeispielergebnis

Verwandte Modelle und nächste Schritte

Ihr Modell ist nicht dabei?

Sagen Sie uns, welches Modell fehlt und wofür Sie es brauchen. Ihre Anfrage geht direkt an das Team, das über die nächsten Modelle entscheidet.

Ein Bildfeld, keine Parameter, ein generiertes Bild zurück

Die Bearbeitungs-API von Celebrity Look-Alike nimmt ein einzelnes Porträt in image_url entgegen und liefert ein generiertes Bild der ähnlichsten prominenten Person zurück. Dieses Feld ist der gesamte Request-Body: kein Prompt, kein Seed, keine Auflösung, kein Ausgabeformat. additionalProperties steht auf false, jeder weitere Schlüssel scheitert also an der Validierung. In der Antwort steckt nur das Bild – kein Name, keine Kandidatenliste, kein Ähnlichkeitswert.

Playground öffnen
Request-Body
image_url (String, erforderlich) ist der ganze Body – eine Eigenschaft, und weder Prompt noch Seed, Auflösung oder Ausgabeformat
Eingabe-URL
Muss direkt auf die Bilddatei führen, ohne Login abrufbar sein und bis zum Ende des Auftrags gültig bleiben
Antwort
Ein generiertes Bild. Kein Promi-Name, keine Kandidatenliste, kein Ähnlichkeitswert
Aufrufmuster
Asynchron: absenden, Auftrags-ID behalten, bis zum Endzustand abfragen. Obergrenze 1.800 Sekunden
Aufbewahrung
Das gesendete Foto wird nach 1 Tag gelöscht, das generierte Ergebnis nach 14 Tagen
Einwilligung
Jede Eingabe ist das Gesicht eines echten Menschen. Senden Sie nur Porträts mit Zustimmung der abgebildeten Person
Schema
Eine Eigenschaft – jeder andere Schlüssel ist ein ValidierungsfehlerDas Anfrageschema definiert image_url und setzt additionalProperties auf false. Ein übrig gebliebener Prompt-String oder ein Stärkewert aus der Payload eines anderen Endpunkts kommt als Validierungsfehler mit dem Namen des beanstandeten Feldes zurück, und daraus entsteht kein Auftrag. Nichts wird eingereiht, und nichts wird unterwegs stillschweigend verworfen.
Antwort
Name und Wert fehlen mit AbsichtHinter diesem Endpunkt steckt kein Klassifikationsschritt, dessen Label wir durchreichen könnten: Er erzeugt ein Bild, er schlägt niemanden in einer Liste nach. Deshalb enthält die Antwort weder einen Promi-Namen noch eine Rangliste noch einen Konfidenzwert. Welche Beschriftung Ihre Oberfläche zeigt, schreiben Sie – und dafür stehen Sie gerade.
Einwilligung
Bei jedem Aufruf ist die Eingabe das Gesicht eines echten MenschenHeikel an dieser Anfrage ist einzig das Foto. In der Praxis gibt es nur eine sichere Quelle: das eigene Porträt der Nutzerin oder des Nutzers, in Ihrem Produkt aufgenommen, für genau diese Funktion, mit einer Einwilligung, die vorliegt, bevor die Datei in Ihren Speicher gelangt. Wenn Sie entscheiden, ob Sie das überhaupt einsetzen dürfen, legen Sie denselben strengen Maßstab an wie bei Gesichtserkennung – auch wenn dieser Endpunkt niemanden erkennt.

Was die Celebrity Look-Alike API gut kann

  • Der gesamte Request-Body ist ein Feld

    image_url ist erforderlich, mehr wird nicht angenommen, und damit ist die Liste vollständig. Es gibt keine Vorlage zu rendern und keine dynamische Feldtabelle zu pflegen: eine String-Variable in einem JSON-Objekt deckt jeden Aufruf ab, den dieser Endpunkt je bekommen wird – ob das Foto ein Handy-Selfie ist oder eine Studioaufnahme.

  • Wo es nichts einzustellen gibt, lässt sich auch nichts falsch einstellen

    Kein Prompt zu schreiben, kein Seed zu fixieren, keine Auflösung und kein Ausgabeformat zu wählen. Der einzige Hebel ist das Foto selbst. Enttäuscht ein Ergebnis, ist die Antwort deshalb eine andere Aufnahme – enger geschnitten, gleichmäßiger ausgeleuchtet, Gesicht gerader zur Kamera – und keine Suche durch Parameter, die es nicht gibt.

  • Ein Gesicht pro Anfrage, so gebaut

    Der Endpunkt nimmt ein Porträt und hat keine Möglichkeit zu erfahren, welche Person im Bild Sie gemeint haben. Eine Gruppenaufnahme ist deshalb keine schwierige, sondern eine falsche Eingabe. Wer vor dem Absenden auf ein Gesicht zuschneidet, beseitigt die häufigste Ursache für ein Ergebnis, mit dem niemand etwas anfangen kann.

  • Ein Auftrag, ein Bild

    Ein abgeschlossener Auftrag gibt genau ein generiertes Bild aus dem Plattformspeicher heraus, und es gibt kein Feld für Anzahl oder Stapel. Zehn Porträts heißt zehn Aufträge, jeder mit eigener ID, eigenem Abfragestand und eigener Abrechnung – so hält ein unbrauchbares Foto die anderen neun nicht auf.

  • Asynchron, mit einer Obergrenze von 1.800 Sekunden

    Das Absenden antwortet mit einer Auftrags-ID statt mit einem Bild, und Sie lesen diesen Auftrag, bis er einen Endzustand meldet. Einen synchronen Modus als Rückfallebene gibt es nicht. Ein Auftrag, der nie in einen Endzustand kommt, bleibt nicht offen stehen, sondern wird an der Obergrenze von 1.800 Sekunden beendet.

  • Zwei Aufbewahrungsfristen, mit denen Sie planen müssen

    Das gesendete Foto wird nach 1 Tag gelöscht, das generierte Ergebnis nach 14 Tagen. Keine der beiden Zahlen ist ein Hindernis, das man umgehen müsste – sie sind der Grund, ein Bild, das bleiben soll, im Vorbeigehen in den eigenen Speicher zu ziehen, und der Grund, warum eine Share-Card nicht dauerhaft auf unsere URL zeigen kann.

Für wen Celebrity Look-Alike gedacht ist

  • Produktteams im Endkundengeschäft

    Eine Funktion, die von der Nutzerseite nichts außer einem Foto verlangt

    Es gibt kein Prompt-Feld zu gestalten, keinen Stil-Auswähler zu erklären und keinen Fehlerfall, in dem jemand etwas Unbrauchbares eintippt. Der Ablauf ist hochladen, warten, Bild sehen. Deshalb passt die ganze Funktion hinter eine Schaltfläche und einen Platzhalter – und deshalb liegt die eigentliche Entwurfsarbeit im Einwilligungsdialog davor.

  • Backend-Entwicklung

    Ein Schema, das klein genug ist, um es fest zu verdrahten

    Bei genau einem String, der zu füllen ist, braucht der Request-Body kein Feldverzeichnis, keinen schemagesteuerten Formulargenerator und keine eigene Validierungsschicht. Übrig bleibt die Verkabelung: eine URL, die auf Bytes führt, ein Idempotenzschlüssel beim Anlegen, eine Abfrageschleife und ein Kopierschritt, bevor die Aufbewahrungsfrist abläuft.

  • Datenschutz- und Rechtsprüfung

    Eine Entscheidung, die vor den Start gehört, nicht danach

    Biometrische Daten sind in der Europäischen Union und in mehreren US-Bundesstaaten gesondert und streng reguliert, und diese Pflicht liegt bei Ihnen, nicht bei uns. Klären Sie zuerst drei Punkte schriftlich: wo die Einwilligung eingeholt wird, wie lange das Foto auf Ihrer Seite liegt und wer für den Text neben dem Ergebnis verantwortlich ist.

  • Teams mit bestehendem Upload-Weg

    Wo die neuen Pflichten in einer Strecke landen, die Sie schon betreiben

    Wenn in Ihrem Produkt ohnehin Porträts unterwegs sind, ist der Endpunkt selbst eine kleine Ergänzung – das Gewicht liegt woanders. Die Einwilligung muss vorliegen, bevor die Datei in Ihren Speicher gelangt, denn nachreichen lässt sie sich nicht. Und unsere Fristen von 1 Tag und 14 Tagen ändern nichts an Ihrer eigenen Aufbewahrungsrichtlinie.

So rufen Sie die Celebrity Look-Alike API auf

  1. Die Einwilligung einholen, bevor das Foto in Ihrem Speicher liegt

    Die Einwilligung steht einen Schritt vor der URL, und nachträglich lässt sie sich nicht ergänzen. Legen Sie fest, wozu die abgebildete Person zustimmt, halten Sie die Zustimmung fest und verknüpfen Sie diesen Nachweis mit dem Foto. Dieser Schritt entscheidet, ob der Rest der Anbindung überhaupt laufen darf.

  2. Eine URL bereitstellen, die die Bilddatei selbst liefert

    image_url ist ein String, der Link muss also direkt zu den Bildbytes führen und ohne Login abrufbar sein. Eine Seite, in die das Foto eingebettet ist, ist kein Foto. Wenn Ihr Speicher kurzlebige signierte URLs ausgibt, prüfen Sie beim Absenden, ob der Link noch gültig ist, und halten Sie ihn bis zum Ende des Auftrags am Leben.

  3. Den Body mit dem einen Feld und einem Idempotenzschlüssel senden

    Bauen Sie den Body allein aus image_url und entfernen Sie Reste aus der Payload eines anderen Endpunkts, denn additionalProperties steht auf false. Hängen Sie einen Idempotency-Key an: Reißt die Verbindung ab und wiederholt Ihr Client die Anfrage, liefert der Schlüssel den ursprünglichen Auftrag statt eines zweiten mit einer zweiten Abrechnung.

  4. Die Auftrags-ID bis zum Endzustand abfragen

    In der Antwort auf das Absenden steht nichts außer der ID, lesen Sie den Auftrag also, bis er einen Endzustand meldet. Halten Sie dafür keine Nutzeranfrage offen – geben Sie dem Browser einen Platzhalter und füllen Sie ihn, sobald die Abfrage etwas liefert. Die Obergrenze von 1.800 Sekunden ist der äußere Rahmen der Schleife.

  5. Das Bild sichern und die Beschriftung selbst schreiben

    Die Ergebnis-URL zeigt auf den Plattformspeicher, und diese Datei wird nach 14 Tagen gelöscht. Ziehen Sie alles, was in eine Galerie oder auf eine Share-Card gehört, im Vorbeigehen in den eigenen Bucket. Die Antwort enthält nichts, womit sich das Bild beschriften ließe – jedes Wort daneben ist also eine Aussage, die Sie treffen.

Celebrity Look-Alike in der Praxis

  • Eine Funktion mit einer einzigen Schaltfläche in einer Endkunden-App

    Die Nutzerin nimmt das Porträt in der App auf, setzt den Haken bei einer Einwilligung, die genau benennt, wofür das Foto verwendet wird, und der Client legt es im eigenen Bucket ab. Ihr Backend sendet ein Feld, zeigt einen Platzhalter und tauscht das Bild ein, sobald die Abfrage zurückkommt. Für die Nutzerseite sichtbare Parameter: keine.

  • Eine Warteschlange von Porträts, die einen Verbindungsabbruch übersteht

    Ein Stapelverarbeiter schickt pro Porträt einen Auftrag und hängt jedem einen Idempotency-Key an, der aus der ID des gespeicherten Fotos abgeleitet ist. Wird ein Absenden unterbrochen und der Lauf wiederholt, liefert der Schlüssel den ursprünglichen Auftrag statt eines zweiten – ein neu gestarteter Stapel zahlt also nicht zweimal für dasselbe Foto.

  • Eine Galerie, die die 14 Tage überdauert

    Ein Produkt, in dem Nutzer zu früheren Ergebnissen zurückkehren, kann unsere Asset-URLs nicht verlinken, denn diese Dateien werden nach 14 Tagen gelöscht. Die tragfähige Form ist ein Kopierschritt in demselben Worker, der die Abfrage auf den Endzustand erledigt: einmal holen, im eigenen Bucket ablegen, die eigene URL speichern und unsere danach nie wieder lesen.

Fragen zur Celebrity Look-Alike API

Es gibt keinen Prompt zu schreiben und keinen Parameter einzustellen, die gesamte Anbindung besteht also aus Eingaben, Verkabelung und Erlaubnis. Klären Sie die Einwilligung, bevor das Foto in Ihrem Speicher landet – das ist der eine Schritt, der sich später nicht mehr reparieren lässt. Stellen Sie eine URL bereit, die die Bildbytes liefert und bis zum Ende des Auftrags gültig bleibt. Senden Sie das eine Feld mit einem Idempotency-Key, fragen Sie die Auftrags-ID bis zum Endzustand ab und kopieren Sie alles, was bleiben soll, vor Ablauf der 14 Tage. Und schreiben Sie dann die Beschriftung: Die Antwort gibt Ihnen ein Bild und bewusst nichts, womit Sie es benennen könnten.