mieki256's diary

とりあえず、ウインドウを表示して、四角、円、画像を描画するところまで動作確認してみた。




_02win.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <X11/Xlib.h>
#include <X11/xpm.h>
#include <math.h>

/* include ufo2_xpm */
#include "ufo2.xpm"

#define WIN_W 512
#define WIN_H 512
#define WIN_X 100
#define WIN_Y 100
#define BORDER 4

#ifndef M_PI
#define M_PI 3.14159265358979
#endif

#define deg2rad(x) (x * M_PI / 180.0)

typedef struct _Pixmaps
{
    Pixmap pix;
    Pixmap mask;
} Pixmaps;

static void update(Display *dpy, Drawable win, GC gc, double ang, Pixmaps pixs);

/* get a color value from a color name */
static unsigned long
get_color(Display *dpy, char *colorname)
{
    Colormap cmap;
    XColor near_color, true_color;

    cmap = DefaultColormap(dpy, DefaultScreen(dpy));
    XAllocNamedColor(dpy, cmap, colorname, &near_color, &true_color);
    return near_color.pixel;
}

int main(void)
{
    Display *dpy;
    Window root;
    Window win;
    int screen;
    XEvent evt;
    unsigned long black, white;
    GC gc;
    Pixmaps pixs;
    int busy_loop;
    double ang;

    /* open display */
    dpy = XOpenDisplay(NULL);
    root = DefaultRootWindow(dpy);
    screen = DefaultScreen(dpy);

    /* get color black and white */
    white = WhitePixel(dpy, screen);
    black = BlackPixel(dpy, screen);

    /* create window */
    win = XCreateSimpleWindow(dpy, root,
                              WIN_X, WIN_Y, WIN_W, WIN_H, BORDER,
                              black, white);

    XSelectInput(dpy, win, KeyPressMask | ExposureMask);

    XMapWindow(dpy, win);

    /* wait display window */
    do
    {
        XNextEvent(dpy, &evt);
    } while (evt.type != Expose);

    XMoveWindow(dpy, win, WIN_X, WIN_Y);

    /* create graphics context */
    gc = XCreateGC(dpy, win, 0, 0);
    XSetGraphicsExposures(dpy, gc, False);

    /* load image */
    if (XpmCreatePixmapFromData(dpy, win, ufo2_xpm,
                                &pixs.pix, &pixs.mask, NULL))
    {
        fprintf(stderr, "Error not load xpm.");
        return 1;
    }

    ang = 0;

    busy_loop = 1;
    while (busy_loop)
    {
        /* event */
        while (XPending(dpy))
        {
            XNextEvent(dpy, &evt);
            switch (evt.type)
            {
                /*
            case Expose:
                if (evt.xexpose.count == 0)
                {
                }
                break;
                */
            case KeyPress:
                busy_loop = 0;
                break;
            default:
                break;
            }
        }

        update(dpy, win, gc, ang, pixs);
        ang += 1.0;
        if (ang >= 360)
            ang -= 360;

        XFlush(dpy);
        usleep(16 * 1000); /* wait */
    }

    XFreePixmap(dpy, pixs.pix);
    XFreePixmap(dpy, pixs.mask);
    XFreeGC(dpy, gc);
    XDestroyWindow(dpy, win);
    XCloseDisplay(dpy);
    return 0;
}

/* update and draw */
static void
update(Display *dpy, Drawable win, GC gc, double ang, Pixmaps pixs)
{
    XWindowAttributes xgwa;
    int scrw, scrh;
    int r, x, y, w, h;
    int r2, x2, y2, w2, h2;

    /* get window attributes */
    XGetWindowAttributes(dpy, win, &xgwa);
    scrw = xgwa.width;  /* window width */
    scrh = xgwa.height; /* window height */

    w = 96;
    h = 96;
    r = 200;
    x = r * cos(deg2rad(ang)) + (scrw / 2) - (w / 2);
    y = r * sin(deg2rad(ang)) + (scrh / 2) - (h / 2);

    w2 = 128;
    h2 = 128;
    r2 = 128;
    x2 = r2 * cos(deg2rad(-ang)) + (scrw / 2) - (w2 / 2);
    y2 = r2 * sin(deg2rad(-ang)) + (scrh / 2) - (h2 / 2);

    /* clear window */
    XClearWindow(dpy, win);

    /* draw shape */
    XSetForeground(dpy, gc, get_color(dpy, "blue"));
    XFillRectangle(dpy, win, gc, x - 8, y - 8, w + 16, h + 16);

    XSetForeground(dpy, gc, get_color(dpy, "cyan"));
    XFillArc(dpy, win, gc, x, y, w, h, 0, 360 * 64);

    /* draw image (Pixmap) */
    XSetClipMask(dpy, gc, pixs.mask);                        /* set clip mask */
    XSetClipOrigin(dpy, gc, x2, y2);                         /* set clip origin */
    XCopyArea(dpy, pixs.pix, win, gc, 0, 0, w2, h2, x2, y2); /* copy Pixmap */
    XSetClipMask(dpy, gc, None);                             /* reset clip */
}

使用画像: _ufo2.xpm
Makefile: _Makefile

コンパイルは以下。

gcc 02win.c -o 02win -I /usr/include/X11 -lX11 -lXext -lm -lXpm

Ubuntu Linux だから上のような指定になっているけれど、別のディストリでは「-I /usr/include/X11」のあたりを変えることになるのかもしれない。巷の解説ページでは別の場所を指定している場合がほとんどなので…。

実行は以下。

./02win

少し解説。

• Xlib を使う時は、#include <X11/Xlib.h> を最初のあたりで書く。コンパイラ(リンカ)には、-lX11 -lXext を追加。
• xpm画像を扱う時は、#include <X11/xpm.h> を以下略。コンパイラ(リンカ)には、-lXpm を追加。
• sin,cos 等の数学関数を使う時は、#include <math.h> を以下略。コンパイラ(リンカ)には、-lm を追加。

xpm画像は中身がテキストファイル。C言語のソースファイル内で include して画像データのバイナリにアクセスすることができる。ちなみに、GIMP で xpm としてエクスポートすれば xpm画像を作れる。

画像を扱う時は Pixmap か XImage を使うらしいけど、今回は Pixmap を使って処理してみた。

xpm から Pixmap に変換しているのは以下。

    /* load image */
    if (XpmCreatePixmapFromData(dpy, win, ufo2_xpm,
                                &pixs.pix, &pixs.mask, NULL))
    {
        fprintf(stderr, "Error not load xpm.");
        return 1;
    }

• ufo2_xpm が、xpm のバイナリが入ってる変数名。
• pixs.pix に非透過部分が、pixs.mask に透過部分が入るように指定してる。
• XpmCreatePixmapFromData() は、処理成功で0、失敗でエラーコードが返る。ちなみにC言語は、0は偽、0以外は真になる仕様。

透過画像を描画する時は、XSetClipMask()、XSetClipOrigin()、XCopyArea()、XSetClipMask() を使う。

    /* draw image (Pixmap) */
    XSetClipMask(dpy, gc, pixs.mask);                        /* set clip mask */
    XSetClipOrigin(dpy, gc, x2, y2);                         /* set clip origin */
    XCopyArea(dpy, pixs.pix, win, gc, 0, 0, w2, h2, x2, y2); /* copy Pixmap */

    XSetClipMask(dpy, gc, None);                             /* reset clip */

• XSetClipMask() で、透過部分が入ってる Pixmap を指定して、クリップマスクを設定。
• XSetClipOrigin() で、クリップマスクの原点を設定。
• XCopyArea() で、Pixmap を別の何か(Drawable。ウインドウかPixmap。今回はウインドウが転送先)にコピー。この時、クリップマスクが反映されて、透過ではない部分だけがコピーされる。
• 最後にクリップマスクをリセットしておかないと、次回、別の何かを描画する際に前回のクリップマスクが働いていしまうので注意。

Pixmap や GC は、プログラムを終了する前に、利用していたメモリ領域を解放しておかないといけない。XFreePixmap()、XFreeGC() を使って解放する。

画像の描画ができたので、画像を拡大縮小できないか試してみる。

どうしてそんなことをしたいのかというと、例えばスクリーンセーバを作る際に、ウインドウサイズ(ディスプレイサイズ)が異なると画像レイアウトが違ってきてしまうからで…。一旦小さい画面(Pixmap)に描いておいて、その小さい画面をウインドウサイズのPixmapに拡大して、それをウインドウに描画することができれば、ウインドウサイズ(ディスプレイサイズ)が違っていても、画像のレイアウトがめちゃくちゃにならずに済むのではないかと。

処理時間的に厳しいのではないかと予想しながら書き始めてみたけど、やり方次第ではどうにかなりそうな気配を感じた。以下のキャプチャ動画は、640 x 360 の Pixmap を 1440 x 900 の Pixmap に拡大してる例。上下にふわふわしてるけど、これでも毎フレーム拡大処理をしている。




_04scale.c

/*
Scaling Pixmap.

Ryzen 5 5600x + VMware Player + Ubuntu Linux 20.04 LTS.
1920 x 1080.
slow result : 0.510753 sec
fast result : 0.000045 sec
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <X11/Xlib.h>
#include <X11/xpm.h>
#include <math.h>
#include <time.h>

/* include xpm binary */
#include "bg01.xpm"
#define XPM_W 640
#define XPM_H 360
#define XPM_NAME bg01_xpm

/*
#include "bg02.xpm"
#define XPM_W 320
#define XPM_H 180
#define XPM_NAME bg02_xpm
*/

/* kind. 0: slow, 1: fast */
#define SCALING_KIND 1

#define WIN_X 0
#define WIN_Y 64
#define BORDER 0

#ifndef M_PI
#define M_PI 3.14159265358979
#endif

#define deg2rad(x) (x * M_PI / 180.0)

/* get a color value from a color name */
static unsigned long
get_color(Display *dpy, char *colorname)
{
    Colormap cmap;
    XColor near_color, true_color;

    cmap = DefaultColormap(dpy, DefaultScreen(dpy));
    XAllocNamedColor(dpy, cmap, colorname, &near_color, &true_color);
    return near_color.pixel;
}

/* scale Pixmap */
static void
scale_pixmap(Display *dpy, Drawable win,
             Pixmap *src, Pixmap *dst,
             int src_w, int src_h, int dst_w, int dst_h)
{
    GC gc;
    float xscale, yscale;
    int x, y;
    struct timespec start, end;
    double diff;

    xscale = (float)src_w / dst_w;
    yscale = (float)src_h / dst_h;

    gc = XCreateGC(dpy, win, 0, 0);
    XSetGraphicsExposures(dpy, gc, False);

    timespec_get(&start, TIME_UTC);

    switch (SCALING_KIND)
    {
    case 0:
        /* slow */
        for (y = 0; y < dst_h; y++)
        {
            int sy = (int)(y * yscale);
            for (x = 0; x < dst_w; x++)
                XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), sy, 1, 1, x, y);
        }
        break;
    case 1:
        /* fast */
        for (x = dst_w - 1; x >= 0; x--)
            XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), 0, 1, src_h, x, 0);
        for (y = dst_h - 1; y >= 0; y--)
            XCopyArea(dpy, *dst, *dst, gc, 0, (int)(y * yscale), dst_w, 1, 0, y);
        break;
    default:
        break;
    }

    XFreeGC(dpy, gc);

    timespec_get(&end, TIME_UTC);
    diff = (end.tv_sec + (double)end.tv_nsec / 1000000000) - (start.tv_sec + (double)start.tv_nsec / 1000000000);
    printf("%lf sec\n", diff);
}

/* update and draw */
static void
update(Display *dpy, Drawable win, GC gc, double ang, Pixmap pix, Pixmap buf)
{
    XWindowAttributes xgwa;
    int r, x, y;
    int buf_w, buf_h;

    /* get window attributes */
    XGetWindowAttributes(dpy, win, &xgwa);
    buf_w = xgwa.width;  /* window width */
    buf_h = xgwa.height; /* window height */

    scale_pixmap(dpy, win, &pix, &buf, XPM_W, XPM_H, buf_w, buf_h);

    r = 64;
    x = 0;
    /* x = r * cos(deg2rad(ang)); */
    y = r * sin(deg2rad(ang));

    /* clear window */
    XClearWindow(dpy, win);

    /* draw image (Pixmap) */
    XSetGraphicsExposures(dpy, gc, False);
    XCopyArea(dpy, buf, win, gc, 0, 0, buf_w, buf_h, x, y); /* copy Pixmap */
}

int main(void)
{
    Display *dpy;
    Window root;
    Window win;
    int screen;
    int display_w, display_h;
    XEvent evt;
    unsigned long black, white;
    XWindowAttributes xgwa;
    GC gc;
    Pixmap pix;
    Pixmap buf;
    int busy_loop;
    double ang;

    /* open display */
    dpy = XOpenDisplay(NULL);
    root = DefaultRootWindow(dpy);
    screen = DefaultScreen(dpy);

    /* get display size */
    display_w = DisplayWidth(dpy, screen);
    display_h = DisplayHeight(dpy, screen);
    printf("Screen: %d x %d\n", display_w, display_h);

    /* get color black and white */
    white = WhitePixel(dpy, screen);
    black = BlackPixel(dpy, screen);

    /* create window */
    win = XCreateSimpleWindow(dpy, root,
                              WIN_X, WIN_Y, display_w, display_h, BORDER,
                              white, black);

    XSelectInput(dpy, win, KeyPressMask | ExposureMask);

    XMapWindow(dpy, win);

    /* wait display window */
    do
    {
        XNextEvent(dpy, &evt);
    } while (evt.type != Expose);

    XMoveWindow(dpy, win, WIN_X, WIN_Y);

    /* create graphics context */
    gc = XCreateGC(dpy, win, 0, 0);
    XSetGraphicsExposures(dpy, gc, False);

    /* load image */
    if (XpmCreatePixmapFromData(dpy, win, XPM_NAME, &pix, NULL, NULL))
    {
        fprintf(stderr, "Error not load xpm.");
        return 1;
    }

    XGetWindowAttributes(dpy, win, &xgwa);
    buf = XCreatePixmap(dpy, win, display_w, display_h, xgwa.depth);
    XSetForeground(dpy, gc, get_color(dpy, "green"));
    XFillRectangle(dpy, buf, gc, 0, 0, display_w, display_h);

    ang = 0;

    busy_loop = 1;
    while (busy_loop)
    {
        /* event */
        while (XPending(dpy))
        {
            XNextEvent(dpy, &evt);
            switch (evt.type)
            {
                /*
            case Expose:
                if (evt.xexpose.count == 0)
                {
                }
                break;
                */
            case KeyPress:
                busy_loop = 0;
                break;
            default:
                break;
            }
        }

        update(dpy, win, gc, ang, pix, buf);
        ang += 4.0;
        if (ang >= 360)
            ang -= 360;

        XFlush(dpy);
        usleep(16 * 1000); /* wait */
    }

    XFreePixmap(dpy, pix);
    XFreePixmap(dpy, buf);
    XFreeGC(dpy, gc);

    XDestroyWindow(dpy, win);
    XCloseDisplay(dpy);
    return 0;
}

使用画像は以下。

_bg01.xpm
_bg02.xpm


コンパイルは以下。

gcc 04scale.c -o 04scale -I /usr/include/X11 -lX11 -lXext -lm -lXpm

実行は以下。

./04scale

少し解説。

最初に処理を書いた時は、愚直に、1ドットずつ XCopyArea() を呼んでみたけれど、このやり方だと圧倒的に処理時間がかかってしまって話にならなかった。

        /* slow */
        for (y = 0; y < dst_h; y++)
        {
            int sy = (int)(y * yscale);
            for (x = 0; x < dst_w; x++)
                XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), sy, 1, 1, x, y);
        }

そこでふと、xscreensaver のソース群の中で目にした処理を思い出した。一旦横方向にのみ引き延ばして、その横方向に引き延ばしたものを縦に引き延ばすというやり方。

        /* fast */
        for (x = dst_w - 1; x >= 0; x--)
            XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), 0, 1, src_h, x, 0);
        for (y = dst_h - 1; y >= 0; y--)
            XCopyArea(dpy, *dst, *dst, gc, 0, (int)(y * yscale), dst_w, 1, 0, y);

後者は、前者と比べて圧倒的に速かった。時間を測定してみたところ、以下のような感じになった。

• slow result : 0.510753 sec
• fast result : 0.000045 sec

• CPU: AMD Ryzen 5 5600x
• OS: Ubuntu Linux 20.04 LTS (Windows10 x64 21H2 + VMware Player上で動作)
• 画面解像度 : 1920 x 1080

考えてみたら、例えば 1920x1080のサイズの場合、前者は XCopyArea() を 2073600回呼んでしまうけど、後者なら3000回呼ぶだけで済むわけで、そのあたりが効いてるのかなと。ただ、Pixmap へのアクセス回数は、横に引き延ばす段階が入ってくる分、増えてしまうはずなのだけど…。Xlib関係はCPUだけが必死に頑張って処理をしてるものと思い込んでたけど、もしかしてGPUが頑張ってる時もあるのだろうか。それとも、Pixmap間の転送は処理が速くなるように何か工夫してるのだろうか。

何にせよ、このぐらいの速さで拡大描画できるなら、一旦ファミコンレベルの解像度の画面を作っておいて、ソレをデスクトップ一杯に拡大描画しても、60FPS程度なら出せるかもしれない。大昔の2Dゲーム画面っぽいスクリーンセーバを作れそうな予感。

Ubuntu Linux 20.04 LTSの場合、xpm画像を扱う時は、libxpm-dev をインストールしておかないとコンパイルできない模様。

sudo apt install libxpm-dev

ソースは以下。

_06scale3.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <X11/Xlib.h>
#include <X11/xpm.h>
#include <math.h>
#include <time.h>

/* include xpm binary */
#include "bg01.xpm"
#define XPM_W 640
#define XPM_H 360
#define XPM_NAME bg01_xpm

/*
#include "bg02.xpm"
#define XPM_W 320
#define XPM_H 180
#define XPM_NAME bg02_xpm
*/

/* kind. 0: slow, 1: fast */
#define SCALING_KIND 1

#define WIN_X 0
#define WIN_Y 64
#define BORDER 0

#ifndef M_PI
#define M_PI 3.14159265358979
#endif

#define deg2rad(x) (x * M_PI / 180.0)

/* get a color value from a color name */
static unsigned long
get_color(Display *dpy, char *colorname)
{
    Colormap cmap;
    XColor near_color, true_color;

    cmap = DefaultColormap(dpy, DefaultScreen(dpy));
    XAllocNamedColor(dpy, cmap, colorname, &near_color, &true_color);
    return near_color.pixel;
}

/* scale Pixmap */
static void
scale_pixmap(Display *dpy, Drawable win,
             Pixmap *src, Pixmap *dst,
             int src_w, int src_h, int dst_w, int dst_h)
{
    GC gc;
    float xscale, yscale;
    int x, y;
    struct timespec start, end;
    double diff;

    xscale = (float)src_w / dst_w;
    yscale = (float)src_h / dst_h;

    gc = XCreateGC(dpy, win, 0, 0);
    XSetGraphicsExposures(dpy, gc, False);

    timespec_get(&start, TIME_UTC);

    switch (SCALING_KIND)
    {
    case 0:
        /* slow */
        for (y = 0; y < dst_h; y++)
        {
            int sy = (int)(y * yscale);
            for (x = 0; x < dst_w; x++)
                XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), sy, 1, 1, x, y);
        }
        break;
    case 1:
        /* fast */
        for (x = dst_w - 1; x >= 0; x--)
            XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), 0, 1, src_h, x, 0);

        if (src_h <= dst_h)
        {
            for (y = dst_h - 1; y >= 0; y--)
                XCopyArea(dpy, *dst, *dst, gc, 0, (int)(y * yscale), dst_w, 1, 0, y);
        }
        else
        {
            for (y = 0; y < dst_h; y++)
                XCopyArea(dpy, *dst, *dst, gc, 0, (int)(y * yscale), dst_w, 1, 0, y);
        }
        break;
    default:
        break;
    }

    XFreeGC(dpy, gc);

    timespec_get(&end, TIME_UTC);
    diff = (end.tv_sec + (double)end.tv_nsec / 1000000000) - (start.tv_sec + (double)start.tv_nsec / 1000000000);
    printf("%lf sec\n", diff);
}

/* update and draw */
static void
update(Display *dpy, Drawable win, GC gc,
       Pixmap pix, Pixmap buf,
       int new_w, int new_h)
{
    XWindowAttributes xgwa;
    int r, x, y;
    int scrw, scrh;

    /* get window attributes */
    XGetWindowAttributes(dpy, win, &xgwa);
    scrw = xgwa.width;  /* window width */
    scrh = xgwa.height; /* window height */

    scale_pixmap(dpy, win, &pix, &buf, XPM_W, XPM_H, new_w, new_h);

    /* centering */
    x = scrw - ((scrw + new_w) / 2);
    y = scrh - ((scrh + new_h) / 2);

    /* clear window */
    XClearWindow(dpy, win);

    /* draw image (Pixmap) */
    XSetGraphicsExposures(dpy, gc, False);
    XCopyArea(dpy, buf, win, gc, 0, 0, new_w, new_h, x, y);
}

int main(void)
{
    Display *dpy;
    Window root;
    Window win;
    int screen;
    int display_w, display_h;
    XEvent evt;
    unsigned long black, white;
    XWindowAttributes xgwa;
    GC gc;
    Pixmap pix;
    Pixmap buf;
    int busy_loop;
    double new_w, new_h;
    double dx;

    /* open display */
    dpy = XOpenDisplay(NULL);
    root = DefaultRootWindow(dpy);
    screen = DefaultScreen(dpy);

    /* get display size */
    display_w = DisplayWidth(dpy, screen);
    display_h = DisplayHeight(dpy, screen);
    printf("Screen: %d x %d\n", display_w, display_h);

    /* get color black and white */
    white = WhitePixel(dpy, screen);
    black = BlackPixel(dpy, screen);

    /* create window */
    win = XCreateSimpleWindow(dpy, root,
                              WIN_X, WIN_Y, display_w, display_h, BORDER,
                              white, black);

    XSelectInput(dpy, win, KeyPressMask | ExposureMask);

    XMapWindow(dpy, win);

    /* wait display window */
    do
    {
        XNextEvent(dpy, &evt);
    } while (evt.type != Expose);

    XMoveWindow(dpy, win, WIN_X, WIN_Y);

    /* create graphics context */
    gc = XCreateGC(dpy, win, 0, 0);
    XSetGraphicsExposures(dpy, gc, False);

    /* load image */
    if (XpmCreatePixmapFromData(dpy, win, XPM_NAME, &pix, NULL, NULL))
    {
        fprintf(stderr, "Error not load xpm.");
        return 1;
    }

    XSetForeground(dpy, gc, get_color(dpy, "green"));

    XGetWindowAttributes(dpy, win, &xgwa);
    buf = XCreatePixmap(dpy, win, display_w, display_h, xgwa.depth);
    XFillRectangle(dpy, buf, gc, 0, 0, display_w, display_h);

    new_w = display_w;
    new_h = display_h;
    dx = -6;

    busy_loop = 1;
    while (busy_loop)
    {
        /* event */
        while (XPending(dpy))
        {
            XNextEvent(dpy, &evt);
            switch (evt.type)
            {
                /*
            case Expose:
                if (evt.xexpose.count == 0)
                {
                }
                break;
                */
            case KeyPress:
                busy_loop = 0;
                break;
            default:
                break;
            }
        }

        update(dpy, win, gc, pix, buf, new_w, new_h);

        new_w += dx;
        if (new_w <= 32)
        {
            new_w = 32;
            dx *= -1;
        }
        if (new_w >= display_w)
        {
            new_w = display_w;
            dx *= -1;
        }

        new_h = display_h * new_w / display_w;

        XFlush(dpy);
        usleep(16 * 1000); /* wait */
    }

    XFreePixmap(dpy, pix);
    XFreePixmap(dpy, buf);
    XFreeGC(dpy, gc);

    XDestroyWindow(dpy, win);
    XCloseDisplay(dpy);
    return 0;
}

使用画像は以下。

_bg01.xpm
_bg02.xpm


Makefileの例。

_Makefile


コンパイルは以下。実行バイナリ 06scale3 が生成される。

gcc 06scale3.c -o 06scale3 -I /usr/include/X11 -lX11 -lXext -lm -lXpm

実行は以下。

./06scale3

_昨日、 書いた処理は、少しバグがあった。元画像より小さい縦サイズに縮小しようとすると、見た目がおかしなことになってしまう。



以下の処理では、(縦方向の)拡大はともかく、縮小はおかしなことになる。参照される部分を上書きコピーで破壊してしまう。

_05scale2.c

        /* fast */
        for (x = dst_w - 1; x >= 0; x--)
            XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), 0, 1, src_h, x, 0);
        for (y = dst_h - 1; y >= 0; y--)
            XCopyArea(dpy, *dst, *dst, gc, 0, (int)(y * yscale), dst_w, 1, 0, y);

以下のように修正。拡大時と縮小時で処理を分けて、拡大時は下から上に向かってスキャン、縮小時は上から下に向かってスキャンしていけばおかしなことにはならない。

        /* fast */
        for (x = dst_w - 1; x >= 0; x--)
            XCopyArea(dpy, *src, *dst, gc, (int)(x * xscale), 0, 1, src_h, x, 0);

        if (src_h <= dst_h)
        {
            for (y = dst_h - 1; y >= 0; y--)
                XCopyArea(dpy, *dst, *dst, gc, 0, (int)(y * yscale), dst_w, 1, 0, y);
        }
        else
        {
            for (y = 0; y < dst_h; y++)
                XCopyArea(dpy, *dst, *dst, gc, 0, (int)(y * yscale), dst_w, 1, 0, y);
        }

帰りにHARD-OFFに寄ったけれど、相変わらずヨサゲなPCケースが見当たらなくて残念。通販なら新品でも、一番安いミニタワーPCケースなら3,000円ぐらいで買えるけど。見た目が傷だらけで、今となっては巨大に感じるミドルタワーATXケースで、フロントベイカバーがポツポツ無くなっている中古のケースが3,300円とか5,500円では…。なかなか厳しい。

相場より高いのか、それとも安いのか、そのあたりはよく分からない…。譲渡証明書の控えに査定内容が書いてあるのだけど、読み方が分からなくて…。Ryzen 3 2200G が特に分からない。買取基準金額と買取査定額が1,000円と書かれてるけど、最後の品目名で6,600円になってる。最初に1,000円の記述が目に入って、「え。そんなに低いの」と驚いてしまったけど、そういうわけではなかったらしい。

質問したかったけれど、後ろに他の買取客が並んでたので、迷惑になったらいかんよなと、質問しないまま店を出た。ただ、ちょっともやもやする…。自分はちゃんと奇麗な状態で持ち込めたのか、そうでもなかったのか等々、一言二言でいいから聞いておきたかったなと…。

譲渡証明書には「Sofmap U-FRONT」と書かれてた。パソコン工房の実店舗で買取してるけど、パソコン工房が買取してるわけではないということだろうか。パソコン工房の買取なら、土日祝日は買取価格上乗せ云々とサイトに書いてあったけど、郡山店ではSofmapの買取サービスを提供してるからそういうオマケは無し、ということかもしれない。

持ち込む前は、やれここが汚れてるだのなんだの言われて、下手すると全部合わせても3千円にすらならないのではと結構不安だったけど。パソコン工房やドスパラのサイトで確認した際の額と大体似たような結果になってホッとした。わざわざIPAやキムワイプを新規購入して掃除した甲斐はあった…のかどうかそのあたり結局何も分からないままだけど、まあ、結果には満足。

もっとも、この額では現行CPUの最低ランク品すら購入できないわけで、以前、弟が、「PCパーツを買取サービスに持ち込むぐらいなら欲しい人にタダでプレゼントしたほうがマシ」と言った感覚も、なんだかちょっと分かったような気もする。

とは言え今回、M/Bさえあれば手元に残してサブPC用として使っただろうけど、空いてる Socket AM4対応M/Bは無く、このままだとCPUもメモリも使われないまま埃を被ってしまうので、だったら別の誰かの手に渡ったほうが、と思った次第。

ソースと使用画像は以下。

_08rasterscroll.c
_bg03.xpm.txt


コンパイルは以下。

gcc 08rasterscroll.c -o 08rasterscroll -I /usr/include/X11 -lX11 -lXext -lm -lXpm

実行は以下。

./08rasterscroll

ラスタースクロールと言っても、あくまでモドキで…。画面の下半分は、元画像を参照する際のx座標をcos()で変化させて、縦幅1ドットずつ、Pixmap から Pixmap にコピーしてるだけ。

元画像は、640x360の左右に32ドットずつ足して、704x360で作成。左右にcos()で揺らして描画するので、横640ドットぴったりで作ってしまうと描画されない部分が出てきてしまう。左右に少しだけ絵を追加しておかないといけない。

• pcd add . : カレントディレクトリを登録リストに追加。
• pcd edit : 登録リストファイルを編集。
• pcd : 登録リストからインクリメンタルサーチで絞り込んでディレクトリ移動。
• cdp : カレントディレクトリ内からインクリメンタルサーチで絞り込んでディレクトリ移動。

pacman -S fzy

$ fzy --version
fzy 1.0 (C) 2014-2018 John Hawthorn

pcd を使えば、自分で登録したディレクトリリストをインクリメンタルサーチで絞り込んでディレクトリ移動ができる。

登録リストファイル、~/.peco/.peco-cd ファイルを作成。

mkdir ~/.peco
touch ~/.peco/.peco-cd

~/.bash_pcd を作成。以下を記述。

• peco を呼び出している場所で fzy を呼ぶように変更。
• pcd edit と打った際は nanoエディタを呼び出すように変更。

function pcd() {
  local PCD_FILE=$HOME/.peco/.peco-cd
  local PCD_RETURN
  if [ $1 ] && [ $1 = "add" ]; then
    if [ $2 ]; then
      ADD_DIR=$2
      if [ $2 = "." ]; then
        ADD_DIR=$(pwd)
      fi
      echo "add $ADD_DIR to $PCD_FILE"
      echo $ADD_DIR >> $PCD_FILE
    fi
  elif [ $1 ] && [ $1 = "edit" ]; then
    if [ $EDITOR ]; then
       $EDITOR $PCD_FILE
    else
       # editor $PCD_FILE
       nano $PCD_FILE
    fi
  elif [ $1 ] && [ $1 = "." ]; then
    PCD_RETURN=$(/bin/ls -F | grep /$ | fzy -l 20)
  else
    PCD_RETURN=$(cat $PCD_FILE | fzy -l 20)
  fi
  if [ $PCD_RETURN ]; then
    cd $PCD_RETURN
  fi
}

function cdp {
  local dir="$( find . -maxdepth 1 -type d | sed -e  's;\./;;' | sort | fzy -l 20 )"
  if [ ! -z "$dir" ] ; then
    cd "$dir"
  fi
}

~/.bashrc に以下を追記。~/.bash_pcd が存在していたら読み込むようにする。

if [ -f "${HOME}/.bash_pcd" ]; then
  source "${HOME}/.bash_pcd"
fi

source ~/.bashrc で反映。

_jhawthorn/fzy: A simple, fast fuzzy finder for the terminal
_pecoの基礎の基礎 - Qiita
_pecoを使ってフィルタリング＆ディレクトリ移動 - Qiita
_msys2で(強引に)pecoを使う - Qiita
_<Linux, msys2, fzy> fzyを入れる。 - ねこゆきのメモ

python sortrename.py PATH0 PATH1 PATH2

hoge_1920x1080_2_.jpg -> hoge_1920x1080_2.jpg
hoge_1920x1080_2.jpg -> hoge_1920x1080_3.jpg
hoge_1920x1080_3.jpg -> hoge_1920x1080_4.jpg

import sys
import os
import re


def main():
    renamelist = []

    cnt = len(sys.argv)
    if cnt <= 2:
        print("Error : Please select two or more files.")
    else:
        lst = []
        for i in range(1, cnt):
            path = sys.argv[i]
            size = os.path.getsize(path)
            lst.append([path, size])

        slist = sorted(lst, key=lambda x: x[1])
        count = len(slist) + 1
        for v in slist:
            path, size = v
            dirname = os.path.dirname(path)
            filename = os.path.basename(path)
            newfile = re.sub("_\d_*\.jpg", "_%d.jpg" % count, filename)
            newpath = os.path.join(dirname, newfile)
            print("%s -> %s : %d byte" % (filename, newfile, size))
            renamelist.append([path, newpath])
            count -= 1

    if len(renamelist) >= 1:
        v = input("\nRename ? (Y/n)")
        if v == "y" or v == "Y" or v == "":
            for v in renamelist:
                oldpath, newpath = v
                os.rename(oldpath, newpath)
            print("\n%d file renamed." % len(renamelist))
        else:
            print("\nCancel.")

    v = input("\nPush any key")


if __name__ == '__main__':
    main()

このスクリプトは、リネーム後のファイル名が既に存在していた場合、妙な動作になりそうだなと気づいた。おそらく、「リネームできねえよ」とエラーを出しそうな気もするけど…。一旦、重複しないであろう仮ファイル名でリネームしておいて、そこから本当に変更したいファイル名にリネームしたほうがいいのかもしれない。元ファイル名と新ファイル名の他に、仮ファイル名も作ってリストに入れておけば処理ができそう。

_Set guest client area to 1600 x 900 (exact resolut... - VMware Technology Network VMTN
_Custom resolution in monitor configuration - KDE Community Forums
_xfce:xfce4-settings:display [Xfce Docs]
_Ubuntuディスプレイ解像度を自動で1920x1080に変更させる - BioErrorLog Tech Blog

どうやら、cvt でパラメータを調べて、xrandr で解像度を追加すればいいらしい。

cvt 1600 900 59
or
cvt 1600 900

$ cvt 1600 900 59
# 1600x900 58.93 Hz (CVT) hsync: 55.04 kHz; pclk: 116.25 MHz
Modeline "1600x900_59.00"  116.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync

$ cvt 1600 900
# 1600x900 59.95 Hz (CVT 1.44M9) hsync: 55.99 kHz; pclk: 118.25 MHz
Modeline "1600x900_60.00"  118.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync

xrandr --newmode "1600x900" 116.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync
or
xrandr --newmode "1600x900" 118.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync

xrandr --addmode Virtual1 "1600x900"

これで、ディスプレイ設定の解像度のリストの中に 1600x900 が増えて、1600x900を選んで「適用」をクリックしたら、それらしい解像度に変わってくれた。

ただ、OSを再起動すると設定は消えてしまう。

/etc/profile.d/ 以下に 何かしらの .sh を作成しておいて、そこに xrandr --newmode ... と xrandr --addmode ... を記述しておくことで、起動時から該当解像度を有効にしておくことができるらしい。

試しに、mydisplay.sh というファイルを作成して、そこに前述の内容を記述してみた。

sudo vi /etc/profile.d/mydisplay.sh

xrandr --newmode "1600x900" 118.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync
xrandr --addmode Virtual1 "1600x900"

Ubuntu 再起動後も 1600x900 が選べるようになった。

ソースと使用画像は以下。

_09tilemap1.c
_scifi_bg_chip.xpm

一応、元画像(.png)も置いておきます。CC0 / Public Domain ってことで自由に使ってください。1チップ(1タイル) 64x64ドットが、8x8個並んでます。インデックスカラー画像、48色。だったはず。たぶん。


_scifi_bg_chip.png

コンパイルは以下。

gcc 09tilemap1.c -o 09tilemap1 -I /usr/include/X11 -lX11 -lXext -lm -lXpm

実行は以下。

./09tilemap1

少し解説。

今回、今までのソースと違って、State という構造体を定義して、処理で利用する変数を全部その State の中に入れることにした。各関数に引数を渡すあたりの記述が面倒臭かったので、State のポインタを渡して全部の変数にアクセスできるようにしてしまえ、みたいな。

1枚の xpm を分割して複数の Pixmap を作るあたりは、split_pixmaps() という関数で処理してる。

ちょっとハマった点。マスク用のPixmapをコピー(XCopyArea)する時は、マスク用のGCを別途用意しないといけない。そのあたりを知らなかったもので、RGB部分とマスク部分の両方を同じGCで処理しようとして、エラーが出て悩んでしまった。RGB部分を持ってる Pixmap と、マスク用の Pixmap は深度(Depth)が違うので、GCも深度別に用意しないといけないのだとか。

タイルマップを描画するあたりは、draw_tilemap() で処理してる。

本来、この手の処理は、BG用の大きなバッファ(Pixmap)を用意しておいて、スクロールに応じて書き換えが必要な場所だけ書き換えて、そのBG用の大きなバッファをソースにして表示用バッファに描画、といった処理をしたほうが速度は稼げるのだけど。今回は面倒臭かったので、毎フレーム、愚直に、チップ(タイル)を何十個も描画し直すやり方を選んでしまった。まあ、これはこれで、BGのアニメーションはしやすかったりもするけれど…。

余談。タイルマップ用のデータは、Tiled 1.8.5 64bit版を使わせてもらいました。ありがたや。

_Tiled | Flexible level editor

ちなみに、Tiled から json でエクスポートするとタイル番号は1から始まるけれど、csv でエクスポートするとタイル番号は0から始まるのですな…。知らなかった…。

Intel Core2Duo E8400 (2コア, 3.0GHz) + NVIDIA GeForce 9500GT + Ubuntu Linux 20.04 LTS、ディスプレイ解像度 1920x1200 の環境でも動作確認してみた。今となっては非力なCPU＋GPUのはずだけど、それでも大体 3〜 5msec で動いてたので、この程度の描画処理なら60FPSで動かせそうな気配がする。

もっとも、Ryzen 5 5600X + VMware Player + Ubuntu Linux 20.04 LTS、ディスプレイ解像度 1920x1080 では 0.9〜1.1msec で動いたので、Ryzen 5 5600X と比べると Core2Duo E8400 は 1/5 の速度、ということになるのだろうか。いやまあ、仮想PC上ではなくて実機上で動かしたら、また違う処理時間になるかもしれないけど。

Xlib についてググったら、1985年頃に登場したものらしくて。

_Xlib - Wikipedia

そんなに古いライブラリ(?)を使ってもこのくらいの描画はできるのだな、という感想を持ったけれど、さすがにこういう感じの描画をしたいなら OpenGL だか glx だかを使うべきなのでは、という気もしてきた。

_GLX - Wikipedia

xscreensaver のドキュメント内でも、「高速な描画をしたいなら OpenGL/glx を使うことを検討すべきやで」みたいなことが書いてあった気もするし。

今回は、xscreensaver-6.04.tar.gz をDL・解凍して、中にファイルを追加する形で実験。

_XScreenSaver
_XScreenSaver: Download


ソース(*.c)、マニュアル(*.man)。hacks/ 以下にコピーする。

_hellotilemap.c
_hellotilemap.man


設定画面定義ファイル(*.xml)。hacks/config/ 以下にコピーする。

_hellotilemap.xml


使用画像。hacks/images/ にコピーする。

_scifi_bg_chip.png


使用画像を .h に変換したファイル。hacks/images/gen/ 以下にコピーする。ただ、本来は、make時に *.png から自動生成されるはず。

_scifi_bg_chip_png.h


hacks/Makefile.in や driver/XScreenSaver.ad.in の変更点は以下。「hellotilemap」で検索すれば、どのあたりを修正してるか分かるかなと。

_makefile.in.patch
_xscreensaver.ad.in.patch


一応、xscreensaver に自作のスクリーンセーバを追加して、ビルドする手順もざっくりとメモ。公式リポジトリ版を上書きしちゃうけど…。

mkdir ~/pkg
mkdir ~/pkg/xscreensaver
cd ~/pkg/xscreensaver
wget https://www.jwz.org/xscreensaver/xscreensaver-6.04.tar.gz
tar zxvf xscreensaver-6.04.tar.gz
cd xscreensaver-6.04

# file copy

*.c : copy to hacks/
*.man : copy to hacks/
*.xml : copy to hacks/config/
*.png : copy to hacks/images/
*_png.h : copy to hacks/images/gen/
Makefile.in : copy to hacks/
XScreenSaver.ad.in : copy to driver/

# build

./configure --prefix=/usr --libexecdir=/usr/lib
make
sudo make install

rm ~/.xscreensaver
xscreensaver-settings &

少し解説。

基本的には、 _昨日、 書いた、 _09tilemap1.c をコピペしていっただけ。

ただし、xscreensaver 上では、XClearWindow() を呼んでしまうとエラーになることに気づかなくて結構ハマった。 Pixmap を対象にして中身をクリアしたかっただけなので、XFillRectangle() を使って塗り潰してしまえばOKだった。

そういえば、このアニメは原作からして顔芸も駆使しまくった作品だと思うけど。顔芸って何時頃から使われ始めたのだろう…。

「DB」「聖闘士星矢」では顔芸なんて使ってなかったよな…。「ゴルゴ13」あたりも使ってないし…。手塚治虫作品や藤子F作品でも使ってないだろうし…。

「進撃の巨人」「ゴールデンカムイ」等を思い返すと、もう顔芸は漫画表現として定着してる気もする。始祖は誰なんだろう…？

もしかして永井豪先生か石川賢先生あたりだろうか。デビルマンやゲッターロボでやってそうな…。

magick montage -tile 8x2 -filter Lanczos -resize 62x62 -unsharp 10x5+0.7+0 -geometry +1+1 -background none render\*.png PNG32:spritesheet.png

magick montage -tile 8x2 -resize 62x62 -unsharp 10x5+0.7+0 -geometry +1+1 -background none render\*.png PNG32:spritesheet.png

そんな感じで、64x64ドットの画像が並んだスプライトシートが得られたので一応アップロード。CC0 / Public Domain ってことで。何か使い道がありそうなら自由に使ってください。

フルカラー画像(RGBA各8bit)。

_spritesheet_lanczos.png


GIMP 2.10.30 で読み込んで、アルファチャンネルを1bitにしたもの。レイヤー → 透明部分 → アルファチャンネルのしきい値、で調整した。

_spritesheet_alpha1bit.png


EDGE2 1.16 dev015 で48色に減色、かつ、少しだけドット修正したもの。

_spritesheet_48col.png


アニメGIFにしたもの。



レンダリング画像(512x512、16枚)。

_render.zip


元のblenderファイル(.blend)も一応置いときます。blender 2.93.9 x64 LTS で作成。

_enemytypec02_lowpoly.zip

ソースは以下。

_10objs.c


使用画像は以下。実際に使ってるのは .xpm。*.xpm は、*.c と同じ場所に置く。

_scifi_bg_chip2.xpm
_scifi_bg_chip2.png


コンパイルは以下。

gcc 10objs.c -o 10objs -I /usr/include/X11 -lX11 -lXext -lm -lXpm

実行は以下。

./10objs

xscreensaver上でも動くかどうか試してみた。 _先日書いたhellotilemap.c を修正。

_hellotilemap.c
_scifi_bg_chip2_png.h
_scifi_bg_chip2.png

一応手元では動いてる。まあ、Xlib利用版と見た目は変わらないけれど…。

簡単な3DCGモデルを作って、45度、30度、22.5度で回転させてみた。

45度ずつ回転。

30度ずつ回転。

22.5度ずつ回転。

元のモデルの作りがよろしくなくて、なんだか分かりづらい気もするけれど。それでも一応、45度はナシだな、ぐらいのことは分かった。最低でも30度、できれば22.5度の回転パターンじゃないと回ってるように見えない気がする。

いやまあ、リアルタイム3DCGでゲーム画面を作るのが当たり前になったこの時代に、こんな検証をしてみても、という気もするのだけど。昔の2Dゲームらしい画面に近づけたい時はこういうのも関係してくるのかもしれないなあ、ということで。あるいは手描きアニメを作る際にも関係してくるのかもしれない。45度ずつの動画は回ってるように見えない、せめて30度は欲しい、とかそんな感じで。

magick spritesheet.png -crop 128x128 +adjoin +repage -adjoin -loop 0 -delay 20 output.gif

色々試していたところ、以下の指定ならディレイ値が反映してくれるようだと分かった。

magick -delay 20 -dispose Background spritesheet.png -crop 128x128 +adjoin +repage -adjoin -loop 0 output.gif

• -delay N : ディレイ値を指定。単位は 1/100秒。
• -dispose (None|Previous|Background) : 背景の消去方法を指定。Background は、フレームを背景色でクリアする。
• -crop NxM : 1フレーム分を切り出すサイズ。N x M のサイズで切り出していく。
• +adjoin +repage -adjoin : 不明。とりあえずこの指定をすると、複数のフレームを持っている画像が出力できるらしい。
• -loop 0 : ループアニメを指定。

要するに、一番最初に「-delay 20」を書いてから、その次に背景の消去方法、「-dispose Background」を記述すれば、期待通りのディレイ値と背景消去方法で生成できる模様。

そんなわけで、以下の画像が得られた。



以下のページで使用事例が色々解説されてる。こういったドキュメントをちゃんと読み込めば、もっと色々な変換作業ができるのだろうな…。

_Animation Basics -- ImageMagick Examples

APNGについて、今時のブラウザの対応状況はどうなっているのだろう。

_Animated Portable Network Graphics - Wikipedia
_APNG - Wikipedia
_Comparison of web browsers - Wikipedia

昔は対応ブラウザが少なかった、というか Firefox しか対応してなかった気がするのだけど、今現在は Google Chrome も対応してくれたらしい。Google Chrome が対応しているということは、Microsoft Edge も、Opera も、Vivaldi も対応してるはず。つまりメジャーなブラウザなら、そのほとんどが APNG に対応済みと捉えてしまっていいのかもしれない。

試しに作ってみた。APNG Assembler で作れるらしいので、APNG Assembler 2.91 GUI版をDLして作業。32bit版と64bit版、GUI版とCUI版があるらしい。

_APNG Assembler download | SourceForge.net
_APNG Assembler
_APNG AssemblerでアニメーションするPNG(APNG)を書き出す - Qiita

作成した APNG を Firefox 101.0.1 x64 にドラッグアンドドロップしたら、たしかにアニメが表示された。これでいいんじゃないかな…。

ここに載せてみたらどうなるだろう。さて、動いているように見えるだろうか…？

_spritesheet_22_5deg_apng.png


Webサーバ側の設定は必要なのだろうか。どうなんだろう。png 扱いのはずだから、特に設定は要らないのかな。

GIMP で APNG を作れないかとググっていたら、「GIMP 2.10 は アニメーションWebPに標準対応してるからそっちを使ったほうがいい」という話を見かけた。

_APNG (animated PNG) plug-in for Gimp 2.10 Windows64x - GIMP Chat

WebP って何だっけ。

_アニメーション画像の歴史 APNG-WebP戦争 | Otogeworks

上記のページで、APNG と WebP に関しての経緯がまとまっていて大変勉強になった。WebPは、アニメーションも、ロスレス画質(画質劣化が一切無い)も、不可逆圧縮(Jpegのようなもの)も、何から何までサポートしたゴイスな画像フォーマット、と思っておけばいいのだろうか。

今時のメジャーなブラウザなら、APNG、WebP、どちらも対応しているらしい。ますますもってアニメGIFを使う理由が無くなってきた。

GIMPを使って作成できるか試してみた。GIMP 2.10.30 Portable x64 samj版を使用。

1. 1レイヤーを1フレーム扱いにして読み込む。アニメGIFを作る際の手順そのままで良い。
2. エクスポート時に、出力ファイル名の拡張子を「.webp」にする。
3. 保存時のダイアログに「Lossless」や「As Animation」という設定項目があるのでチェックを入れて保存。

これで、たしかにアニメーションするWebPが生成できた。


_spritesheet_22_5deg_gimp210.webp


画質設定でロスレス指定もできるようだし、これでもいいんじゃないかな…。

ちなみに、Webサーバ IIS上でWebPを利用するには、「MIMEの種類」に対して設定が必要だった。追加を選んで、「.webp」に「image/webp」を指定しないといけない。

Webサーバ Apache2上でWebPを利用する場合は、「AddType image/webp webp」を .htaccess あたりに追加しておけばいいのかもしれない。たぶん。

前述のフォーラムで紹介されているプラグインを使って、GIMP 2.10 64bit版で APNG の保存ができるか試してみた。

環境は、Windows10 x64 21H2 + GIMP 2.10.30 Portable 64bit samj版。Portable版なので、一般的なGIMPとはフォルダ構成が違ってるかもしれない。

_APNG (animated PNG) plug-in for Gimp 2.10 Windows64x - GIMP Chat

1. apng-Gimp-2.10-64bit.zip をDLして解凍。
2. libpng15-15.dll を、GIMPインストールフォルダ\bin\ にコピー。libpng16-16.dll というファイルが既に入ってるのだけど、いいのだろうか…？
3. file-apng.exe を、ユーザフォルダ\.gimp\plug-ins\ 等の場所にコピー。
4. plug-in-file-apng.ui を、GIMPインストールフォルダ\share\gimp\2.0\ui\ にコピー。
5. GIMPを起動。

アニメGIFを作る時と同様に、1レイヤーを1フレーム扱いにして画像を作成。

これを APNG として保存する。

1. ファイル → 名前を付けてエクスポート。
2. 「ファイル形式の選択」をクリックして、「PNG+APNG Image」を選んで「エクスポート」。
3. 「拡張子が一致しません。この名前で保存してもよろしいですか？」と尋ねてくるけど、気にせず「保存」。
4. 何故かDOS窓が開きつつ、ファイル保存設定ダイアログが表示される。
5. 「Animated PNG Options」の「As animation」にチェックを入れる。
6. 他はPNG保存時のノリで設定して、「エクスポート」。

保存された png を Firefox 101.0.1 64bit や Google Chrome 102.0.5005.63 64bit にドラッグアンドドロップしてみたけれど、アニメ画像として再生された。

_spritesheet_22_5deg_apng_from_gimp210.png


ただ、この file-apng.exe を導入すると、GIMP の起動時に一瞬DOS窓が開いて閉じるあたりが気になる…。APNG保存時に、DOS窓が開くのも気になる…。でもまあ、動いてるからいいか…。

手元の環境では GIMP 2.8.22 Portable x86 もインストールしてあるけれど、そちらにも file-apng.exe は導入済みだった。APNG で保存したい時は GIMP 2.8.22 Portable を使えば済むのかもしれない。

_APNG support for GIMP download | SourceForge.net

などと思ったりもしたのだけど、GIMP 2.8.22 Portable を起動して APNG のエクスポートを試してみたら、保存時の設定ダイアログが表示されないことに気づいた。DOS窓上に file-apng.ui 関係のエラーが大量に発生している。どうやら以前から正常動作してなかったらしい。

エラーメッセージを眺めたら、「GIMP 2.8.22 Portableインストールフォルダ\App\gimp\lib\gimp\2.0\plug-ins\ 以下に file-apng.ui が無いぞ」と言ってるように見えた。もしかすると .ui ファイルを読み込んでくる場所については決め打ちで作ってあるのかもしれない。試しにその場所に file-apng.ui を置いてみたらエラーが出ない状態になって、APNGでのエクスポートができるようになった。

ちなみに、file-apng.exe は、ユーザフォルダ/.gimp-2.8/plug-ins/ に置いてあっても動いてくれた。.ui の置き場所だけは注意、ということになるのだろうなと。

GIMPでアニメGIF等を作る場合、レイヤー名にディレイ値(wait時間)を書いておくことで、各フレームの表示時間を個別に変更できるのだけど、以下のスクリプトを利用すれば全レイヤーに対して一括で値を変更できるので便利。

_フレーム表示時間変更

フィルタ → アニメーション → フレーム表示時間変更、で呼び出せる。

このあたり、以前もメモしてあった…。

_GIMPでGIFアニメを作成する際のwait値を変更するスクリプトその2

各スクリプトを追加すると、フィルター → アニメーション以下のメニューに追加される。

• フレーム表示時間変更
• Rename Layers...
• Set frames delay...
• Change frame delays...

最初の2つは、Combine、Replace の指定も選べる。後の2つはディレイ値のみを追加する。最初の2つのうちのどちらかをインストールしておけば済みそうな気がする。

ImageMagick でも APNGを出力できないものかと調べてみた。環境は、Windows10 x64 21H2 + ImageMagick 7.1.0-37 Q16-HDRI x64。static版。

スプライトシート画像からアニメGIFを生成する指定に対して、アニメGIFではなくAPNGで保存するように変更すればOKだったりしないか。ググったところ、「apng:output.png」と書けば APNG を指定することになるらしい。

_ImageMagick - Image Formats

試してみた。どうだろう。動いてるように見えるだろうか。

magick -delay 3 -dispose Background spritesheet.png -crop 128x128 +adjoin +repage -adjoin -loop 0 apng:output.png

_spritesheet_22_5deg_apng_from_im7.png

ImageMagick で アニメーションWebPを出力できるだろうか。以下のページによると、7.0.8-68 で対応、と書いてあるので、使えそうな気がする。

_ImageMagick と WebP - Qiita

試してみた。

magick -delay 7 -dispose Background spritesheet.png -crop 128x128 +adjoin +repage -adjoin -loop 0 output.webp

_spritesheet_22_5deg_im7.webp

これで、ImageMagick を使えばアニメーションWebPを出力することも可能、と分かった。ただ、この指定では、ロスレス画質は指定してないので、不可逆圧縮で出力されてるのではないか。

前述の解説ページに、ロスレスを指定する時は「-define webp:lossless=true」をつける、と書いてあった。これも試してみる。

magick -delay 7 -dispose Background spritesheet.png -crop 128x128 +adjoin +repage -adjoin -loop 0 -define webp:lossless=true output_lossless.webp

_spritesheet_22_5deg_im7_lossless.webp

ファイルサイズが、10.9 KByte から 61,9 KByte に増えたので、おそらくロスレス画質になっているのではないかな…。たぶん。

でも、見た感じ、違いは全然分かりませんな…。

GIMP 2.10.30 で両方開いて、拡大表示をして確認してみたけれど、たしかに不可逆圧縮とロスレスの違いはあった。でも、等倍表示では分からない程度の微妙な差だなと…。

magick input.png -channel alpha -threshold 85% output.png

ここまでできたら、減色処理も ImageMagick でやれないものかと思って試していたのだけど。

_ImageMagick の減色処理 - Qiita

これはちょっと、思っていた通りの結果にならず。自分は市松模様っぽいディザが好きなので、そういう見た目の減色結果が欲しいのだけど、ImageMagick で処理をすると誤差拡散っぽいディザパターンになってしまう。まだ、EDGE2 か GIMP で減色したほうが自分好みの結果になるなと…。いやまあ、GIMP の減色処理もなかなかに酷いのだけど。あちこちに突飛な色のドットが出現してしまう。なんでだろ。

以下のページに、ImageMagick の使用例が色々載ってるのでメモ。

_Examples of ImageMagick Usage


日本語で膨大な量の解説記事を書いてくれてる方がいらっしゃる。ありがたや。マジで助かります。

_ImageMagick 解説インデックス - Qiita


ImageMagick で射影変換できるなんて知らなかった。ラッパーを書けば便利に使えるのではあるまいか…。

_ImageMagick で射影変換 (Homography, Perspective projection) - Qiita

ググっていたら、DB8、DB16、DB32パレット等がまとめてあるページに遭遇。

_geoffb/dawnbringer-palettes: Limited color palettes by DawnBringer in various formats.

.csv やGIMPのパレットファイルまで置いてある。ありがたや。

ググっていたら、iZYINS というソースが存在すると知った。

_iZYINS : Color Reducer on .NET Framework Project Top Page - OSDN

xPadieのソースコードを参考にした、.NET FrameworkやMONO上で動作する、C#で書かれた減色プログラムのソースコードを、研究用あるいは教育用にGPLで公開します。

iZYINS : Color Reducer on .NET Framework Project Top Page - OSDN より

こういった研究をする場合は参考になりそう。

また、減色処理について研究を続けている方のブログにも遭遇。少なくとも2015年頃からずっと研究してるらしい。

_画像処理（減色、限定色表示） - ずるやすみねこのリサイズ研究
_作者: zuruneko - Vector
_ZURUYASUMINEKOのホームページ
_減色
_ハーフトーン技術

研究成果の一部については、仕様を限定した状態で Vector で公開されている模様。ソースもブログに貼り付ける形で公開されているけれど、環境も、ビルド方法も分からない…。もっとも、この手の研究をしている方々なら、ソースを眺めれば理解できてしまうものだったりするのかもしれない。

減色ツールに限らず、png画像の最適化ツールの類についても調べていたけど、海外ではこの手のツールの作り方についてなんだか傾向があるように感じた。

減色処理部分をGUIツールに含める形で作ってしまうと、そこでそのツールは閉じてしまって、たとえ減色処理が優秀であっても、「操作が不便」「複数画像に対して処理ができない」等の理由で敬遠されてしまう ―― そんな気配があるなと。

しかし、減色処理部分をコマンドラインツールとして作っておけば、別の誰かがそのツールを呼び出すGUIのラッパーを作ってくれたりして、減色処理自体の研究と、変換作業時の利便性追求を、切り分けて実装できる。呼んでいるコマンドラインツールが同じなら生成結果も同じになるので、後は使い勝手に注目してラッパーを選べばよい、みたいな状況になる。例えば pngnq や pngquant には、そういった気配を感じた。

このあたり、*NIXの文化なのかなと…。コアになる部分は単機能のツールとして提供しておいて、それらツール群を別の何かで組み合わせて目的を果たす、みたいな。あるいは、不便さを感じたらその時にラッパー書けばいいんじゃね、で済ませていくノリというか。

ビルドに必要なファイルは、ソースファイル(.cpp)が3ファイル、ヘッダファイル(.h)が1ファイル。計4ファイルを、上記のブログからコピペして作成。

• main.cpp
• mediancut.cpp
• mediancut_util.cpp
• mediancut_util.h

ちなみに、コメントが日本語文字列で書かれているので、文字コードは UTF-8N にして保存しておいたほうがヨサゲ。

ビルドに使った環境は、Windows10 x64 21H2 + MSYS2 MinGW 64bit。

g++ と GNU Make が使える環境であること。

$ g++ --version
g++.exe (Rev2, Built by MSYS2 project) 12.1.0

$ make --version
GNU Make 4.3
このプログラムは x86_64-pc-msys 用にビルドされました
Copyright (C) 1988-2020 Free Software Foundation, Inc.

MSYS2 のインストールは、以下のページが参考になりそう。

_MSYS2/MinGW-w64 (64bit/32bit) インストール手順 メモ
_【msys2】インストール [新石器Wiki]
_MSYS2 MinGW GCC環境をつくる（その1）

ビルドの手順としては、*.cpp をコンパイルして *.o を作って、その *.o 達をリンカで結合して実行バイナリを作るわけだけど…。

勉強も兼ねて、Makefile を書いてみた。Makefile の書き方は詳しくないので、無駄が多い記述になってるかもしれんけど…。

_Makefile.msys2

CXX = g++
CXXFLAGS = -O2
SRCS = main.cpp mediancut.cpp mediancut_util.cpp
OBJS = $(SRCS:.cpp=.o)
PROGRAM = bmp_color_reducer.exe

all: $(PROGRAM)

$(PROGRAM): $(OBJS)
	$(CXX) $(CXXFLAGS) -o $@ $(OBJS) -static -lstdc++ -lgcc -lwinpthread

.cpp.o:
	$(CXX) $(CXXFLAGS) -c $< -o $@

mediancut.o: mediancut_util.h
mediancut_util.o: mediancut_util.h

.PHONY: clean
clean:
	rm -f *.o
	rm -f $(PROGRAM)

余談。Makefile内のインデントは、スペースじゃなくてTAB文字にしておくことに注意。

この Makefile.msys2 を、4つのソースファイルと同じ場所に置く。

Makefile.msys2 を Makefile にリネームすれば、単に make と打ち込むだけでビルドできる。

make

あるいは、使う Makefile を指定しても良い。

make -f Makefile.msys2

ちなみに、make clean と打てば、*.o や *.exe を削除するように Makefile 内で指定しておいた。


問題無くビルドができれば、bmp_color_reducer.exe という実行ファイルが生成される。

せっかくだから、ビルドした bmp_color_reducer.exe を zip に入れて置いときます。

_bmp_color_reducer.zip

MSYS2 をインストールしていないサブPC(Windows10 x64 21H2)上でも動いたから、他の環境でも動くのではないかな…。たぶん。

ソース配布先のブログでも説明されているけれど、以下のような指定で減色処理ができるらしい。

bmp_color_reducer.exe -i input.bmp -o output

• 入出力できる画像は、bmp画像のみ。試しに png画像を渡してもエラーを出して受け付けなかった。
• 入力ファイル名は、input.bmp のように、拡張子まで指定する。
• 出力ファイル名は、output のように、拡張子は省略する。自動で「.bmp」をつけてくれる。
• 入力ファイル名、出力ファイル名しか指定していない場合は、256色の画像に減色してくれる。

-irosuu N をつけると、使用する色数を指定できる。以下は、16色、32色を指定して減色する例。

bmp_color_reducer.exe -i input.bmp -o output -irosuu 16
bmp_color_reducer.exe -i input.bmp -o output -irosuu 32

ヘルプ表示は、-h。

bmp_color_reducer.exe -h

その他のオプションは、元ブログの説明を参考に。

_高速版2色以上任意色数減色ソフト１ - ずるやすみねこのリサイズ研究

当初、MSYS2上でビルドした bmp_color_reducer.exe をDOS窓上で実行したら、「DLLが無い」とエラーダイアログが表示されて動かなかった。

ググったら、以下が参考になった。

_msys2とC++で特定のDLLに依存しないwindowsバイナリを作る - siunのメモ

ldd というコマンドを使うと、その実行バイナリが何のDLLを要求するのか ―― 共有ライブラリの依存関係が分かるらしい。

$ ldd bmp_color_reducer.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa18af0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffa18450000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffa164e0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffa181a0000)
        libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x7ff9b7d10000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x7ff9fe9d0000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x7ff9fe920000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x2a5132b0000)

どうやら、/mingw64 から始まる場所に置かれている .dll を見つけることができなくてエラーが表示されてしまった模様。それらの .dll を、.exe に静的リンクしてやれば解決するらしい。

前述の記事を参考にして、g++ に -static -lstdc++ -lgcc -lwinpthread を渡してビルドしたところ、以下のバイナリになった。

$ ldd bmp_color_reducer.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa18af0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffa18450000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffa164e0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffa181a0000)

この状態なら、bmp_color_reducer.exe がDOS窓上でも動いてくれた。

せっかくだから、VMware Player + Ubuntu Linux 20.04 LTS上でもビルドできるか試してみた。

おそらくだけど、Ubuntu Linux の場合、build-essential というパッケージをインストールすれば g++ も make もインストールされるから、それだけでビルドできる状態になるのではないかと。たぶん。ちょっと自信無いけど。

sudo apt install build-essential

_Ubuntu - focal の build-essential パッケージに関する詳細
_Ubuntu LinuxやDebianで使う、build-essentialってなんだ？ - CLOVER
_build-essentialとは - Qiita


*NIX用の Makefile は以下。MSYS2版から、リンカに渡す指定を削って、生成ファイル名の .exe を削っただけ。

_Makefile.unix

CXX = g++
CXXFLAGS = -O2
SRCS = main.cpp mediancut.cpp mediancut_util.cpp
OBJS = $(SRCS:.cpp=.o)
PROGRAM = bmp_color_reducer

all: $(PROGRAM)

$(PROGRAM): $(OBJS)
	$(CXX) $(CXXFLAGS) -o $@ $(OBJS)

.cpp.o:
	$(CXX) $(CXXFLAGS) -c $< -o $@

mediancut.o: mediancut_util.h
mediancut_util.o: mediancut_util.h

.PHONY: clean
clean:
	rm -f *.o
	rm -f $(PROGRAM)

Makefile.unix を Makefile にリネームすれば、make と打つだけでビルドできる。

make

あるいは、Makefile を指定しても良い。

make -f Makefile.unix

make してみたら、いくつか警告は表示されてしまったものの、一応 bmp_color_reducer という実行バイナリが得られた。

実行は以下。

./bmp_color_reducer -i input.bmp -o output

動作確認してみたところ、Windows用バイナリと同様に、減色処理ができているように見えた。

xscreensaver 上で実際に表示してみた。

動作確認環境は Ubuntu Linux 20.04 LTS。Windows10 x64 21H2 + VMware Player上で動かしてる状態。




_先日の見た目 よりは、それらしくなってくれた気がする。


ソース群や使用画像は以下。

_hellotilemap.c
_hellotilemap.man
_hellotilemap.xml
_scifi_bg_chip2_png.h
_scifi_bg_chip2.png


ファイルのコピー先や、ビルドの仕方は、以下でメモしてある。

_xscreensaverでタイルマップ描画

xscreensaver 版と似た感じの処理になるように、Xlib 描画版も修正して試してみた。まあ、見た目は xscreensaver版と同じなのだけど…。

ソースと使用画像は以下。

_10objs.c
_scifi_bg_chip2.xpm


ビルド手順や実行の仕方は、以下でメモしてある。

_Xlibでタイルマップの前に雑魚敵モドキを描画してみた

gcc 10objs.c -o 10objs -I /usr/include/X11 -lX11 -lXext -lm -lXpm
./10objs

POV-Rayのコマンドラインオプションとして、例えば以下のような指定ができる。

• +W512 : 出力画像の横幅を指定。(width=512)
• +H512 : 出漁画像の縦幅を指定。(height=512)
• +a0.3 : Antialias を on にして、Threshold 0.3 を指定。(Antialias_Threshold=0.3 Antialias=on)
• +UA : 出力画像のアルファチャンネルを有効化。(Output_Alpha=on)
• +KFF20 +KC : フレーム数を20に。ループアニメ有効化。(Final_Frame=20 Cyclic_Animation=on)

+KFFxx を指定することで、clock という変数が 0.0 - 1.0 まで xxフレームで変化するので、オブジェクトの座標指定などに clock を含めた数式を書けばアニメーション画像が作れる。

ただ、ループアニメを作る場合、+KFFxx を指定しただけでは、一番最初のフレームと最後のフレームが同じ画になってしまう。+KC を指定することで最後のフレームを余分にレンダリングしなくて済む状態になる。

.pov ファイルの最初のあたりに、コメント行として以下のような記述をしておけば、POV-Rayエディタで開いた際に該当行を右クリックしてコマンドラインオプション入力欄にコピーできる。

// +W512 +H512 +a0.3 +UA +KFF20 +KC

「こういう条件でレンダリングしたよ」と未来の自分に伝えたいなら、書いておいたほうがヨサゲ。

各オブジェクトの定義の最後で「no_image」を指定すれば、そのオブジェクトについてはレンダリングしない状態にできる。

例えば、背景に相当するオブジェクトを定義しておいて、その中で「no_image」を指定すれば、対象オブジェクトの表面には背景の映り込みをさせつつ、背景部分だけを透明な状態にできる。まあ、これについては以前のメモを見たほうが分かりやすいはず…。

_POV-Rayで任意のオブジェクトをレンダリング対象から外す

複数のレンダリング画像が得られたら、ImageMagick を使ってスプライトシート画像を作れる。

magick montage -filter Lanczos -resize 78x78 -unsharp 10x5+0.7+0 -geometry +1+1 -background none render_512x512/*.png PNG32:spritesheet.png

• -filter Lanczos : リサイズフィルタに Lanczos を指定。
• -resize 78x78 : 78x78ドットにリサイズ。
• -unsharp 10x5+0.7+0 : アンシャープマスクをかける。
• -geometry +1+1 : (1,1)の位置にずらす。リサイズの大きさが 78x78 だったので、結果的に1フレーム 80x80 になる。
• -background none : 背景を透明化。
• render_512x512/*.png : 入力ファイル群を指定。
• PNG32:spritesheet.png : 出力ファイル名を指定。RGBA各8bitの png が欲しい場合、PNG32: をファイル名の前につける。

ImageMagick を使って、スプライトシートからアニメgifを作れる。

magick -delay 2 -dispose Background spritesheet.png -crop 80x80 +adjoin +repage -adjoin -layers OptimizeFrame -loop 0 output.gif

• -dispose Background : 背景の消し方を指定。
• spritesheet.png : 入力画像を指定。
• -crop 80x80 : 1フレームを80x80で切り出す。
• +adjoin +repage -adjoin : 不明。
• -layers OptimizeFrame : アニメgifを最適化。
• -loop 0 : ループアニメを指定。(ループ回数制限を無しにしている。)
• output.gif : 出力ファイル名を指定。

いっそこのあたり、どこかでイベントにしてみたらどうだろうか。例えばドワ〇ゴあたりで、「21世紀のレナさんコンテスト」を開いたりしないか、などとバカ妄想。

「コンピュータの画像処理分野で使われる写真画像を募集します」
「ひょっとすると、50年も100年も200年も、世界中で、英文で書かれた論文の類に頻繁に登場する、そんな扱いになるかもしれません」
「『俺(私)のこのポートレートなら、見てくれ的にかなり自信あるから使っていいよ。何十年も使われちゃう？ どんとこいだぜ』と仰ってくれる奇特な方は居ませんか？」

みたいな。

こういうのって、売り出し中の若手芸人さんあたりには美味しい話だったりしないか…。

「前々から気になってたけど、この手の論文にいつも出てくるこの人、一体何者なん？」
「ああ、彼(彼女)は日本のコメディアンらしいよ。たしか名前は…」

世界(の画像処理研究者達の間)で一番有名な男(女)になれる。知名度上げたい人にとっては、ちょっと美味しくないですか。

ただ、画像内で肌色成分が多いと、Google や Apple や Microsoft のAIが卑猥な画像として誤認識して、画像を載せてる論文ごとWeb上から即BANされる可能性が高い…。海パン一枚で持ちネタを披露する系の写真は、テスト画像としてアウトでしょうな…。

レナさん画像の代替画像を選んで決定する過程をTV番組に出来ないものか。

「俺(私)の写真使っていいよ」と言い出した芸人さん・芸能人さんを集めて、プロの写真家さん達に渾身の一枚を撮影してもらう。撮り方次第で被写体はここまで化けますよ、写真家さんってスゴイよね、と紹介するのが第一章。

AI研究をしてる人も呼んできて、画像分析してもらうのが第二章。現時点のAI技術の可能性と限界を紹介する。

「あー。これはダメですね。卑猥画像として認識されました」
「ダメかー。ノースリーブがあかんのかなあ。それとも乳首かなあ」
「これは…人間じゃなくてチンパンジーとして認識されてますね」
「なんでや！ ワシは人間や！」
(テロップ「AIにチンパンジー認定された男」)

何らかの方法でNo.1画像が決まったら、いよいよ感動の最終章。モデルになってくれた人に海外まで行ってもらって、レナお婆さんに直接お会いする。番組側で用意した証書を ―― 「これからは私の代わりにテクノロジーの発展に貢献してくださいね」的証書みたいなものを、初代(?)から二代目(?)に手渡してしてもらって、熱いハグ。「こうして伝統(?)は引き継がれた。これからはこの写真をレナさん画像の代わりに使いましょう」と視聴者に啓蒙して終わる。みたいな。

もっとも、最初から狙って用意したこういうアレコレって大体はスルーされがちだし、実際やってみてもどうせ全然普及しないままだろうな…。そして、何故か問題がある画像がいつまでも使われ続ける…。えてしてそういうパターンになるよな…。

以上、馬鹿馬鹿しい妄想メモでした。

レナさん画像の良いところは、目にした瞬間、「ああ、コレって画像処理の話ですね？」と予想できるところかもしれないなと。そういう共通認識が持てるなら、代替画像って実はどんな画像でも良かったりするのかもしれず。

_PillowのImage.mergeの使い方: 画像のバンドをマージする - なるぽのブログ
_【Python/Pillow(PIL)】画像の輝度値の取得／設定 | イメージングソリューション
_Pythonで画像のピクセル操作 - Qiita
_【Python】PILで高速に全画素アクセスを行う - kuranabeの開発備忘録
_PILでのピクセル単位での操作 - 自分のためのPython Wiki

Pillow (PIL) は、Python に付属している pip というツールを使って、インターネット経由でインストールできる。

pip install Pillow
pip install Pillow -U

• -U をつけると、モジュールを現行版にアップデートできる。

RGB画像を読み込んで、チャンネル別(R,G,B)に分解してみる。

以下の事例では、チャンネル別に分解した後、各チャンネル(グレースケール)を2値化して、それをまたRGBに結合？ 合成？ し直している。

_01split.py

from PIL import Image


def main():
    im = Image.open("mandrill.png")
    width, height = im.size
    print("%d x %d" % (width, height))

    rc, gc, bc = im.split()

    rc1 = rc.convert("1").convert("L")
    gc1 = gc.convert("1").convert("L")
    bc1 = bc.convert("1").convert("L")

    oim = Image.merge("RGB", (rc1, gc1, bc1))
    oim.show()
    oim.save("output_01split.png")


if __name__ == '__main__':
    main()

py 01split.py で実行。以下が得られた。



各チャンネルを2値化したことで、元画像と比べるとディザがかかった状態になっている。



各行について、簡単に説明。

• PIL (Pillow) の Image クラスを使うには、最初のあたりで、from PIL import Image と記述。
• im = Image.open("mandrill.png") で、画像を読み込む。
• im.size には、画像の横幅と縦幅が入っている。w, h = im.size で、横幅と縦幅を w と h にコピー。
• チャンネルを分解するには、.split() を使う。r, g, b = im.split() で、r,g,b に各チャンネルが入る。
• .convert() を使えば画像のモード(?)を変換できる。"1" を指定すれば2値化される。"L" を指定すればグレースケールになる。
• チャンネルを結合？ 合成？ するには、Image.merge() を使う。oim = Image.merge("RGB", (r, g, b)) で、r,g,bチャンネルを合成して、RGB画像にして返す。
• im.show() で、画像を表示。自分の環境では、png を、画像ビューア IrfanView に関連付けているので、im.show() を呼ぶと IrfanView が起動して画像が表示される。
• im.save("output.png") で画像を保存。ファイル名の拡張子によって、保存に使う画像フォーマットを Pillow (PIL) が自動で選んでくれる。

画像内から1ドットずつ値を読んで処理をする際は、.getpixle()、.putpixel() を使える。

以下の事例では、RGB画像を読み込んでグレースケールに変換した後、各ドットの値を反転して(255-v)、新規画像に書き込み直している。

_02getpixel.py

from PIL import Image


def main():
    im = Image.open("mandrill.png")
    width, height = im.size
    print("%d x %d" % (width, height))

    gim = im.convert("L")
    oim = Image.new("L", (width, height))

    for y in range(height):
        for x in range(width):
            v = 255 - gim.getpixel((x, y))
            oim.putpixel((x, y), (v))

    oim.show()
    oim.save("output_02getpixel.png")


if __name__ == '__main__':
    main()

py 02getpixel.py で実行。以下が得られた。

• im = Image.new("L", (w, h)) で、w x h サイズのグレースケール画像を新規作成。"L" を "RGB" にすれば、グレースケールではなくRGB画像を新規作成できる。
• im.getpixel((x, y)) で、(x, y) 座標のドットの値を取得できる。
• im.putpixel((x, y), (r, g, b)) で、(x, y) 座標のドットの値を設定できる。

ただ、.getpixel()、.putpixel() は、処理が遅いという話も見かけた。自分の手元の環境(Ryzen 5 5600X)では、そんなに遅いようには見えてないのだけど…。

少しでも処理を速くしたい場合は、以下のような書き方もできる模様。Pillow 1.1.6a1 の時点での追加機能、と ChangeLog(?) には書いてあるように見える。

_Pillow/CHANGES.rst at main - python-pillow/Pillow

* Added pixel access object. The "load" method now returns a access object that can be used to directly get and set pixel values, using ordinary [x, y] notation:

pixel = im.load()
v = pixel[x, y]
pixel[x, y] = v

If you're accessing more than a few pixels, this is a lot faster than using getpixel/putpixel.

Pillow/CHANGES.rst at main ・ python-pillow/Pillow より

_03getpixel2.py

from PIL import Image


def main():
    im = Image.open("mandrill.png")
    width, height = im.size
    print("%d x %d" % (width, height))

    gim = im.convert("L")
    oim = Image.new("L", (width, height))

    gpixel = gim.load()
    opixel = oim.load()

    for y in range(height):
        for x in range(width):
            opixel[x, y] = 255 - gpixel[x, y]

    oim.show()
    oim.save("output_03getpixel2.png")


if __name__ == '__main__':
    main()

py 03getpixel2.py で実行。以下が得られた。

• pixle = im.load() で、ピクセル値を配列っぽい形で取得。
• pixel[x, y] で、各ピクセルを読み書きできる。

しかし、処理速度がそれほど変わったようには見えてないのだけど…。もしかして、Pillow (PIL) の現行バージョンでは、.getpixel()、.putpixel() の処理速度は改善済み、というオチだったりしないか…。分からんけど。

Pillow (PIL) を使って、グラデーション画像を作ってみる。

今回は、矩形の塗りつぶしを繰り返すことで目的を果たした。

_04gradation.py

from PIL import Image, ImageDraw


def make_gradation_image(w, h):
    im = Image.new("L", (w, h), (128))
    draw = ImageDraw.Draw(im)
    for y in range(16):
        for x in range(16):
            v = y * 16 + x
            x0 = x * w / 16
            y0 = y * h / 16
            x1 = (x + 1) * w / 16 - 1
            y1 = (y + 1) * h / 16 - 1
            # draw.rectangle((x0, y0, x1, y1), fill=(v), outline=(0))
            draw.rectangle((x0, y0, x1, y1), fill=(v), outline=None)
    return im


def main():
    im = make_gradation_image(512, 512)
    im.show()
    im.save("gradation.png")


if __name__ == '__main__':
    main()

py 04gradation.py で実行。以下の画像が得られた。0-255までの値で塗り潰されている。

_gradation.png

• Pillow (PIL) で何かしらを描画する際は、ImageDraw が使える。最初のあたりで、from PIL import Image, ImageDraw と記述。
• draw = ImageDraw.Draw(im) で、描画のためのクラス？ グラフィックコンテキスト？ を取得。
• draw.rectangle((x0, y0, x1, y1), fill=(v), outline=None) で、矩形塗り潰し。(x0, y0) が左上の座標。(x1, y1) が右下の座標。fill=(r, g, b) で塗り潰し色を指定。outline=None で境界線無しを指定。outline=(r, g, b) で境界線の色を指定。

諧調を持った画像を0/1のみで疑似的に表現する際に、ディザリングという手法が利用できる。ディザリングの種類は色々あるけど、その中の Ordered dithering というのを試してみた。

_Ordered dithering - Wikipedia
_配列ディザリング - Wikipedia
_Unityでディザリングシェーダを作ってみた - WonderPlanet Developers’ Blog
_105AI研究所: ベイヤーディザフィルタ（BayerDitherFilter）
_ImageMagick/thresholds.xml at main - ImageMagick/ImageMagick

上記の参考ページを眺めてみたけど、処理としては以下のような簡単な処理で実現できるらしい。

1. ディザ配列から、しきい値の配列を作る。
2. x, y の座標値を、ディザ配列の数で割って余りを求める。
3. 得られた余りを使って、しきい値の配列から、しきい値を取得。
4. そのドットの値と、しきい値を比較して、0 or 1 (0 or 255) で置き換える。

以下は、グレースケール画像を読み込んで、2x2, 3x3, 4x4, 8x8 のディザをかけて保存する例。

_05ordered_dithering.py

from PIL import Image


odtbl2x2 = [
    [1, 3],
    [4, 2]
]

odtbl3x3 = [
    [3, 7, 4],
    [6, 1, 9],
    [2, 8, 5]
]

# odtbl3x3 = [
#     [7, 9, 5],
#     [2, 1, 4],
#     [6, 3, 8]
# ]

odtbl4x4 = [
    [1, 9, 3, 11],
    [13, 5, 15, 7],
    [4, 12, 2, 10],
    [16, 8, 14, 6]
]

odtbl8x8 = [
    [1, 33, 9, 41, 3, 35, 11, 43],
    [49, 17, 57, 25, 51, 19, 59, 27],
    [13, 45, 5, 37, 15, 47, 7, 39],
    [61, 29, 53, 21, 63, 31, 55, 23],
    [4, 36, 12, 44, 2, 34, 10, 42],
    [52, 20, 60, 28, 50, 18, 58, 26],
    [16, 48, 8, 40, 14, 46, 6, 38],
    [64, 32, 56, 24, 62, 30, 54, 22]
]

odtbls = {
    "2x2": [5, odtbl2x2],
    "3x3": [10, odtbl3x3],
    "4x4": [17, odtbl4x4],
    "8x8": [65, odtbl8x8]
}


def get_dither_table(odtype):
    d, tbl = odtbls[odtype]
    w = len(tbl[0])
    h = len(tbl)
    odtbl = [[0 for i in range(w)] for j in range(h)]

    for y in range(h):
        for x in range(w):
            odtbl[y][x] = tbl[y][x] * 256 / d

    return w, h, odtbl


def get_dither_image(odtype, im):
    width, height = im.size
    oim = Image.new("L", im.size)

    tw, th, od = get_dither_table(odtype)

    src_pixel = im.load()
    dst_pixel = oim.load()

    for y in range(height):
        dy = y % th
        for x in range(width):
            dx = x % tw
            if src_pixel[x, y] < od[dy][dx]:
                dst_pixel[x, y] = 0
            else:
                dst_pixel[x, y] = 255

    return oim


def main():
    # im = Image.open("mandrill.png").convert("L")
    im = Image.open("gradation.png")

    for odtype in ["2x2", "3x3", "4x4", "8x8"]:
        oim = get_dither_image(odtype, im)
        oim.save("output_dither_%s.png" % odtype)


if __name__ == '__main__':
    main()

py 05ordered_dithering.py で実行。4つの画像が生成される。

先ほど作成した gradation.png を読み込んで変換してみた。

元画像。256段階の諧調が含まれている。

2x2。5段階の疑似諧調を表現できる。

3x3。10段階の疑似諧調を表現できる。

4x4。17段階の疑似諧調を表現できる。

8x8。65段階の疑似諧調を表現できる。

猿(マンドリル)画像でも試してみる。

2x2。
3x3。
4x4。
8x8。

どれもそれっぽく変換できたような気がする。

さて、グレースケール画像を0/1で表現することはできたけど…。複数の色を指定して変換するにはどうしたらいいのだろう…。

RGB8色のみを使って表現するだけでも良いのであれば、RGBチャンネル別にディザリングをかけて、最後に合成すれば済みそうな気がする。しかし、一般的な減色処理として行いたいなら、もうちょっと何かやらないといけないはず…。画像内で使われている色の中から残したい色を決定して、その残したい色では表現できない部分についてはディザを使って疑似表現、ということになるはずで…。どうすればいいんだろうな…。

半日ほど作業して思ったのですが。猿の画像では学習モチベーションが上がらない…。やっぱりレナさん画像のようなテスト画像を使いたいなあ…。

この手の実験をする時って、何十回、何百回、何千回と、その画像を拡大表示しながら「ここのドットが変だな…」「このドットの色はおかしくないか…」とチェックを繰り返すわけでして。なのに、その画像が、猿の画像ですよ。猿ですよ、猿。いくら「カラフルで奇麗な画像だよねー」って言ってみたところで猿は猿なんだよ！ 下手すると何千回も猿を見つめ続けるわけですから当然精神的には苦痛なわけですよ。こんなん頭がおかしくなるわ。少し上の猿4連発を眺めただけでも自分ちょっと嫌な感じの汗出てきましたもん。コレ、ボディブローのように地味に効いてくるわ…。

どうせなら美しさを感じる画像を ―― 何度凝視したって全然ウンザリしてこない画像を使って実験したい。だから皆、こぞってレナさん画像で実験してたわけでね…。レナさんの御姿なら、256回でも65536回でも余裕で凝視できますわ。それぐらいの美しさがレナさん画像にはある。その美しさのおかげで心が折れずにトライアンドエラーを繰り返せる。レナさん画像がテクノロジーの発展に寄与してきたというのはガチですわ。猿に睨まれてたら挫けてた。レナさんがあの眼差しでこっちを見つめてくれて、こっちもソレを延々見つめ返したから、画像処理という分野はここまで来れたわけですよ。

でも、御本人が「もうやめろや」と仰られているのでは…ねえ…。代替画像、無いのかなあ…。

_見比べ君2 -ソフトウェアの部屋-
_見比べ君2 - ｋ本的に無料ソフト・フリーソフト

コレは良さそう。と思ったのだけど png に対応してなかった。残念。jpg には対応している模様。

_DiffImg download | SourceForge.net

画像の異なる部分を色をつけて表示してくれる。pngも開けた。数ドット程度の違いを見つけ出したい場合は便利かもしれない。

ただ、入力ファイル名を指定するウインドウに、エクスプローラ等からファイルをドラッグアンドドロップできなかったのと、画像のサムネイルをクリックしないと画像表示を切り替えられなかったのがちょっと残念。

_pixDiff - 使い方
_pixDiffの詳細情報 : Vector ソフトを探す！

ワイパーを使って画像を見比べることができる。pngも開けた。スコープ表示も ―― マウスカーソルの近くに四角を表示して、四角の中だけ別画像を表示する機能も便利そう。

ただ、別々のフォルダに入っている画像をドラッグアンドドロップで指定することはできないっぽい。ファイル → 画像を開く、から別々のフォルダに入ってる画像を指定することはできた。

512x512の画像を1:1で表示した際、画面の真ん中に妙な線が入るあたりは少し気になった。OpenGLを使っているっぽいので、ドライバ側の問題かもしれない。環境は、NVIDIA GeForce GTX 1060 6GB。OpenGL Version 4.6.0 NVDIA 512.77、と表示されている。

_画像ワイパー

pixDiff の前身となったソフトだろうか…？ pngも開けた。ウインドウへのファイルのドラッグアンドドロップはできない模様。

_WinMerge 日本語版
_「WinMerge」2つのテキストの異なる点を色分け表示 - 窓の杜
_開発ツール/画像比較もできるWinMerge - Windowsと暮らす

WinMerge でも画像比較ができると今頃になって知った。左側と右側に別々の画像を表示して比較できる。エクスプローラ上で右クリックして「左側として選択」「比較」を選べば、別々のフォルダに入った画像も比較できる。

自分の場合、今まで WinMerge をテキストファイルの比較に使っていたのだけど、画像に対してもいつものノリで比較できる点はありがたいなと。ひとまずコレさえインストールしておけば、比較作業ができるのは助かる…。

RGB画像を、Rチャンネル、Gチャンネル、Bチャンネルに分解して、それぞれに対してディザリングをしてから最後に合成すればそれっぽくならないかなと思えてきたので試してみた。

_06ordered_dithering_8col.py

from PIL import Image


odtbl2x2 = [
    [1, 3],
    [4, 2]
]

odtbl3x3 = [
    [3, 7, 4],
    [6, 1, 9],
    [2, 8, 5]
]

# odtbl3x3 = [
#     [7, 9, 5],
#     [2, 1, 4],
#     [6, 3, 8]
# ]

odtbl4x4 = [
    [1, 9, 3, 11],
    [13, 5, 15, 7],
    [4, 12, 2, 10],
    [16, 8, 14, 6]
]

odtbl8x8 = [
    [1, 33, 9, 41, 3, 35, 11, 43],
    [49, 17, 57, 25, 51, 19, 59, 27],
    [13, 45, 5, 37, 15, 47, 7, 39],
    [61, 29, 53, 21, 63, 31, 55, 23],
    [4, 36, 12, 44, 2, 34, 10, 42],
    [52, 20, 60, 28, 50, 18, 58, 26],
    [16, 48, 8, 40, 14, 46, 6, 38],
    [64, 32, 56, 24, 62, 30, 54, 22]
]

odtbls = {
    "2x2": [5, odtbl2x2],
    "3x3": [10, odtbl3x3],
    "4x4": [17, odtbl4x4],
    "8x8": [65, odtbl8x8]
}


def get_dither_table(odtype):
    d, tbl = odtbls[odtype]
    w = len(tbl[0])
    h = len(tbl)
    odtbl = [[0 for i in range(w)] for j in range(h)]

    for y in range(h):
        for x in range(w):
            odtbl[y][x] = tbl[y][x] * 256 / d

    return w, h, odtbl


def get_dither_image(odtype, im):
    width, height = im.size
    oim = Image.new("L", im.size)

    tw, th, od = get_dither_table(odtype)

    src_pixel = im.load()
    dst_pixel = oim.load()

    for y in range(height):
        dy = y % th
        for x in range(width):
            dx = x % tw
            if src_pixel[x, y] < od[dy][dx]:
                dst_pixel[x, y] = 0
            else:
                dst_pixel[x, y] = 255

    return oim


def main():
    im = Image.open("mandrill.png")
    r, g, b = im.split()

    odtype = "4x4"
    rim = get_dither_image(odtype, r).convert("L")
    gim = get_dither_image(odtype, g).convert("L")
    bim = get_dither_image(odtype, b).convert("L")

    oim = Image.merge("RGB", (rim, gim, bim))
    oim.save("output_8col.png")


if __name__ == '__main__':
    main()

py 06ordered_dithering_8col.py で実行。output_8col.png というファイル名で、以下のRGB画像が得られる。



見た感じ、一応どうにかカラー画像(RGB画像)に対してもディザがかかっているように見えなくもないなと…。

ただ、RGB各チャンネルが、0 or 1 (0 or 255) の値しか持ってないから、全部で 2 x 2 x 2 = 8色しか使ってないわけで…。当然ながら、結構悲惨な見た目になってるというか。

もっとも、230427色使ってた画像を、たった8色しか使ってない画像に変換して、このぐらいそれらしさが残ってるなら、これはこれでイイ感じなのでは、という気もしてくる。

ちなみに、昨日試した、Pillow の .convert("1") を使った事例 ―― RGBチャンネルを分解して、それぞれ2値化して、合成した結果とかなり近い結果になった気もする。使用色数はどちらも8色なわけで…。


違いは、ディザの種類が Ordered dithering か、Floyd Steinberg dithering か、ぐらいではないのかなと…。たぶん。

_フロイド-スタインバーグ・ディザリング - Wikipedia

RGB各チャンネルに対して0/1しか使ってない状態にしてしまうから厳しい見た目になるのではないか、もっと段階を持たせたら改善しないかなと思えてきた。もちろん、段階を持たせた分、使用色数は増えるわけだけど。

つまり、以下のような感じで処理できないかな、と。


そんなわけで試してみた。

_07ordered_dithering_ncol.py

from PIL import Image
import sys

odtbl2x2 = [
    [1, 3],
    [4, 2]
]

odtbl3x3 = [
    [3, 7, 4],
    [6, 1, 9],
    [2, 8, 5]
]

# odtbl3x3 = [
#     [7, 9, 5],
#     [2, 1, 4],
#     [6, 3, 8]
# ]

odtbl4x4 = [
    [1, 9, 3, 11],
    [13, 5, 15, 7],
    [4, 12, 2, 10],
    [16, 8, 14, 6]
]

odtbl8x8 = [
    [1, 33, 9, 41, 3, 35, 11, 43],
    [49, 17, 57, 25, 51, 19, 59, 27],
    [13, 45, 5, 37, 15, 47, 7, 39],
    [61, 29, 53, 21, 63, 31, 55, 23],
    [4, 36, 12, 44, 2, 34, 10, 42],
    [52, 20, 60, 28, 50, 18, 58, 26],
    [16, 48, 8, 40, 14, 46, 6, 38],
    [64, 32, 56, 24, 62, 30, 54, 22]
]

odtbls = {
    "2x2": [5, odtbl2x2],
    "3x3": [10, odtbl3x3],
    "4x4": [17, odtbl4x4],
    "8x8": [65, odtbl8x8]
}


def get_dither_table(odtype, vrange, ofs):
    d, tbl = odtbls[odtype]
    if d >= vrange:
        print("Error: dither table range >= vrange")
        sys.exit()

    w = len(tbl[0])
    h = len(tbl)
    odtbl = [[0 for i in range(w)] for j in range(h)]

    for y in range(h):
        for x in range(w):
            odtbl[y][x] = tbl[y][x] * vrange / d + ofs

    return w, h, odtbl


def get_dither_image(odtype, im, level):
    width, height = im.size
    oim = Image.new("L", im.size)

    tw, th, _ = get_dither_table(odtype, 256, 0)

    ods = []
    for i in range(level):
        v0 = (256 * i) // level
        v1 = (256 * (i + 1)) // level
        vrange = v1 - v0
        _, _, od = get_dither_table(odtype, vrange, v0)
        ods.append([v0, v1, od])

    src_pixel = im.load()
    dst_pixel = oim.load()

    for y in range(height):
        dy = y % th
        for x in range(width):
            dx = x % tw
            v = src_pixel[x, y]
            for v0, v1, od in ods:
                if v0 <= v and v <= v1:
                    if v < od[dy][dx]:
                        dst_pixel[x, y] = v0
                    else:
                        dst_pixel[x, y] = v1

    return oim


def main():
    im = Image.open("mandrill.png")
    r, g, b = im.split()

    # odtype = "2x2"
    odtype = "4x4"
    level = 4
    
    rim = get_dither_image(odtype, r, level).convert("L")
    gim = get_dither_image(odtype, g, level).convert("L")
    bim = get_dither_image(odtype, b, level).convert("L")

    oim = Image.merge("RGB", (rim, gim, bim))
    oim.save("output_ncol_%s_lvl%d.png" % (odtype, level))


if __name__ == '__main__':
    main()

py 07ordered_dithering_ncol.py で実行。output_ncol_4x4_lvl4.png、といった感じのファイル名で生成画像が得られる。

まずは、ディザ配列の大きさは4x4、256諧調を分割しない状態で試してみた。


前述の、8色しか使ってないディザ画像と同じ結果が得られた。

では、256諧調を2分割して、それぞれにディザをかけてみるとどうなるか…。


かなり改善できた気がする。RGB各チャンネルが3段階を持ってる状態になってるから、使用できる色数は 3 x 3 x 3 = 27色のはず。8色から27色に増えると、見た目もこのぐらい違ってくるのだな…。

ただ、上記の画像は、本来27色まで使えるはずなのに、21色しか使ってなかった。おそらく、元画像がどんな色を使っているかで、変換後の画像の使用色数も変わってくるのではないかと。

この調子で、分割数を増やしてみる。

256諧調を3分割。最大64色中、41色を使用。
4分割。最大125色中、75色を使用。
5分割。最大216色中、112色を使用。
6分割。最大343色中、170色を使用。
7分割。最大512色中、234色を使用。
8分割。最大729色中、309色を使用。
9分割。最大1000色中、402色を使用。
ということで、使用色数8色でディザをかけると悲惨な見た目になるけれど、256諧調の分割数を増やして、色数も増やせば、その分見た目もそれなりに改善されていくことが確認できた。ただ、分割数が増えれば増えるほど、差を感じにくくなってくる気もする。

一応、元画像も再掲。230427色。

ところで…。ImageMagick の Ordered dithering も、おそらくはコレと似たような処理をしているのではないかと想像してみたりもして。あちらも、何かの値を増やしていくと見た目がどんどん改善されていくので…。

_Quantization - ImageMagick Examples

「Ordered Dither with Uniform Color Levels」の項で、ディザ配列サイズの後ろに何かを指定してる。

magick gradient.png -ordered-dither o4x4,6 od_o4x4_6.gif

この値が、たぶんソレなのかなと。

(※2022/06/21追記。ImageMagick 7.1.0-37 Q16-HDRI x64 で試してみたら、予想通り似た感じの変換結果が得られた。全く同じ結果にはならなかったけど、おそらくしきい値の取り方が微妙に違ってるから違う結果になっただけで、やってることは大体同じなのだろう、と…。追記終わり。)

さておき。今回試したこの減色処理(?)は、ImageMagick の Ordered dithering と同様の問題を抱えている。最終的に残る色が固定パレット相当になるあたりがよろしくない。もし、ちゃんとした減色処理をしたいなら、画像毎に使っている色を分析して、その画像特有のパレットを生成して、そのパレットを使いながらディザをかけないといけないはず。

しかし、任意のパレットを指定しながら、この種のディザをかける方法が分からないなと…。何せ、あの ImageMagick ですら、その実装はしていないらしいので…。 *1 もっとも、例えば GIMP や EDGE2 は任意のパレットを指定しながらディザをかけて減色ができてるので、仕組みさえ分かれば実装できるはずだよなと…。

それはそれとして。Pillow関係の解説記事を眺めてたら、そもそも Pillow は減色機能も持ってるようで。メディアンカットとかkmeans(k平均法)とかサポート済みっぽい。

_Pythonで画像の減色をする

そのあたりを使いつつ、この手のディザをかけたら、もっとそれっぽくなるのだろうか。どうなんだろう。

今回、256諧調を均等に分割して実験してみたわけだけど。画像によっては256諧調のうち、この範囲は頻繁に使うけどこの範囲はほとんど使ってない、といったものもあるかもしれないなと。そういった画像の場合は、分割位置に偏りを持たせたら、更に結果が改善されるのかもしれないなと妄想したりもして。まあ、そんなの絶対誰かしらが既に思いついて試しているだろうなー、とも思いますけど。

画像によっては、R,G,B成分の使用具合にばらつきがあるかもしれないな、とも。その場合、例えばR成分とG成分は細かく分割するけれど、B成分は粗く分割して使用色数を抑える、といったこともできたりするのかもしれない。まあ、これも絶対誰かしらが既に思いついて試してるやろ、とも思いますが。

RGBじゃなくて、YCbCr(輝度+色差)、HSV(色相、彩度、明度)でこの手の処理をしたらどうなるだろう、という疑問も湧いたりして。まあ、そのあたりも既に誰かが以下略。

昨日は猿4連発だったけど、今日なんか猿10連発ですよ。気が狂いそう。嗚呼、レナサン画像を使いたい…。レナお婆ちゃんも少しはこの苦しみを理解してくれないものか…。

上記の記事の中で、Adobe Photoshop が実装してたパターンディザ化の処理は特許が切れてるかも、みたいな記述があった。

Adobe Systems Incorporated is in possession of US Patent number 6606166, applied for on 1999-04-30, granted on 2003-08-12, but which expired on 2019-11-16. It describes an algorithm called pattern dithering invented by Thomas Knoll. For the sake of documentation, we will explain how that algorithm works as well.

Arbitrary-palette positional dithering algorithm より

パテントナンバー 6606166 は、1999/04/30に申請して2003/08/12に特許が取れた。でも 2019/11/16 に特許切れした。と書いてあるのかな。たぶん。ちょっと気になる。

ただ、遥か大昔にグラフィッカーさん達が、「Photoshopの減色はイマイチだ」「OPTPiXで減色するほうが奇麗」とこぞって言ってた記憶もあるのだよな…。でもまあ、それでも、上記の記事の減色結果を眺める限り、GIMPの減色処理よりは全然マシに見える。GIMPのソレは突拍子もない色のドットがポツポツと入ってしまうわけで。

そうか…Photoshopのソレは特許が切れているのか…。ググってみたけど、たぶん以下がその特許内容なのかな。

_US Patent for Pattern dithering Patent (Patent # 6,606,166 issued August 12, 2003) - Justia Patents Search
_US6606166B1 - Pattern dithering - Google Patents

ざっと眺めてみたけど何が何やらさっぱり。

各ソースが最初のあたりで gd.h を include してるのが気になる。ググってみたら libgd なるライブラリのようで、png、bmp、gifの読み書きができるようになるらしい。幸い MSYS2 にも libgd パッケージが用意されていたので、インストールは簡単だった。

pacman -S mingw-w64-x86_64-libgd
pacman -S mingw-w64-i686-libgd

_GD Graphics Library
_libgd/libgd: GD Graphics Library
_Package: mingw-w64-x86_64-libgd - MSYS2 Packages
_libgd メモ
_GD Graphics Library - Wikipedia
_Debian7 CPANでinstall GDするとjpegテストエラーでこける - Qiita
_ubuntu C言語 GDライブラリのインストール - Qiita

ウルトラマンって、ああいう見た目だから、人類の味方として認知される展開になったけど。アレがもし、ゴモラだのレッドキングだのバルタン星人みたいな見た目だったら、はたして人類の味方として認知されたのかなあ、という疑問が湧いた。どうなんだろう。

いやまあ、ゴジラやガメラの事例を考えると、色々やってるうちに「コイツはこういう見た目でも人類の味方かもしれん」という展開になっていくのだろうけど。そういやウルトラセブンのカプセル怪獣もあったっけ。見た目が怪獣だからと言って、最後まで敵扱いされる展開は、一般的な娯楽作品であれば無いのかもしれないな…。

とは言え、見るからにヤバそうな見た目のヒーローだったら、やはり最初のうちは「コイツは敵なのでは」と人類側から思われちゃうのが自然な流れのような気もする。逆に、見た目がスマートでカッコよかったら、実は人類にとって敵であっても、「コイツは俺達の味方なのかな」と勘違いされそうでもあるなと…。

そういう感じの設定を盛り込んだ特撮ヒーローが既に居たような気がする。映画版「ハカイダー」は近かったりしないか。あるいは未見だけど、「アクマイザー3」あたりはどうなんだろう。「ライダー電王」のモモタロスあたりもそういうアレなのかなあ。見た目はヤバそうだけどこっち側、みたいな。

仮にヒーローがモンスターっぽいデザインに変身したとして。しかしヒロインが怪獣大好き少女だったらどうだろう。

「スゴイ！ その腕、レッドキングみたいじゃん！ 足なんかガラモンだよ！ 頭のてっぺんなんかウルトラマンの初期企画のベムラーにクリソツ！ 君、実にいいよ！ その姿、たまらない！」

ハッピーエンドですね。

仮にヒーローが狼男みたいなモンスターに変身したとして。しかしヒロインがモフモフ大好き少女だったらどうだろう。

「うわっ…モフモフだ！ モフモフしたい！ モフモフさせて！ モフモフー！ モフー！」

ハッピーエンドですな。

現代日本においては、ウルトラマンシリーズ等を通じて様々な宇宙人のデザインがTVで流れて、子供達がそれらデザインに親しみを感じていることも多いだろうけど。

実は、地球人の間にひっそりと紛れ込んだ異星人達が、いずれ来るであろう地球人とのファーストコンタクトの日のために、その手の見た目に対する地球人側の拒否反応を薄めようと画策した故の現状…だったりしたらどうしよう。

アナウンサー「さあ、いよいよ異星人がUFOから降りてきます。一体どういう姿なのでしょう…」
手を振りながら姿を現す異星人。
視聴者「アレッ？ コイツ…メトロン星人じゃん！」

策士だな…異星人…。

以上、バカ妄想でした。

前述の解説ページからコピペして、C++のソースファイル(.cpp)として保存してみた。

_yliluoma_ordered_dither_1a.cpp
_yliluoma_ordered_dither_1ba.cpp
_yliluoma_ordered_dither_1bb.cpp
_yliluoma_ordered_dither_1c.cpp
_yliluoma_ordered_dither_1d.cpp
_yliluoma_ordered_dither_2a.cpp
_yliluoma_ordered_dither_2b.cpp
_yliluoma_ordered_dither_3a.cpp
_adobelike_pattern_dither.cpp

処理内容の簡単な説明は以下。

• yliluoma_ordered_dither_1a.cpp : 2色の組み合わせを評価して妥当な2色を選んでディザをかける。
• yliluoma_ordered_dither_1ba.cpp : 異なり過ぎる2色の組み合わせは除外して処理する。
• yliluoma_ordered_dither_1bb.cpp : 2色の差を CCIR 601 で求める。
• yliluoma_ordered_dither_1c.cpp : ループで結果を求めず数式で求めて高速化。ただし品質は落ちる。
• yliluoma_ordered_dither_1d.cpp : 3色のディザリングで処理する。
• yliluoma_ordered_dither_2a.cpp : ディザは2色の組み合わせという前提を捨てて考えた版。
• yliluoma_ordered_dither_2b.cpp : 2a のガンマ値を補正した版。
• yliluoma_ordered_dither_3a.cpp : 2b のアレンジ版。
• adobelike_pattern_dither.cpp : Photoshopに近い処理。

前述のページを眺めないと、どんなことをしているのかピンとこないだろうけど…。とりあえず、色々な方法を試しているのだな、ぐらいの認識でもいいかと…。

コンパイルには、g++、libgd が必要になる。できれば GNU Make も欲しい。

$ g++ --version
g++.exe (Rev2, Built by MSYS2 project) 12.1.0
...

$ make --version
GNU Make 4.3
このプログラムは x86_64-pc-msys 用にビルドされました
...

libgd は、MSYS2 も Ubuntu Linux 20.04 LTS もパッケージが用意されてるので、以下でインストールできる。

MSYS2の場合。

pacman -S mingw-w64-x86_64-libgd
or
pacman -S mingw-w64-i686-libgd

Ubuntu Linux 20.04 LTSの場合。

sudo apt install libgd-dev

コンパイルの一例。

MSYS2の場合。

g++ yliluoma_ordered_dither_1a.cpp -fopenmp -o yliluoma_ordered_dither_1a.exe -lgd -lm

Ubuntu Linuxの場合。

g++ yliluoma_ordered_dither_1a.cpp -fopenmp -o yliluoma_ordered_dither_1a -lgd -lm

ちなみに、「-fopenmp」を指定しなくても実行バイナリは作れるけれど、その場合、ディザをかける処理時間がかなり長くなって結構待たされる。「-fopenmp」を指定して実行バイナリを作ったら並列処理が有効になったようで、変換がかなり速くなった。

一応、Makefile も書いてみた。Makefile というファイル名にリネームして、*.cpp と同じ場所に置いておいて、make と打てば全ファイルをビルドできる。一応、make clean で、実行バイナリを削除できるようにもしておいた。

_Makefile.msys2
_Makefile.unix

前述のページから、元画像をコピーしてきた。

_scene.png

各プログラムの使い方は以下。

# MSYS2
./xxxx.exe INPUT.png OUTPUT.png

# Linux
./xxxx INPUT.png OUTPUT.png

一応、全部のプログラムに画像を生成させるシェルスクリプトも書いてみた。chmod +x test.sh で実行権限を与えてから ./test.sh で実行できる。

_test.sh

chmod +x test.sh
./test.sh

DOS窓上で動かす場合は以下のbatファイルが使えるけれど、MSYS2上でビルドした今回のプログラムをDOS窓上で動かすためには、*.dll群が必要になる。

_test.bat

一応、DOS窓上で動かせるようにするための .dll群を MSYS2 (/mingw64/bin/) からコピーしてくるシェルスクリプトも書いてみた。MSYS2上で、chmod +x copydll.sh で実行権限を与えて ./copydll.sh を実行すれば、動作に必要になるdll群がカレントディレクトリにコピーされる。シェルスクリプトの最初のあたりで、.dll が置かれてる場所を指定してるので、MSYS2 のインストール場所を変更してる場合は注意。

_copydll.sh

一応、MSYS2 (MinGW64) の .dll群も含めた実行バイナリその他を zip にして置いときます。

_yliluoma_ordered_dither.zip (14.6 MByte)

MSYS2 をインストールしてない環境で動くのかどうかは分からんけど…。一応サブPC(Windows10 64bit)でも動くことは確認しましたが…。

静的リンクしたかったのだけど、-static をつけてビルドしたら大量にエラーが出てしまって、しかし解決することができなくて。そのあたりは今後の課題。

出来上がった実行バイナリ群を使って、一応動作確認をして、前述のページに貼られている画像と比較してみたのだけど、見た感じ、結果が同じにはならなくて…。もしかすると、元画像が違うんじゃないかと邪推しているところ。

ただ、アルゴリズムに改良を加えると生成画像の品質が上がっていくことや、別のアルゴリズムを使えば生成画像の傾向が変わってくることはたしかに確認できた。

「とにかく処理が遅い」と説明されてたけど、たしかにこれはかなり時間がかかる処理だなと…。Photoshop の処理は全然速くて、かなり上手い具合にやってるらしいことも確認できた。

CUIでプログレスバーを出したい。tqdm というモジュールが便利らしい。

pip install tqdm

Python 3.9.13 x64 上で導入してみたけど、Windows10 x64 21H2 + DOS窓/ConEmu では、そのままだと正常表示されなかった。tqdm(... ,ascii=True) をつけて、ASCIIコードのみで出力すれば改善される模様。

from tqdm import tqdm

for i in  tqdm(range(100), ascii=True):
    hoge()

以下、参考ページ。

_Pythonで進捗バーを表示する(tqdm) - Narito Blog
_Tqdm Issues and Tips - jdhao's digital space
_Wrong output in Windows console - Issue #454 - tqdm/tqdm