「Python」タグアーカイブ

screentone 2D and 3D

コミックブックアーカイブビューアを作っている筆者でありますが。
スクリーントーンの描写が変になる場合があることに困っていた。

Clutter(OpenGL ES) でリサイズしているのが悪いのかな？
と思い GdkPixbuf をリサイズしてからレンダリングで解決した。
よかったよかった、じゃない！もう少し調べよう。

Jトーン　網点（ドットパターン） J-00｜スクリーントーン 通販【ジェイトーン・ネットショッピング】

トーンは上記のサンプル画像をお借りしてと。

#!/usr/bin/env python3

import gi
gi.require_version("Gtk", "3.0")
gi.require_version("Clutter", "1.0")
gi.require_version("GtkClutter", "1.0")
from gi.repository import Gtk, Gdk, GdkPixbuf, Clutter, GtkClutter, Cogl

class DrawWindow(Gtk.Window):
    """
        2D and 3D View Check
    """
    def __init__(self):
        Gtk.Window.__init__(self)
        # tone
        self.pixbuf = GdkPixbuf.Pixbuf.new_from_file("tone.jpg")
        # cairo (2D)
        self.da = Gtk.DrawingArea()
        self.da.connect("draw", self.on_draw)
        # OpenGL ES (3D)
        embed = GtkClutter.Embed()
        stage = embed.get_stage()
        stage.set_background_color(Clutter.Color.new(0, 0, 0, 255))
        stage.connect("allocation-changed", self.on_stage_allocation_changed)
        self.actor = Clutter.Actor()
        image = Clutter.Image()
        image.set_data(
            self.pixbuf.get_pixels(),
            Cogl.PixelFormat.RGBA_8888 if self.pixbuf.get_has_alpha() else Cogl.PixelFormat.RGB_888,
            self.pixbuf.get_width(),
            self.pixbuf.get_height(),
            self.pixbuf.get_rowstride()
        )
        self.actor.set_content(image)
        stage.add_child(self.actor)
        # set
        vbox = Gtk.Box.new(Gtk.Orientation.VERTICAL, 0)
        vbox.pack_start(self.da, True, True, 0)
        vbox.pack_start(embed, True, True, 0)
        self.add(vbox)
        self.connect("delete-event", Gtk.main_quit)
        self.show_all()

    def on_stage_allocation_changed(self, actor, box, flags):
        aw = box.x2
        ah = box.y2
        w = self.pixbuf.get_width()
        h = self.pixbuf.get_height()
        if aw * h > ah * w:
            width = w * ah / h
            height = ah
            x = (aw - width) / 2
            y = 0
        else:
            width = aw
            height = h * aw / w
            x = 0
            y = (ah - height) / 2
        self.actor.set_size(width , height)
        self.actor.set_position(x, y)

    def on_draw(self, widget, cr):
        d_width = widget.get_allocated_width()
        d_height = widget.get_allocated_height()
        cr.set_source_rgb(0, 0, 0)
        cr.rectangle(0, 0, d_width, d_height)
        cr.fill()
        p_width = self.pixbuf.get_width()
        p_height = self.pixbuf.get_height()
        if (d_width * p_height) > (d_height * p_width):
            width = p_width * d_height / p_height
            height = d_height
        else:
            width = d_width
            height = p_height * d_width / p_width
        pixbuf = GdkPixbuf.Pixbuf.scale_simple(self.pixbuf, width, height, GdkPixbuf.InterpType.BILINEAR)
        Gdk.cairo_set_source_pixbuf(cr, pixbuf, (d_width-width)/2, (d_height-height)/2)
        cr.paint()

GtkClutter.init()
DrawWindow()
Gtk.main()

動かす。

上半分が cairo で下が Clutter です。
拡大はまったく同じ描写になるけど縮小は全然違うものになることが解る。
なんだよこの 3D 描写。。。。。

画像処理や 3D に詳しいわけではないので細かい解説はできないけど。
単なるラスターデータとして扱う 2D と RGB として扱う 3D の違いだろう。
網点を RGB 色として認識した結果こんな悲惨なことに。

とにかく 3D では小さめな画像かアニメ調のベタ塗りでないとこんなことになる。
スクリーントーンを多用するコミック表示には徹底的に向いていないようです。

Clutter で cairo が使える手段があるのはそういうことか。
cairo で作り替えしよ。

text/x-python3

Fedora 27 では ContentType に text/x-python3 が追加されていた。
…ことを昨日久々に Python ネタを書いてやっと気が付く筆者であった。
Gedit で python の所に登録したスニペットが流し込めなかったということで。

とうとう Python2 からの完全置き換えをあきらめたということかな。
ちなみに Gedit はモードラインが無いなら ContentType で見分けている。
どういう振り分けをしているのかしらべてみよう。

/usr/share/mime/magic
を Gedit で無理矢理開いて Ctrl+F から python3 を検索。

あぁシバンのみで判断しているってことね。
拡張子を py にしただけのファイルは text/x-python のままだ。

python3+15 って何だろと思ってアレコレ試してみた。
先頭から 15 文字目までにコレを見つけたら Python3 だと認識、でいいのかな。

#!!!!!!!!!!!/usr/bin/env python3

から ! を一文字増やし Ctrl+s で Gedit のステータスバー表記が Python に変わる。

いや実験です、この shebang は当然動作しません。
しかし 15 文字っていったいどんだけ変な場所に env があるんだよ。

とにかくこれで Python2/3 コードの振り分けが簡単になる。
いや現行の Fedora デフォルトに Python2 は含まれていませんけど。

multiprocessing, staticmethod

Python3 にて multiprocessing ではまったので覚書

#!/usr/bin/env python3

import multiprocessing

def global_pool(num):
    """ return is a Python Type Onry """
    return num

class MpTest():
    def __init__(self):
        self.n = 10
        pool = multiprocessing.Pool()
        for num in range(10):
            #pool.apply_async(self.on_pool, args=(num,), callback=self.on_pool_result) # NG
            #pool.apply_async(global_pool, args=(num,), callback=self.on_pool_result) # OK
            pool.apply_async(self.static_pool, args=(num,), callback=self.on_pool_result) # OK
        pool.close()
        pool.join()

    def on_pool(self, num):
        """ Not Work """
        return num

    @staticmethod
    def static_pool(num):
        """ OK """
        return num

    def on_pool_result(self, result):
        print(result, end=",")

if __name__ == '__main__':
    MpTest()

で。
ランダムな順に出力され並行処理されているのが確認できる。

Pool はインスタンスメソッドにはアクセスできないのね。
実は去年からドン詰まりしていたのがやっと解決。

グローバル関数にするのもアレだし、ってことで static にしてもイケた。
あぁ @staticmethod はこういう場合に使うんだな。

それより数値や文字列という Python の型しか戻せないのが痛い。
Gir で GdkPixbuf を数個作るのを並行処理みたいなことはできない。
というかしようと思ったんだけど、どうやらこの手段では無理っぽい。

GTK+ Cancel Long Keypress

GTK+ にてキーの長押しを判別する手段を発見。
GTK+ はキーの長押しを認識できないようで | PaePoi
こんなことを書いて 8 年もたってしまった、遅すぎるぞ俺！

何かキーを長押しした状態で event.time の値を見ると同一だった。
つまり長押しは最初に押した時間のまま延々とイベントが飛んでくるようだ。
とっととサンプルコードを書いたほうが解りやすいということで。

#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk

class CancelLongKeypressWindow(Gtk.Window):
    """
        Wayland Only
    """
    def __init__(self):
        Gtk.Window.__init__(self)
        self.connect("hide", Gtk.main_quit)
        self.connect("key-press-event", self.on_key_press_event)
        self.long_keypress = 0
        self.show()

    def on_key_press_event(self, widget, event):
        #
        # Cancel Long Keypress
        #
        if self.long_keypress == event.time:
            return False
        self.long_keypress = event.time
        #
        print("Press!")
        return False

CancelLongKeypressWindow()
Gtk.main()

これでうっかり長押ししてしまっても早送りみたいな状態を避けられる。
逆に長押しされているのを判別するということも可能、こんなに簡単だった。
Comipoli で使うのと 8 年前の記事に合わせるため Python にしました。
これで我が Comipoli で早送りされてしまうのを防げるぞと。

そういえばあの頃は Ubuntu を使っていたなぁ。
今度から GNOME に戻るんだっけ、良さげなら又使うかな？
って GNOME に Dock を付けるという余計なことを又してる、ヤメた。
筆者は MacBook Air でも Dock はまったく使わないんですけど。
第493回　Ubuntu 17.10の変更点：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社

追記
Wayland 環境だけのようです。
X.org でログインしたら同様にならなかった。

LOKDocView

本日の Fedora アップデートでこんなのが出た。

LOKDocView って何だ？

Development/Integrating LOKDocView and GNOME Documents – The Document Foundation Wiki

libreoffice 文書を GNOME Document で表示する API なのか。
ということは gir でバインドされているのかな。

普通にあったわ、コレって今まであったっけ？
まあそれはいいや、さてサンプルコードを探してみよう。

GitHub – pranavk/lokdocviewer: An application for testing LOKDocView

js/py 両方用意してくれているとは親切ですね。
しかし new メソッドの引数が PyGObject は 2 つで Gjs は 3 つ。
Gjs らしく new キーワードに書き換えるとコアダンプ。

#!/usr/bin/gjs

const Gtk = imports.gi.Gtk;
const LOKDocView = imports.gi.LOKDocView;
const Lang = imports.lang;

const LOKWindow = new Lang.Class({
    Name: 'LOKWindow',
    Extends: Gtk.ApplicationWindow,

    _init: function(app) {
        this.parent({
            application: app
        });
        // Segmentation fault
        //this.view = new LOKDocView.View();
        this.view = LOKDocView.View.new(null, null, null); // OK
        this.view.open_document(
            "/home/sasakima-nao/syokumu.odt",
            "{}",
            null,
            Lang.bind(this, function() {
                this.view.set_edit(true);
            }),
            null);
        let sw = new Gtk.ScrolledWindow();
        sw.add(this.view);
        this.add(sw);
        //
        this.show_all();
    }
});

let app = new Gtk.Application();
app.connect("activate", function() {
    new LOKWindow(app);
});
app.run(null);

前々回みたいな問題があるし…
GNOME はぶっちゃけ Gjs に全面移行したいのだろうけどまだ問題が多いなぁ。
てか Python はサードパーティなのに対応っぷりがスゲェ。
当面は Python と併用が続くのだろう。

コレを使って何か作るかな、ここんとこネタ切れなのは秘密だよ。