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

Hi S:oren,

interessant...klar dass ein guter Algorithmus das wesentliche bei der Sache ist. Hast du auch mal mit GraphicsMagick getestet, das wird ja mittlerweile auch unterstützt...musst du im Makefile nur angeben.

Wenn der Patch nicht zu komplex ist, würde ich mir den sicherlich mal anschauen...

Ciao Louis

Hi S:oren,

Wow, abgefahren...vielen Dank! Ich habe den Patch eben mal getestet, die skalierten Icons und Logos schauen definitiv ein gutes Stück besser aus...und schneller ist es auch Ich habe den Patch gleich mal ins Git aufgenommen...super Sache

DIe aufgehübschten Graphiken von Copperhead sind jetzt auch im Git...schick

Ciao Louis

Letztlich nutzt auch *magick die libpng und *magick wird ja auch genutzt um z.B. Bilder übereinanderzulegen.

Andererseits hat aber auch der VDR einige Funktionen zur Bildverarbeitung. Ein Scaler scheint mir da auch dabei zu sein. Keine Ahnung wie gut der arbeitet. Interessant in dem Zusammenhang ist "osd.h" und "osd.c" aus dem VDR-Source. Ich kenne nur einen ziemlich kleinen Teil von nOpacity aber wenn es mit den VDR-eigenen Funktionen getan wäre, dann könnte man in der Tat libpng nutzen um ein "cBitmap" damit zu füllen und eventuell auf *magick ganz verzichten.

Wenn man nötige Änderungen an Grafikfunktionen dann direkt an Klaus schicken würde, dann würden zudem alle Themes davon profitieren.

Moin,

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.

Soweit ich das aber sehe, unterstützt der VDR nur ein Scaling für cBitmap, und Bitmaps sind für das TrueColor OSD nicht geeignet. Für cImage gibt es eine solche Funktion nicht. Wenn man in die cImage Klasse eine Option zum laden von Jpges / PNGs einbauen würde und dann noch eine Skalierfunktion...dann hätte man wohl alles was man braucht. Das Scaling könnte man über die von S:oren gelieferte Klasse machen...bräuchte man nur noch die Möglichkeit, Bilder zu laden. Keine Ahnung, mit welchem Aufwand man das ohne externe Bibliothek hinbekommen würde...das wäre wohl die Grundvoraussetzung für Klaus, sowas direkt in den VDR aufzunehmen.

Ciao Louis

Klaus wird keine weitere Abhängigkeit wollen. Die "libpng" wirst du also wohl in deinem Theme nutzen müssen. Ich wüsste aber nicht, was Klaus gegen einen Scaler in "cImage" haben sollte.

Hat sich da ein Fehler in dem Patch von S:oren eingeschlichen? Bei mir kompiliert es nur, wenn ich die Tilde lösche:

--- skin-nopacity/imagemagickwrapper.c  2013-11-26 09:45:03.207414557 +0100
+++ b/imagemagickwrapper.c      2013-11-26 09:49:10.359805336 +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)));
+                                  (pixels->opacity / ((MaxRGB + 1) / 256)));
         return image;
     }
     for (const void *pixels_end = &pixels[width*height]; pixels < pixels_end; ++pixels)

Die Tilde ist ein bitweises Nicht, egal, ob es da richtig ist oder nicht (kenne den Source nicht), was für ein Fehler kommt denn da?

Lars.

Hm...bei mir hat es problemlos auf meinen beiden VDRs (64Bit und 32Bit) mit dem aktuellen Git Stand gebaut...und die Tilde wird da nicht umsonst sein

Ist das Ergebnis denn korrekt ohne die Tilde? Sind die transparenten Bereiche auch wirklich transparent?

Ciao Louis

Zitat von louis

Ist das Ergebnis denn korrekt ohne die Tilde? Sind die transparenten Bereiche auch wirklich transparent?

Nein, die sind dann weiß...
Aber sonst bekomme ich diesen Fehler (ich baue gegen imagemagick):

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=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
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

Ich verstehe das Verzichten auf externe Libs nicht. Der vdr benutzt schon libjpeg, und ob ein Plugin noch zusätzlich libpng benutzt, ist doch eigentlich egal. Solange die Libs "vernünftig & stabil" sind (nicht so wie anscheinend ImageMagick), dann spricht da überhaupt nichts gegen. Wollt ihr wirklich für das Laden von jpeg/png eigene Routinen schreiben mit all dem, was dazugehört? Header parsen, Bild dekomprimieren und was auch immer alles dazu gehört, inkl. der möglichen Sicherheitsrisiken bei korrupten Dateien, die dann bei einem schlechten Parser zu einen Absturz führen können usw. usf.?

Ständig das Rad neu zu erfinden, nur um externe Abhängigkeiten zu vermeiden, ist doch so gar nicht der Unix-Weg, oder?

Wenn die Libs keinen vernünftigen Scaler bieten, ist es in meinen Augen ok, einen eigenen zu implementieren, der dann auf die internen Klassen zugeschnitten ist. Aber ansonsten...

Lars.

Was erwartet PutSourcePixel denn für Argumente?

Lars.

Huch, es hat doch niemand gesagt, dass er auf libpng verzichten möchte.

Es war nie die Rede von Verzicht auf externe Libraries. Ich hatte nur ein Problem mit Imagemagick. Dieses spezielle Problem habe ich ja mit Graphicsmagick gelöst

Es ging um die prinzipielle Idee bevorzugt auf Grafikfunktionen des VDR zurückzugreifen und diese ggf. um weitere "grundlegende Grafikoperationen" zu erweitern. So finde ich z.B. das der hier geschaffene Scaler wunderbar in die VDR-API passen würde. Damit würde das Theme-API an sich besser und auch andere Themes, bzw. deren Entwickler, könnten davon profitieren. Macht ja keinen Sinn, dass man den Scaler für ein anderes Theme komplett duplizieren müsste.

Selbstverständlich nutzt man "libpng" um eine PNG-Datei einzulesen. Die Frage, die im Raum stand, war eher ob diese direkt vom VDR genutzt werden sollte. Meine bescheidene Meinung ist, dass diese Abhängigkeit eher in das Theme gehört.

Die Funktion sieht so aus: http://projects.vdr-developer.…69b9ddbe2583b25baa93c#n25 - sollte ein unsigned char sein.