2017/03/20(月)JPEGエンコーダーguetzliを試してみた

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

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

入手元

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

圧縮手順

  • 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で可逆最適化してあります。)

分類guetzlimozjpeg
元画像元画像 (29,871B)
orig_RanHeart.jpg
元画像 (29,871B)
orig_RanHeart.jpg
高画質Quality 95 (24,596B)
guetzli_RanHeart_q95.jpg
Quality 93 (25,557B)
mozjpeg_RanHeart_q93.jpg
中画質Quality 90 (19,051B)
guetzli_RanHeart_q90.jpg
Quality 88 (19,378B)
mozjpeg_RanHeart_q88.jpg
低画質Quality 85 (15,658B)
guetzli_RanHeart_q85.jpg
Quality 82 (15,764B)
mozjpeg_RanHeart_q82.jpg

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

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

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

エンコード時間

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

感想

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

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

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

2017/03/06(月)スロット拡張成功率調査(イリスカード強化祭+OTPボーナス)

スロット拡張成功率調査(イリスカード強化祭+OTPボーナス)

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

ポーチ/武器製造LV10&スロット成功確率%上昇2
スロットS1S2S3S4S5S6S7S8S9S10
成功数-334255142633213844
失敗数-6679113793119540
成功割合[%]-83.5076.3555.6944.3750.7940.6361.5450.00100.00
サマートップス/防具製造LV10&スロット成功確率%上昇2
スロットS1S2S3S4S5S6S7S8S9S10
成功数4003412541436636211271
失敗数05987111773015956
成功割合[%]100.0085.2574.4956.3046.1554.5558.3357.1458.3314.29

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

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

2016/11/23(水)ノートPC購入・SSD換装 (LEVEL∞ N-Class Lev-15QX092-i7-RNE)

PC::Memo

ノートPC購入・SSD換装

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

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

続きを読む

*1 : 代わりにHDDを取り付けたのでまだ旧PCも使えます。起動が凄く遅かったですが^^;

*2 : 買った時期の違いが大きいですが、今まで買ったSSDの中で一番安かったり。

*3 : 本機種はOptimusを無効化してGeforceだけを動作させることができるのでその状態で計測。

2016/09/30(金)パートナーステータス一覧

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

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

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

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

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

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

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

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

プルル・アルマ ATK


おまけ:考察

pururu_hp.png

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

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

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

  • 転生後
    • 転生後HP = 転生前HP + 転生後ボーナスHP の形になっている
    • 転生後ボーナスは10の倍数LVで増える。具体的な値は下の表を。
      • 増え方の法則はたぶん無い?
プルル・アルマHP一覧表
LV転生前転生後転生後ボーナス=転生後-転生前
1450750300
2475775300
3500800300
4525825300
5550850300
6576876300
7601901300
8626926300
9651951300
106771,177500
117021,202500
127271,227500
137521,252500
147771,277500
158031,303500
168281,328500
178531,353500
188781,378500
199041,404500
209291,729800
219541,754800
229791,779800
231,0051,805800
241,0301,830800
251,0551,855800
261,0801,880800
271,1051,905800
281,1311,931800
291,1561,956800
301,1812,1811000
311,2062,2061000
321,2322,2321000
331,2572,2571000
341,2822,2821000
351,3072,3071000
361,3332,3331000
371,3582,3581000
381,3832,3831000
391,4082,4081000
401,4333,4332000
411,4593,4592000
421,4843,4842000
431,5093,5092000
441,5343,5342000
451,5603,5602000
461,5853,5852000
471,6103,6102000
481,6353,6352000
491,6613,6612000
501,6864,6863000
511,7114,7113000
521,7364,7363000
531,7614,7613000
541,7874,7873000
551,8124,8123000
561,8374,8373000
571,8624,8623000
581,8884,8883000
591,9134,9133000
601,9385,9384000
611,9635,9634000
621,9885,9884000
632,0146,0144000
642,0396,0394000
652,0646,0644000
662,0896,0894000
672,1156,1154000
682,1406,1404000
692,1656,1654000
702,1908,1906000
712,2168,2166000
722,2418,2416000
732,2668,2666000
742,2918,2916000
752,3168,3166000
762,3428,3426000
772,3678,3676000
782,3928,3926000
792,4178,4176000
802,44310,4438000
812,46810,4688000
822,49310,4938000
832,51810,5188000
842,54410,5448000
852,56910,5698000
862,59410,5948000
872,61910,6198000
882,64410,6448000
892,67010,6708000
902,69511,6959000
912,72011,7209000
922,74511,7459000
932,77111,7719000
942,79611,7969000
952,82111,8219000
962,84611,8469000
972,87211,8729000
982,89711,8979000
992,92211,9229000
1002,94724,94722000
1012,97224,97222000
1022,99824,99822000
1033,02325,02322000
1043,04825,04822000
1053,07325,07322000
1063,09925,09922000
1073,12425,12422000
1083,14925,14922000
1093,17425,17422000
1103,20027,20024000

2016/09/11(日)RecentChangesページを考慮したブラウザキャッシュ制御

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の引数を変えてはいけないという制約ができてしまっているのであまり良くないですね。(うっかり忘れて将来事故を起こしそう^^;)そのうち修正するかもしれません。

*1 : 機能が不要な場合に負荷が増えないように。

その他のbodycache改良版の更新

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

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

*2 : PukiWikiのコードが基本的にタブだったので。

OK キャンセル 確認 その他