Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Jun 07, 2024 19:48

Foren-Übersicht » Programmierung » Shader
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 17 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: Mi Jun 16, 2010 09:42 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Serv,

ich bastel gerade einen YUV -> RGB GLSL Fragment Shader und
erziele fortschritte.
Genauer gesagt scheint habe ich es endlich geschaft ein RGB bild
aus den YUV daten zu generieren, aber leider ist die Auflösung zu niedrig.

Es wirkt sehr pixelig. Hier sind screenshots wie es aussehen soll und wie es mit dem Shader aussieht:

Original RGB24:
Bild

GLSL YUY2 Shader:
Bild

Ich habe keine idee warum das so pixelig rauskommt, evtl. ist irgendwo ein Fehler seh ihn aber nicht ?

Vielleicht helfen die folgende Hinweise:

- Die YUV Daten sind in einer 320x480 RGBA GL Texture gespeichert und im format GL_RGBA, GL_BGRA angegeben.
- Gezeichnet wird ein Quad in der aktuellen Auflösung des Clientrects (Fenster) mit den Texture Koordinaten 0-0, 640-480.
- Projection ist natürlich ortho.
- Bevor der Shader aktiviert wird, wird die texture ganz normal gebunden
- Die texture ist als GL_TEXTURE_RECTANGLE target gebunden. Defakto nutze ich auch sampler2DRect als uniform variable für meine texture.

Hier ist der fragment shader code:

Code:
// Unsere YUV RGBA Texture
uniform sampler2DRect yuvTexture;

// Texture dimension, notwendig weil daten Bottom orientiert sind.
uniform float TextureDimH;

const float y_const = 0.0625;
const float vu_const = 0.5;
 
// Yuv -> RGB Berechnung
vec4 YUVToRGBA(float y, float u, float v)
{
  vec4 rgbcolor;
  rgbcolor.r = (1.164 * (y - y_const)) + (2.018 * (v - vu_const));
  rgbcolor.g = (1.164 * (y - y_const)) - (0.813 * (u - vu_const)) - (0.391 * (v - vu_const));
  rgbcolor.b = (1.164 * (y - y_const)) + (1.596 * (u - vu_const));
  rgbcolor.a = 0;
  return rgbcolor;
}

void main(void)
{
  float nx = gl_TexCoord[0].x/2;
  float ny = TextureDimH - gl_TexCoord[0].y;

  // Fische die y-u-y-v daten aus den RGBA farben
  float y1 = texture2DRect(yuvTexture, vec2(nx, ny)).r;
  float u = texture2DRect(yuvTexture, vec2(nx, ny)).g;
  float y2 = texture2DRect(yuvTexture, vec2(nx, ny)).b;
  float v = texture2DRect(yuvTexture, vec2(nx, ny)).a;
 
  // Jeder erste pixel wird mit y1 ausgeben 
  // Jeder zweite pixel wird mit y2 ausgeben
  // Funktioniert nicht!
  vec4 rgb;
  if (mod(gl_FragCoord.x, 2.0) == 0)
  {                   
    rgb = YUVToRGBA(y1, u, v);
  }
  else
  {
    rgb = YUVToRGBA(y2, u, v);
  }
  gl_FragColor = rgb;   
 
  /*
  // Mache aus 2 yuv werte 1 yuv wert
  float yanteil = (y1 + y2) * 0.5;
 
  // Berechne RGBA aus yuv wert
  gl_FragColor = YUVToRGBA(yanteil, u, v);
  */
}


Ich bekomme mit 4 byte (RGBA) 2 Pixel als endergebnis, kann aber nur 1 Pixel ausgeben.
Möglicherweise steckt hier der Wurm, aber ich habe keine idee, wie ich den 2 pixel auch mit ausgeben kann.

Das modulo fragcoord 2 funktioniert nicht, Tip hatte ich von Aya.
Das habe ich getestet, indem ich die resultierende farbe im If und else block verändert habe.
Defakto wird immer Else ausgegeben.

Bitte um Hilfe.

Wenn es hilft poste ich auch gern den kompletten Lazarus Source.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 10:08 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Code:
// Fische die y-u-y-v daten aus den RGBA farben
float y1 = texture2DRect(yuvTexture, vec2(nx, ny)).r;
float u = texture2DRect(yuvTexture, vec2(nx, ny)).g;
float y2 = texture2DRect(yuvTexture, vec2(nx, ny)).b;
float v = texture2DRect(yuvTexture, vec2(nx, ny)).a;

Nicht verantwortlich für dein Problem.....aber Performance-Technisch.....du machst hier 4 mal die gleiche Texturanfrage. Zwar gibt es einen Cache, trotzdem ist das recht lahm. Besser so:
Code:
vec4 tex = texture2DRect(yuvTexture, vec2(nx, ny));
float y1 = tex.r
float u = tex.g;
float y2 = tex.b;
float v = tex.a;


Zu dem modulo kann ich nur sagen, das müsste eigentlich funktionieren ;)

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 10:14 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Versuche ggf. mal erst zu runden vor dem Modulo:
Code:
int x = int(gl_FragCoord.x + 0.5);
if (mod(x, 2) == 0) { ...

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 13:16 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Coolcat hat geschrieben:
Code:
// Fische die y-u-y-v daten aus den RGBA farben
float y1 = texture2DRect(yuvTexture, vec2(nx, ny)).r;
float u = texture2DRect(yuvTexture, vec2(nx, ny)).g;
float y2 = texture2DRect(yuvTexture, vec2(nx, ny)).b;
float v = texture2DRect(yuvTexture, vec2(nx, ny)).a;

Nicht verantwortlich für dein Problem.....aber Performance-Technisch.....du machst hier 4 mal die gleiche Texturanfrage. Zwar gibt es einen Cache, trotzdem ist das recht lahm. Besser so:
Code:
vec4 tex = texture2DRect(yuvTexture, vec2(nx, ny));
float y1 = tex.r
float u = tex.g;
float y2 = tex.b;
float v = tex.a;


Zu dem modulo kann ich nur sagen, das müsste eigentlich funktionieren ;)


Danke für die tips, hab ich geändert.

Coolcat hat geschrieben:
Versuche ggf. mal erst zu runden vor dem Modulo:
Code:
int x = int(gl_FragCoord.x + 0.5);
if (mod(x, 2) == 0) { ...


Ist ebenfalls geändert und es funktioniert zumindest nun das modulo.

Aber es stimmt leider immer noch nicht :-(

Das ergebnis sieht so ziemlich genau aus, wie ohne modulo.

Ich hab das gefühl das die position des fragments irgendwie nicht passt ?

Shader:

Code:
// Unsere YUV RGBA Texture
uniform sampler2DRect yuvTexture;

// Texture dimension, notwendig weil daten Bottom orientiert sind.
uniform float TextureDimH;

const float y_const = 0.0625;
const float vu_const = 0.5;
 
// Yuv -> RGB Berechnung
vec4 YUVToRGBA(float y, float u, float v)
{
  vec4 rgbcolor;
  rgbcolor.r = (1.164 * (y - y_const)) + (2.018 * (v - vu_const));
  rgbcolor.g = (1.164 * (y - y_const)) - (0.813 * (u - vu_const)) - (0.391 * (v - vu_const));
  rgbcolor.b = (1.164 * (y - y_const)) + (1.596 * (u - vu_const));
  rgbcolor.a = 0.0;
  return rgbcolor;
}

void main(void)
{
  float nx = gl_TexCoord[0].x/2.0;
  float ny = TextureDimH - gl_TexCoord[0].y;

  // Fische die y-u-y-v daten aus den RGBA farben
  vec4 texel = texture2DRect(yuvTexture, vec2(nx, ny));
  float y1 = texel.r;
  float u = texel.g;
  float y2 = texel.b;
  float v = texel.a;
 
  int x = int(gl_FragCoord.x);
 
  // Jeder erste pixel wird mit y1 ausgeben 
  // Jeder zweite pixel wird mit y2 ausgeben
  vec4 rgb;
  if (mod(x, 2) == 0)
  {     
    rgb = YUVToRGBA(y2, u, v);
  }
  else
  {
    rgb = YUVToRGBA(y1, u, v);
  }
  gl_FragColor = rgb;   
 
  /*
  // Mache aus 2 yuv werte 1 yuv wert
  float yanteil = (y1 + y2) * 0.5;
 
  // Berechne RGBA aus yuv wert
  gl_FragColor = YUVToRGBA(yanteil, u, v);
  */
}


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 15:15 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Ich hab mal ein C Beispiel einer GLSL YUV-RGB Konvertierung gefunden.
Dies nutzt aber 3 Luminance Texturen und nicht 1 RGBA wie ich.

Evtl. könnte das helfen.
Die schreiben im Kommentar das es einfach sei, das für eine Single texture zum laufen zu kriegen.
Nur find ich das definitiv nicht einfach.

http://fourcc.org/source/YUV420P-OpenGL-GLSLang.c

Habe auch nochmal den Speicher überprüft.
Die 320 x 480 als RGBA Texture ist exakt so gross wie die YUV quell daten.
Somit passen zumindest die daten. Das kann man also ausschliesen.

Hier mein testprogramm als Binary mit Shader und Sampledateien:

http://xenorate.com/tl_files/dgl/GL%20Renderer%20Bin.zip
(Läuft nur unter windows)

Mit leertaste kann man die Sample formate durchschalten.
Durch das umschalten, wird die aktuelle Texture zerstört und durch eine neue ersetzt.
Der Inhalt wird direkt aus der jeweiligen Sample datei gelesen.

Mit F kann man den Texturefilter von Nearest (Off) auf Linear (Bilinear) umstellen.

Der Shader ist nur für Sample YUY2 definiert, kann also nur damit genutzt werden.
Der Shader source liegt im glsl ordner. Verwendet wird nur "yuv.frag".

Aufbau der sample datei (Nur zur info):

- VideoInfoHeader
- Directshow Subtype (TGUID) z.b. MEDIASUBTYPE_RGB24.
- Daten länge (Integer)
- Der rest sind die YUV daten.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 16:37 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Aug 18, 2007 18:47
Beiträge: 694
Wohnort: Köln
Programmiersprache: Java
hi Finalspace,

ändere doch mal die Texturkoordinaten auf 320, 480 in der Anwendung. Also ohne die Division im Shader.
Btw: Müsste man nicht auch 0,480 und 320,0 angeben können? Dadurch sollte doch die Textur direkt gespiegelt sein. TextureDimH bräuchtest du dann auch nicht mehr.

Ausserdem wirft er bei mir folgende Warnings aus:
Dateianhang:
finalspace_glrenderer_warnings.jpg
finalspace_glrenderer_warnings.jpg [ 50.9 KiB | 8770-mal betrachtet ]


EDIT:
Ich glaub ich habs:
Du darfst nicht den Modulo von FragCoord.x nehmen...du musst die Texturkoordinate nehmen.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.


Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 18:32 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
damadmax hat geschrieben:
hi Finalspace,

ändere doch mal die Texturkoordinaten auf 320, 480 in der Anwendung. Also ohne die Division im Shader.
Btw: Müsste man nicht auch 0,480 und 320,0 angeben können? Dadurch sollte doch die Textur direkt gespiegelt sein. TextureDimH bräuchtest du dann auch nicht mehr.


Habe ich probiert, die Texture ist dann nur noch in der hälfte sichtbar und sieht echt merkwürdig aus.
Das mit dem Spiegeln könnte man machen, aber ich mach das lieber im Fragment Shader, die eine Integer Operation reist es denk ich nicht raus oder ?

damadmax hat geschrieben:
Ausserdem wirft er bei mir folgende Warnings aus:
Dateianhang:
finalspace_glrenderer_warnings.jpg



Komisch, auf meinem notebook ATI X1400 mit 128 MB habe ich keine Warnings
Ich zeige nämlich nur die Messagebox an, wenn ein error,failed oder warn string vorhanden ist.

Was auch richtig merkwürdig ist, das wenn ich die #version 140 ganz oben definiere,
dann geht der shader gar nicht mehr (Version wird nicht unterstützt).

Ansich tut aber der Shader, weil vor allem texture rects ja gehen O_o

Ich probier das auf meinem standrechner mal aus. NV 8800 GT.

damadmax hat geschrieben:
EDIT:
Ich glaub ich habs:
Du darfst nicht den Modulo von FragCoord.x nehmen...du musst die Texturkoordinate nehmen.


Probiert, gleiches ergebnis.
Ich hab nx und direkt die texture korrdinate probiert :-(


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 18:52 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Aug 18, 2007 18:47
Beiträge: 694
Wohnort: Köln
Programmiersprache: Java
Sind die Texturkoordinaten bei allen Formaten gleich?

Habe testweise mal den Cast auf int rausgenommen. Hatte sonst einen vertikalen Interlace-Effekt wenn man das Fenster größer macht.

Bei mir geht übrigens der Modulo auch mit nem float.
Code:
if (mod(nx, 2.0) == 0.0) { ...


EDIT:
Grafikkarte ist eine 8800 GTS 512

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.


Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 18:56 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Jop die texcoords sind für alle formate gleich.
Jediglich ist die Texturegrösse in der Breite bei YUY2 der Hälfte reduziert.

Aber genau diesen effekt meine ich, diesen interlace effekt.
Diesen bekomm ich einfach nicht weg :-(

Auch mit änderung des modulos :-(
Im gegenteil, der if part wird nie verwendet.
Kannst ja schnell so prüfen:

Code:
  // Jeder erste pixel wird mit y1 ausgeben 
  // Jeder zweite pixel wird mit y2 ausgeben
  vec4 rgb;
  if (mod(nx, 2.0) == 0.0)
  {     
    rgb = vec4(1.0,0.0,0.0,0.0);
    //rgb = YUVToRGBA(y2, u, v);
  }
  else
  {
    rgb = YUVToRGBA(y1, u, v);
  }
  gl_FragColor = rgb;   


Ach es ist zum mäuse melken.

Das ist bestimmt irgendwas triviales.


Achja, bekomme nun auch die Warnings bei der 8800 GT.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 20:13 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Aug 18, 2007 18:47
Beiträge: 694
Wohnort: Köln
Programmiersprache: Java
.....nachdem ich die Sample-Datei in Photoshop geladen hab, wusste ich endlich warum die Texel abwechselnd gezeichnet werden müssen :)

Der einzelne Texturelookup scheint mir dabei nicht ganz geheuer.
Habe mal testweise zwei weitere Lookups reingemacht:

Code:
  vec4 texel = texture2DRect(yuvTexture, uv);
  vec4 texelLeft = texture2DRect(yuvTexture, uv + vec2(-0.25,0.0));
  vec4 texelRight = texture2DRect(yuvTexture, uv + vec2(0.25,0.0));
  float y1 = texelLeft.r;
  float u = texel.g;
  float y2 = texelRight.b;
  float v = texel.a;

  int x = int(nx) ;
  // Jeder erste pixel wird mit y1 ausgeben 
  // Jeder zweite pixel wird mit y2 ausgeben
  vec4 rgb;
  if (mod(x, 2) == 0)
  {     
    rgb = YUVToRGBA(y2, u, v);
  }
  else
  {
    rgb = YUVToRGBA(y1, u, v);
  }



Also 1/4 Texel in jede Richtung.
Sieht auf jeden fall schonmal besser aus.

Wobei ich aber immer noch das beste Ergebnis mit dem von dir auskommentierten Teil gemacht hab:
Code:
float yanteil = (y1 + y2) * 0.5;

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.


Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jun 16, 2010 20:44 
Offline
DGL Member

Registriert: Do Jun 28, 2007 17:58
Beiträge: 193
Programmiersprache: Pascal, C
Das Problem ist allgemein, dass die YUYV oder YUV422-Daten für einen Pixel Werte für zwei RGB-Pixel beinhalten. Der Interpolator in texture2DRect weiß das jedoch nicht, und schmeißt die Pixelwerte natürlich durcheinander: Einzige Möglichkeit: Selbst richtig interpolieren.

Siehe auch: http://en.wikipedia.org/wiki/YUV#Y.27UV422

Nach ein bisschen Überlegen bin ich auf folgenden Code gekommem: Das Ergebnis ist IMHO auf jeden Fall schon mal besser als das von deinem Code aus dem Beispielprogramm und sollte in die "richtige Richtung" weisen. Für mehr hatte ich jetzt auf die Schnelle keine Zeit:
Code:
void main(void)
{
  float ny = TextureDimH - gl_TexCoord[0].y;
  float nx = gl_TexCoord[0].x / 2.0;

  vec4 texel = texture2DRect(yuvTexture, vec2(nx, ny));
  float pos = fract(nx);
  float y = texel.r * (pos) + texel.b * (1 - pos);
  gl_FragColor = YUVToRGBA(y, texel.g, texel.a);
}

Störend sind hier die Übergänge von fract(nx) von 0.999 nach 0.0.

Gibst du mal mittels
Code:
gl_FragColor = vec4(fract(nx), 0.0, 0.0, 0.0);

die Verteilung von "pos" aus und vergrößerst/verkleinerst das Fenster, so siehst du, dass der von dir eingestellte Texturfilter momentan auch noch einiges kaputtmacht. Auch solltest du mal die einzelnen Y/U/V Werte einzeln als RGB ausgeben, dann siehst du direkt, welcher der Werte die "Pixeligkeit" verursacht.

Allgemein ist mir aufgefallen: Shadercode der Integer oder "If" braucht, benutzt oftmals den falschen Ansatz. Es gibt weder feste Pixel noch sollten Sprünge in Betracht gezogen werden, da letztere den Shadercode sehr verlangsamen und in diesem Fall "feste" Pixel vorraussetzen.

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Jun 17, 2010 16:40 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Gibt es denn eine möglichkeit wie ich einen Fragment Shader debuggen kann ?

Also z.b. das ich weiss welche texcoords über den fragment shader reinkommen, wie die YUV daten aussehen.
Alles damit ich überprüfen kann, was schief läuft.

Gibt es einen weg, wie ich daten irgendwie ausgeben kann ?

Weil es wohl doch nicht so einfach ist, diese YUV-RGB Konvertierung zu machen.

Ich denke ich werd vorerst wohl mit meiner Software Lösung leben müssen, die ja gut funktioniert,
aber denk ich bei HD Videos wieder einbricht :-(

Das projekt lade ich die nächsten tage sofern ich zeit finde mal inkl. source hoch.
Aktuell ist meine Zeit leider begrenzt, ich muss das Kinderzimmer noch fertigmachen :D


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Jun 17, 2010 17:55 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Zitat:
Gibt es denn eine möglichkeit wie ich einen Fragment Shader debuggen kann ?

Naja, du die Ausgabe des Fragmentshaders (Farbe) zum debuggen benutzen. Für Texturkoordinaten und Normalen reicht das völlig. Es ist natürlich hilfreich wenn du den Shader möglichst bequem neu laden kannst....z.B. ein Tastendruck und sämtliche Shader werden neu geladen ohne das du dein Programm neustarten musst.

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Jun 17, 2010 18:18 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Coolcat hat geschrieben:
Zitat:
Gibt es denn eine möglichkeit wie ich einen Fragment Shader debuggen kann ?

Naja, du die Ausgabe des Fragmentshaders (Farbe) zum debuggen benutzen. Für Texturkoordinaten und Normalen reicht das völlig. Es ist natürlich hilfreich wenn du den Shader möglichst bequem neu laden kannst....z.B. ein Tastendruck und sämtliche Shader werden neu geladen ohne das du dein Programm neustarten musst.


Lustig genau das habe ich vorhin eingebaut :D

Mit G kann man die GLSL implementierung ein / ausschalten
Mit R kann man das sample inkl. Shader neu laden

Es gibt nun auch ein debug fenster inder man allerart von infos sehen kann.

Hab die zip durch ne neue ersetzt.

Es gibt nun auch neue sample dateien (q3 rulez).

Link ist der gleiche aber hier nochmal:

http://xenorate.com/tl_files/dgl/GL%20Renderer%20Bin.zip

Und hier ein paket von erstellten samples (Anime, Q3 und das alte text bild): (Bei bedarf einfach über die alten drüber kopieren)

http://xenorate.com/tl_files/dgl/samples.zip


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Jun 18, 2010 21:14 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
Yay es funktioniert und sieht 1 zu 1 so aus wie meine Software Dekodierung.

Das problem war die ganze Zeit das ich 2 Pixel per Fragment zeichnen wollte und
somit immer 1 pixel verloren ging mehr oder weniger. Dafür hatte hat ich immer Y1, U, Y2 und V (RGBA) gehabt.
Das hat dazu geführt, das man einen unschönen scanline effekt hatte.

Habe ein bischen im Internet Recherchiert, weil ich es doch irgendwie möglich sein muss,
das ich mit OpenGL beim Texture hochladen, die Daten anderst anordnern kann, so das ich nur noch ein Y wert habe.

Bin Fündig geworden und habe folgende Zeilen gefunden die mich gerettet haben:

Code:
    glTexImage2D(GL_TEXTURE_RECTANGLE,0,GL_RGBA8, W div 2, H,
               GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, UVtex);

    glTexImage2D(GL_TEXTURE_RECTANGLE, 0, GL_LUMINANCE_ALPHA, W, H, 0,
               GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE,Ytex);


Nachdem ich das eingebaut habe, habe ich mit den Shader rumexperimentiert und habe erstmal nur die zweite (Y) Texture versucht auf den Bildschirm zu bringen. Klappte wunderbar, rot musste ich einfach ausgeben, das war mein Y wert.

UV hatte ein weilchen gedauert bis ich herausgefunden habe was für auswirkung das GL_UNSIGNED_INT_8_8_8_8_REV tut.

Verstehen tu ich aber immernoch nicht was genau bei GL_UNSIGNED_INT_8_8_8_8_REV im Speicher passiert.
Dreht das einfach nur die Daten um ? Also von RGBA nach ABGR ? Wäre super wenn mir das jemand mal erklären könnte.

LUMINANCE_ALPHA ist klar, das sind 8 byte ingesamt (Luminance+Alpha) und somit werden immer nur 2er blöcke verwendet (R und A), wobei A nicht verwendet wird.

Andere frage:

Gibt es denn eine möglichkeit wie ich auf eine Farbe (Vec4) per Array drauf zugreifen kann ?
Also was ich meine das ich nicht angeben "mycolor.r" sondern "mycolor[0]" ?
Weil dann bräuchte ich nur einen Shader machen der für viele andere YUV formate auch funktioniert.
Das würde dann mittels offset funktionieren oder ?


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 17 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » Shader


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 12 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.013s | 16 Queries | GZIP : On ]