Test Nativ vs. DLSS 4.5 vs. FSR AI: Ihr wählt euren Favoriten in sechs Spielen im Blindtest

[Iscaran]

Nein, nur die temporalen Daten werden gejittert. Und mit dem EINEN gerenderten Bild verrechnet um es zu optimieren.

Und diese temporalen Daten werden vorher reduziert durch das DLSS Modell. Das Renderbild selbst ist

Oder anderes Beispiel:
Du hast einen imput von 100x100 Pixeln (10.000 Pixel), gejittert werden draus Informationen aus 150x150 Pixel (22.500 Pixel), da das gejitterte Bild um einen halben Pixel versetzt gerendert wird. Mach das mal ca. 50x die Sekunde, was den ungefähren jetzigen Zahlen der Jitterbilder bei Nvidia entspricht.
Da kommen irrsinnige Mengen bei raus.
Das Modell entscheidet nur, was von diesem Datenberg weg kann, um dennoch ein ansprechendes Ergebnis zu liefern. Je besser es trainiert wurde, desto mehr kann in kürzerer Zeit verworfen werden.

Es wird aber nicht das "gejitterte Bild" gerendert - sondern die temporal vorliegenden BILDER werden gejittert "gesampled" in einem "post-Processsing" Verfahren um daraus INKLUSIVE des aktuell gerenderten Bildes ein auszugebendes Bild zu generieren. Das entweder einfach nur "temporal" gefiltert ist (TAAU bzw. DLAA) oder ZUSÄTZLICH upscaled ist.

EDIT: Das Abtasten eines bereits bestehenden Bildes geht super schnell. Zumal man ja auch nicht ALLE Pixel scannt sondern eben nur die Zufällig "gejitterten". Denn rein zeitlich ist der RENDER Schritt immer noch das was am längsten Dauert. Der Post-Processing Schritt ist dagegen relativ schnell.

https://developer.unigine.com/en/docs/latest/principles/render/upscaling/?highlighted=dlss,dlsslll

EDIT: Deswegen steht da bei "Upscalers"

DLAA (Deep Learning Anti-Aliasing) is an AI-powered tool to eliminate jagged edges in video apps, by rendering at native (100%) resolution. It improves image quality with less performance cost than traditional anti-aliasing methods.

/EDIT


ziemlich weit unten findet sich ein Schema, wie die Frame erzeugung in einzel schritten abläuft.

Das DLSS kommt ganz offensichtlich hier erst NACH dem deferred rendering und dem TO-Rendering.

Das zeigt ganz klar, dass es sich beim DLSS um eine Art Post-Processing Filter handelt.

Entsprechend ist das Jittering die "Abstatung" (Sampling) der temporal vorliegenden Daten. Da werden nicht in jedem Bild nochmal ZIG-unterbilder "Gerendert"...es werden die schon zuvor gemachten Bilder erneut abgetastet - aber nur an bestimmten "Sub-Pixel" Positionen nach einem möglichst "Random" Muster (um Artefakte aus dem Sampling zu reduzieren).
Dieses Jittering/Abtasten nun wird bei TAA mit einem vorher definierten "Pseudo-Random" Halton-Muster gemacht. Beim DLSS aber mit einem Transformer Neural Net (seit DLSS 4 oder so).
Weil dies nach dem Training eine sehr komplexes, zugleich aber maximal cleveres Parametrieren dieser "Pseudozufallsfunktion" die das Jittering braucht um möglichst perfekte Ergebnisse zu liefern macht.

DLSS nutzt einen Buffer von zuvor generierten Frames und kreiert daraus mit dem neuen Frame sowie eben einer von Frame zu Frame WECHSELNDEN Abtastung eine Art "best guess" des finalen Bildes (basierend auf dem aktuell gerenderten Bild + eben den "Post-Processing DLSS-Filter".

Vielleicht hilft auch das hier fürs Verständnis: https://en.gamegpu.com/news/zhelezo/kak-na-samom-dele-rabotaet-apskejling-dlss-4-5-v-igrakh


Also NEIN: Diese Aussage ist einfach falsch

...da das gejitterte Bild um einen halben Pixel versetzt gerendert wird.

.
Das gerenderte Bild wird mit einem FILTER "korrigiert" der aus X-ZUVOR gerenderten (bzw. Ausgegebenen?) Bildern besteht, die mit einem "Sub-Pixel" Verfahren das eine Transformer Neural Net "steuert" erneut abgetastet werden um daraus das fertige Bild zu kreieren.

Das ganze kann nun MIT oder OHNE Upsampling gemacht werden, was das schöne an dem Verfahren ist.

 

[n8mahr]

Bitte ergänze UNBEDINGT, dass der Videoplayer auf den zoom 100% gestellt werden soll, bevor man den Gesamteindruck des Bildes beurteilt! Gerade auf Zoom-Out Stufen (Zoom < 100%) erzeugt der Player selbst ein Flimmern der Ausgabe.

Das würde das Ergebnis verfälschen!

hat´s schon. der player startet bei mir standardmäßig auf 33%, und da war in einem der 3 video MASSIVES flimmern. und dann auch noch bei dem, was lt. umfrage die meisten stimmen bekommen hatte. habe dann erstmal in die kommentare geschaut, ob das etwa noch mehr leute verwundert hat... und da lese ich deinen hinweis.
das sollte wirklich FETT noch mal vor jedem video stehen.

 

[Grestorn]

@Iscaran

Wieder, all das, was Du geschrieben hast, bezieht sich auf die Renderpipeline von Engine und nicht auf DLSS/FSR/TAA selbst.

Das sind alles Nebelkerzen. Das, worum es bei DLSS/FSR/TAA geht, adressierst Du gar nicht.

Nein, nur die temporalen Daten werden gejittert. Und mit dem EINEN gerenderten Bild verrechnet um es zu optimieren.

Was sind denn "temporale Daten"? Was gejittert wird, sind natürlich die nativ gerenderten Frames aus der Render-Pipeline der Engine – sonst gar nichts.

Dass das natürlich zu EINEM Bild am Ende zusammengerechnet wird, ist ja klar, denn nur das wird dann als Input für die Folgeschritte der Pipeline genutzt (die Du so schön dargestellt hast). Aber wie DLSS/FSR/TAA die Daten der vorhergehenden Frames nutzt, wie viel davon gespeichert wird, wie viel genutzt wird, eine Art neuronales Netz zu füttern oder nur in irgendwelchen anderen Algorithmen genutzt wird, darin unterscheiden sich die Verfahren.

Natürlich kann man nicht viele dieser Frames vollständig speichern; das würde den Speicher sofort sprengen. Also muss man diese Daten sehr intelligent über den Zeitstrahl verarbeiten.

Wenn man unbegrenzten Speicher hat und alle Frames vollständig speichern kann, ist ein gejittertes, statisches Bild nach x Frames zu 100% äquivalent mit einem x-fach supergesampleten Bild. Das ist die Theorie des temporalen Renderns. Mehr habe ich nie geschrieben.

Dass der Algorithmus auf GPUs das so direkt nicht machen kann, ist ja auch der Grund dafür, dass TAA so deutlich abfällt gegenüber modernen Verfahren. Die Daten müssen anders, "intelligenter" verrechnet werden.

Was aber bleibt, ist, dass die Basis-Renderauflösung keine Aussage über die Detailauflösung des am Ende erzeugten Bildes mehr erlaubt.

Und damit sind wir wieder dabei, dass auch ein Bild, das nur mit 50% der Pixel berechnet wird (Performance), gejittert gerendert und intelligent verrechnet, dennoch mehr Details zeigt als das nativ gerenderte Bild.

Und dass es kaum einen Unterschied macht, ob man mit 67% oder mit 100% rendert – außer dass man Framerate und Energie verschenkt.

 

[Nolag]

Das DLSS kommt ganz offensichtlich hier erst NACH dem deferred rendering und dem TO-Rendering.

Das zeigt ganz klar, dass es sich beim DLSS um eine Art Post-Processing Filter handelt.

Entsprechend ist das Jittering die "Abstatung" (Sampling) der temporal vorliegenden Daten.

Bei dem Jitter handelt es sich um Camera Jitter. Man spricht dabei auch gerne von "jittered rendering". Ohne den Camera Jitter könnte ein reines Post-Processing Verfahren kein Anti-Aliasing gewährleisten, wenn der Nutzer die Kamera nicht bewegt. Das Jittern der Kamera sorgt dafür, dass die Szene an unterschiedlichen Sub-Pixel Positionen abgetastet wird. Hier ist ein Link zur FSR Dokumentation, der erklärt dass man sich die Halton-Sequenz mit den Jitter Offsets für die Kamera über eine Funktion im API holen muss und auf die Kamera anwenden muss. Es gibt dort sogar ein Code Beispiel, wie man die Jitter Offsets auf die Kameraprojektion anwenden muss. Natürlich muss man dann dem Filter auch mitteilen, welchen Jitter man beim Rendern verwendet hat. Diese Abhängigkeit wird in den Diagrammen gerne verschwiegen.

Camera jitter​

FSR Super Resolution relies on the application to apply sub-pixel jittering while rendering - this is typically included in the projection matrix of the camera. To make the application of camera jitter simple, the FideiltyFX Upscale API provides a small set of utility function which computes the sub-pixel jitter offset for a particular frame within a sequence of separate jitter offsets.

AMD FidelityFX FSR Super Resolution - Camera Jitter
Am Ende des Unity Links, den du gepostet hast, ist ein Link zu fsr_max_contexts, der zeigt, dass der Camera Jitter teil des Kontextes ist.
Auch der verlinkte GameGPU Artikel redet natürlich von Camera Jitter wenn dort steht:

With each new frame, the game engine selects a color sampling point from a slightly different location within the pixel. If the camera is stationary, the system collects information from different points over several frames, effectively increasing the resolution.

 

[maxi_rodriges]

Bilder die am schärfsten sind, sind einfach die besten. Verschwommenheit oder Unschärfe kann ich überhaupt nicht leiden, alles andere ist mir egal.

 

[Iscaran]

With each new frame, the game engine selects a color sampling point from a slightly different location within the pixel. If the camera is stationary, the system collects information from different points over several frames, effectively increasing the resolution.

Genau, DAS ist aber ein Post-Processing verfahren. Es werden nur "temporale" also schon zuvor gerenderte fertige Frames dazugenommen.

Das ganze "pseudo-randomisiert" über multiple "temporale" Frames (+ den jeweils NEU gerenderten Frame) = Ausgabebild.

Ist doch genau die Erklärung, die Pipeline oben enthält diese Schritte ebenfalls, eben am ENDE des kompletten Vorgangs im "Post-Processing" teil.

DLSS ist somit der ERSTE Schritt im Post-Processing nachdem das klassische Rendering abgeschlossen ist.

Es ist dahingehend "hybrid", da es für die Aliasing funktion wiederum auf teile der Informationen aus dem Rendering Schritt bzw. VORHERIGEN (temporal) Rendering ergebnissen (und/oder Schritten) zurückgreift.

Das ganze ist durch ein TNN-"gesteuert"

Bei dem Jitter handelt es sich um Camera Jitter. Man spricht dabei auch gerne von "jittered rendering". Ohne den Camera Jitter könnte ein reines Post-Processing Verfahren kein Anti-Aliasing gewährleisten, wenn der Nutzer die Kamera nicht bewegt. Das Jittern der Kamera sorgt dafür, dass die Szene an unterschiedlichen Sub-Pixel Positionen abgetastet wird. Hier ist ein Link zur FSR Dokumentation, der erklärt dass man sich die Halton-Sequenz mit den Jitter Offsets für die Kamera über eine Funktion im API holen muss und auf die Kamera anwenden muss. Es gibt dort sogar ein Code Beispiel, wie man die Jitter Offsets auf die Kameraprojektion anwenden muss. Natürlich muss man dann dem Filter auch mitteilen, welchen Jitter man beim Rendern verwendet hat. Diese Abhängigkeit wird in den Diagrammen gerne verschwiegen.

AMD FidelityFX FSR Super Resolution - Camera Jitter
Am Ende des Unity Links, den du gepostet hast, ist ein Link zu fsr_max_contexts, der zeigt, dass der Camera Jitter teil des Kontextes ist.
Auch der verlinkte GameGPU Artikel redet natürlich von Camera Jitter wenn dort steht:

Der Camera Jitter wird ja nicht im Rendering appliziert, sondern erst danach, beim "Samplen" des bildes.

GPU Rendering Pipeline with DLSS (frei nach ChatGPT)
CPU
└─ Game Logic
└─ Draw Calls
↓
GPU

1. Geometry Stage
- Vertex Processing
- Tessellation (optional)
- Primitive Assembly

2. Rasterization
- Convert triangles → fragments (pixels)

3. Shading
- Pixel/Fragment Shaders
- Lighting
- Materials
- Ray tracing (if enabled)

4. Low-Resolution Frame Buffer
(e.g., 1440p instead of 4K)

5. DLSS Upscaling Stage
- Inputs:
• Low-res rendered frame
• Motion vectors
• Depth buffer
• Previous frame
- AI Super Resolution (Tensor Cores)

6. Post-Processing
- Bloom
- Tone mapping
- Color grading
- UI composition

7. Final Frame → Display

1., 2., 3. 4. sind die Schritte die man normalerweise unter "Rendering" zusammenfasst.

5.6.7 sind Schritte die man als "Post-Processing" beschreibt.

Aber in der Tat ist DLSS ein bisschen was "Hybrides" da es aufgrund des Zugriffs auf Motion Vectors und ähnliches kein "klassisches Post-Processing" darstellt.

Es greift aber in jedem fall NACH dem eigentlich Rendering. Sub-Pixel Jittering ist keine expliziter Rendering Vorgang. Das geschieht normalerweise bei TAA ja auch im "ersten" Post-Processing schritt.

ChatGPT beschreibt dies folgerichtig auch so:

DLSS is neither traditional rendering nor simple post-processing.
It sits between rendering and post-processing.

Allerdings ist es entweder eine "separater" Zwischenschritt (wenn man es mit "Upscaling"einbindet (also DLSS, nicht DLAA). Aber auch dann, ist es eigentlich nichts anderes als ein "Vor-Verschieben" des ursprünglich später greifenden Aliasing Schrittes (in TAA) an eine Stelle etwas früher im Prozess.

Wobei man es eben direkt mit dem "Upscaling" paaren kann um so die mit BEIDEN diesen Prozessen verbundenen Artefakte und Verzerrung zu korrigiegen.

Die Korrektur dieser Artefakte erfolgt eben mit den AI gesteuerten Halton Verfahren + Verrechnung und Einbindung von Informationen die dem Rendering zugrunde LAGEN.

ChatGPT sagt dazu:


DLSS is a reconstruction stage.
It replaces the traditional:
Render at native resolution → Post-process → Display
With:
Render at lower resolution → DLSS reconstructs to higher resolution → Post-process → Display

Aber eine "Rekonstrution" ist nach meiner Kenntnis der Begriffsdefinitionen KEIN Rendering und wird traditionell eher als ein "Post-Processing" definiert. Denn Rekonstruktionen gabs schon immer und wurden auch schon immer genutzt, in diversen Post-Processing schritten.

Deswegen heisst das ja auch Post-Processing da es NACH dem Rastering/Rendering/Shading schritten kommt wo das "generierte Bild" optimiert wird durch Anwendung von diversen Verfahren, Filtern (wie AA), usw.
Normalerweise haben BISLANG aber Post-Processing Verfahren nicht auf motion vectors oder z-buffer info benutzt. Das ist das neue an DLSS (und FSR was quasi genauso abläuft)

Deswegen summiert ChatGPT auch folgerichtig:

Post-processing effects:

• Don’t add new geometric detail
• Operate only on the final image
• Usually don’t use motion vectors or depth

DLSS:

• Uses motion vectors
• Uses temporal history
• Uses depth buffer
• Uses AI neural network (Tensor Cores)
• Reconstructs sub-pixel detail

It’s more similar to temporal anti-aliasing + super resolution, but AI-powered.

Weil es eben keinen "statischen" Halton nutzt sondern einen von BILD zu BILD optimierten Halton filter.
Diese Halton Optimierung ist letztlich das was "AI" hier macht. Sub-Pixel Aliasing hatte man ja mit TAA selbst auch schon.

EDIT: Deswegen taucht auch in den nVidia Beschreibungen dazu z.B. explizit immer die Verwendung der Motion Vectors auf:

https://www.nvidia.com/en-us/geforc...-graphics-innovations/?utm_source=chatgpt.com
1080p (Render)-Bild + Motion Vectors => 4k -Bild (vereinfacht)
https://images.nvidia.com/aem-dam/S...phics-innovations/how-nvidia-dlss-2-works.jpg
/EDIT

https://developer.unigine.com/en/do...r/antialiasing/taa?implementationLanguage=cpp
Auch das TAA nutzt das schon, und da würde KEIN MENSCH Behaupten das das Sub-Pixel Jittering einen Teil der Rendering sequenz darstellt. Weil es auch nicht so ist, und das ist bei DLSS das sozusagen eine Weiterentwicklung davon ist ebenfalls so.
Wie ich schon mal schrieb DLSS ist TAA(U) auf "Boost" oder Steroiden, dank einer DYNAMISCHEN Anpassung der Sub-Pixel patterns...
https://www.cg.tuwien.ac.at/research/publications/2023/cech-2023-taa/cech-2023-taa-Report.pdf

Das passiert nicht IM Rendering, sondern DANACH.

Deswegen das Fazit von ChatGPT:

DLSS Super Resolution is:

A post-render reconstruction stage integrated into the rendering pipeline, before final post-processing.
It is:

• ✔ After shading
• ✔ Before tone mapping & UI
• ✔ Not a simple post-process filter
• ✔ A deep pipeline modification

Ja es ist kein simpler "statischer" Post-Process Filter...sondern eben eine "Reconstruction", dennoch ist es im Grunde "Post-Processing" nur dynamischer mit wesentlich mehr Zugriff auf frühere Frames und eben vor allem die Motion Vectors und Z-Buffers...das ganze parametriert durch ein LOKAL laufendes super spezialisiertes TNN (das VORtrainiert wurde auf Supercomputern) aber dann LOKAL während dem Post-Processing läuft.

 

[Nolag]

Der Camera Jitter wird ja nicht im Rendering appliziert, sondern erst danach, beim "Samplen" des bildes.

Zuerst dachte ich dass du hier nur Haarspalterei betreiben willst, aber aus diesem Satz muss ich schließen, dass du den Camera Jitter und die Funktion von temporalem Supersampling nicht verstanden hast. Ein Jitter nach dem Rendering ist völlig nutzlos.
Ich habe in meinem vorherigen Post angedeutet, warum man den Camera Jitter benötigt und auch die FSR Dokumentation als Quelle genannt, die ganz klar erklärt wie Camera Jitter beim Rendering funktioniert. Es ist eine fundamentale Notwendigkeit für TAA, DLSS und FSR, dass ein Camera Jitter beim Rendern angewendet wird. In der FSR Dokumentation wird das genauestens erklärt. Das verdeutlich bereits der erste Satz im Kapitel:

FSR Super Resolution relies on the application to apply sub-pixel jittering while rendering - this is typically included in the projection matrix of the camera.

Und weiter:

Jitter should be applied to all rendering. This includes opaque, alpha transparent, and raytraced objects.

Wenn ich FSR einsetzen möchte, dann muss ich mir je nach FSR Qualität den entsprechenden Jitter Offset vom API besorgen und auf die Kameraprojektion beim Rendering anwenden und dann den verwendeten Offset beim Post-Processing an FSR übergeben. Das gleiche Prinzip gilt auch für TAA und DLSS.

Deswegen heisst das ja auch Post-Processing da es NACH dem Rastering/Rendering/Shading schritten kommt wo das "generierte Bild" optimiert wird durch Anwendung von diversen Verfahren, Filtern (wie AA), usw.
Normalerweise haben BISLANG aber Post-Processing Verfahren nicht auf motion vectors oder z-buffer info benutzt.

Ohne Camera Jitter beim Rendering hätten die Motion Vectors aller Bilder übrigens den Betrag 0, wenn der Nutzer die Kamera eine Weile nicht bewegt. Damit wäre Supersampling bei stehender Kamera unmöglich.

Auch das TAA nutzt das schon, und da würde KEIN MENSCH Behaupten das das Sub-Pixel Jittering einen Teil der Rendering sequenz darstellt.

Nochmal, es handelt sich um Camera Jitter! Der wird beim Rendering auf die Projektionsmatrix angewendet. Im Prinzip ist sogar das Gegenteil der Fall. Der Jitter wird nicht im Post-Processing angewendet, sondern er muss bei der Rekonstruktion sogar wieder herausgerechnet werden (dejittter) damit die rekonstruierten Bilder nicht "wackeln".

 

[Grestorn]

Ich glaube, das Verständnisproblem bei @Iscaran liegt auch daran, dass er den Grund für das Jittern noch nicht ganz nachvollziehen kann.

Das Problem bei der Rasterisierung besteht generell darin, dass Details auf der Strecke bleiben, wenn sie feiner sind als ein Renderpixel. Denn entweder das Detail landet zufällig auf einem Renderpixel – dann wird es sichtbar – oder eben nicht. Das hängt von der Position des Details relativ zum gerenderten Pixel (im Bildkoordinaten) ab.

Das ist der Grund, warum feine Linien, wie Stromleitungen, unterbrochen dargestellt werden und bei Bewegung flimmern: Je nach *Kamera*position sind einzelne Pixel mal sichtbar und mal nicht.

Das ist letztlich auch der Grund für Aliasing.

Und das Jittering der Kamera (danke, Nolag, für das Einbringen des Begriffs Kamera an der Stelle) um Subpixel wird das eben statistisch ausgeglichen. Irgendwann landet jedes Detail auch mal auf einen Renderpixel und kann damit berücksichtigt werden.

Jittering NACH dem Rendern macht null Sinn, denn dann sind die Details ja schon verloren. Man jittert die Koordinaten der zu rendernden Polygone (der ganzen Szene), denn nur so kann man die Details, die sonst beim Rasterisieren verloren gehen, wieder erfassen.

Genau das ist die ganze Magie hinter temporalem Anti-Aliasing. Die Herausforderung, die Mengen an Daten sinnvoll zu verrechnen, bleibt natürlich, und da unterscheiden sich die Verfahren eben deutlich.

 

[Iscaran]

@Nolag:

Ah danke, das hab ich in der Tat falsch verstanden. Aber der Jitter (und auch der Sub-Pixel Jitter) ist ja schon seit TAA im Rendering. (nicht erst seit DLSS)...insofern ist das kein Alleinstellungsmerkmal von DLSS.

Danke fürs Nachbohren.

Und TAA ist damit auch kein reiner Postprocessing Filter (da es implizit auch das Rendering verändert). Was ich bislang annahm. :-)

So oder so ist auch DLSS aber nichts anderes als TAA (mit scaling factor und AI NN für die Optimierung der Bildrekonstruktion es greift null-komma-null anders ins "rendering" ein wie ein herkömmliches TAA.

 

[Grestorn]

Ah danke, das hab ich in der Tat falsch verstanden. Aber der Jitter (und auch der Sub-Pixel Jitter) ist ja schon seit TAA im Rendering. (nicht erst seit DLSS)...insofern ist das kein Alleinstellungsmerkmal von DLSS.

Das hat ja auch nie irgendwer behauptet. Das Jittering ist ein altes Prinzip, und das habe ich gefühlt bereits 100x geschrieben.

Aber statt das mal zu lesen, bist Du ja gegen mich auf die Palme gegangen (und hast mich wohl auch auf Ignore).

Your loss.

 

[wGuardian]

Ich bin dann doch überrascht, dass ich bei jedem Video in der größten Abstimmungsgruppe gelandet bin. Dann gehe ich jetzt total zufrieden ins Bett. 🤠

 

[Bccc1]

@Wolfgang wie hier schon mehrfach erwähnt wurde, sollten zukünftige Umfragen mehr Wert darauf legen, das die Teilnehmer sich die Inhalte korrekt angesehen haben. Bezogen auf den Zoomfaktor wäre ich sehr stark für eine technische Lösung statt oder zusätzlich zu einer schriftlichen Anleitung. Wenn man sich die Kommentare hier durchliest, sieht man ja leider, das einige die erste Seite nicht vollständig gelesen und verstanden haben.

Ich hab versucht über js in der Konsole den Zoom zu ändern, aber das geht nicht so einfach, weil ihr ICAT über ein iframe ladet und www.computerbase.de zu media.computerbase.de ein cross orgin Zugriff wäre -> CORS verhindert, das ich den iframe content manipulieren kann.
Da ihr aber das ICAT html unter media.computerbase.de selber hostet, müsste es euch doch möglich sein, eigenes javascript in diese html Dateien einzufügen.

Mit diesem Script Block zusätzlich im html müsste das funktionieren:

    <script>
        window.addEventListener('load', (event) => {
            // warte eine Sekunde mit der Änderung,
            // da die icat app selber zum 'load' Zeitpunkt nicht fertig initialisiert ist,
            // und den Wert sonst überschreiben würde
            setTimeout(() => {
                let icatApp = document.querySelector('icat-app')
                let mediaControls = icatApp.shadowRoot.querySelector('media-controls')
                let zoomInputElement = mediaControls.shadowRoot.querySelector('#zoom-input')
                let zoomInput = zoomInputElement.shadowRoot.querySelector('#input')
                zoomInput.value = 100
                let inputEvent = new Event('input', { bubbles: true });
                zoomInput.dispatchEvent(inputEvent);
            }, 1000);
        })
    </script>

Ich hab's im Firefox für das Anno Video, also für https://media.computerbase.de/icat/218-513f4f7d/index.html via Skriptüberschreibung ausprobiert, da geht's. Andere Browser oder im eingebetteten Kontext hab ich nicht getestet.

Ist nicht die eleganteste Lösung und nervige Handarbeit auf eurer Seite, jede HTML Datei zu bearbeiten, aber besser als nichts. Vielleicht findet ihr ja noch was besseres.

Noch ne Idee: Ihr könntet im js via window.devicePixelRatio prüfen, ob Skalierung aktiv ist. Wenn da was anderes als 1 rauskommt, eine dicke Warnung anzeigen, die erklärt, warum das, was man gerade sieht, nicht repräsentativ ist.

 

[Fika]

Kann man den Zoom dann nicht auch gleich noch korrigieren, so damit 100 immer nativ entspricht?
100 % = Logische/Videopixel = Physische/Monitorpixel

Sowie Zoomstufen kleiner 100 sperren.

 

[Bccc1]

Gute Idee, aber ein bisschen aufwändiger umzusetzen. Mein Code ist so gedacht, das man den eigentlichen ICAT code nicht anfassen muss, sondern quasi von außen ein User imitiert, der in das Skalierungsfeld ein Wert eingibt. Den korrekten Zoom für 1:1 mapping zu errechnen und den statt 100% zu setzten wäre noch recht simpel. Die Zahl 100 im Player anders zu interpretieren, so dass es 1:1 mapping entspricht wäre dagegen eine Anpassung tiefer im Player code. Auf den ersten Blick würde ich sagen, sollte machbar sein, aber zumindest für mich nicht mal so eben gemacht.
Was aber halbwegs gut gehen sollte, ist den minZoom auf 100/devicePixelRatio zu setzten. Das ist zumindest während der Initialisierung eine einfach zu konfigurierende Variable. Würde dann aber nicht darauf reagieren, wenn man nachträglich den Browser Zoom ändert. D.h. man öffnet die Seite mit 100% Zoom auf einem FHD Display, merkt, das man das Bild nicht vollständig sehen kann und auch nicht rauszoomen kann und zoomt daher mit dem browser auf 25% und sieht dann doch das ganze Bild samt Skalierungsartefakten.
Daher vielleicht lieber ein code snippet, das bei jeder Änderung des zooms prüft, ob der neue Zoom Wert >= 100/devicePixelRatio ist und wenn nicht, ihn darauf zurücksetzt.

 

[Tevur]

5 nach 12!
Wasissnnu?

 

[rollmoped]

Wie spannend

 

[Fika]

Wasissnnu?

Abstimmen vorbei. 🤷‍♂️

Mit der Auflösung lässt man uns noch weiter zappeln.🤣