雑記帳 - JasminInfo

JPEGエンコーダーguetzliを試してみた

• JPEGを「libjpeg」よりも20～30％小さく ～Google、新エンコーダー「Guetzli」を発表 - 窓の杜

Googleが新しいJPEGエンコーダー「Guetzli」を発表したので試してみました。

入手元

guetzliと比較用のmozjpegのWindows向けバイナリは以下のサイトから入手しました。

• Releases · google/guetzli · GitHub
• binaries - mozjpeg | codelove

圧縮手順

• guetzli

   guetzli_windows_x86-64.exe --quality 95 RanHeart.jpg guetzli_RanHeart_q95.jpg
  

• mozjpeg

   cjpeg.exe --quality 95 -outfile mozjpeg_RanHeart_q95.jpg RanHeart.jpg 
  

いずれも、RanHeart.jpgが入力画像。

画像比較

画像アップローダー - ECO-Wiki (acronia)に上がっていたちょうど良さそうな大きさの画像で試してみました。

guetzliでQualityを95/90/85の3通りで圧縮し、mozjpegで近いファイルサイズになった画像を比較用に並べています。（なお、元画像はjpegtranで可逆最適化してあります。）

分類	guetzli	mozjpeg
元画像	元画像 (29,871B)	元画像 (29,871B)
高画質	Quality 95 (24,596B)	Quality 93 (25,557B)
中画質	Quality 90 (19,051B)	Quality 88 (19,378B)
低画質	Quality 85 (15,658B)	Quality 82 (15,764B)

・・・どうしよう、ぱっと見どれも違いがよく分からない(^_^;)

とりあえず分かりやすいのは口元の赤色で、guetzliの方は元の色合いが大分保たれています。

JPEG高圧縮時に現れるモスキートノイズの現れ方はよく見るとguetzliとmozjpegで違っているのですが、特にどちらの方が良いというわけではない気がしました。

エンコード時間

1回しか測ってませんが、guetzliが6.6秒で、mozjpegが0.05秒でした。かなり遅いです。

感想

JPEGが苦手な赤に強いのは良さそうです。

エンコード時間がかかるのは難点ですが、Web公開する画像がそんなに大量にあるわけでも無いので、そう考えれば許容範囲でしょうか。（デジカメで撮った大きな写真を片っ端から圧縮するような使い方は難しそう。）

出たばっかりのソフトですし、もうちょっと速度とか改善されるまで様子見が無難かも。

スロット拡張成功率調査（イリスカード強化祭＋OTPボーナス）

スロット上限が10スロットまで拡張されたので、武器と服を400個ずつスロット拡張してみました。

ポーチS10が4個できたのは運が良かっただけのようで、サマートップスは最後のS9→S10でかなり失敗してしまいました。

とは言え、S9とS10の成功率は凄く低いと言うほどではなさそうな感触です。保険を使った強化の時も半分くらいは成功してましたし。

• ノートPC購入・SSD換装
  • 購入機種とスペック
  • 外観とか
  • ストレージ換装
  • OSインストール
  • ベンチマーク
  • 熱と騒音
  • ディスプレイ
  • 総評

ノートPC購入・SSD換装

今まで使っていたノートPCは結構前から調子が良くなく、新しいCPU/GPUが出たタイミングで買い換えようと思っていたのですが、最近GeForce GTX 10シリーズ(Pascal)がリリースされたのでついに買い換えることにしました。

CPUの方はKabylake-Hを待ってるとまたしばらく先になりそうなのと、Skylakeとの性能差はそんなに無さそうだったので待たずに買うことに(^_^;)

続きを読む

パートナーステータス一覧

• 2017/06/16追記: パートナーステータス一括ダウンロード(2017/06/16)で、新しいデータをダウンロードできます。

ECO公式ツール・パートナーサーチ

ECO公式ツール・パートナーサーチが公開されて、パートナーのステータスを簡単に調べることができるようになりました。しかし、パートナー名やLVを指定した検索なので、LV1～110のステータスを一覧にして眺めるような目的にはちょっと使いにくいです。

パートナーステータス一覧CSVファイル

そこで、パートナーサーチのデータを機械的に取得してCSV形式の一覧表を作ってみました。

以下のリンクからダウンロードできます。

• eco_partner_20160930.zip (約2MB、解凍後約15MB)
  • 成長ポイントは未振り、信頼度は灰色で、転生前後のLV1～110を取得しています。

これで、表計算ソフトでグラフを書いて遊んだりすることができます(>_<)

おまけ：考察

ちゃんと確認したのはプルル・アルマのHPだけですが、以下のような法則があるようです。

• 転生前
  • 完全に線形（一次関数）
  • なので、LVがnの時のHPは、LV1とLV110のHPを使って、以下の計算式で計算できます。（端数切り捨て。）

    HP[LVn] = HP[LV1] + (HP[LV110] - HP[LV1]) * (n-1) / 109

• 転生後
  • 転生後HP = 転生前HP + 転生後ボーナスHP の形になっている
  • 転生後ボーナスは10の倍数LVで増える。具体的な値は下の表を。
    • 増え方の法則はたぶん無い？

PukiWiki: RecentChangesページを考慮したブラウザキャッシュ制御

PukiWiki If-Modified-Since（条件付きリクエスト）対応のコメントでやりとりしていた、RecentChangesページを考慮したブラウザキャッシュ制御の機能をbodycache改良版に追加しました。

PukiWiki bodycache改良版のページで公開しています。なお、追加機能を使うには設定が必要です。*1

RecentChangesを考慮したページ更新日時

基本的な方針は、「Wikiページキャッシュ更新日時とRecentChanges更新日時のうち新しい方」をページの更新日時と見なすというものです。

以下の関数がこの新しい方の更新日時を返す関数です。$bodycache_lastmod_whatsnewはpukiwiki.ini.php内の設定で、$bodycache_lastmod_whatsnewがtrueの時のみこの機能は動作します。

• bodycache.php

  // Get last-modified time for client side cache control
  function get_lastmodtime($page)
  {
  	global $bodycache_lastmod_whatsnew;
  	global $whatsnew;
  	static $lastmodtime = null ;
  	if ($lastmodtime !== null) {
  		return $lastmodtime ;
  	}
  
  	$cachetime = get_cachetime($page);
  	if ( $cachetime != 0 && $bodycache_lastmod_whatsnew ) {
  		$whatsnewtime = get_filetime($whatsnew);
  		$lastmodtime = ( $cachetime >= $whatsnewtime ) ? $cachetime : $whatsnewtime;
  	} else {
  		$lastmodtime =  $cachetime;
  	}
  
  	return $lastmodtime;
  }
  

この関数が返す日時を、ブラウザに返却するLast-Modifiedや、If-modified-sinceの比較に用いることで、RecentChanges更新時にはブラウザキャッシュも更新される動作になります。

追記

get_lastmodtimeは複数回呼ばれるので、処理量を減らすために1回目に呼ばれたときの結果を$lastmodtimeに残して2回目以降は$lastmodtimeを返すだけにしているのですが、今の書き方では引数の$pageを変更して呼ばれると正しく動作しなくなってしまいます。

今のコードでは、$pageを変更してget_lastmodtimeを呼ぶことはないので問題は起こりませんが、get_lastmodtimeの引数を変えてはいけないという制約ができてしまっているのであまり良くないですね。（うっかり忘れて将来事故を起こしそう＾＾；）そのうち修正するかもしれません。

その他のbodycache改良版の更新

更新のついでに、bodycache.php内の不要な記述の削除とコードインデントのタブへの統一*2も実施しました。

また、bodycache.php内にあった設定用の変数$bodycache_del_depthをpukiwiki.ini.phpに移動しました。