[skinnopacity 1.0.0] die ganze Scaler-Diskussion...

louis · 26. November 2013

@seahawk: laut imagemagick Doku haben die Pixelpacket Members (darunter auch opacity) abhängig von der gesetzten QuantumDepth unterschiedliche Typen. Bei QuantumDepth = 8 sind es unsigned char, bei QuantumDepth sind es unsigned short.

Womöglich ist bei dir QuantumDepth = 16 gesetzt...probier doch mal auf unsigned char zu casten:

Code

~(unsigned char)((pixels->opacity / ((MaxRGB + 1) / 256)))

Ciao Louis

louis · 26. November 2013

Um Verwirrungen mit Klammern zu vermeiden, hier nochmal der komplette Funktionsaufruf:

Code

scaler.PutSourcePixel(pixels->blue / ((MaxRGB + 1) / 256),
                                  pixels->green / ((MaxRGB + 1) / 256),
                                  pixels->red / ((MaxRGB + 1) / 256),
                                  ~((unsigned char)(pixels->opacity / ((MaxRGB + 1) / 256))));

louis · 26. November 2013

Alternativ kannst du auch im Makefile vom Plugin per

Code

DEFINES += -DMAGICKCORE_QUANTUM_DEPTH=16

bzw.

Code

DEFINES += -DMAGICKCORE_QUANTUM_DEPTH=8

die QuantumDepth setzen.

Ciao Louis

seahawk1986 · 26. November 2013

Ja er baut mit -DMAGICKCORE_QUANTUM_DEPTH=16

Mit deinem Lösungsvorschlag klappt es:

Diff

--- skin-nopacity/imagemagickwrapper.c  2013-11-26 10:22:43.436091880 +0100
+++ b/imagemagickwrapper.c      2013-11-26 10:23:25.981310477 +0100
@@ -37,7 +37,7 @@ cImage *cImageMagickWrapper::CreateImage
             scaler.PutSourcePixel(pixels->blue / ((MaxRGB + 1) / 256),
                                   pixels->green / ((MaxRGB + 1) / 256),
                                   pixels->red / ((MaxRGB + 1) / 256),
-                                  ~(pixels->opacity / ((MaxRGB + 1) / 256)));
+                                  ~((unsigned char)(pixels->opacity / ((MaxRGB + 1) / 256))));
         return image;
     }
     for (const void *pixels_end = &pixels[width*height]; pixels < pixels_end; ++pixels)

Alles anzeigen

louis · 26. November 2013

@seahawk: hm...und transparent ist auch transparent?

Ich bin mir nicht sicher, ob man durch den cast eventuell irgendwas kaputt macht...der Datentyp wird ja nicht umsonst bei DMAGICKCORE_QUANTUM_DEPTH=16 von unsigned char (8 Bit) auf unsigned short (16 Bit) geändert. Vielleicht kann da S:oren was zu sagen, ob man das problemlos so einbauen kann...alternativ könnte ich im Makefile von nOpacity auch hart

Code

DEFINES += -DMAGICKCORE_QUANTUM_DEPTH=8

setzen...hast du mal getestet ob es dann auch mit der ursprünglichen Version von S:oren klappt? Falls nein, könntest du bitte mal? Die Version wäre mir irgendwie sympathischer...

Ciao Louis

seahawk1986 · 26. November 2013

Zitat von louis

@seahawk: hm...und transparent ist auch transparent?

Jetzt schon

louis · 26. November 2013

@seahawk: Hast du mein edit gesehen?

seahawk1986 · 26. November 2013

Ja, aber offenbar hab ich noch nicht die richtige Stelle, um

Code

DEFINES += -DMAGICKCORE_QUANTUM_DEPTH=8

einzubauen - wenn ich das richtig sehe kommt die ursprüngliche Definition ja von pkg-config:

Code

$ pkg-config --cflags Magick++
-fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/ImageMagick-6

Und nur mit einem zusätzlichen DEFINES habe ich beide Werte drin:

Code

<Kommandozeile>:0:0: Warnung: »MAGICKCORE_QUANTUM_DEPTH« redefiniert [standardmäßig aktiviert]
<Kommandozeile>:0:0: Anmerkung: dies ist die Stelle der vorherigen Definition
g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"skinnopacity"' -DMAGICKCORE_QUANTUM_DEPTH=8 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/ImageMagick-6  -o imagemagickwrapper.o imagemagickwrapper.c
<Kommandozeile>:0:0: Warnung: »MAGICKCORE_QUANTUM_DEPTH« redefiniert [standardmäßig aktiviert]
<Kommandozeile>:0:0: Anmerkung: dies ist die Stelle der vorherigen Definition
imagemagickwrapper.c: In Elementfunktion »cImage* cImageMagickWrapper::CreateImage(int, int, bool)«:
imagemagickwrapper.c:40:75: Fehler: Argument falschen Typs für Bit-Komplement
                                   ~(pixels->opacity / ((MaxRGB + 1) / 256)));
                                                                           ^
Makefile:78: recipe for target 'imagemagickwrapper.o' failed
make: *** [imagemagickwrapper.o] Error 1
==> FEHLER: Ein Fehler geschah in build().
    Breche ab ...

Alles anzeigen

louis · 26. November 2013

Hmmm...da bin ich überfragt...das pkgcfg file von ImageMagick anzupassen kann ja auch nicht wirklich die Lösung sein...

mini73 · 26. November 2013

Moin!

Zitat von louis

sicherlich wäre es schick, wenn man in Plugins, die mit Graphiken arbeiten, ganz auf externe Bibliotheken verzichten und nur mit VDR Mitteln arbeiten könnte.

Zitat von louis

Wenn man in die cImage Klasse eine Option zum laden von Jpges / PNGs einbauen würde

Dann hab ich das wohl missverstanden. Gemeint war dann wohl, dass das Plugin auf die externe Lib verzichten soll und dafür der vdr diese einbindet, die er selbst aber gar nicht braucht...
Da finde ich es besser, wenn das Plugin die Abhängigkeit behält.

Lars.

mini73 · 26. November 2013

Muss dann nicht abhängig von der Konfiguration von "*Magick*" der Source mit #ifdef angepasst werden?
In der Art

Code

#if MAGICKCORE_QUANTUM_DEPTH == 16
(die Zeile mit unsigned short cast)
#elif MAGICKCORE_QUANTUM_DEPTH == 8
(die Zeile mit unsigned char cast)
#else
(Fehler melden)
#endif

MAGICKCORE_QUANTUM_DEPTH kann man nicht selbst definieren, das wird vom System vorgegeben.

Lars

louis · 26. November 2013

Nein ich habe das schon so gemeint...ich hatte ja geschrieben, dass ich keine Ahnung habe, wie komplex es wäre, einen Loader für PNG / JPEG selbst zu schreiben. Eine externe Lib im VDR ist sicherlich keine Option...da ist sie im Plugin b esser aufgehoben, da sind wir uns einig

Ciao Louis

seahawk1986 · 26. November 2013

Ich habe jetzt mal das ins Makefile eingebaut:

Diff

--- skin-nopacity/Makefile      2013-11-26 11:14:50.357623317 +0100
+++ b/Makefile  2013-11-26 11:15:29.030573987 +0100
@@ -54,7 +54,7 @@ SOFILE = libvdr-$(PLUGIN).so
 DEFINES += -DPLUGIN_NAME_I18N='"$(PLUGIN)"'


 ifeq ($(IMAGELIB), imagemagick)
-       INCLUDES += $(shell pkg-config --cflags Magick++)
+       INCLUDES += $(shell pkg-config --cflags Magick++ | sed 's/DMAGICKCORE_QUANTUM_DEPTH=16/DMAGICKCORE_QUANTUM_DEPTH=8/g')
        LIBS += $(shell pkg-config --libs Magick++)
 else ifeq ($(IMAGELIB), graphicsmagick)
        INCLUDES += $(shell pkg-config --cflags GraphicsMagick++)

Alles anzeigen

Aber es baut damit auch nicht:

Code

g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"skinnopacity"' -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=8 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=8 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=8 -I/usr/include/ImageMagick-6  -o imagemagickwrapper.o imagemagickwrapper.c
imagemagickwrapper.c: In Elementfunktion »cImage* cImageMagickWrapper::CreateImage(int, int, bool)«:
imagemagickwrapper.c:40:75: Fehler: Argument falschen Typs für Bit-Komplement
                                   ~(pixels->opacity / ((MaxRGB + 1) / 256)));
                                                                           ^
Makefile:76: recipe for target 'imagemagickwrapper.o' failed
make: *** [imagemagickwrapper.o] Error 1
==> FEHLER: Ein Fehler geschah in build().
    Breche ab ...

Scheint so als müsste man das mit dem unsigned char erzwingen, denn erst wenn ich zusätzlich den oben geposteten Patch einbaue klappt es - ob es Sinn macht bis zur Skalierung mit 16-Bit Kanälen zu rechnen weiß ich nicht...

louis · 26. November 2013

Zitat von mini73
Muss dann nicht abhängig von der Konfiguration von "*Magick*" der Source mit #ifdef angepasst werden?
In der Art
Code
#if MAGICKCORE_QUANTUM_DEPTH == 16
(die Zeile mit unsigned short cast)
#elif MAGICKCORE_QUANTUM_DEPTH == 8
(die Zeile mit unsigned char cast)
#else
(Fehler melden)
#endif
MAGICKCORE_QUANTUM_DEPTH kann man nicht selbst definieren, das wird vom System vorgegeben.

Ist das nicht unnötig? So wie ich es verstehe, liefert pixels->opacity einen unsigned char bei MAGICKCORE_QUANTUM_DEPTH=8 und einen unsigned short bei MAGICKCORE_QUANTUM_DEPTH=16. Bei MAGICKCORE_QUANTUM_DEPTH=8 macht der cast gar nix...bei MAGICKCORE_QUANTUM_DEPTH=16 zieht er entsprechend...bauen tuts ja in beiden Fällen.

Wenn ich mir es recht überlege kann der cast eigentlich nix kaputt machen...im Aufruf von PutSourcePixel werden die Parameter eh implizit auf unsigned char gecastet. Also kann da eigentlich nichts kaputt gehen. Ich baue das einfach so ein, wird schon passen

Ciao Louis

mini73 · 26. November 2013

Und wenn da Werte zurückgegeben werden, die größer als das Maximum von unsigned char sind?
Vielleicht sollte PutSourcePixel mit unsigned short arbeiten und dort entsprechend umrechnen, dann sind wir auf der sicheren Seite und du kannst immer auf unsigned short casten.

Lars.

louis · 26. November 2013

Zitat von mini73

Vielleicht sollte PutSourcePixel mit unsigned short arbeiten und dort entsprechend umrechnen, dann sind wir auf der sicheren Seite und du kannst immer auf unsigned short casten.

Aber der ~ Operator verlangt doch anscheinend zwingend einen unsigned char?!

Ciao Louis

seahawk1986 · 26. November 2013

Sicher, dass der nicht einfach übereinstimmende Datentypen will?
BTW: Was ist denn die maximale Farbtiefe mit der das VDR-OSD umgehen kann? Hat Klaus im VDR wirklich eine Unterstützung für 16 Bit pro Farbkanal eingebaut oder wird das nicht sowieso alles auf 8 Bit pro RGBA-Kanal normiert?

louis · 26. November 2013

Hi,

Zitat von seahawk1986

Sicher, dass der nicht einfach übereinstimmende Datentypen will?

Also deine Fehlermeldung

Code

imagemagickwrapper.c:40:75: Fehler: Argument falschen Typs für Bit-Komplement
                                   ~(pixels->opacity / ((MaxRGB + 1) / 256)));

scheint mir doch eindeutig...der Fehler kommt nicht vom Funktionsaufruf von PutSourcePixel sondern vom falschen Datentypen für den ~ Operator.

Zitat von seahawk1986

BTW: Was ist denn die maximale Farbtiefe mit der das VDR-OSD umgehen kann? Hat Klaus im VDR wirklich eine Unterstützung für 16 Bit pro Farbkanal eingebaut oder wird das nicht sowieso alles auf 8 Bit pro RGBA-Kanal normiert?

Das VDR OSD kann mit 32 Bit Farbtiefe umgehen, also pro Wert (ARGB) jeweils 8 Bit. Also macht eine Farbtiefe von 16 Bit pro Kanal in *magick nicht so wirklich Sinn...

Ciao Louis

mini73 · 26. November 2013

Zitat von louis

Aber der ~ Operator verlangt doch anscheinend zwingend einen unsigned char?!

Nein, den kann ich mit allen Integergrößen benutzen, sonst wäre er sehr nutzlos.

Lars.

louis · 26. November 2013

Zitat von mini73

Nein, den kann ich mit allen Integergrößen benutzen, sonst wäre er sehr nutzlos.

Lars.

Dann ist die Compilermeldung aber Müll...und dass mein Vorschlag mit dem Cast funktioniert verstehe ich dann auch nicht mehr

Ciao Louis

[skinnopacity 1.0.0] die ganze Scaler-Diskussion...

Jetzt mitmachen!

Teilen