Rivya gids voor referenties en uploads

Gebruik deze gids voor referenties en uploads voordat je een model kiest dat afhangt van image references, video references of uploaded audio.

Referenties en uploads zijn een kernonderdeel van hoe Rivya-taken van discovery naar ingelogde Studio-uitvoering bewegen.

Ze beinvloeden:

• modelkeuze
• workflowkeuze
• promptstructuur
• taakkosten
• of de gebruiker moet starten op een public start page, modeldetailpagina of Studio

Daarom zijn uploads niet alleen een UI-detail. Ze zijn onderdeel van de workflowlogica.

Een operationeel detail is vroeg belangrijk:

• reference-aware pages kunnen openbaar zijn
• daadwerkelijke file upload vereist momenteel sign-in

Een public start page kan dus nog steeds de juiste plek zijn om te beginnen, maar upload-based execution is in het huidige product niet volledig anoniem.

Drie uploadvormen

Vandaag valt reference- en uploadgedrag in Rivya vooral in drie vormen:

• beeldreferenties
• videoreferenties
• audio-uploads

Niet elk model ondersteunt alle drie.

Daarom is de modelpagina belangrijk voordat de taak begint.

Beeldreferenties

Veel image- en videoworkflows ondersteunen image references.

Afhankelijk van het model kunnen reference-image limits sterk verschillen.

Op dit moment loopt die range van:

• een enkele reference image
• grotere multi-image workflows

Dit is belangrijk omdat "supports references" en "supports many references" niet hetzelfde zijn.

Videoreferenties

Sommige videoworkflows kunnen ook video references of andere uitgebreide reference modes accepteren.

Dit is niet universeel in de catalogus.

Daarom moeten gebruikers niet aannemen dat elk videomodel dezelfde inputsoort accepteert alleen omdat het in dezelfde category zit.

Audio-uploads

Audio uploads zijn het belangrijkst in workflows zoals:

• audio-opschoning
• audio-isolatie
• audiotransformatie

Die verschillen structureel van prompt-first audio generation.

Als het model uploaded audio verwacht, gedraagt het formulier zich met opzet anders.

Waarom het formulier per model verandert

Rivya's generation forms zijn model-driven.

Dat betekent dat zichtbare inputs afhangen van:

• wat het geselecteerde model ondersteunt
• welke file kinds het accepteert
• hoeveel bestanden het kan gebruiken

Dit is het juiste gedrag, omdat een prompt-only model en een upload-first model niet dezelfde workflow zijn.

Huidige upload kinds

De belangrijkste upload kinds in huidige productflows zijn:

• image
• video
• audio

Deze worden in het product genormaliseerd voordat ze naar de uiteindelijke model request gaan.

Huidige upload limits

Het uploadpad dwingt momenteel size- en typechecks af per kind:

Image

• JPEG
• PNG
• WebP
• huidige standaard max size: 10 MB
• Nano Banana 2 en Nano Banana Pro staan momenteel tot 30 MB toe

Video

• MP4
• MOV / QuickTime
• WebM
• huidige max size: 50 MB
• Wan 2.6 gebruikt momenteel een strengere 10 MB cap en accepteert MP4, MOV / QuickTime en MKV-style video uploads

Audio

• MP3
• MP4 audio
• WAV
• AAC
• OGG
• huidige standaard max size: 10 MB

Deze limits gaan over veilige ingestion en routing, niet alleen over UI-gemak.

Referenties en modelkeuze

Reference support is vaak belangrijker dan hype.

Bijvoorbeeld:

• als de workflow veel image references nodig heeft, kies je het juiste model zelden alleen op brand reputation
• als de workflow uploaded audio nodig heeft, is een standaard TTS-model de verkeerde ingang

Daarom is de schoonste volgorde voor modelkeuze:

1. outputtype
2. reference- of uploadvereiste
3. cost en quality fit
4. pas daarna modelvoorkeur

Openbare pagina's versus Studio

Public start pages zijn goed wanneer je wilt:

• een eerste openbare landing page
• een directe model-specific entry
• een search-driven pad naar de juiste workflow

Studio is beter wanneer de taak nodig heeft:

• signed-in upload en execution
• herhaalde iteratie
• meer continuiteit
• een vollere werkcontext

Dit geldt vooral zodra de upload zelf onderdeel wordt van een langere workflow.

Veelvoorkomende fouten

Fout 1: aannemen dat alle modellen in een category dezelfde file types accepteren

Dat doen ze niet.

Fout 2: een model kiezen voordat je upload support checkt

Dit veroorzaakt vaak vermijdbare rework.

Fout 3: uploaded-audio workflows behandelen als prompt-only workflows

Dat zijn verschillende paden en ze moeten verschillend worden behandeld.

Referentieworkflow

Een praktisch pad in Rivya ziet er zo uit:

1. check de modelpagina op reference support
2. kies de juiste public start page of Studio path
3. log in voor de daadwerkelijke uploadstap als accountcontext vereist is
4. upload alleen de kinds die het model echt ondersteunt
5. houd de prompt afgestemd op de geuploade context
6. review het resultaat en itereer in dezelfde workflow

Lees verder

• Rivya gids voor modelkeuze
• Rivya AI-imageworkflowgids
• Rivya AI-videoworkflowgids
• Rivya AI-audioworkflowgids
• Rivya openbare pagina's versus ingelogde workflows
• Rivya-gids voor probleemoplossing
• AI-afbeeldingsgenerator met referentiebeelden

Checklist voor reference uploads

Controleer dit voordat een taak afhangt van een reference file of upload:

• Bevestig of de taak een image reference, video reference, audio upload of helemaal geen bestand nodig heeft.
• Check de modelpagina op ondersteunde file kinds en limits voordat je assets voorbereidt.
• Bepaal of de taak op een public start page of in signed-in Studio thuishoort.
• Verwijder gevoelige of onnodige file content voor upload.
• Houd de prompt afgestemd op wat elk geupload bestand moet sturen.

Het doel is het bestand nuttig, toegestaan en relevant te maken voordat je credits uitgeeft.

Wanneer je upload fit opnieuw controleert

Controleer upload fit opnieuw wanneer het geselecteerde model verandert, een bestand te groot is, een reference role onduidelijk is, of de asset mensen, logo's, private data of client-owned material bevat.

Review in die gevallen Rivya richtlijnen voor veilige uploads en de relevante reference page voordat je een nieuwe run start.