Guerrilla Games verklaart interne resolutie van 960x1080 pixels in Shadow Fall

Guerrilla Games gebruikt een techniek die 'temporal projection' genoemd wordt om zo een hogere framerate te bereiken in de multiplayer-modus. Dat houdt in dat de helft van de pixelkolommen in beeld wordt gerenderd en de andere helft wordt gereconstrueerd.

Eerder kwamen berichten naar buiten dat de multiplayer-modus van Killzone: Shadow Fall op een resolutie van 960x1080 draait. Daarbij zou een toen nog onbekende techniek gebruikt worden om de resterende helft van de pixelkolommen in te vullen. Het resultaat is een hogere framerate en daarmee een snellere reactie op invoer van de controller. Opvallend was dat Sony beweerde dat de game in native 1080p draait, maar dit bericht leek op iets anders te wijzen, namelijk dat het beeld naar 1080p wordt opgeschaald.

Poria Torkan, producer bij het Nederlandse Guerrilla Games, gaat op de officiële Killzone-blog in op de details. Hij omschrijft temporal projection als een techniek die verschillende frames analyseert: het huidige frame, het vorige frame en het frame daarvoor. Voor iedere pixel in die frames wordt geregistreerd waar die op dat moment was en in welke richting hij zich verplaatst: de pixelvector. Pixelvectors worden zo veel mogelijk gebruikt om de oneven kolommen in te vullen. Bij onbruikbare pixels wordt een voorspelling van de kleur geput uit alternatieve, naburige pixels. "Af en toe gaat die voorspelling mis en kunnen delen van het beeld wazig worden of verschijnen er kleine verticale lijntjes. Meestal gaat het voorspellen echter goed en is het beeld identiek aan een normaal 1080p-beeld." Na het proces worden het voorgaande 1080p-frame en de pixelbewegingsvectoren nog gebruikt om de anti-aliasing te verbeteren. In de singleplayer wordt deze techniek niet toegepast.

Torkan verdedigt de bewering dat Killzone: Shadow Falls multiplayer in 1080p draait. "Onder native 1080p worden beelden verstaan die niet opgeschaald zijn. Volgens die definitie draait Killzone in multiplayer op native 1080p." Dat is echter niet het hele verhaal. "De temporal projection-techniek die we in multiplayer gebruiken, bouwt het 1080p-beeld op uit ondere andere pixels en bewegingsvectors van verschillende lageresolutieframes. Als onder native verstaan wordt dat ieder onderdeel van de rendering-pipeline in 1080p werkt, draait de multiplayer niet in native 1080p." Volgens Torkan is dat niet helemaal eerlijk. "Games gebruiken vaker lagere resoluties voor bepaalde onderdelen van het beeld. Zo kunnen particles of schaduwen op een lagere resolutie dan de rest van het beeld gerenderd worden. Naar deze games wordt ook nog verwezen als 1080p." Guerrilla Games gaat verder in op Killzones renderingtechnieken op de Game Developers Conference, op 20 maart in San Francisco.

Reacties (142)

[v8power67]

Er waren vele meldingen van mensen die de multiplayer wazig vonden, maar werd vaak afgedaan als slechte AA implementatie of FXAA.
Maar nu blijkt dus dat het komt omdat ze dus trucjes uithalen.
Maar hoe dan ook hebben ze dus geadverteerd dat het native 1080p is in mulitplayer maar is dus niet het geval.
Jammer, zeker aangezien sony zelf extra hout op het vuur gooide in de 1080p discussies. En nu dus gecorrigeerd moet worden.
En ze riepen wel degelijk NATIVE 1080p, en niet SCALED op 1080p. IS dus achteraf damage control van sony...
Jammer want ze hadden niet hoeven liegen erover. De singleplayer is wel gewoon 1080p/30.

Heb wel een ps4 maar geen killzone. Zal de gratis multiplayer eens testen van de week.

[Bullet NL]

Wat wel een puntje is, en ik wil beslist geen flame war starten....

Van uit de PS4 community is heel veel schamper lach geweest om de Xbox One en het feit dat deze console bepaalde games niet op 1080p afspeelt. Nu blijkt dat in Killzone ook trucjes worden toegepast en de resolutie helemaal geen 1080p is. Feit is dat beide consoles bij lang en na niet uitontwikkeld zijn. Zowel voor de PS4 als de One worderen nieuwe API's geschreven die de prestaties moeten verbeteren.

Kortom, resolutie zegt niet alles, het spel zelf moet ook goed zijn. De vraag is dus gaat resolutie altijd boven gameplay?

[raro007]

maar er zijn wel andere spellen waar de verschil wel zit bijvoorbeeld thief.
http://tweakers.net/nieuw...-en-900p-op-xbox-one.html
en nog een paar waar ik de naam van niet meer weet.

[Pb Pomper]

Kortom, resolutie zegt niet alles, het spel zelf moet ook goed zijn. De vraag is dus gaat resolutie altijd boven gameplay?

Nee, dat is niet de vraag aangezien het daar nu niet om gaat. Het gaat hier puur over de rendering techniek. Of de gameplay goed of slecht is heeft daar niets mee te maken.

[halofreak1990]

"De vraag is dus gaat resolutie altijd boven gameplay?"
Dat denk ik niet. Echter, waar veel mensen zich aan storen, is dat Sony, zoals gewoonlijk, weer eens niet eerlijk is geweest over hoe het daadwerkelijk zit, en daarbij ook nog eens de ander (Xbox One) heeft lopen kleineren omdat die niet 1080p doet en de PS4 zogenaamd wel. Nu blijkt dat er bij beide consoles games zijn die dat niet halen.

edit:
Waarom worden normale reacties op mijn post -1 gemod?

[Reactie gewijzigd door halofreak1990 op 25 juli 2024 07:55]

[v8power67]

Op de ps4 waren al meerdere games niet 1080p hoor
BF4 is ook 900P op ps4. En het is niet zo dat nu ineens blijkt dat de ps4 geen 1080p aankan, want de singleplayer is native 1080p en gewoonweg prachtig.
Maar het gaat er meer om dat ze het nodig vonden het te verbergen terwijl het absoluut niet nodig was. Is geen schande dat een multplayer iets minder is dan singleplayer, Geloof dat de meeste games dit wel hebben.
En denk ook dat de game niet volledig geoptimaliseerd is(met de 4gb ram in achterhoofd gemaakt ipv 8gb ram).

[koelpasta]

"Nu blijkt dat er bij beide consoles games zijn die dat niet halen. "

Wat is niet halen?
Als guerilla wat effecten had uitgezet dan hadden ze het wel 'gehaald'...
Feit is dat resolutie voor de grote massa niet superbelangrijk is ( ) en dat het feit dat ze opeens meer dingen strakker kunnen tekenen veel belangrijker is voor de algemene indruk van het spel.
Met andere woorden, het is gewoon een afweging van hoe je de bschikbare resources gebruikt. De ps3 kan ook full hd produceren, maar zie daar maar eens een visueel complex spelletje in te maken...

[bigbadbull]

Jammer, zeker aangezien sony zelf extra hout op het vuur gooide in de 1080p discussies. En nu dus gecorrigeerd moet worden.
En ze riepen wel degelijk NATIVE 1080p, en niet SCALED op 1080p. IS dus achteraf damage control van sony...

Zoals ik het begrijp krijgt de PS4 1080p materiaal aangeleverd en hoeft de PS4 niet aan upscaling te doen.
Als Sony PS4 zijnde, zie je dat als Native 1080, het wordt zo door de engine aangeleverd.
de upscaling gebeurt door Guerilla Games voor het aan de PS4, of zelfs aan de TV geleverd wordt.
Dit is fundamenteel verschillend van een game die 720 aanlevert en dan zegt tegen de PS4/TV "maak er nu eens 1080 van."
Betwijfel zelfs of de huidige standaard upscaling technieken deze halve resolutie goed aan kunnen.

Als je verder het artikel leest en de beweringen van Torkan volgt is het duidelijk dat Guerilla Games Sony mis geïnformeerd heeft als je wil dat native betekent "dat elk onderdeel op 1080 gerenderd wordt"

Of het moet zijn dat Sony nog wat extra geld aan Guerilla Games gegeven heeft om de schuld op hun te nemen.

[BruT@LysT]

Ben het ook niet eens met de onderbouwing. Het is een soort interlacing techniek, die weliswaar van interessante foefjes gebruik maakt om de tussenliggende horizontale lijnen op te vullen tot 1080P, maar dan is het in mijn optiek niet native 1080P. Ookal zou de techniek superieur zijn, wat zou betekenen dat er geen reden meer is om deze techniek NIET toe te passen.

Gelukkig wordt er dan ook toegegeven dat er wel eens foutjes ontstaan, heel begrijpelijk ook, net zoals het omhoog krikken van framerates door tussenbeelden te verzinnen zoals TV's dat hedendaags vaak doen. Daar wordt ook veel gebruik gemaakt van motionvectoring. Dat geeft echter ook vaak vreemde effecten en ben er zelf niet zo dol op.
Een ander probleem van deze technieken is dat er vaak informatie van voorafgaande frames gebruikt wordt, uit een buffer dus. Wat ook automatisch betekend dat er iets meer lag is. Voor TV beelden niet zo erg, maar voor games wel een stuk vervelender. Natuurlijk hebben we het hier nog wel over een console titel waarbij input/output lag toch net even iets minder erg is dan wat ik van mijn PC verwacht, en gezien de framerate blijkbaar hoger is, heft dat een deel van de lag weer op.

Desalniettemin, blijf ik er bij dat het verkondigen van native 1080P incorrect is. De melding dat texturen en effecten ook niet altijd 1080P zijn moet ik even om lachen, wacht nou even... als ik Quake1 in 1080P draai is dat gewoon native 1080P, ookal zijn alle texturen niet groter dan 64x64 pixels. Alsof we dan ineens niet meer over native en full-HD mogen praten, het gaat om de output resolutie, niet om hoe hoog de resolutie van texturen en effecten zijn. Hier krijg je dus weer een ander type probleem van, producenten die beweren dat een game 4K is omdat er textures worden gebruikt van 4096x4096 pixels (wat al langere tijd vrij standaard is), al draait de game gewoon op 1080P. Laten we het niet hopen! Marketing is a bitch...

[Reactie gewijzigd door BruT@LysT op 25 juli 2024 07:55]

[Verwijderd]

De melding dat texturen en effecten ook niet altijd 1080P zijn moet ik even om lachen, wacht nou even... als ik Quake1 in 1080P draai is dat gewoon native 1080P, ookal zijn alle texturen niet groter dan 64x64 pixels.

Wat hij bedoelt is dat textures ook geresampled/gestretcht worden, en dat je op die manier ook niet het volledige 1080p-detail hebt.

het gaat om de output resolutie, niet om hoe hoog de resolutie van texturen en effecten zijn.

Dat is nou precies zijn punt: De output-resolutie *is* 1080p. Het verschil met conventionele render-methoden is alleen dat ze hier voor de even en oneven pixelkolommen andere rendermethoden gebuiken.

[koelpasta]

"Wat hij bedoelt is dat textures ook geresampled/gestretcht worden, en dat je op die manier ook niet het volledige 1080p-detail hebt."

Ja, dat is met q1 en 64x64 pixel textures op 1080 ook zo..

"Dat is nou precies zijn punt: De output-resolutie *is* 1080p. Het verschil met conventionele render-methoden is alleen dat ze hier voor de even en oneven pixelkolommen andere rendermethoden gebuiken. "

Nee, zo mag je dat niet zien. Die extra pixels worden geextraheerd uit omliggende informatie en hebben dus niks meer te maken met het renderen van de 3d wereld. Dat is waarom het dus zoveel sneller is. Het is eigenlijk niet renderen in de normale zin des woords maar een vorm van reconstrueren van wat er eigenlijk had moeten zitten door naar andere voorbeelden van soortgelijk beeld te kijken.

[Verwijderd]

Nee, zo mag je dat niet zien.

Knappe cirkelredenering! Het is nou juist de vraag hoe je het wel of niet moet zien.

Die extra pixels worden geextraheerd uit omliggende informatie en hebben dus niks meer te maken met het renderen van de 3d wereld.

Ten eerste is dit incorrect, want de informatie die gebruikt wordt, heeft wel degelijk te maken met de gerenderde 3d-wereld (eerdere frames, motion informatie, buffers met lagere resolutie... staat allemaal in de tekst).
Ten tweede, de vraag is dus wat het criterium precies zou moeten zijn om iets al dan niet 1080p te noemen.

[koelpasta]

"Ten eerste is dit incorrect, want de informatie die gebruikt wordt, heeft wel degelijk te maken met de gerenderde 3d-wereld (eerdere frames, motion informatie, buffers met lagere resolutie... staat allemaal in de tekst)."

Het criterium is volgens mij of de pixel wordt bepaald door de oorspronkelijke geometriedata.
Breder gezien is het criterium dat de game elke pixel van het 1080p beeld door het renderpad loopt en dat niet achteraf wordt gegokt welke kleur het renderpad mischien had opgeleverd voor die pixel.

In het geval van deze techniek komt de informatie van na het renderen.
Zoals ik het lees doet guerilla een 2D beeldanalyse achteraf. Ze volgen waarschijnlijk groepen pixels en doen daar voorspellingen mee.
Daarbij wordt niet de intrinsieke 3D informatie die in de geometrie zat gebruikt.
Als de informatie werkelijk met de 3D wereld (geometrie) te maken had dan hadden ze die artefacten namelijk niet.

[Verwijderd]

Het criterium is volgens mij of de pixel wordt bepaald door de oorspronkelijke geometriedata.
Breder gezien is het criterium dat de game elke pixel van het 1080p beeld door het renderpad loopt en dat niet achteraf wordt gegokt welke kleur het renderpad mischien had opgeleverd voor die pixel.

Ja, het was wel duidelijk dat dat jouw visie was
Ik probeer alleen aan te geven dat deze 'klassieke' visie misschien wel iets te eng is, en dat er misschien wel argumenten zijn om het eens wat breder te bekijken.

Als de informatie werkelijk met de 3D wereld (geometrie) te maken had dan hadden ze die artefacten namelijk niet.

Maar zoals men terecht al opmerkt, zijn er in games sowieso al allerlei artifacts, omdat niet alles ieder frame direct vanuit de geometrie afgeleid wordt.
Denk bv aan shadowmaps, die dus onder allerlei hoeken op de geometrie gemapt worden, en hierdoor ook sampling artifacts vertonen (vooral omdat ze vaak relatief lage resolutie gebruiken om de snelheid erin te houden, en niet teveel videogeheugen te gebruiken).
Of wat te denken van cubemaps voor reflectie/refractie of iets?
Zelfs bij dynamische cubemaps wordt vaak niet ieder frame de cubemap opnieuw berekend, maar wordt ie een aantal frames 'hergebruikt', om processorkracht te sparen. Ook een 'temporal' techniek (kan overigens ook met bv shadowmaps gedaan worden).

De grens die jij trekt, is dus behoorlijk arbitrair, wat dat betreft. Misschien had je daar nog niet zo over nagedacht, voordat Guerilla met deze techniek naar buiten kwam.

[koelpasta]

"De grens die jij trekt, is dus behoorlijk arbitrair, wat dat betreft."

Nee, niet arbitrair.
Er is nog steeds een verschil tussen het beeld 'normaal' renderen en deze truuk. Er zijn namelijk fouten in de vorm van zichtbare atrefacten. Je kunt dat niet wegwuiven.
1 van de hoofdredenen om zoiets als 'native 1080p' na te streven is om artefacten te voorkomen. Meestal gaat het dan om blurryness of aliasing door schaling o.i.d. . Maar deze artefacten zijn ook een duidelijke afbreuk aan het beeld en daarmee is er dus een goede reden om vol gerenderde beelden te willen.
Nu heeft guerilla een andere keuze gemaakt en daar valt ook iets voor te zeggen. Ik ben zelf juist eerder blij met strakke framerates omdat het mij een beter gevoel geeft van een raam naar een wereld.
Maar dat betekent niet dat er geen verschil is tussen een normaal gerenderd beeld en het resultaat van deze truuk.

Bij de andere artefacten die je noemt is het alsnog zo dat de positie van de pixeldata (aliasing daargelaten, is een artefact van het samplen zelf) direct wordt bepaald door de geometrie en rasterizer. Er hoeft niet te worden getraced en gegokt of een pixel bij een andere groep pixels hoort of niet en er wordt dus ook geen inschattingsfout gemaakt bij het bepalen van de kleur.
Dat is een wezenlijk verschil en dat is dus ook waar ik de grens leg.
Dat is niet arbitrair maar heeft dus specifieke consequenties met specifieke classes artefacten.
Anders wordt het teveel youtube die een soort 'gevoelstemperatuur' voor resolutie hanteren...

Verder hebben veel van die artefacten die je noemt vooral met textures te maken.
Cubemaps, shadowmaps, etc worden in world space geprojecteerd en dus kan het zo zijn dat je achterlijk veel resolutie nodig hebt voor die maps om geen artefacten te zien. Wat dat betreft gedragen ze zich niet anders dan normale textures.

Ergens ben ik het met je eens dat textures in sommige gevallen (dus als ze vergroot worden weergegeven) niet meer 'native' resolutie halen. Maar dat is inherent aan texturing.
Van oudsher wordt bij 'native' vooral verwezen naar het feit dat de geometrie uit het frame elke pixel 'raakt'. En dat lijkt bij de killzone methode gewoon niet aan de hand te zijn.

[Verwijderd]

Er zijn namelijk fouten in de vorm van zichtbare atrefacten. Je kunt dat niet wegwuiven.

Dan heb je niet begrepen wat ik zei: Ik bedoel het dus omgekeerd: Er zijn genoeg zichtbare artefacten, die je WEL wegwuift. Dat is het arbitraire eraan.

[Xtuv]

Wat een geouwehoer om niks. Het spel is allang uit, heb nooit iemand gehoord over de resolutie in multiplayer... wat maakt het uit, ga lekker gamen

[XanderDrake]

In dit artikel gaan ze juist in op de -zeer indrukwekkende- methodiek die wordt toegepast om de beste combo van resolutie en framrate te krijgen. Dit is in ieder geval geen upscaling, dus daar hoeven ze zich in ieder geval niet voor de verontschuldigen.

Lang geen ouwehoer, meer reclame. Dit werkt prima dus is interessant voor andere games.

[Reactie gewijzigd door XanderDrake op 25 juli 2024 07:55]

[Daeley]

Het is misschien een mooie methode, maar het blijft wel upscaling. Ze renderen 960x1080 en gebruiken dan voorspellende algoritmen om de rest van de pixels in te vullen gebaseerd op de gerenderde pixels. Hoe goed die algoritmen zijn, het zal nooit zo "echt" zijn als volledig 1080p renderen.

Aan de andere kant, er bestaat natuurlijk altijd iets als "goed genoeg". Als ze hierdoor de framerate aanzienlijk kunnen bumpen tegen een kleine kost aan grafische pracht, is het zeker een mooie ontwikkeling.

[johnbetonschaar]

Je zou het 'opschalen' kunnen noemen, maar het is niet hetzelfde als wat typisch onder opschalen ('upsamplen') wordt verstaan, waarbij je je een lager resolutie beeld gewoon aanvult door te filteren/resamplen. Dat is wat je 'spatial resampling' noemt. Wat ik uit de beschrijving van deze dev lees is dit veel geavanceerder en wordt data uit meerdere tijdpunten (frames) gecombineerd om de ontbrekende delen te voorspellen (temporal upscaling), wat fundamenteel anders is dan alleen maar RGB waardes interpoleren zoals bij spatial upsampling.

Wat ik ook een instructieve en inzichtvolle opmerking van deze dev vindt die dit alles in perspectief zet, is dat dit soort technieken niet anders zijn dan wat je veel vaker in het hele arsenaal aan render trucs tegenkomt in elk geavanceerd spel op elk platform, ook PC: de interne representatie van onderdelen van de rendering pipeline hoeft niet op native resolutie te gebeuren (en dat is dus doorgaans ook niet zo). Dit argument snap ik helemaal maar ik was er in de discussie in het vorige topic over KZ:SF zelf niet opgekomen: moderne engines gebruiken bijvoorbeeld vaak deferred rendering en deferred shading, waarbij het beeld wordt opgebouwd door meerdere passes die naar verschillende render targets renderen (depth buffer, normal buffer, color buffer, etc) en dan een laatste pass die al deze targets combineert en zo belichting en schaduw effecten lokaal kan toepassen, in plaats van 1 uberdikke shader waarin alle belichting is verwerkt te moeten toepassen op elke pixel die gerendered wordt. De gebruikte rendertargets hoeven helemaal niet allemaal op native resolutie gerendered te worden, en doorgaans gebeurt dit ook niet. Hetzelfde geldt voor shadow maps, occlusion maps, lightmaps, etc.

Al met al toch grappig om te zien hoe hier de vorige keer een heel topic vol met reacties in de trant van 'ha ha kijk die PS4 rendert ook niet op 1080p' stond, en als je nu van iemand leest die weet waar hij het over heeft en alles in context plaatst, blijkt dat het allemaal toch net iets genuanceerder ligt. De techniek die Guerilla toepast levert waarschijnlijk op bepaalde aspecten zelfs betere beelden op dan zonder enig gebruik te maken van temporale data direct op native resolutie renderen.

Ik ben zelf nooit echt heel erg onder de indruk geweest van Guerilla games als het om plot en gamplay gaat, maar wat techniek betreft weten deze jongens (en meisjes?) echt wel waar ze het over hebben, Guerilla games zijn voor iemand die geinteresseerd is in de techniek achter de spellen (zoals ikzelf) altijd erg indrukwekkend.

[roy-t]

Wat je over deferred rendering zegt klopt. Hoewel ik moet opmerken dat je hierbij meestal je resolutie meet uit waarop je je colorbuffer rendered. Daar haal je immers de scherpheid vandaan. Voor belichting is het soms zelfs beter als die op een lagere resolutie gerenderd wordt omdat je dan door upsampling al een beetje goedkope blur krijgt zodat de belichting en schaduwen wat zachter worden.

Maar ik ben het niet met je eens dat temporal sampling anders is dan up-sampling. Er is toch geen groot verschil tussen de informatie halen uit naburige ruimte of uit naburige tijd? Het is gewoon een extra dimensie gebruiken om missende data zo goed mogelijk te gokken.

Ook ben ik het niet met je eens dat hierdoor het beeld beter wordt. 50% van je pixels bestaan immers uit gegokt materiaal. In het allerbeste geval zijn alle pixels goed gegokt. Dan is het beeld dus even goed als wanneer je gewoon full-HD rendered. Vaak zullen een paar pixels niet kloppen en soms (bijvoorbeeld bij snelle overgangen) heel veel niet. Waardoor het beeld blurry wordt of waardoor je gekke flitsende strepen krijgt. (Exact zoals Guerrilla zelf ook op biecht.

[johnbetonschaar]

Als je de temporele upsampling volledig beperkt tot het interpoleren van bepaalde beeldlijnen tussen het vorige en het volgende frame, dan zal je beeldkwaliteit daar zeker niet per se beter van worden, in feite ben doe je dan inderdaad iets wat vergelijkbaar is met spatiele interpolatie, met als verschil dat je compenseert voor verschil over tijd, in plaats van verschil over een bepaalde afstand tussen 2 pixels van het oorspronkelijke beeld. Dit zou je als een vorm van upsampling kunnen zien, je samples zijn dan (x, y, t) triplets. Combineer je temporele upsampling met spatiele upsampling dan denk ik dat je daar zeker betere resultaten mee kunt halen dan alleen spatiele upsampling, je hebt immers meer informatie. Ik ben het er echter nog steeds niet mee eens dat je dit upscaling kunt noemen, want het heeft niks met schaling te maken, op die manier zou je het resamplen van een audio signaal of een sensor reading of wat dan ook, ook 'opschalen' kunnen noemen.

Methodes om een signaal te verbeteren of interpoleren kunnen zeer specifiek zijn voor het type signaal en soms extreem complex door gebruik te maken van bijvoorbeeld een model (een acoustisch model, een model van een geidealiseerde sensor, etc), terwijl opschalen 'gewoon' domme interpolatie is, linear of via een curve (cubic). Hierbij maak je geen gebruik van de eigenschappen van het signaal, en typisch ook niet van informatie buiten het signaal zelf. De methode van Guerilla games suggereert dat er wel degelijk gebruik wordt gemaakt van een 'model' om de temporele upsampling te verbeteren, bewegingsvectoren worden in het artikel genoemd (het is niet helemaal duidelijk of deze berekend worden uit de beelden zelf, of extern aangeleverd door de engine), maar ik kan me heel goed voorstellen dat er nog meer informatie gebruikt kan worden, diepte informatie bijvoorbeeld, of informatie over wat er precies onder een bepaalde pixel ligt (een muur zou je bijvoorbeeld anders kunnen behandelen dan een andere speler). Alles bij elkaar kun je dit echt geen upscaling noemen, en slechts onder een hele brede interpretatie 'upsampling' gezien het feit dat er voorspellende component in zit.

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 07:55]

[koelpasta]

"Als je de temporele upsampling volledig beperkt tot het interpoleren van bepaalde beeldlijnen tussen het vorige en het volgende frame, ..."


Ik zou het daarom dus niet zo snel resampling noemen, er gebeurt blijkbaar meer dan wat binnen sampling valt en zoals je al aangeeft zijn er veel potentiele informatiebronnen beschikbaar post render.

Maar ik zou weer geen moeite hebben met het woord rescaling. Het is en blijft een kwestie van het opwaarderen van de resolutie van een beeld. Volgens mij impliceert het woord upscaling geen methode.
TV's doen al een tijdje meer dan alleen upsamplen en er zullen tv's zijn die soortgelijke truuks uithalen als killzone. En dat heet ook allemaal upscaling.

[roy-t]

De techniek is echt extreem simpel en ik snap echt niet waarom je eerst toegeeft dat het wel sampling is zolang er alleen maar info uit het vorige frame wordt gebruikt en dan niet meer zodra er temporale en locale informatie wordt gebruikt.

De 'fancy' verplaatsings vector is verder gewoon een richting ge-encodeerd in het alpha kanaal van elk final frame (waar je geen alpha meer nodig hebt). Deze techniek wordt al langer gebruikt om onder andere blur effecten mogelijk te maken.

Maar waar het om gaat, en waar we het beide over eens zijn volgens mij, is dat het een techniek is die renderen goedkoper maakt en achteraf deze degradatie probeert te verbeteren.

Even als achtergrond, ik ben zelf een (bijna afgestudeerd) master student Game & Media Technology aan de UU en daar komen technieken als deze ook langs , zo super fancy is het niet

[johnbetonschaar]

Lijkt erop dat deze hele discussie enigzins is verzand in semantiek over de woordjes upscaling en upsampling (ook door mijn eigen reacties), eigenlijk is dat helemaal niet zo interessant. Uiteindelijk begon het hele verhaal met 'het is gewoon upscaling' in de context van 'het is precies hetzelfde als intern naar een lagere resolutie buffer renderen en die dan opblazen', op dezelfde manier waarop een Full HD televisie dat bij een SD signaal doet bijvoorbeeld. Hoe je het ook noemt, volgens mij is de techniek die Guerilla gebruikt gewoon veel meer dan dat, omdat er meer en verschillende informatie wordt gebruikt.

De 'fancy' verplaatsings vector is verder gewoon een richting ge-encodeerd in het alpha kanaal van elk final frame (waar je geen alpha meer nodig hebt) Deze techniek wordt al langer gebruikt om onder andere blur effecten mogelijk te maken.

Ik ga kijken of ik na de Game Developer Conference ergens de slides of een video van de presentatie van Guerilla kan vinden, want ik denk toch dat hun techniek verder gaat dan wat jij beschrijft, anders hoef je er geen praatje op zo'n high-profile conferentie over te geven. Mijn vermoeden (speculatie dus) is dat er meer gebeurt dan 'alleen maar' een verplaatsingsvector berekenen uit het gerenderde beeld en die gebruiken om beeldlijnen slim op te vullen. Dat zou namelijk inderdaad niet zo bijzonder zijn, eigenlijk (zoals al door anderen genoemd) een soort slimme verticale de-interlacing.

[roy-t]

Ze moesten de discussie ontmantelen dus misschien klonk het wat interessanter dan het misschien is. Verder is het natuurlijk veel beter dan de-interlacing omdat je veel meer informatie hebt. Als je wat meer info vindt kun je het dan ook hier posten. Ben benieuwd!

[Verwijderd]

Ze renderen 960x1080 en gebruiken dan voorspellende algoritmen om de rest van de pixels in te vullen gebaseerd op de gerenderde pixels. Hoe goed die algoritmen zijn, het zal nooit zo "echt" zijn als volledig 1080p renderen.

Dan kun je je afvragen wat dan wel 1080p is. Een BluRay? Daar wordt ook niet iedere pixel opgeslagen, maar wordt met een compressietechniek op een vergelijkbare manier beweging afgeleid uit eerdere frames etc.
Zelfde geldt voor digitale TV-uitzendingen.
Ik kan me er dus wel in vinden dat ze het 1080p noemen. Het is inderdaad geen upscaling, en alle pixels worden ieder frame wel berekend. Alleen worden niet alle pixels op dezelfde manier berekend.
Je zou het 'compressed' 1080p of iets kunnen noemen, net als dus BluRay en digitale TV.
Upscaling is het in ieder geval niet.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 07:55]

[kiang]

Sorry, maar wat je zegt is onzin, de vergelijking met videocompressie slaat namelijk op niets, helemaal niets. Het is inderdaad zo dat beelden worden opgebouwd uit vorige frames, maar dat betekent niet dat die frames helemaal verzonnen worden: het residuele beeld wordt namelijk nog altijd opgeslagen. Er worden geen hele pixels zomaar weggelaten.

Een goede vergelijking is deinterlacing: daarbij worden volledige scanlines weggelaten om ruimte te sparen, en worden interlace technieken gebruikt om het beeld weer op te bouwen. Dat is EXACT hetzelfde als er hier in de game gebeurt. Het is gewoon interlacing. Ja, ze maken gebruik van motionvectors om de interlacing beter te maken, maar het is en blijft interlacing: het genereren van de helft van de scanlines adhv een bepaald itnerlacing algoritme.

Laten we alsjeblieft dus een kat een kat noemen. De multiplayer hier is dus geen full HD, net zoals 1080i ook geen full HD is.

[Reactie gewijzigd door kiang op 25 juli 2024 07:55]

[Verwijderd]

Als je 1080i erbij gaat halen, heb je het over iets anders...
De interlacing is een manier om beelden te versturen (even en oneven fields apart). Je hebt wel degelijk nog steeds een 1080p-scherm nodig om een 1080i-stream goed (deinterlaced) te tonen. Daarom is het ook wel degelijk nog steeds full HD (zie ook http://en.wikipedia.org/wiki/1080i)
Dat deinterlacen wordt vaak door een stukje hardware gedaan... In dit geval is het een beetje een grijs gebied... De 'deinterlacing' wordt door de game engine zelf gedaan, als deel van het renderingproces, en er wordt een 1080p-stream uitgestuurd.

[Veneus]

De techniek is weldegelijk vergelijkbaar met (blu-ray en MPEG) videocompressie. Waar gebruik gemaakt wordt van Intra-frames én sub-sampling óók op 1080p. Interlacing is juist minder vergelijkbaar, daar wordt de volledige resolutie ververst, al zit er dan wel wat tijd tussen de fields.
1080i valt ook gewoon onder full HD en 'native' en de 'i' heeft weinig met resolutie te maken

[sygys]

Houdt iedereen er wel rekening mee dat een film of een game spelen 2 volledig verschillende dingen zijn? de beelden en bewegingen van een film staan vast... als een bepaald vlak voor 10 seconden zwart is op een video, dan hoeft dit hele gedeelde 10 x 30 fps niet van pixel te veranderen en is de opslag dus minimaal. dit kan nauwkeurig bekeken worden en gecomprimeerd.

Als ik een spel speel en draai mijn beeld naar rechts dan worden er dus als ik het goed begrijp, pixels vooruit gerendered en hiermee een schatting gemaakt van het daadwerkelijke beeld. als ik dus plots naar links draai dan zullen de deel van deze pixels foutief worden weergegeven. voor 1 of 2 frames. Nu zul je dit amper merken verwacht ik. maar met niet alleen bewegingen van jou maar ook van je mede spelers en de omgeving kan ik me voorstellen dat deze techniek best wel zichtbaar kan zijn voor de echte gamers met een goed oog.

Ik snap sowieso niet waarom een console direct bij release al games niet op vol vermogen kan draaien... in mijn ogen had de console beter 600 euro kunnen kosten met echt verbluffende hardware waar iedereen weer jaren mee vooruit had gekund. nu zul je zien dat er veel sneller weer een nieuwe console gaat komen.

Ik persoonlijk ben eerlijk gezegd diep teleurgesteld over de "next gen" consoles... in mijn ogen kun je dit absoluut niet next gen noemen. het is in mijn ogen niks beter dan wat de PC al kan. welliswaar voor veel minder geld. maar de PC overstijgt nu alweer de consoles. dat was in de tijd van de PS3 wel anders.

[Verwijderd]

...kan ik me voorstellen dat deze techniek best wel zichtbaar kan zijn voor de echte gamers met een goed oog.

Daarom toch ook de hele analogie met BluRay/digitale TV?
Ook daar kun je als je goed kijkt best wel compressie-artifacts zien. Het is niet voor niets lossy compression.

Ik snap sowieso niet waarom een console direct bij release al games niet op vol vermogen kan draaien...

Mee eens... Die APUs van AMD zouden zo geweldig moeten zijn... Maarja, als je ze niet krachtig genoeg kunt maken voor goede 1080p-gaming... Had een losse GPU dan niet gewoon beter geweest? Het heeft nu een hoog net-niet-gehalte.

[Invoke]

"Ik snap sowieso niet waarom een console direct bij release al games niet op vol vermogen kan draaien"

Leercurve, experimenteren, prototypes.. etc. Als jij een nieuwe auto/tv/etc. koopt duurt het ook een tijd voor je er aan went en er het maximale uit kan halen. En hoe complexer dat product is of hoeveel dat product afwijkt van je vorige producten en ervaringen des te langer dat dat proces gemiddeld duurt.

[Reactie gewijzigd door Invoke op 25 juli 2024 07:55]

[sygys]

ik snap best dat het een tijdje duurt. maar bij de PS3 toentertijd was het echt van wow de games die uitkomen gebruiken nog niet een fractie van wat de console kan. Nu is het gelijk bij release al dat games terug geschaald worden omdat de console het niet aan kan.

Er zal nog veel winst geboekt gaan worden. Echter of het echt significant beter zal worden... ik betwijfel het... guerrilla games is nu niet bepaald een B studio die zomaar wat heeft gedaan met killzone. Die zullen echt wel hebben getracht het onderste uit de kast te halen van de PS4 vandaar ook deze techniek.

[SuperDre]

De vergelijking met videocompressie gaat juist perfect op, want het is exact hetzelfde, en bij video worden wel degelijk hele pixels weggelaten..
Interlacing is juist helemaal niet te vergelijken hiermee, tenzij het dus zou zijn dat frame 1 eerst alle even verticale lijnen zou doen en frame 2 alle oneven verticale lijnen..

[kiang]

"bij video worden wel degelijk hele pixels weggelaten."

Duidelijk dat je niets van videocodering kent.

Er worden GEEN pixels weggelaten. Wel hogere frequenties, afhankelijk van hoe sterk je wilt comprimeren, maar dat is iets HEEL anders.

In deze game worden er 960 verticale lijnen in de breedte gerenderd dmv rasterization, oftewel het 'gewoon' renderen. De andere 960 lijnen worden dmv een bepaalde techniek gerenderd, die NIETS te maken heeft met het achterliggende 3D model: zoals gezegd worden er motionvectoren gebruikt en kleuren van naburige pixels. EXACT hoe geavanceerde deinterlacing werkt.

Maar goed. Blijkbaar zijn feiten niet belangrijk, als we kijken naar de mods.

[Reactie gewijzigd door kiang op 25 juli 2024 07:55]

[SoloH]

Scalibq zegt terecht dat het lijkt op een moderne mpeg compressie. Hier worden exact dezelfde technieken gebruikt, zoals pixelvectoring en neighbouring pixels.

Dat het ook gebruikt wordt in geavanceerde deinterlacing, neemt niet weg Scalibq gewoon gelijk had.

[dramborleg]

"Maar goed. Blijkbaar zijn feiten niet belangrijk, als we kijken naar de mods."

Voor zover ik kan zien zijn er geen onderbouwde feiten voorbij gekomen. Ik vind de discussie erg interessant, echter is de gehele discussie niet onderbouwt en daarom blijft het hangen op het niveau: "dit is mijn mening, dat is jou mening" (veredeld wellus-niettus)

Dus, iemand die hier bronnen voor heeft? (wiki, achtergrond, testen, etc...)

[kiang]

"Bij interlacing wordt het beeld om en om tussen de kolommen ververst "

Dat is neit juist: bij itnerlacing worden om en om bepaalde lijnen doorgestuurd, maar de tussenliggende lijnen die neit worden doorgestuurd worden WEL elke keer ververst.

Om die tussenliggende, missende lijnen te evrversen worden ze 'gerenderd' dmv de-itnerlacing technieken. Die gaan die lijnen invullen adhvh omliggende pixels (pixels in de naburige, wel doorgestuude lijnen, en de lijn in het vorige frame)

Meer geavanceerde deinterlacing technieken gaan motion vectoren inschatten en verbeteren hiermee het 'renderen' van de ontbrekende lijnen.

Dit is exact hetzelfde als in deze multiplayer gebeurt.

Dus wederom: het gaat hier gewoon om geavanceerde deinterlacing, uitgevoerd door het spel zelf ipv door je TV, en dan ook nog eens op verticale ipv horizontale lijnen.

[Veneus]

Volgens mij weet je zelf niet zo veel van videocompressie en videotechniek in het algemeen.

Het is gewoon een feit dat bij video compressie WEL pixels worden weggelaten, daarom is het ook 'lossy'.

http://nl.wikipedia.org/wiki/MPEG-2#Situering

Verder heb je nog binnen het frame, afhankelijk van je apparatuur en codecs: http://en.wikipedia.org/wiki/Chroma_subsampling

Waarbij er voor bijvoorbeeld elke 4 intensiteitswaardes, maar 1 kleurenwaarde gebruikt wordt.

Vervolgens heb je bij videocompressie ook nog de hier in de game engine als nieuw bestempelde motion-vector:
http://en.wikipedia.org/wiki/Motion_vector

Dat allemaal in tegenstelling tot interlacing, waarbij in principe geen kwaliteit verloren gaat..
Zoals ik in een andere reactie ook al aangaf, bij interlacing blijft het aantal HELE beelden per seconden gelijk aan de progressive variant.
Voor PAL is dit dus:
Progressive: 25 FRAMES per seconde (hele beelden)
Interlaced: 50 FIELDS per seconde (halve beelden, om-en-om, met een informatie uit een verschillend moment in tijd)

http://nl.wikipedia.org/wiki/Interlaced_scanning

p.s.: overigens is de techniek de je ZELF beschrijft niet interlacing, maar interpolatie. en dus scaling.
Vroeger in de demo-scene ook wel pixel-doubling genoemd.
http://en.wikipedia.org/wiki/Image_scaling
Tegenwoordig zijn er daarnaast 'slimmere' filtering technieken maar het idee is hetzelde: invullen van ontbrekende data.

[Reactie gewijzigd door Veneus op 25 juli 2024 07:55]

[kiang]

Sorry, maar je blijft beweren dat er pixels worden weggelaten bij videocodering end at is gewoon helemaal onjuist: lossy compressie betekent niet dat je gewoon pixels weg laat. Jij bent absoluut degene die geen barst kent van videotechniek.

Korte samenvatting: eerst wordt het frame door meerdere technieken (intra en itner predictie) een zo neutraal mogelijk (poixelwaarden zo dicht mogelijk bij nul) differentiaalbeeld opgesteld. daarna worden de differentiaalwaarden per kanaal per macroblok omgezet van het pixeldomein naar het frequentiedomein, doormiddel van een techniek gebaseerd op de fourrier transformatie, meestal een DCT variant. Dan worden hogere frequenties wegelaten: DIT is de enige stap waar informatie verloren gaat: geen pixels dus, FREQUENTIES. De overgebleven waarden van het frequentiedomein worden dan losless gecomprimeerd.

Interlacing is overigens wat ingewikkelder dan jij het voorstelt: jij doet alsof het een simpel iets is waarbij je de helft nu en de helft in het volgende frame krijgt, maar de realiteit is wel heel wat anders: je hebt een hogere refreshrate, maar je krijgt bij elke refresh wel maar de helft van de scanlines. Wat doe je met de ontbrekende helft? Laat je die gewoon staan uit het vorige frame? Dan krijg je HEEL duidelijk artefacten. Dus als je die wilt vermijden gebruik je betere deinterlacing technieken. Enkele worden hier getoond: http://en.wikipedia.org/w...ing#Deinterlacing_methods Merk op wat ze hier vermelden: motion detection. Dat is EXACT wat er beschreven wordt in deze game.

En juist dat punt maak ik: dit is deinterlacing met wat dure woorden eromheen.

[Veneus]

Ok, dit is de laatste keer dat ik reageer op dit artikel, we komen er uiteindelijk toch niet uit.

Ik heb niet gezegd dat video-compressie 'gewoon' pixels weglaten is, maar netto gezien is dit bij lossy compressie wel het geval. Afhankelijk van welke compressie methode je gebruikt uiteraard.
Voor de rest heb ik je nog niet gehoord over chroma sub-sampling waarbij er ook weldegelijk data wordt weggelaten.

Verder wil ik ook stellen dat interlacing an sich wel degelijk zo simpel is als ik het stel. Waar de moeilijkheid in zit, die jij noemt, is deinterlacing.
Maar dat is pas moeilijk alleen als je er vanuit gaat dat het NODIG is.

Even ervan uitgaande dat de bron interlaced is, en de monitor ook, is interlaced DEZELFDE resolutie (bijvoorbeeld 1920x1080 pixels) als progressive, zonder verlies maar MET een voor het oog vloeiender beweging omdat je op 2x meer momenten in de tijd 'sampled'.

Als kijker zie je nog steeds 25 HELE beelden per seconden, opgebouwd uit 50 FIELDS per seconden (PAL).

[kiang]

Je negeert compleet alle problemen die itnerlacing oplevert, ik heb je verodire zelfs een link gegeven, maar die negeer je.

Mijn punt is van in mijn eerste post geweest dat wat ze doen NEIT evenwaardig is aan 1080p, en dat hun toegepaste technieken gewoon deinterlacing zijn.

Jij draait rond de pot door videocompressie aan te halen, iets dat compleet van de pot gerukt is hier. De links die je gaf gaven GEEN ENKELE relevante inormatie. De link die ikj gaf vermeld expliciet de tehcnieken die hier genoemd wordne in de game, en vertsterken dus mijn punt dat wat gedaan wordt hetzelfde is als 1080i vs 1080p, iets dat WEL DEGELIJK een lagere kwaliteit oplevert. En dat zou je weten als je ook maar iets wist van videocoding.

Chroma Subsampling heeft wederom niets te maken met dit alles. Het strikt genomen trouwens geen techniek die gebruikt wordt bij compressie: subsampling gebeurt voor de compressie, veelal is je bron (een YUV stream) al gesubsampled. Ook zijn het geen hele pixels, enkel de chroma subpixels.

Maar goed. Je ging toch niet meer reageren, dus je wilt blijkbaar gewoon niet bijleren.

[Veneus]

Ok, toch nog een keer dan.

Dit komt van je eigen link:
Line doubling is sometimes confused with deinterlacing in general, or with interpolation (image scaling) which uses spatial filtering to generate extra lines and hence reduce the visibility of pixelation on any type of display.[4] The terminology 'line doubler' is used more frequently in high end consumer electronics, while 'deinterlacing' is used more frequently in the computer and digital video arena.

Om het allemaal even samen te vatten:
Het originele artikel heeft het over resolutie... renderen op de helft, en tonen op volledig (met slimme techniekjes verbeterd).

Interlacing/deinterlacing an-sich doet NIKS aan de resolutie. en ook niet aan de kwaliteit van de individuele pixels.

Compressie en de upscaling methode van het artikel wel (eigenlijk door de slimme methodes een soort van reverse compressie, of de DEC van CODEC).

(Of je dat verschil als eindgebruiker ook ziet is hier niet aan de orde)

[Verwijderd]

Dat is neit juist: bij itnerlacing worden om en om bepaalde lijnen doorgestuurd, maar de tussenliggende lijnen die neit worden doorgestuurd worden WEL elke keer ververst.

Dat hoeft niet per se.
Als je bv uitgaat van een klassieke CRT, dan worden letterlijk alleen de beeldlijnen uit het signaal ververst. De tussenliggende beeldlijnen worden overgeslagen.

Ook bij digitale deinterlacing hoeven de tussenliggende beeldlijnen niet per se ververst te worden. Een simpele 'weave' bv laat gewoon de oude beeldlijnen staan in de framebuffer, en update alleen de beeldlijnen van het inkomende field, vergelijkbaar met een klassieke CRT.

[kiang]

..En dat creëert een heleboel artefacten zoals deze: http://projects.cwi.nl/dy...ed_interlaced_cropped.jpg

Elke degelijke speler of TV voert al lang degelijke deinterlacing uit, minimaal blending.

[Reactie gewijzigd door kiang op 25 juli 2024 07:55]

[Verwijderd]

..En dat creëert een heleboel artefacten zoals deze: http://projects.cwi.nl/dy...ed_interlaced_cropped.jpg

Ja, dat lijkt me logisch.

Elke degelijke speler of TV voert al lang degelijke deinterlacing uit, minimaal blending.

Dat maakt het niet minder waar dat het niet per definitie zo is dat alle lijnen bij ieder field ververst worden.
Beetje overbodige reactie van je.

[Flight77]

Ik ben het wel met je eens dat het een (nieuwe?) vorm van upscaling is. En wel eentje die tijd (verschillende achtereenvolgende frames) gebruikt. (Geen idee of andere upscaling dat ook doet).

Ik ben het echter met @Xtuv eens, dat het allemaal een discussie in de marge is. Als we het nou over filmbeelden hadden die niet op 1080 opgenomen waren oid, dan was het iets anders, maar het gaat om volledig virtuele werelden, die met allerlei technieken op een scherm getoverd worden.
Bij wijze van, ik kan met een crappy engine prima native realtime 4k op 120 Hz output hebben, maar als dat er niet uit ziet, heeft het ook geen functie. Maar dan mag ik wel roepen dat ik native 4k doe...
En als ik met een 160x90 output via een super geavanceerd upscaling algoritme fotorealistische 1080p beelden zou kunnen realiseren. Is dat dan nog steeds minderwaardig omdat het niet native 1080 is?

[boe2]

Het beeld wordt gerendered aan halve resolutie waarna de ontbrekende pixels geraden worden door een geavanceerd algoritme. Dat is toch een vrij accuraat voorbeeld van upscaling in mijn boek.
Qua totaal aantal pixels is dit niet eens zoveel meer dan 720p. Dan maandenlang claimen dat je native 1080p draait durf ik toch bedrog noemen

[Reactie gewijzigd door boe2 op 25 juli 2024 07:55]

[johnbetonschaar]

Dat is toch een vrij accuraat voorbeeld van upscaling in mijn boek.

Niet dus. Upscalen gebruikt alleen informatie uit het beeld zelf, en past vervolgens een interpolatie (bilinear, bicubisch) toe, niet door iets te 'raden' of 'reconstrueren', maar door een wiskundige functie 'door de beschikbare pixels te trekken' (om het maar even versimpeld te stellen) en die te evalueren op de ontbrekende pixels. Upscaling kan dus nooit data terug reconstueren die niet in de input zit.

Stel dat je bijvoorbeeld horizontaal bewegende om-en-om zwart/witte verticale lijntjes van 1 pixel breed rendert op halve resolutie, dan verlies je of de zwarte, of de witte lijntjes, en een upsampling kan die daar nooit meer uit terughalen. Met temporele interpolatie kan dat dus wel, omdat je de witte lijntjes in het vorige frame hebt, en de zwarte in het volgende frame, en je dus kunt reconstrueren waar ze in het huidige frame zouden moeten zijn, gesteld dat je weet hoe snel ze bewegen.

Fundamenteel anders dan simpelweg opschalen dus.

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 07:55]

[roy-t]

"Upscalen gebruikt alleen informatie uit het beeld zelf"

Beeld is nu 3D ipv 2D, met X-positie, Y-positie en T-positie (tijd)

"en past vervolgens een interpolatie (bilinear, bicubisch) toe, niet door iets te 'raden' of 'reconstrueren', maar door een wiskundige functie 'door de beschikbare pixels te trekken' (om het maar even versimpeld te stellen) en die te evalueren op de ontbrekende pixels"

Guerilla gebruikt een formule (namelijk een stukje code) die uit de beschikbare pixels de ontbrekende pixels trekt. Past dus perfect in jouw voorbeeld

[boe2]

Nee, simpele vormen van upscaling gebruiken enkel informatie uit 1 beeld zelf. Wat denk je dat de betere televisies en dvd spelers doen? Juist ja, upscaling via de techniek die jij beschrijft. Dat Guerilla het doet maakt het niet plots zoveel magischer. Integendeel: Het toont aan in hoeveel bochten ze zich moesten wringen om toch maar die 1080p resolutie te kunnen claimen.

[Reactie gewijzigd door boe2 op 25 juli 2024 07:55]

[johnbetonschaar]

Nee, simpele vormen van upscaling gebruiken enkel informatie uit 1 beeld zelf. Wat denk je dat de betere televisies en dvd spelers doen? Juist ja, upscaling via de techniek die jij beschrijft

Ik neem aan dat je het dan over dingen als 'intelligent frame creation' enzo hebt, dat is inderdaad enigzins vergelijkbaar met de techniek die Guerilla toepast, maar dat is dus ook geen upscaling, dat soort technieken worden namelijk gebruikt om beweging vloeiender weer te geven als je een signaal hebt dat op lagere framerate loop dan je display. Dus een 25 Hz beeld op 50 of 100 Hz weergeven door frames te interpoleren, bijvoorbeeld. Heeft niks met upscaling te maken. Ander voorbeeld dat hierboven ook al genoemd werd door Scalibq zijn video codecs, die gebruiken ook bi-directionele predictie van frames om zo veel mogelijk beeld informatie te reconstrueren zodat die niet geencodeerd hoeft te worden, maar wederom heeft dat niks met upscalen te maken, en er is ook niemand die daarom zegt dat een Blu-Ray film 'geen 1080p' is omdat de ge-encode versie niet de volledige film op native resolutie bevat.

Misschien kun je een concreet voorbeeld geven van andere temporele interpolatie technieken die voor upscaling gebruikt worden, want ik weet anders niet waar je het over hebt.

Dat Guerilla het doet maakt het niet plots zoveel magischer.

Wat ik er van begrijp is dat Guerilla meer informatie gebruikt dan 'alleen maar' de beelddata van het vorige en volgende frame, maar ook informatie uit de engine zelf, ze hebben de hele spelwereld in het geheugen zitten dus ze kunnen allerlei slimmigheid gebruiken om de predictie waar iets op het scherm verschijnt tussen verschillende beeldlijnen van verschillende frames in te verbeteren. Dat is wederom dus wel degelijk meer dan frames interpoleren. Het feit dat het blijkbaar dusdanig geavanceerd is dat ze er een praatje over gaan houden op de Games Developer Conference doet mij vermoeden dat ze bij Guerilla net iets meer verstand van dit soort dingen hebben, dan jij nodig hebt om er zinnige uitspraken over doen.

Integendeel: Het toont aan in hoeveel bochten ze zich moesten wringen om toch maar die 1080p resolutie te kunnen claimen.

Volgens mij loopt de single player wel gewoon op 1080p, dus de verklaring die Sony en Guerilla zelf hebben gegeven dat deze techniek andere voordelen heeft dan alleen maar hogere framerate is best plausibel, de predictie kan namelijk ook gebruikt worden om snel bewegende pixels (poppetjes die ver weg lopen) die anders te onduidelijk zouden worden door motion blurring op een speciale manier te behandelen en renderen. Dit is slechts speculeren want ik ken de details niet, maar laten we het er op houden dat er dus echt wel iets meer achter zit dan 'in bochten wringen om de performance op 1080p te krijgen', anders hadden ze voor de MP ook gewoon de grafische settings wat terug kunnen schroeven (wat PC FPS spelers trouwens ook vaak doen, wat zegt dat volgens jou dan over de hardware? Helemaal niks volgens mij)

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 07:55]

[koelpasta]

"Dat is wederom dus wel degelijk meer dan frames interpoleren. "

Maar niemand zegt dat alle andere vormen van upscaling van het type 'frame interpoleren' moeten zijn. Dat bedenk je helemaal zelf.
Volgens mij gebruiken tv's al een tijdje dit soort algoritmes om interalced 50/60 op te schalen naar progressive 50/60, dus het wordt wel degelijk gebruikt. Technisch zou je het converteren kunnen noemen maar omdat er extra beeld bij wordt gemaakt (hoe dat ook wordt gedaan) blijft het ook een vorm van schalen.

Ik denk ook dat het aannemelijker is dat er iemand van sony's tv afdeling eens kwam praten met het dev team die de exclusive schreef die de ps4 launch moest dragen.,,, veel aannemelijker nu ik er over nadenk.

[Verwijderd]

Guerilla heeft zelf al aangegeven dat de multiplayer grafisch minder belastend is omdat juist in multiplayer een goede framerate belangrijk is (veel actie).

Daaruit blijkt dus al dat er wel wat moeite is gedaan om het te halen in 1080p 60fps. Het is dus helemaal niet zo vreemd wat boe2 zegt, ze wilde blijkbaar perse die 1080p 'halen' en dus gaan ze dit soort technieken gebruiken.

Niet dat daar iets mis mee is volgens mij, juist een creatieve oplossing om toch je 'doel' te halen. Maar of je het dan 1080p noemt daar kunnen we over discussiëren natuurlijk

[koelpasta]

"Ander voorbeeld dat hierboven ook al genoemd werd door Scalibq zijn video codecs, die gebruiken ook bi-directionele predictie van frames om zo veel mogelijk beeld informatie te reconstrueren zodat die niet geencodeerd hoeft te worden, "

Fout.
Er wordt bij het coderen een fout-signaal gegenereerd en meegecodeert. De coder genereert dit door hetzelfde prediction algoritme te gebruiken als de decoder en dan het verschil te nemen met het eigenlijke frame. Dit is de fout en dit kan de decoder gebruiken om in combinatie met het vorige frame het huidige frame te reconstrueren.

Dit mechanisme werkt volledig lossless en staat dus los van andere compressiemechanismes in b.v. een mpeg codec.
Het heeft ook helemaal niets te maken met upscalen oid. Alle informatie in de beelden blijft behouden en dus is er geen sprake van schalen.
In het geval van killzone mist gewoon de halve x resolutie en dat moet dus geschaald worden. Omdat het naar een hogere x resolutie moet noemt men het upscalen.

[johnbetonschaar]

Dit mechanisme werkt volledig lossless en staat dus los van andere compressiemechanismes in b.v. een mpeg codec.

Ik weet hoe het werkt, ik heb zelf een MPEG decoder geschreven. De techniek werkt inderdaad zoals jij beschrijft, maar het is niet waar dat de predicted frames lossless zijn. De encoder berekent een set motion vectoren door het beeld te analyseren, en slaat dan voor elk predicted (inter-) frame het verschil met het originele macroblock uit het laatste (en/of volgende) intra-frame op. Hierbij gaat wel degelijk informatie verloren want de motion vectors worden gequantiseerd (hebben maar een beperkte 'resolutie' zogezegd) waardoor je subpixel effecten introduceert die niet in het originele signaal zitten, verder wordt de kleurinformatie in het verschilbeeld wordt meestal op halve resolutie opgeslagen. Als je stap-voor-stap door de predicted frames van een video stream stapt dan zie je de beeldkwaliteit gewoon afnemen tot het volgende intra-frame. Bij MPEG-1 heel duidelijk omdat de motion vectors daar volgens mij maar tot halve resolutie opgeslagen zijn en de chroma (kleur) informatie op een kwart, bij h264 zijn de motion vectors volgens mij tot 2x subpel (dubbele resolutie) dus daar is dat effect veel minder (maar is het veel duurder om te encoderen en door de complexere filtering die moet worden toegepast om het gereconstrueerde beeld op te bouwen uit het vorige beeld en het verschilbeeld).

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 07:55]

[koelpasta]

" Hierbij gaat wel degelijk informatie verloren want de motion vectors worden gequantiseerd (hebben maar een beperkte 'resolutie' zogezegd) waardoor je subpixel effecten introduceert die niet in het originele signaal zitten, "

Ja, ok, er wordt OOK nog compressie overheen gelaten.
Die codecs zijn sowiso echt verzamelbakken van compressietechnieken. Elk bitje wordt omgedraait..

Goeie leesvoer schrijf je, overigens.!

"Als je stap-voor-stap door de predicted frames van een video stream stapt dan zie je de beeldkwaliteit gewoon afnemen tot het volgende intra-frame."

Ik dacht dat dat te maken had met de kwantisering van het i frame zelf en de daardoor ontstane extra fout waarop voortgeborduurt wordt in de predictive frames. Dus dat het predictive verschil wordt genomen van het originele macroblock maar dat het macroblock daarna nog fft en kwantisering ondergaat waardoor de veerschilbeelden minder betrekking hebben op de geencodeerde iframe .
Magoed, ik heb geen decoder geschreven dus verbeter me als je zin hebt.

[koelpasta]

"Niet dus. Upscalen gebruikt alleen informatie uit het beeld zelf, en past vervolgens een interpolatie (bilinear, bicubisch) toe, niet door iets te 'raden' of 'reconstrueren', maar door een wiskundige functie 'door de beschikbare pixels te trekken' (om het maar even versimpeld te stellen) en die te evalueren op de ontbrekende pixels."

Volgens mij beschijf je hier upsamplen. De filters (biliniair, bicubisch, etc) zijn dan eigenlijk de anti alias filters voor het resampleproces.
Upsamplen is dan gewoon een specifieke vorm van upscalen.

Elke vorm van interpolatie is overigens een vorm van raden en reconstrueren. Daar is het ook voor bedoeld, althans, het zijn allemaal gewoon methodes om de plekken van missende data zo goed mogelijk op te vullen.

Het woord upscaling wordt volgens mij overal breed gebruikt en duid niet op een specifieke methode maar generiek op het vergroten van de resolutie
Het ligt alleen, om allerlei redenen, voor de hand om daar resampling voor te gebruiken. Maar als er andere informatie voorhanden is, zoals bij gegenereerd beeld, dan zie ik niet waarom dat niet onder de term upscaling zou vallen.
Uiteindelijk, hoe je het wendt of keert, zijn ze namelijk 'gewoon' missende pixels aan het inschatten...

[Verwijderd]

Het beeld wordt gerendered aan halve resolutie waarna de ontbrekende pixels geraden worden door een geavanceerd algoritme. Dat is toch een vrij accuraat voorbeeld van upscaling in mijn boek.

Nee. Upscaling is dat je een bitmap neemt van een bepaalde grootte, en die uitrekt naar een groter formaat.
Dit heeft meer te maken met een soort deinterlacing-techniek, met extra motion compensation of iets.

[koelpasta]

"Nee. Upscaling is dat je een bitmap neemt van een bepaalde grootte, en die uitrekt naar een groter formaat."

Nee dat heet upsampling, een speciaal geval van resampling.
Bitmap impliceert dat het beeld een gesampled signaal is.
Upscaling is een bredere term voor het verkrijgen van extra beeldpunten en impliceert geen signaal (in de zin van sampling theorem) waaruit gesampled wordt.
Vandaar dat upscaling nog best op zn plaats is al wordt er temporale informatie gebruikt.
Uiteindelijk is het doel van dit hele gedoe om de resolutie in 1 richting te verdubbelen en dat is gewoon een vorm van schahalen.
Ze gebruiken alleen een intensievere (en op zich best wel coole) methode en behalen daardoor beter resultaat dan simpel resamplen.

[koelpasta]

"Er staat wel degelijk expliciet een signaal dat upscaled wordt, middels interpolatie."

Als je een signaal upscaled via interpolatie dan doe je dat meestal via resampling. In het geval van meer pixels erbij filteren heet dat upsampling.

In het geval van killzone wordt er buiten sampling theorem gewerkt en dan geldt de algemene term upscaling..

[Verwijderd]

In het geval van killzone wordt er buiten sampling theorem gewerkt en dan geldt de algemene term upscaling..

Dat ligt eraan hoe je het bekijkt.
Zoals ik het interpreteer, renderen ze wel degelijk naar een 1920x1080 framebuffer, maar wordt de helft van de kolommen 'overgeslagen' bij het klassieke renderen van de geometrie, en wordt die door een soort 'post processing'-fase ingevuld.
In dat geval is er niet daadwerkelijk sprake van het opschalen van een bitmap (de grootte/schaal verandert immers niet). Net zomin als dat het geval is bij deinterlacing in het algemeen. Voor een 1080i-beeld heb je ook een 1080p-buffer nodig, zoals al eerder gezegd.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 07:55]

[koelpasta]

"Zoals ik het interpreteer, renderen ze wel degelijk naar een 1920x1080 framebuffer, maar wordt de helft van de kolommen 'overgeslagen' bij het klassieke renderen van de geometrie,"

Maar als ik GPU's goed begrijp kan je niet de helft van de lijnen in een framebuffer overslaan. De framebuffer bepaalt voor welke pixels er geshade gaat wordt. En die afmetingen bepalen hoe de rasterizer zich gedraagt, dacht ik. Dus de grootte van je framebuffer heeft geloof ik erg veel effect op hoe de rest van je pipeline zich gedraagt.
Ik weet niet of het te voorkomen is dat de gpu fragments gaat lopen uitrekenen voor alle pixels in het framebuffer. En ook alle geometrie die op de weggelaten pixels valt wordt dan verwerkt.
Dat lijkt mij niet zoveel winst opleveren.

De enige optie die ik zie is renderen naar een 960x1080 framebuffer en dan opnieuw door een shaderstage halen om de niet-gerenderde informatie bij te genereren op basis van 2D algoritmes.
En dan is het natuurlijk logisch dat die laatste renderbuffer fullHD is. Maar dat is bijvoorbeeld ook zo als je een dvd in een blu-ray speler afspeelt. De framebuffer is welliswaar full hd, maar de informatie van de dvd is dan uitgesmeerd. Je zult dan waarschijnlijk niet zeggen dat de dvd dan in native 1080p speelt, niet?

[Verwijderd]

Ik weet niet of het te voorkomen is dat de gpu fragments gaat lopen uitrekenen voor alle pixels in het framebuffer.

Zbuffer? Stencil? Alpha? Er zijn genoeg methoden... Deferred rendering is daar helemaal op gebaseerd: Reken pas de pixel uit als bepaald is dat ie zichtbaar is.

De enige optie die ik zie is renderen naar een 960x1080 framebuffer en dan opnieuw door een shaderstage halen om de niet-gerenderde informatie bij te genereren op basis van 2D algoritmes.

Dat ligt er een beetje aan hoe het werkt. Als je bovenstaande idee neemt waarbij je bv de oneven pixels markeert als 'niet uitrekenen', kun je dat ook opvatten als: "reken wel A en B uit, en sla dat op in een of ander deferred target, maar reken niet C en D uit". Dus dan heb je wel *iets* van de geometrie gebruikt.

[koelpasta]

"Dat ligt er een beetje aan hoe het werkt. Als je bovenstaande idee neemt waarbij je bv de oneven pixels markeert als 'niet uitrekenen', "

Ja, maar volgens mij doorloop je dan alsnog de geometiestage en raterisation voordat je mag bepalen of er iets 'niet uitgerekend' hoeft te worden. Je wint dus nikt op die stages als je naar een grotere buffer rendert en je moet dan alsnog fragment shaders maken die de lijnen scheiden. Het is dus aanemelijk dat ze naar een 960 buffer renderen. Dan heb je alle voordelen van sneller rasterizen. Vervolgens gebruik je die data om naar een 1920 buffer te renderen.
Als je masking gebruikt via stencils dan worden er volgens mij alsnog fragments gegenereerd voor die pixels alleen worden ze vervolgens weggegooid. Ik weet dus niet of dat wel veel snelheid oplevert. Veel makkelijker is om het naar een halve buffer te renderen. Je hoeft dan echt een pak minder te doen. Minder culling, minder zbuffer, minder rasterisatie. Allemaal winst.
Deferred of niet maakt in die zin verder niet uit denk ik.

Geometrie komt denk ik helemaal niet om de hoek kijken omdat de beslissing of een pixel wel of niet wordt gerendert niet afhangt van de geometrie maar van de locatie van de pixel in de uiteindelijke framebuffer.
Je kan het beeld dus op halve x resolutie renderen voordat je aan de 'truuk' begint.

Ik ben nog steeds niet overtuigd van het feit of ze werkelijk nog extra framebuffer informatie (zoals zbuffer) gebruiken voor de reconstructie. Wat ik zie beschreven lijkt allemaal op 2D beeldverwerking methodes en dat werkt op de pixeldata en niet op data dieper uit een renderlaag.
De pixelvectors waar ze het over hebben lijkt te wijzen op optic flow algoritmes. En dat heeft niks meer met de oorspronkelijke pre-render data te maken en is een post aangelegenheid.
Als ze namelijk WEL beschikten over vectorinfor uit de geo pipeline dan wisten ze precies de verandering van de pixels in screenspace en waren die artefacten er niet.
De artefacten suggereren dus dat het hele algoritme op de pixeldata zonder extra informatie uit de pipeline werkt.

[Verwijderd]

Ja, maar volgens mij doorloop je dan alsnog de geometiestage en raterisation voordat je mag bepalen of er iets 'niet uitgerekend' hoeft te worden.

Geometry is afhankelijk van het aantal vertices/triangles, niet van de resolutie, en is dus constant.
Het rasterizen is embarassingly parallel, dus verwaarloosbaar in de meeste gevallen.

Als je masking gebruikt via stencils dan worden er volgens mij alsnog fragments gegenereerd voor die pixels alleen worden ze vervolgens weggegooid. Ik weet dus niet of dat wel veel snelheid oplevert.

Zoals ik al zeg, het rasterizen zelf is verwaarloosbaar, en ook het weggooien van pixels aan het begin is heel goedkoop (anders zou deferred rendering ook helemaal niet lonen... dat werkt alleen omdat het shaden van de pixels veel duurder is dan het rasterizen).

Het is dus aanemelijk dat ze naar een 960 buffer renderen. Dan heb je alle voordelen van sneller rasterizen. Vervolgens gebruik je die data om naar een 1920 buffer te renderen.

Het zou kunnen. Aan de andere kant... als je dus eerst naar een 960-buffer rendert, moet je de data nogmaals kopieren naar de 1920-buffer. Als je direct naar een 1920-buffer rendert, hoeft dat niet. De vraag is alleen hoe het precies werkt. Want je zou in het tweede geval een read-modify-write op je buffer willen doen qua post-processing, en ik weet niet precies welke beperkingen de PS4 daarvoor heeft (met compute shaders zou het sowieso geen probleem moeten zijn).

Minder culling

Culling? Je bedoelt backface culling? Dat gaat per triangle, en is dus wederom niet afhankelijk van resolutie.

De pixelvectors waar ze het over hebben lijkt te wijzen op optic flow algoritmes.

Dat vraag ik me af. Dat lijkt me dan weer VEEL duurder (en minder precies), dan gewoon temporeel proberen af te leiden aan de hand van per-pixel normalvectors of iets.

Als ze namelijk WEL beschikten over vectorinfor uit de geo pipeline dan wisten ze precies de verandering van de pixels in screenspace en waren die artefacten er niet.

Hoe kom je daarbij? Bij deferred rendering heb je zeg maar 2.5D informatie: je weet de kleuren van de pixels, de surface normal voor de pixels, en de z-waarde voor de pixels. Maar het blijft view-dependent. Dus zodra de camera beweegt kijk je niet meer recht op die maps, en vallen er gaten vanwege de diepte-verschillen.
"Pixelvectors worden zo veel mogelijk gebruikt om de oneven kolommen in te vullen. Bij onbruikbare pixels wordt een voorspelling van de kleur geput uit alternatieve, naburige pixels."
Dit lijkt me dan ook te wijzen op het feit dat als er te veel 'beweging' in het beeld zit, dat ze dan niet meer die oude frames gebruiken ('onbruikbaar'), en in plaats daarvan 'gewoon' lerpen tussen de pixels van het huidige frame.

[koelpasta]

"Geometry is afhankelijk van het aantal vertices/triangles, niet van de resolutie, en is dus constant."

Ja, niet aan gedacht.

"Het rasterizen is embarassingly parallel, dus verwaarloosbaar in de meeste gevallen."

Maar het houdt de pipeline wel op. Daarnaast moet alle geometrie van de (defered) render door dat proces. En het is nog steeds een fixed function iets bij amd , dus ik weet niet of het paralelisme van de gpu uberhaupt wel ter sprake komt.

"Het zou kunnen. Aan de andere kant... als je dus eerst naar een 960-buffer rendert, moet je de data nogmaals kopieren naar de 1920-buffer."

Ja, das ook wel waar.
Maar je hebt dan alsnog de vorige 2 beelden nodig.

"Als je direct naar een 1920-buffer rendert, hoeft dat niet. De vraag is alleen hoe het precies werkt. Want je zou in het tweede geval een read-modify-write op je buffer willen doen qua post-processing, en ik weet niet precies welke beperkingen de PS4 daarvoor heeft (met compute shaders zou het sowieso geen probleem moeten zijn)."

Ik geloof dat ze dat letterlijk zeggen, dat het 1920 beeld uit 3 960 beelden wordt opgebouwd.

"We keep track of three images of “history pixels” sized 960x1080
The current frame
The past frame
And the past-past frame

For each pixel we store its color and its motion vector – i.e. the direction of the pixel on-screen
We also store a full 1080p, “previous frame” which we use to improve anti-aliasing"

Ze onthouden dus kleur en bewegingsvecor uit de renderbuffer en die is blijkbaar 960.
Intresting...
Dus geen optical flow of eigenlijk een enorm 'gehinte' optical flow.
Die bewegingsvector hadden ze natuurlijk ook al voor de motion blur.

[Verwijderd]

Maar het houdt de pipeline wel op. Daarnaast moet alle geometrie van de (defered) render door dat proces. En het is nog steeds een fixed function iets bij amd , dus ik weet niet of het paralelisme van de gpu uberhaupt wel ter sprake komt.

Rasterizen moet toch wel gebeuren. Het enige verschil is het aantal pixels dat rasterized moet worden. En zoals ik zeg, dat is dus enorm parallel. Het probleem is tegenwoordig vaak dat de triangles te klein worden om goede efficientie bij rasterizing te hebben. Hier wat interessante achtergrond-info daarover: http://www.beyond3d.com/content/reviews/55/10

[koelpasta]

"Rasterizen moet toch wel gebeuren. "

Maar als je het 2x sneller kan maken door minder fragments te genereren dan lijkt mij dat zinnig. En het oorspronkelijke artiekel bevestigt dat ze blijkbaar 960 renderbuffers gebruiken en pas aan het eind een 1920 buffer samenstellen.

Anyway, leuk artiekel !.
Interesant is het wel om te zien dat de rasterizers bij shader groups worden ondergebracht. Dat maakt het een stuk paraleller. Zeker voor kleinere driehoeken kan dat efficient uitpakken.

[Verwijderd]

Maar als je het 2x sneller kan maken door minder fragments te genereren dan lijkt mij dat zinnig.

Dat is dus mijn punt: omdat het embarasssingly parallel is, schaalt het niet lineair. Een twee keer zo grote triangle duurt dus niet twee keer zo lang qua rasterizing. Duurt lang voordat dat tot je doordringt.

[Daeley]

[...]


Nee. Upscaling is dat je een bitmap neemt van een bepaalde grootte, en die uitrekt naar een groter formaat.

Het is meer semantiek dan echt nuttige discussie, maar wat jij aanhaalt is een voorbeeld van upscaling. Hetgeen hier gebeurt is dat echter ook: er worden namelijk pixels berekend aan de hand van andere pixels in het beeld. Dat het iets intelligenter gebeurd dan 1+1=2 wil niet zeggen dat het geen upscaling is.

[Verwijderd]

Dan heb je niet goed gelezen. Er worden niet alleen andere pixels van het huidige beeld gebruikt, maar ook van voorgaande:

Hij omschrijft temporal projection als een techniek die verschillende frames analyseert: het huidige frame, het vorige frame en het frame daarvoor. Voor iedere pixel in die frames wordt geregistreerd waar die op dat moment was en in welke richting hij zich verplaatst: de pixelvector. Pixelvectors worden zo veel mogelijk gebruikt om de oneven kolommen in te vullen. Bij onbruikbare pixels wordt een voorspelling van de kleur geput uit alternatieve, naburige pixels. "Af en toe gaat die voorspelling mis en kunnen delen van het beeld wazig worden of verschijnen er kleine verticale lijntjes. Meestal gaat het voorspellen echter goed en is het beeld identiek aan een normaal 1080p-beeld."

En dat is dus anders dan het upscalen van een bitmap, zoals ik al zei, en is meer in de richting van deinterlacing.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 07:55]

[Daeley]

Heb dat goed gelezen. Je moet het niet persoonlijk opvatten hé. Nogmaals: er worden nieuwe pixels gemaakt op basis van andere reeds berekende pixels. Dus dat kan je perfect upscaling noemen.

[Adion]

Je kan het ook downscaling noemen. Er worden immers 3 beelden van 960x1080 gebruikt om 1 beeld van 1920x1080 te genereren.

[koelpasta]

"Je kan het ook downscaling noemen. Er worden immers 3 beelden van 960x1080 gebruikt om 1 beeld van 1920x1080 te genereren. "

Ware het niet dat je die andere beelden ook nog te zien krijgt.
En dat niet alle informatie die je nodig hebt in de omliggende beelden zit.
Maar ergens heb je wel gelijk

[Reactie gewijzigd door koelpasta op 25 juli 2024 07:55]

[Verwijderd]

Alles kan, maar dan rek je het begrip wel ver buiten z'n bedoelde context uit (no pun intended).

[darkpluisje]

Zelf al was het native 1080p dan nog zou er upscaling plaats vinden omdat lang niet alle textures en shadows op die resolutie gerenderd worden. Er zitten zoveel truukjes in het maken van een 3D beeld dat je dit moeilijk als enige upscalen kan noemen terwijl, wanneer ze een lagere texture resolutie hadden gebruikt maar wel op 1080p hadden gerenderd, je niet van upscaling had gesproken

[ironx]

Waar het om gaat is dat men de consument bewust verkeerde informatie geeft. Wees gewoon vanaf het begin eerlijk dat de resolutie wat lager is maar dmv technieken geupscaled wordt, dan heb je dat 'geouwehoer' achteraf ook niet. Als jij een BMW koopt waarvan BMW beweert dat hij 320 km/u kan, maar in de praktijk gaat ie maar 160km/u "maar de snelheidmeter geeft door middel van een techniek 320 aan waardoor het lijkt dat ie 320 gaat" zullen ook veel mensen zeggen: ja, wat is dit nou?

Nogmaals, het zal mij een zorg zijn wat de resolutie is, heb geen van beide consoles (PS4 of One), maar wees wel gewoon eerlijk naar je (betalende) klanten toe...

[Reactie gewijzigd door ironx op 25 juli 2024 07:55]

[innerchild]

Tja bij auto's worden de hoeveelheid km's die je kan benutten op 1 liter ook bewust bij elkaar gelogen. Ik denk dat de meeste mensen die dit spelen spelen er niet eens bij stil staan wat en hoe de techniek in elkaar steek. Die kijken of het spel leuk is ja of nee..

[et36s]

idd care

[Verwijderd]

"Af en toe gaat die voorspelling mis en kunnen delen van het beeld wazig worden of verschijnen er kleine verticale lijntjes. Meestal gaat het voorspellen echter goed en is het beeld identiek aan een normaal 1080p-beeld."

Wat een onzin. Opschalen is hetzelfde als een native 1080p beeld? Natuurlijk is dat niet het geval. Vergelijk maar eens hetzelfde beeld van een film op 720p en 1080p op een 1080p TV.

[alingebruik1978]

Zoals ik het lees is het geen opschalen maar gewoon op een handige manier berekenen van bepaalde pixels in plaats van normaal berekenen. Beeld dat die engine eruit duwt is toch nog steeds 1920x1080? (in 16:9)
Of begrijp ik hem verkeerd...

[tedades]

Als ik het goed lees heb je gewoon 1080p beeld. Maar het beeld is niet 100% vers berekend, het is deels gerecycled beeldmateriaal. Maar eindresultaat is praktisch hetzelfde.

[Bullet NL]

Het is gewoon 1080i, de beeldlijnen worden niet zoals bij 1080 Progressive weer gegeven, maar de helft daar van. Beeld wat voor de deels wordt hergebruikt maakt het signaal niet 1080P

Zie voor meer info; http://en.wikipedia.org/wiki/Progressive_scan

[Veneus]

bij interlacing en dus 1080i wordt NIET maar de helft van het aantal beeldlijnen weergegeven.
Ze worden ECHT wel allemaal weergegeven, maar zit er een zeer klein tijdsverschil tussen de even en oneven lijnen.

In sommige aspecten zou je de kwaliteit van 1080i zelfs als 'beter' kunnen opvatten aangezien de er een hogere resolutie in de factor tijd zit.
Namelijk niet 25 frames per seconden, maar 50 fields per seconde.

(echter ziet men 1080p meer als 'film'-achtig, en is charmanter)

[Reactie gewijzigd door Veneus op 25 juli 2024 07:55]

[koelpasta]

Nee, het is echt zo dat bij 50 of 60Hz interlaced de fields van andere tijden afkomstig zijn en dus om en om weergegeven moeten worden. Het is dus niet zo dat je 2x de helft van hetzelfde frame ziet. Je ziet de helft de beeldlijnen van het ene moment, daarna de andere helft van een ander frame. En dat wordt samengepakt tot een interlaced frame.
Als je een progressive 25 of 30Hz bron hebt en je stuurt dat over een interlaced systeem dan wil je inderdaad dat uiteindelijk die fields eigenlijk tegelijk weergegeven worden omdat ze gewoon bij elkaar horen. Maar als het bronmateriaal interlaced is dan komen de fields uit het frame van andere momenten in tijd.
Door de blur van een crt of het deinterlacingalgoritme van de flatscreen in combinatie met de traagheid van je ogen lijkt het alsof je hele beelden ziet, maar elk 50e of 60e seconde zie je maar de helft van wat er op dat moment gebeurde...

[Veneus]

Ik zei ook dat er een tijdsverschil in zat.
Maar bij PAL is het dus wel zo dat je 25 HELE beelden per seconden ziet, of je nou interlaced gebruikt of progressive.

Progressive: 25 HELE beelden per seconde. (frames)
Interlaced: 50 halve beelden per seconde. (fields)

en ja, een progressive bron op een interlaced apparaat kijken ziet er niet mooi uit, en andersom al helemaal niet.

Maar naar mijn mening is 1080i technisch gezien niet slechter.
Met het oog op het aspect tijd, zelfs beter.

[koelpasta]

"Maar bij PAL is het dus wel zo dat je 25 HELE beelden per seconden ziet, of je nou interlaced gebruikt of progressive."

Nee, want PAL is een interlaced standaard.
Je ziet dus 50 halve beelden. Elk beeld is een appart moment in tijd maar gebruikt slechts de helft van de beeldlijnen bij opslag/overdracht. Omdat er zo snel wordt gewisseld denken je hersenen dat je 50 hele beelden ziet, maar in feite zie je 50 halve beelden per seconde. Wat je bij een crt duidelijk kunt waarnemen is de flikkering van het wisselen van beeldlijnen/fields
PAL transporteert het beeld wel op 25 frames per seconde, maar er wordt verwacht van de weergever dat dat frame uit elkaar getrokken wordt (ene field alle even lijnen en ander field alle oneven lijnen) en als losse fields na elkaar op 50Hz wordt weergegeven.
Dit is hoe de PAL standaard is bedacht.

Als je in dat pal signaal een 25fps progressive signaal encodeert dan wordt dat automatisch goed weergegeven en lijkt het op een crt alsof je 25 hele beelden ziet. Een flatscreen zou dat ook moeten begrijpen en de fields in elkaar plakken en dan op halve framerate het progressive frame laten zien. Daar is geen probleem mee tenzij de apparatuur of software brak is.

Interlaced weergeven op een pc is dan vaak wel een probleem.
OF de deinterlacing zuigt, OF de output is 25 (of 30)Hz waardoor je dus niet de benodigde 50Hz haalt om een interlaced signaal correct weer te geven.

Maar het is dus echt zo dat in het PAL systeem (en eigenlijk alle interlaced tv standaarden, zoals NTSC) je nooit 25/30 hele beelden ziet, tenzij de bron progressive was. Het enige dat in die systemen op 25Hz loopt zijn de frames. Maar frames zijn bij die systemen gewoon een manier om fields in te pakken en te vervoeren.

[Veneus]

Je ziet dus 50 halve beelden. Elk beeld is een appart moment in tijd maar gebruikt slechts de helft van de beeldlijnen bij opslag/overdracht. Omdat er zo snel wordt gewisseld denken je hersenen dat je 50 hele beelden ziet, maar in feite zie je 50 halve beelden per seconde.

behalve dan dat er bij een crt niet snel wordt gewisseld, maar er BIJ wordt geschreven. Er staan dus per seconde 25 hele beelden in beeld.
Je hersenen denken dus niet 50 hele beelden te zien, maar 25.

En ja deinterlacing en dus interlaced content op een progressive monitor bekijken is geen pretje. Maar dat maakt van interlacing zelf geen slecht iets.

[koelpasta]

"behalve dan dat er bij een crt niet snel wordt gewisseld, maar er BIJ wordt geschreven. Er staan dus per seconde 25 hele beelden in beeld."

Nope.,
Er is wel een soort nagloei van de fosfors.
Maar dat geldt voor elk field dat wordt weergegeven.
Dus elk field blurrt een beetje over in het vorige field.
Maar tegen de tijd dat er een nieuw field wordt getekend is het vorige field dus al grotendeels uitgedooft. zie bijvoorbeeld dit. Hier zie je duidelijk dat al tijdens het scannen het meeste licht van het frame is uitgedooft. Eigenlijk zie je per field (50 keer per seconde) dus alleen een soort balkje dat van boven naar beneden beweegt. En elk van die scans is om-en om alleen even of oneven lijnen. En elk field is gemaakt uit een heel ander origineel vol frame. Dit gebeurt al in de ccd van de videocamera die elke 50e seconde allen zn even of oneven lijnen uitspuugt.

Nogmaals. Een interlaced PAL signaal bevat helemaal geen hele beelden, tenzij het oorspronkelijk een progressive signaal was.
Het bevat frames die zijn opgebouwd uit fields (halve frames op 50Hz) die in elkaar geschoven worden voor transport.

Je zou eens op een tv een 25 progressive video met een 50 interlaced video moeten vergelijken.
Wat je dan ziet is dat het 50i signaal veel smoother in tijd loopt.
Dit is per direct het resultaat van het feit dat je beelden op 50Hz ziet. En die beelden zijn opgeslagen met slechts de helft van de beeldlijnen. Je ziet dus halve beelden voorbijkomen op dubbele framerate. (en met framerate bedoel ik de snelheid van de PAL frames, niet de beeldschermrequentie)
De (halve) beelden staan dus werkelijk 50 keer per seconde op je tv.

Als je een crt in slow motion zou zien dan zie je echt dat er (b.v.) eerst de even lijnen worden getekend, met informatie van moment 1, daarna de oneven lijnen worden gevuld met informatie van moment 2 en vervolgens weer de even lijnen worden getekend met informatie van moment 3, etc etc. Tussen elk van die weergegeven fields zit evenveel tijd. Er staan dan 50 verschillende (halve) beelden per seconde op je scherm.

In een PAL frame zitten dus eigenlijk 2 frames verpakt. Alleen zijn van het ene frame de even lijnen weggegooid en van het ander frame de oneven en zijn die beelden in elkaar geschoven. De twee halve frames worden dan fields genoemd maar zijn dus gewoon halve frames bedoelt voor dubbele snelheid.

Verder heb ik niks tegen interlacing hoor.
Waar ik kritiek op heb, qua pc's, is dat er bar weinig software is die correct met interlaced signalen omgaat en dat ook prettig kan presenteren. Deinterlacen naar 50Hz (zoals het dus hoort) is een zeldzame vertoning.

[Veneus]

Hmm ja ik denk dat er een spraakverwarring is.

Ik ben me er van bewust dat het steeds halve beelden zijn. Maar dat wil niet zeggen dat de netto resolutie voor de beelden per seconde gehalveerd is.

Ik bedoel dus dat er wel degelijk 25 fps op de hele resolutie getoond wordt en dat er niet per definitie lijnen bij verzonnen worden of langer getoond dan nodig.

Interlacing != interpolatie

Maar ik geloof dat we het in essentie eens zijn

[koelpasta]

Bijna eens Het is nog steeds zo dat de resolutie bij pal per beeld dat je ziet slechts de helft is van een volledig frame.
Het punt is dat je ogen/hersenen dat aanvullen. Die doen namelijk ook, net als killzone, aan een soort temporale interpolatie. Weldegelijk verzonnen dus! Hierdoor denk je dat je de volle resolutie ziet maar die indruk ontstaat omdat je even ervoor een compleet ander beeld zag dat de resolutie van het huidige beeld in je hersenen aanvult.

[tedades]

Zover ik kan lezen gaat 1080i/1080p alleen over het opslaan/versturen van de data en niet het renderen ervan. Lijkt me dat het beeld hoe dan ook 1080 gerenderd wordt, en dan in hele of halve plaatjes naar het beeld gaat.

[darkpluisje]

maar 720p is heel wat anders, dan laat je gewoon 4 pixels het werk van 1 doen. Hierbij zijn in de hoogte sowieso all pixels uniek en in de breedte om en om uniek en om en om berekend (dus of uniek of met een kleine fout)
Dus totaal niet vergelijkbaar met elkaar.

[Bosmonster]

Het gaat dus niet om "opschalen"...

[halofreak1990]

Eigenlijk snap ik niet hoe deze techniek sneller kan zijn dan gewoon de betreffende beeldlijnen renderen. Met al het rekenwerk wat die 'voorspellingen' doet kun je beter die resterende beeldlijnen renderen. Is volgens mij nog goedkoper (qua performance) ook. Volgens mij is dit gewoon een verkooppraatje en is het zootje horizontaal gewoon gestretched.

[woutertje]

Het is niet waarschijnlijk dat ze deze techniek zouden toepassen als gewoon renderen goedkoper zou zijn qua performance. Het is in ieder geval een feit dat jij daar geen inschatting over kunt maken, en dus een vreemde uitspraak.

[YopY]

Veel 'volgens mij'-s in je comment. Het renderen van een frame van een volledige scene is nogal complex, je moet een soort foto nemen van de hele staat van de game wereld op dat moment, 30-60 keer per seconde. De beschreven techniek werkt als ik het goed lees op basis van al gerenderde beelden, dus eigenlijk puur op 1-2 gerenderde frames in het verleden; berekeningen op volledige frames kunnen veel sneller gedaan worden.

Zie ook: MPEG video compressie.

[majic]

Elke pixel die je ziet is niet één 2D vierkantje, maar vooral een blokje wat soms wel tientallen 'stappen' diep kan zijn. Allerlei berekeningen worden op dat puntje losgelaten.

Bij het half-interpoleren wat ze nu doen wordt er bijna geen diepte informatie meegenomen heb ik de indruk, of iig veel minder. Die pixel vereist dus veel minder rekenwerk dan bij de traditionele methode.

iig, dit is wat ik er van begrijp, maar ik ben een complete noob.

[Verwijderd]

Het kan ook nog best eens zo zijn dat ze eigenlijk het huidige beeld 'laten staan' en daar motion vectors op toepassen (vrij snel te doen in hardware, mede met dank aan de alom aanwezige MPEG chips), en dan razendsnel checken of het contrast tussen pixels niet te groot is - en als dat wel het geval is even het gemiddelde van naburige pixels nemen. Dat kan allemaal ontiegelijk rap - en inderdaad vast een stuk sneller dan de hele rendering pipeline doorlopen

[Verwijderd]

Af en toe gaat die voorspelling mis en kunnen delen van het beeld wazig worden of verschijnen er kleine verticale lijntjes. Meestal gaat het voorspellen echter goed en is het beeld identiek aan een normaal 1080p-beeld.

Ben benieuwd of hier dan ook berichten over zijn, heb tijdens de launch niet gehoord van zulke problemen, echter heb ik zelf de game noch de playstation 4.

[darkpluisje]

Dat betekend dat er een fout zit van misschien een paar pixels hoog en 1 pixel breed in een paar van de frames van een beeld dat op 60 frames per seconde draait en het gebeurd alleen als de voorspelling het fout heeft (dus bij veel beeldverandering) .. Moet jij in al die chaos maar eens die paar frames eruit pikken waar de fout op stond

[Ereaser]

Ik weet niet of je wel merkt dat 1 frame wazige delen heeft of kleine verticale lijntjes heeft in de 60 frames die er per seconde verschijnen?

[lasharor]

Klinkt alsof er geen zichtbaar verschil is tussen SP en MP afgezien van het feit dat die laatste op 60 FPS draait en soms ietwat wazig en/of met artefact kan zijn.

[revertive]

Het klinkt alsof er geen zichtbaar verschil is afgezien van het zichtbare verschil? 30FPS vs 60FPS zou waargenomen kunnen worden (ik moet toegeven niet iedereen lijkt het te kunnen zien), ietwat wazig en/of artefacten zijn natuurlijk gewoon te zien als het zich voordoet.

[lasharor]

wat snap je niet aan "afgezien van het feit". Dus behalve die 60FPS en de soms wat mindere beeldkwaliteit is datgene wat op je scherm laat zien grotendeels gelijkwaardig.

[darkpluisje]

Das op dezelfde manier als dat een Ferrari en een Fiat grotendeels gelijkwaardig zijn behalve dat de ferrari een snellere motor heeft en er beter uit ziet

[Darkblaster]

Al dit gedoe, mobieltjes draaien de hoogste resoluties, TV's gaan richting de 4K, en de zogenaamde next-gen consoles kunnen niet eens 1080P normaal aan?

Nu is resolutie ver van de belangrijkste aspecten, maar ze moeten niet slordig gaan worden met een beetje bijblijven op technisch gebied. Dit apparaat moet nog minimaal 5 jaar meegaan.

[K0L3N]

Mobieltjes en tv's hoeven het beeld alleen maar weer te geven, de consoles moeten alles eerst helemaal uitrekenen, en dit zo snel dat je geen hinderlijk vertraging krijgt in je beeld. Ik snap heel goed dat dat knap lastig is, en ik begrijp dat ze daarom een dergelijke keus hebben gemaakt. Ik zou er zelf eerder voor zorgen dat je minder uit te rekenen hebt maar wel de volledige resolutie, maar dit ziet er weer minder mooi uit.

[Darkblaster]

Ook de mobiele games spelen gewoon op de native resolutie, geen concessies.

[K0L3N]

Klopt, daar had ik me even vergist, het punt is echter ook dat die mobieltjes veel minder grafisch geweld hebben, ondanks de hogere resolutie, dus het ziet er scherper uit, maar niet mooier.

[Verwijderd]

Wauw...een console afrekenen op de eerste generatie game Vergelijk alsjeblief eens de eerste games op de N64, PSX, PS2, Xbox 360 en PS3 eens met de latere games die zijn uitgekomen...een wereld van verschil!!!

[Henkie]

Denk dat je respect moet uiten voor een techniek als deze, hogere fps en het duurt maanden voordat iemand echt doorheeft dat het geen 'echte' 1080p is. Hulde aan guerrilla games!

[sys64738]

Soort verticale interlace dus: 1080vi

Als het niet opvalt dan zie ik het probleem niet zo maar als die voorspellingen regelmatig mis gaan en er dus echt een interlace gevoel onstaat, is het niet zo sjiek natuurlijk.