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

    Also: Der Scaler verwendet immer nur unsigned char, die ganze Rechnerei mit (x / ((MaxRGB + 1) / 256)) dient nur dazu, die von *magick gelieferten 8 oder 16-Bit-Werte auf 8-Bit zu wandeln (das expandiert zu nichts oder " >> 8" bei der Optimierung im gcc, MaxRGB sollte eine Konstante sein). Ein cast auf unsigned char macht an diesen sowieso immer 8-bittigen Werten nichts kaputt, warum man den cast anscheinend manchmal braucht verstehe ich auch nicht. Aber C++ ist auch nicht meine Muttersprache...


    Gruss,
    S:oren

    Also sollte da dann einfach

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


    stehen und alles ist gut, oder?


    Lars.

    louis:
    Wenn du möchtest, dann kann ich heute Abend die ganze Diskussion um dieses Problem in einen eigenen Thread auslagern.


    EDIT: getan... leider nur in VDR-News, da ich in VDR-Plugins keine Mod-Rechte habe. Ich werde einen anderen Moderator bitten, den Thread noch zu verschieben.


    Lars.

    Zitat von louis

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


    Zitat von mini73

    Was hat den MaxRGB für einen Typ?


    Der variiert, je nachdem wie die Quantum-Einstellungen von imagemagick gesetzt sind:

    Zitat

    The maximum value that a Quantum can attain is specified by a constant value represented by the MaxRGB define, which is itself determined by the number of bits in a Quantum. The QuantumDepth build option determines the number of bits in a Quantum.


    Wenn ich zusätzlich zu -DMAGICKCORE_QUANTUM_DEPTH=8 auch noch -DMAGICKCORE_HDRI_ENABLE=0 erzwinge, baut es ohne Anpassungen, aber der VDR schmiert dann beim Starten ab - vermutlich müsste ich diese Änderung für alle Plugins, die Imagemagick nutzen wiederholen, weil die sonst mit unterschiedlichen MaxRGB-Werten arbeiten - das probier ich mal heute Abend.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Nein, du solltest diese Werte nicht setzen müssen. Ist ImageMagick nicht auch mit diesen übersetzt? Die darf das Plugin nur als gegeben hinnehmen, nicht ändern.
    Sprich, du müsstest dann auch ImageMagick neu übersetzen, trotzdem dürfen die Plugin-Makefiles diese Werte nur auslesen, aber nicht ändern (wenn ich das jetzt richtig verstehe).
    Probiere es einfach mal mit dem cast, dann sollte es egal sein, wie ImageMagick konfiguriert ist.


    Lars.

    Zitat von mini73

    Probiere es einfach mal mit dem cast, dann sollte es egal sein, wie ImageMagick konfiguriert ist.

    Das hat ja funktioniert - mich hätte nur interessiert, ob es möglich ist das mit imagemagick direkt auf 8 Bit pro Kanal festzunageln, weil das ja eigentlich effizienter sein sollte (und eventuell mein Raspberry Pi davon profitieren könnte) - aber so klappt es nicht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ok, wenn du imagemagick umkonfigurierst und neu baust und alles was das benutzt auch neu übersetzt, müsste es möglich sein.
    Ist ja quasi eine configure-Anweisung oder so, richtig?


    Ich würde aber erwarten, dass der Code nicht schneller wird, sondern evtl. weniger Speicher verbraucht.


    Lars.

    Moin,


    so, ich habe den Fix mit dem cast jetzt mal ins Git aufgenommen...hoffen wir mal dass es jetzt so passt :)


    Lars: wäre nett wenn du die ganze Diskussion bzgl. dieses Problems in einen eigenen Thread auslagern könntest...danke!


    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden