Linux」カテゴリーアーカイブ

AVIF

Web 用途の画像形式で近年は WebP が人気、筆者も blog で使っている。
文字列に弱い JPEG とサイズが大きめな PNG という欠点を補っています。
更に透過やアニメーションや可逆圧縮まで対応と至れり尽くせり。

でも広まらないと意味が無い、HEIF はもう死んでいる。
そういえば JPEG 2000 とかそんなのあったよなって、他は忘れた。
とはいえ既に結構広まっていますのでこのまま安泰かも。

ところで、似たようなフォーマットに avif という形式があるらしい。
特徴までそっくりで WebP より更にサイズが小さくなるらしい。

AVIFとは?特徴や注意点から変換できるアプリ・ツールまで紹介

AV1 動画と同じ圧縮を画像に展開したもののようです。
とりあえず上記からのリンク先にある avif ファイルで試す。

gnome

GNOME

macos

macOS

macOS スゲェ、すべて Preview.app で普通に表示できるし。
でも avif への変換はできない、これは WebP と同じ。
avif はオープンソースですし GNOME も対応は時間の問題かな。

hex

バイナリを見ると見事に ftypavif の mp4 コンテナですね。
そういえば HEIF もそうだし WebP も RIFF のコンテナだったね。
ということは。

mpv -autofit 400x300 photo.avif

mpv

mpv で普通に開くことができました、当然 WebP も同様に。
totem ではエラー、Quick Time はそもそも受け付けない。

次世代画像形式のWebP、そしてAVIFへ。変わり続ける技術に対応するweb制作の黄金解 – ICS MEDIA

こんなページも見つけた、JPEG XR なんて知らないぞ?
あぁ Windows 専用なのか、7 以降の Windows はマジで知らないし。
てか WebP って ffmpeg で変換できるのか、もしかして今なら。

ffmpeg -i gara.webp gara.avif

ffmpeg

おいおい、できるじゃないか。
これは新たな生き残りゲームが始まる予感。

でも写真は Exif の関係で今後も jpeg のままだろうし。
今は GIF や PNG を選んでいた所を WebP に置き換えが最適解かな。
知らんけど。

pdftocairo

PDF ファイルに一つの画像しか入っていないファイルが時々見つかる。
こういうファイルは使い辛いので画像に変換したくなりますよね。

Fedora 等の Linux であれば最初から入っている gs コマンドで変換できる。
以下のスクリプトをパスの通った場所に置いておくと便利みたいな。

#!/bin/sh

# pdf to jpeg
gs -dSAFRE -dBATCH -dNOPAUSE -sDEVICE=jpeg -sOutputFile=${@%.*}.jpg "$@"
# output 300dpi
#gs -dSAFRE -dBATCH -dNOPAUSE -sDEVICE=jpeg -r300 -sOutputFile=${@%.*}.jpg "$@"

これで今まで問題なかったんですけど。

路線・駅情報|電車のご利用案内|名古屋鉄道

ココの PDF ファイルで困ったことに。

gs jpeg

この手段では文字が潰れて読めません、JPEG の弱点がモロに。
300dpi に指定すれば読めるけどファイルが巨大に、一億画素って。。。
ならば PNG にすればいいかなと。

gs -h

を見ると png256 や pngalpha があるなと。
png256 指定だと jpeg 同様に潰れる、てかアンチエイリアスが死ぬ。
pngalpha を指定してみる、嫌な予感がするけど。

#!/bin/sh

gs -dSAFRE -dBATCH -dNOPAUSE -sDEVICE=pngalpha -sOutputFile=${@%.*}.png "$@"

gs png

やっぱり、PDF の白背景って実は透過なのよ。
印刷用途を考えると利にかなっているけど GUI ではこうなるんです。
自作アプリを PDF に対応させた時ソコに苦労したもん。

じゃあ、ということで Poppler を使って自作してみたんですが。
今度は異様に小さくなってしまった、dpi を得るとかしなきゃ駄目なのか?
上手くいかなかったのでコードは貼らないけど。

なんか他に上手い手段は無いかと色々探す。
いやまて、もしかしたらオイラは凄い遠回りをしているんじゃないか?
思いつきでターミナルにて pdf と打って Tab キーを叩いてみる。

pdftocairo

pdftocairo なんてコマンドがあるんだが。
Poppler の付属品のようなので GNOME なら最初から入っているはず。
help を見てみるとこの用途ズバリみたいな、よし試す。
ppi はデフォルトが 150 だけど 72 で十分かな。

pdftocairo -png -r 72 rosenzu.pdf out

出力名指定は拡張子不要、自動連番で複数ページにも対応みたい。
更に以前書いたスクリプトで WebP に変換すると小さくなって素敵。

to webp

うん完璧だ、今度からこのコマンドを使おう。
指定が単純だから Nautilus スクリプト化やラッパーコマンドも不要ですね。
と Fedora ではここまで調べるのに時間が掛かりましたけれど。

preview.app

macOS なら Preview.app から複製して保存するだけで変換できます。
dpi 指定も GUI で可能とか、やっぱり画像関連では macOS のほうが便利です。

Gedit: fstring Highlighting

Gedit が Ctrl+Q で終了する、あれ?
今まではドキュメントを全部閉じてからでないと終了できなかったはず。
面倒だから Ctrl+W の連続押しをずっと使ってきたんだが、いつからだ?

NEWS ? master ? GNOME / gedit ? GitLab

書いていない、もしかして今まではバグだったとかだろうか。
Ctrl+F9 が Wayland では Ctrl を認識しないのは変わっていないけど。
てか GNOME 同梱から外れたのに開発は続いているみたい、GTK3 のまま。
まあいいや、今度から Ctrl+Q を使おう。

せっかくなので Gedit 小ネタ。

Gedit で Python を書いていて不満なこと。
fstring が色分けされない、いやこれは。

/usr/share/gtksourceview-4/language-specs/python3.lang

に認識する定義を書き込めば反映されるんですけど。
gnome-text-editor は色分けされるのでコレ用をそのまま反映させたい。
GTK3(GtkSource 4) と GTK4(GtkSource 5) で違うけど仕様は同じみたいですし。
GtkSource 4 の LanguageManager がドコを参照しているか調べる。

#!/usr/bin/env python3

import gi
gi.require_version('GtkSource', '4')

from gi.repository import GtkSource

man = GtkSource.LanguageManager.get_default()
print(man.props.search_path)

path

~/.local/share/gtksourceview-4/language-specs

が一番最初の参照先になる、$PATH と同じ UNIX お馴染みな仕様。
ココに GtkSource 5 用の python3.lang をコピーすればいいはず。

mkdir ~/.local/share/gtksourceview-4
cd ~/.local/share/gtksourceview-4
mkdir language-specs
cp /usr/share/gtksourceview-5/language-specs/python3.lang language-specs/

gedit

よしコレで fstring のストレスは無くなったぞい。
他の gnome-text-editor との色違いも同じ手段で同じにできるよ。

いや、本当はプラグインでやろうと思ったんだけど。
GtkSource.LanguageManager.set_search_path() がエラーになるのよね何故か。

WebP @ GNOME

Fedora 37 で今更気がついた。
WebP が Nautilus でサムネイル、及び Eye of GNOME で表示できるように。
EoG で拡張子を webp にて別名保存すると作成することさえも可能。
JPEG からでは Exif は消えてしまうけど回転情報に合わせて変換してくれる、凄い。

webp

上記が変換したもの、WebP も今は WordPress で普通にアップロードできるのね。
しかし PNG から変換したらサイズが 1/4 になって笑う。

size

heaf はライセンスの関係で GNU/Linux では今後も無理だと思う。
互換性無さすぎて実験用途にしか使っていないから別にいいけど。

#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '4.0')
from gi.repository import Gtk, Gio

class Win(Gtk.ApplicationWindow):
    '''
        WebP Test
    '''
    def __init__(self, a):
        Gtk.ApplicationWindow.__init__(self, application=a, title='GTK4')
        f = Gio.file_new_for_path('webp.webp')
        pic = Gtk.Picture(file=f)
        self.set_child(pic)

app = Gtk.Application()
app.connect('activate', lambda a: Win(a).present())
app.run()

GTK4 もデフォルトで対応済。

GdkPixbuf でも読み書きできるけどオプションが解らん。
GdkPixbuf.Pixbuf.save
書いていないし cwebp のオプションとも違うようで、お手上げ。

#!/usr/bin/env python3

'''
    Nautilus Script @ Create WebP
'''

import gi, os
gi.require_version('GdkPixbuf', '2.0')
from gi.repository import GdkPixbuf

path_array = os.environ['NAUTILUS_SCRIPT_SELECTED_FILE_PATHS'].split('\n')
for filepath in path_array:
    try:
        pixbuf = GdkPixbuf.Pixbuf.new_from_file(filepath)
    except:
        continue
    webp_name = f'{os.path.splitext(filepath)[0]}.webp'
    pixbuf.savev(webp_name, 'webp')

とりあえず Nautilus Script を簡易で作ってみた。
ドキュメントに追記があるまでオプション無しで。
スクリーンショットの PNG から変換程度ならコレで十分だろう。

mac_img

macOS のプレビュー.app では WebP 変換の選択肢が無くて笑う。
まさか画像関連で Fedora のほうが優れている場合があったなんて。
ということで。

yamagara

ヤマガラ、トリミング無しでこのサイズいけた。
こういうのは劣化しないように JPEG のままがいいよ。
というか Exif を残さないと自分が困るもんね。

Python: open r+

Fedora 37 で今頃気がついたけど。
Anthy の辞書がまた PageDown でページ送りができなくなっているじゃん。

/usr/share/ibus-anthy/engine/engine.py は八月に更新されているな。
バッチは当ててくれなかったのか、気がつかなかったようで。
do_page_down なんてメソッドは定義されていないよメンテナさん。
しかたがない、今回も自前バッチを。

#!/usr/bin/env python3

'''
    Fedora 37 の Anthy で PageUp(Down) にて辞書送りできないのを修正
    コピペして sudo で実行しログインのやりなおし
    万が一失敗したら gnome-softwere から入れ直しで元通り
'''

import os

os.chdir('/usr/share/ibus-anthy/engine')

with open('engine.py') as f:
    src = f.read()
    dst = src.replace('do_page_up()', '__page_up(0)', 1).replace('do_page_down()', '__page_down(0)', 1)
    with open('engine.py', 'w') as g:
        g.write(dst)

今回は replace で。

いや Python の open には r+ という読み書きモードがあるんだけど?
と思うかもだけど r+ は使わないほうがいいよ。

#!/usr/bin/env python3

import os

with open('rw.txt', 'w') as f:
    f.write('ABCDEFG')

with open('rw.txt', 'r+') as f:
    src = f.read()
    #
    # 巻き戻すのを忘れずに
    f.seek(0)
    #
    # r+ での書き込みは以前の内容が残る
    dst = src.replace('ABCDE', 'a', 1)
    f.write(dst)
    #
    # 確認
    f.seek(0)
    print(f.read())
    #
    #=> 'aFGDEFG'

ね。
書き出しが短いと最初の語尾が残ってしまうんです。
文字数を合わせる、又はそれ以上なら問題ないんですけど。
ただ文字数を合わせても日本語だと以下のように。

#!/usr/bin/env python3

import os

with open('rw2.txt', 'w') as f:
    f.write('あいうえお')

with open('rw2.txt', 'r+') as f:
    src = f.read()
    f.seek(0)
    #
    # write は UTF-8 で書き出す
    dst = src.replace('あいう', 'aiu', 1)
    f.write(dst)
    #
    # 確認
    f.seek(0)
    print(f.read())
    #
    #=> 'aiuえおえお'

日本語はほぼ 3byte なので。
対策はあるんだろうけど、一番の対策は使わないことですよね。

ところで Nautilus 43 のリネームで入力メソッド切り替えが初回が無視される。
いやこれ US 配列キーボード愛用者以外には関係ないといえばそうなんですけど。
Ctrl+J のほうを使えばいいんだけど macOS と同じコッチを使ってしまうし。

Fedora とは関係ないけど GTK4 になった GHex もなんかおかしいな。

ghex font

Source Code Pro 以外のフォントだとはみ出すんだが。
なにがどうしてこうなるのか全然わからん。