mieki256's diary

Ruby や Perl では、そういうことが ―― スクリプトソースの最後にデータを列挙することができる。

Ruby の場合、__END__ と書くと、そこから下はデータとして扱えて、DATA定数を使って取得することができる。

_Ruby の __END__ と DATA とは - Just do IT
_DATAと__END__でファイルオブジェクトを扱う | Ruby入門 - Worth Living
_[ Ruby ] DATA定数って何よ？ [ 知ってる？ ] - Qiita


Perl も似た感じで、__END__ 以降を <DATA> で取得することができる。

_ぺるりめも / DATAと__END__
_Perlでファイル内に書いた文字複数行を<DATA>で参照・ループする方法 - Qiita
_特殊ファイルハンドル DATA - ぱるも日記

Ruby や Perl ではこういうことができるんだから、当然 Python にもあるんだろう。と思ってググってみたけど…。どうやら Python はそんな仕様を持ってないらしい…。

_Python, Ruby で簡単なテキスト処理 (1) - 特定の単語が含む行を抽出する | すぐに忘れる脳みそのためのメモ
_In Python what's the best way to emulate Perl's __END__? - Stack Overflow

「なんでそんなものが必要なんだ」とすら言われてるような…。Python の思想的に許せない何かがあるんだろうか。知らんけど。

考えてみれば、せっかくプログラム部分とデータ部分を分けた状態で作ってあっても、データ部分を変更したいだけなのにプログラムソースを書き換える羽目になるわけで、そこはデメリットかもしれないなと…。まあ、ちょっとしたスクリプトを配布する時に、プログラム部分とデータ部分の2つのファイルをわざわざ配布しなくて済む点はメリットなんだろうけど…。

さておき。Pythonも、自分で処理を書けば似たようなことができなくもないらしい。

_Pythonで__END__(もどき)を実現する - Qiita

_見比べ君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連発ですよ。気が狂いそう。嗚呼、レナサン画像を使いたい…。レナお婆ちゃんも少しはこの苦しみを理解してくれないものか…。

function love.load()
  json = require 'json'
  text = love.filesystem.read('data.json')
  o = json.decode(text)
  cur_time = 0
end

function love.update(dt)
  cur_time = cur_time + dt
end

function love.draw()
  y = 8
  love.graphics.print("ESC to exit.", 8,  y)
  y = y + 32
  for key, value in pairs(o) do
    local fn = value["path"]
    love.graphics.print(key .. " : " .. fn, 8, y)
    y = y + 24
  end
end

function love.keypressed(key, isrepeat)
  if key == "escape" then
    love.event.quit()
  end
end

function love.conf(t)
  t.window.width = 640
  t.window.height = 480
  t.window.title = "Json read"
  t.window.fullscreen = false
  -- t.window.fullscreentype = "exclusive"
end

{
    "Title": {
        "path": "imgs/img01.png",
        "start": 1,
        "area": [{
                "link": "Hall",
                "type": "rect",
                "pos": [561, 399, 718, 582]
            }
        ]
    },
    "Hall": {
        "path": "imgs/img02.png",
        "area": [{
                "link": "RoomYellow",
                "type": "poly",
                "pos": [80, 201, 310, 355, 308, 594, 84, 706]
            }, {
                "link": "RoomGreen",
                "type": "rect",
                "pos": [471, 378, 673, 564]
            }, {
                "link": "RoomBrown",
                "type": "poly",
                "pos": [1059, 337, 1231, 194, 1225, 706, 1059, 587]
            }
        ]
    },

...(中略)...

}

love2d + json.lua は、おおよそ以下のような使い方になるっぽい。

• json = require 'json' で、jsonライブラリを使えるようにする。
• text = love.filesystem.read('data.json') で、data.json をテキストデータとして読み込む。love.filesystem.read() は love2d で用意されている、テキストファイル読み込み用の関数。
• data = json.decode(text) で、JSONデータとして記述されたテキストを解析して、Luaのテーブルに変換する。
• あるいは、text = json.encode(data) で、Luaのテーブルを JSONデータ文字列に変換することもできるらしい。

以下が参考になった。

_How do you read from a file? - LoVE

_キャプチャソフト一覧 UVC 録画 - Qiita
_第2回　WEBカメラを使った撮影について - 向上心はありません
_サポートソフトウェアとか - oekaki-live @ ウィキ - アットウィキ

そのへんのメモ用紙に書いた何かしらをPCに取り込みたいなと。

ちゃんとした状態で取り込みたいなら、スキャナの類を使うべきで。自分もフラットヘッド型スキャナ、ドキュメントスキャナを持ってるのでソレを使えばいいのだけど…。ただ、自分の場合は利用頻度が圧倒的に低いものだから、電源コードは差してないし、USBケーブルも外してあるし、机の引き出しにしまい込んであるしで、セットアップするのが面倒臭い。

そこでふと、Webカメラ(USBカメラ)を使って取り込むのはどうだろうと。でも、Windows10で使えるかどうか確認してなかったな…。ということで動作確認してみた次第。

もっとも、一応動くことは分かったけれど…。画質が酷過ぎて、目的を果たすには少々厳しい印象。

こういったことをしたい場合、一般的にはどうやってるのかググってみたら、今時はスマホのカメラでメモを撮影してクラウド上にアップロード後、ソレをPCでダウンロード、という流れが多いようで。例えば、Microsoft が提供している Office Lens というアプリを使えば、斜めに撮影したメモも自動で補正して書類っぽい画像にしてくれるし、OneDrive にアップロードもできる。そりゃまあ、スマホを持ってたら、そういう流れで撮るわなと…。

VMware Player上で Ubuntu Linux 20.04 LTS を動かして、Canon PowerShot A300 をUSB接続して、gphoto2 を使ってリモート撮影(?)してみた。手順は以前メモしてあった。

_mieki256's diary - gphoto2を使ってみた

圧倒的な高画質。やはりコンデジはWebカメラと格が違う…。

もっとも、この仕組みではプレビュー等が得られないので、撮影してみるまでどんな画像になるのか分からないのが痛いなと…。まあ、1枚撮影して受信するまで十数秒かかるから、プレビューを見るのはちょっと無理だわな…。

余談。Webカメラにもなるコンデジ(コンパクトデジカメ)があればなあ…。比較的高画質な静止画や動画が得られるだろうに…。

昔はそういう製品もあったけど、 *1 今はもう絶滅状態で。残念。スマホの普及でコンデジと言う市場ジャンルが壊滅状態と聞くけれど、その割に、Webカメラにもなりますよ、等々の機能をつけてくれないまま終わっていくあたりが更に残念。 *2

この日記ページの先頭にある、「Free Sound」のリンク先の SoundCloudは、音楽ファイルを誰でもダウンロードできる仕様ではなくなってしまったようなので、Googleドライブに置き直して、リンクURLも変更しておいた。

_music - mieki256 - Google ドライブ

置いてある音楽ファイルはflacファイル(可逆圧縮)だけど、Firefox / Google Chrome でアクセスしたところ再生もできてるようなので、どういう曲データか一応確認できそうだし、これでもいいかなと。

この flac再生、サーバ側で各ブラウザが再生できる形式に変換し直してるのか、それとも今時のブラウザは flac も対応してるのか、どっちなんだろう…。

_HTML の audio 及び video で対応しているメディア形式 - HTML: HyperText Markup Language | MDN

今時のブラウザなら、flac に対応してるっぽいな…。

最初は、各画像レイヤーがカメラを向くように、レイヤー設定 → 一般タブ → フェイスカメラ、のあたりを弄ってたけど。パースが変わるとどうも見た目が不自然になるなと思えてきて、そのあたりは無効に設定し直したり。単にZ値に応じた拡大縮小だけをしたほうが、アニメっぽい雰囲気に近づけられるのかもしれない。

弟からワイヤレスキーボードも貰ったのでメモ。Logicool K400r。右側にタッチパッドがついてる製品。タッチパッドは二本指で操作したり等ジェスチャ機能が働くっぽい。

最初のうちは喜んで使ってたけど…。

• 「ろ」が変なところにある。
• ファンクションキーが、FNキーを押しながらじゃないと使えない。

何故こんな作りに…。

ググったところ、Windows + setpoint インストール環境ではFNキーを押さなくてもファンクションキーを使えるようにできるらしいけど。キーボード本体にそういう機能を付けておいてほしかった…。ファンクションキー部分に割り当てられた各機能は、一部を除いて連打するものではないだろうに、何故そちらを標準にしてしまったのか。いやまあ、何かのキーと同時押しで起動するのもアレだろうという気もするのだけど。リビング等で使うことを優先して考えたらこうなった、ということなのかな…。

とりあえずPCのセットアップ作業時には便利そうなのでコレはコレで。ポインティングデバイスも一体になったキーボードって、なかなか存在しないから…。

USBメモリに入れた _Ultimate Boot CD から memtest86+ を実行。

以前、この CPU + M/B + メモリで memtest86+ を実行した時は、メモリエラーが出たり、途中でフリーズしてたのだけど。今回はどうやら3回ぐらいはpassしたようで。

もしかして、以前メモリエラーが出ていたのは電源関係が…。それとも今回はビデオカードを差してビデオ用メモリをメインメモリから取らなくなったことで無理をしない状態になったのだろうか…。

前面に8cmFAN x 2、背面に8cmFAN x 1のケースだけど、結構うるさいような…。ブオーンという音が…。いや、コレはCPUクーラーのファン、あるいはビデオカードのファンなのかな…。ちょっと分からんなあ…。

OSを入れてみないことにはアレだなと思って、Ubuntu Linux 14.04 LTS をインストール。いつものように、 _Ubuntu 14.04 非公式日本語ISO Lubuntu Xubuntu kumasan から 64bit版のISOを落としてきて、 _UNetbootin でUSBメモリに書き込んで、USBメモリから起動してHDDにインストール。

DVI-D接続をしようと、MITSUBISHI MDT243WG 付属のDVI-Dケーブルを繋ごうとしてみたら、片方の端子は刺さるものの、もう片方の端子が何をどうしても刺さってくれず。

これは…。このケーブルは、初期不良品だったのでは…。それとも作業中にピンを曲げてしまったのだろうか。でも、じっと眺めてみても変な方向に曲がってるようには見えない…。

諦めて、アナログRGBケーブル(ミニD-SUB 15ピン)で接続することに。

ちょっと気になったのだけど、MDT243WGの背面、DVI-D端子やアナログRGB端子に、付属のケーブルを接続するのがとにかく一苦労で。ケーブルが太くて曲がらない上に、ケーブルのフェライトコア部分が、ディスプレイ背面下部の出っ張りにぶつかるという。素直に後ろに突き出す形にしてあればこんなことには…。なんというか、やっぱり三菱製のディスプレイだなあ、という気分に。デザインが実用性を阻害してくれるあたりが三菱製ディスプレイ。

NECやNANAOのデザインと比べると、三菱製ディスプレイのデザインは「何考えてんだ」「自分達で使ってみたことがあるのか」と首を捻る部分があちこちに。実用性という面で考えが足りないというか気が利かないというか。いやまあ、撤退する直前あたりは結構改善されてた印象もあるのですけれど。

_script を使った場合だけど、#!/usr/bin/env python の前に # を打って、# #! /usr/bin/env python にすれば…最低限の修正で誤魔化せなくもないかなと。

以下で気になる話が。

_Python can't be executed because "#! /usr/bin/env python" ? - Issue #288 - rgbkrk/atom-script
_atom-script/script-view.coffee at 833e7a3a680a53941f972b5ae3c64bcd520eccb9 ・ rgbkrk/atom-script

lib/script-view.coffee#L44 we currently return early from the getShebang method. One possible workaround is returning early if a atom-script config option for ignoreShebang was specified.

ignoreShebang って何だろう…。

む。なんとかなったかも。C:\Users\アカウント名\.atom\packages\script\lib\script-view.coffee をいきなり書き換えちゃって、getShebang の中で何もせずに return するよう修正してみたら出力結果が文字化けしなくなった。これなら使えそう。

ところで、拡張子が .coffee ってついてるけど…コレ何？ CoffeeScript ってヤツかな。どんな言語なんだろう。

ググってみたら、JavaScript を Ruby っぽく書けるものらしく。なんだかヨサゲ。

録画してたソレを見てみたのだけど、さすがにあのデザインは…アレでアクションはできるのか…？ しかも、平成シリーズでインパクトのある画を多数生み出してきた(のであろう)田崎監督が担当してもあそこまでということは…うーん。

カードの組み合わせで戦うソレについては、チョーカッコイイなと思ったけれど。しかしソレは、ライダー自身のカッコよさとは別のところに存在するカッコよさなんだろうな、という気がしたり。

でもまあ、あのデザインを一目見れば「あ。ディケイドだ」と判るから、そういう意味では良いデザインなのか。どれがどのライダーだか判らないデザイン、に比べれば、みたいな。

コードレスホンの電源スイッチを弄ってたら、音割れが直ってしまった。何かの拍子に異常動作してただけで、寿命じゃなかったのか…。

とはいえ、使い続けるわけにもいかない。今まで使ってたFAXは、外部出力？用の端子があったのだけど。今回購入したFAXは、入力端子だけ。電話回線の最終位置(?)に設置されることが前提の製品。よって、別種類のコードレスホンを接続することは不可能。たぶん。…昨今の家庭用FAXは、大体がそういう感じの仕様だったりするのだろうか。いや、FAX機能のみの製品なら、外部出力端子もあるんだろうな。たぶん。

今まで使ってた機器を眺めながら、「コレ、何かに使えないかなぁ」と口にしたら。親父さんが、「今は携帯の時代だし、使い道ないだろ」と。なるほど、たしかに。固定電話の利用場面自体が少なくなってるわな。であれば、捨てるしかないか…。

Webブラウザから簡単にWebページの発行・編集などが行なえる、Webコンテンツ管理システム。WebサーバにインストールしてWebブラウザから利用する。

複数人が共同でWebサイトを構築していく利用法を想定しており、閲覧者が簡単にページを修正したり、新しいページを追加したりできるようになっている。

そんなコマンドがあったのか。知らなかった… orz

config.ph 中の $IncludeDir で場所を指定しているのですな。試してみやう。

INCLUDE コマンドのテスト。
EUC,LFで書いてみる。

どうだらう。…出てますな。ありがたや。

なぬ。知らずに ../img/hoge.jpg とかやってた。orz …まあ、今更書き換えるのも面倒だから、いいか。

と思ったら _違った。 ディレクトリはやっぱり指定しないといけないらしい。

そんな方法が… orz

なんとなく、~/public_html/diary/ 以下に画像関係も置いたほうが良さそうな気がしてきた。日記コンテンツに関連する画像なんだし。

ということで、~/public_html/my_diary_img/ に置いていた画像を、~/public_html/diary/img/ 以下に移動した。RLINK でリンクしてたものに関しては、~/diary/conf/rlink.txt を書き換えれば即座に修正できる。しかし、IMG 指定は、../img/hoge.jpg といった形で書かれてるわけで。…後で修正しよう。

せっかくだから、この際、INCLUDEコマンドと同様に、画像の置き場所も config.ph 中で指定できると助かるかもしれない。と思って lib/HNS/Hnf/Command.pm を覗いたけど、さっぱりわからない。INCLUDEコマンドが出来ているのだから、IMG もできるはずなのだけど。勉強しないとなぁ。(;´Д｀)

これだ！ これを使えば、先日悩んでた、「テーブルやリスト中でリンクが使えない」問題も解決。たぶん。しかし、どこに入れるんだろう。lib/HNS/Hnf/Command.pm でいいのかしら。

…しまった。 _こっちが本物(?) だったらしい。また、 _こちら によると、範囲指定はRAW、単独はTAGにしたとのことなので、自分もそれに習っておくであります。

これでどうだらう。

ツール	-density	-geometry	+antialias	結果画像
oodraw で png エクスポート				[画像]
convert	150	608	無	[画像]
convert	150	608	有	[画像]
convert	300	608	無	[画像]
convert	300	608	有	[画像]
convert	600	608	無	[画像]
convert	600	608	有	[画像]
convert	1200	608	無	[画像]

いろんな記号：¢£¥©®±µ¶

そのまま書いたら位置がズレてしまった。<div class="sub">〜</div> で挟んだらどうか。…ダメだ。TAGコマンドはともかく、RAWコマンドでは、一度サブ記事が終了してしまう。

つまり、

• TAGコマンドは特に意識しなければならない点はない。たぶん。
• RAWコマンドを使うときは、自分で意識的に、「<div class="sub">〜</div>」等で囲まないと位置がズレる。

といった感じなのだろう。

それはともかく、これでかなり楽になりそう。テキストだけ書けばいいときは、今までどおりにhnfフォーマットで書けばいいし。少し外れた事をしたければ、RAW、TAGを使えばいい。いざとなれば、HTMLタグを直に書けばいいというのは、精神的に楽であります。ありがたや。感謝感激。

おお。こちらでも実装してる人が。

_開発者用 と _ユーザ用。 昔のMLログは勉強になるので、メモ。ありがたや。

おお。面白い。

これもブラウザ上でHTML編集ができる、らしい。

CRLF になった .hnf を全消去するつもりが！ 間違って .bak まで消してしまったDEATH！ ギャーッ！ しかもゴミ箱に残ってないし。なんてこった。1年分の日記が消滅してしまった… orz

…サーバから1年分をDLしてきました。危なかった。

いや待て。本当に最新版・各種修正済みの日記だろうか。うーん。でもまあ、どのみち公開してたのは、サーバに入ってた版なのだから、いいか。

アレ？ 改行コードがCRLFになってる。さては、FFFTPでダウンロードした際に、LF→CRLF変換されてしまったか。うう。

これで CRLF → LF 変換を。うう。

なんでそんなことをしたんだ… orz ＞過去の俺。

Wild.pm が云々と怒られた。ActivePerlでワイルドカードが使えるように、そのへん入れて、環境変数を指定してたのだったか。環境変数を消去するにはどうすればいいのだらう。

_シェル変数を定義したり、削除するには
設定するときは、export HOGE=hoge とかやって、削除するときは、unset HOGE でいいのかな。

ガーン。今、cygwin版Perlで変換したばかりなのに。…いや。LFだから、いいのか。いや待て。EUC が SJIS になってたりしないか。うーん。

そしてそして、Cygwin の cat には大きな罠があります！！
Cygwin 上で cat だけは出力が CRLF です。
ファイルを作成するときに cat を使うときは要注意です！！

わあ。どうすりゃええのん。

これでいいような気がしてきた。M-x grep-dialog か M-x gresreg-dialog を使うのだな。

簡単にできた。最初からxyzzyで作業すれば良かったのだな。orz

名前のとおり。Standby,Suspend,PoewrOffを送る時間をそれぞれ指定できるのでCRTの節電モードを段階的に移行できる。更に、何時から何時までの指定で節電モードにすることもできるし、別のスクリーンセーバを指定して *1 動かした後に節電モードにすることも出来る。ただし、メッセージは英語だし、Win9x/NTにしか対応してない。もっともWin2000/XPならより細かい省電力設定ができるはずだし、Win98もCRTの節電モードを選ばなければ標準機能で同様の事ができるしで、今更かも。

G400ユーザであれば利用可能。Win98の場合、Hwacc.dll,MGADPMS.scr,Hwacc95.vxdをc:\windows\systemにコピーするだけ。試してみたけど、DPMSが動作する前のスクリーンセーバがショボイ *2 ので、前者の方がいいなと思った。