PowerShellによるD&Dしたファイル名などの取り出し方

　先の投稿ではPowershellのスクリプトをD&Dで動かす方法を説明しました。
　今回は、D&Dしたファイルの名前、ファイルパス、拡張子などの取り出し方を説明していきます。

　バッチファイルではご存知のように、%~n1 でファイル名、%~dp1でファイル名を除いたパス、%~x1 で D&Dしたファイルの拡張子を取り出し、バッチファイルのスクリプト上に変数として使用できます。
　しかし Powershell においては、このように簡単に取り出すことはできません。

　そこで今回は、Get-ItemProperty と Select-Object を使って得られるプロパティ情報と、実際にプロパティの呼び出す方法を説明します。

ファイルから得られるプロパティ情報

下記のサンプルプログラムをそのままコピペし、D&Dで動かしてみてください。

#サンプル1
Get-ItemProperty  -LiteralPath $args |  Select-Object  *
 
pause
exit

　スクリプトの内容としては、 Get-ItemProperty を使って $args (D&Dした物を絶対パスとして引数にしている) のプロパティを Select-Object にパイプラインですべて流して表示しているだけに過ぎません。

　例として、 “D:\sample-pic.jpg” を上記のサンプルプログラムにD&Dすると次のような結果になると思います。

　左に緑でハイライトされている文字列がプロパティ名、右の白字がそのプロパティで得られる内容です。
　
　つまり、バッチファイルでいう %~n1 のように BaseName プロパティを選択したらファイル名が得られますし、%~x1 のように Extension プロパティを選択したら拡張子が得られることがわかりました。
　それでは、実際に得る方法を説明します。

プロパティの内容を取得

　また下記のサンプルプログラムをそのままコピペし、D&Dで動かしてみてください。
　スクリプトの内容としては、 Get-ItemProperty を使って $args のプロパティを、プロパティ名を使って呼び出しているだけです。

#サンプル2
Write-Host  "Name is " (Get-ItemProperty  -LiteralPath $args).BaseName
Write-Host  "Extension is " (Get-ItemProperty  -LiteralPath $args).Extension
Write-Host  "FullName(Fullpath) is " (Get-ItemProperty  -LiteralPath $args).FullName
Write-Host  "Last Access Time is " (Get-ItemProperty  -LiteralPath $args).LastAccessTime

pause
exit

　再度 “D:\sample-pic.jpg” を上記のサンプル2にD&Dすると次のような結果になると思います。

　このように、プロパティ名からメンバーアクセス演算子 ( . (ドット))を用いて必要な情報を取り出すことに成功しました。
　単に " . " で繋いで、　.BaseName や .Extension などと書くだけですね。

　これで、今までバッチファイルで使っていた %~n1 や %~x1 などの各種プロパティ変数を Powershell スクリプト上で実現することが出来ました。

参考資料
Microsoft プロパティについて - Powershell
Microsoft オブジェクトの一部を選択する (Select-Object)
PowerShellを使ってサイズや更新日時、バージョンなど、ファイルのプロパティ情報を取得する方法

Powershell 7 スクリプト を D&Dで実行する

• Powershell 7 の ドラッグアンドドロップでの実行方法
  • はじめに・・・Powershellの実行ポリシーの変更
  • D&Dによる Powershell スクリプトの実行方法

Powershell 7 の ドラッグアンドドロップでの実行方法

実行環境：Windows10 x64、Powershell 7.2.4

　最近、従来のバッチファイルからPower shell 7 に頑張って乗り換えようとしています。
　そこで、自分が躓いた事を後学の人の参考になればと思い、備忘録も兼ねて書きました。
　参考になったら幸いです。　
　
　Powershell と Powershell 7 はバージョンが違うため、異なるところが多々あります！
　必ずPowershell 7 の最新バージョンをインストールした上でこの記事をお読みください！

はじめに・・・Powershellの実行ポリシーの変更

　Powershellで自分のスクリプトを書いても、デフォルトのセキュリティの都合により実行できないという事が多々あります。
　はじめに、ローカルファイルにあるPowershellスクリプトの実行ポリシーを変更しましょう。
　
　必ず Powershell 7 を管理者権限で起動し、下記のコマンドで実行ポリシーを変更してください。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

　デフォルトの設定だと、Powershell の ExecutionPolicy は Undefined となっています。
　そこでローカルで作成された Powershell　スクリプトを容易に動かせるように、現在のユーザー　(CurrentUser)　に対して RemoteSigned されたファイルの実行ポリシー (ExecutionPolicy) をこのコマンドで変更しています。
　このコマンドにより、インターネット上で取得した署名済みの Powershell スクリプトと、ローカルで作成された Powershell スクリプト(署名なし含む) が動かせるようになります。

ここまでの参考資料
Qiita : PowerShellの実行ポリシー変更
Microsoft : 実行ポリシーについて - Powershell

D&Dによる Powershell スクリプトの実行方法

　さて本題です。
　自作した Powershell スクリプトを D&D で実行させる方法です。

　最初に作ったPowershell スクリプトのショートカットを作ります。
　その後、作ったショートカットファイルの ”リンク先” に以下のように記入してください。

"C:\Program Files\PowerShell\7\pwsh.exe" -File  "C:\hoge\Powershell-Script.ps1"

　“C:\hoge\Powershell-Script” の部分は適宜変更してください。

　これで、PowershellスクリプトがD&Dで動くようになりました。バッチファイルのようにスクリプトを書けばD&Dで動かせるようになります。

　ただ、D&Dしたファイルの名前の取り出し方や、ファイルパス、拡張子の取り出し方は、バッチファイルと違って一工夫必要です。次回はその事をネタにした記事を書きます。

参考資料
Qiita : PowerShellをダブルクリックやドラッグアンドドロップで実行したい。
PowerShellスクリプトへファイルをドラッグ&ドロップする(bat不要)

ランベルトのW関数を用いたおべんきょう(その2)

前回は[ランベルトのW関数を用いた簡単なお勉強](http://takayoshikane.blogspot.com/2020/09/w1.html)をしました。 今回は、ランベルトのW関数がどのような条件において多価関数として値を返すのか見ていきましょう。 前回の記事は、$\frac{x^2}{log(x)}=9$ の一つの解が $1.162...$ を返し、さらにもう一つの $3.262...$ の解が存在することがわかりました。 ここで、ランベルトのW関数がどのような条件において一価関数として返すのか、二価関数として返すのかをいきなり見てみると、 $$W(z) の z において$$ $$\begin{aligned} W_0 (z) \quad \AND {\rm if} \AND z \AND \gt 0 \\ \ W_0 (z) \ {\rm and} \ W_{-1} (z) \quad \AND{\rm if} \AND -\frac{1}{e} \lt z \AND \lt 0 \\ W_{-1} (z) \quad \AND {\rm if} \AND z \AND \lt -\frac{1}{e} \end{aligned}$$ になります。 具体的に見ていきましょう。 前回の記事では、最後の式で $$x = e^{- \frac {1} {2} W \left(- \frac {2} {9} \right) }$$ という式がでました。この中の、 $$W \left( -\frac{2}{9} \right)$$ で、ランベルトのW関数が一価関数を返すのか二価関数を返すの判別していきます。 先程述べた、「$W(z)$ の $z$ においての条件～」のくだりより、 $$\begin{aligned} W \left( -\frac{2}{9} \right), \ \AND z = -\frac{2}{9} \\ z = -\frac{2}{9} \quad {\rm is} \ -\frac{1}{e} \lt \AND z \lt 0 \quad より、 \end{aligned}$$ この $$x = e^{- \frac {1} {2} W \left(- \frac {2} {9} \right) }$$ は、 $\ W_0 (z)$ と $\ W_{-1} (z)$ の二価関数を取ります。よって、 $$\begin{aligned} x \AND = e^{- \frac {1} {2} W_0 \left(- \frac {2} {9} \right)} \\ \AND = e^{- \frac {1} {2} W_{-1} \left(- \frac {2} {9} \right)} \end{aligned}$$ が解となります。これを計算してみると、 $$\begin{aligned} e^{- \frac {1} {2} W_0 \left(- \frac {2} {9} \right)} \AND = 1.162... \\ e^{- \frac {1} {2} W_{-1} \left(- \frac {2} {9} \right)} \AND = 3.262... \end{aligned}$$ となります。 計算は、[こちら($W_0$版)](https://www.wolframalpha.com/input/?i=e%5E%28%28-1%2F2%29*ProductLog%280%2C-2%2F9%29%29&lang=ja)と[こちら($W_{-1}$版)](https://www.wolframalpha.com/input/?i=e%5E%28%28-1%2F2%29*ProductLog%28-1%2C-2%2F9%29%29&lang=ja)です。 これで、ようやくわからなかった交点も求めることも出来ました。 次回は、他の計算例も見ながら勉強を進めていくことにします。

ランベルトのW関数を用いたおべんきょう(その1)

みなさん、おはこんばんちは 唐突ですが、皆さんはこれ解けますか？ $$\frac{ x^2}{log(x)} = 9$$ ただし、 $log(x)$ は自然対数です。 「は？こんなもん右辺に $log(x)$ 移行して・・・え？」 って普通の人はなると思います。 自分もここから先でつまづいたので、メモがてら解き方をネタにしておきます。 ここで、[ランベルトのW関数](https://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%B3%E3%83%99%E3%83%AB%E3%83%88%E3%81%AEW%E9%96%A2%E6%95%B0)というのが出てきます。 超々ざっくりに言うと、 $z = W(ze^z)$ が成り立つ関数というものがあるってことです。(数学科の人ゆるして) 簡単な例を出すと、 $$x^2 = W( x^2e^{x^2} )$$ ですし、 $$5x =W( 5xe^{5x} ) $$ が成り立ちます。 ただし、$z$ の部分が以下のように違うと $$7x \neq W( 7xe^{5x} )$$ 当然ですが成り立ちません。そのような関数です。 ではここで、 $$\frac{ x^2}{log(x)} = 9$$ に立ち戻ってみましょう。 まずは、さっきのランベルトのW関数を使える形にしたいですよね。 まず計算しやすいように逆数にして $$\begin{aligned} \frac {log(x)}{x^2} \AND = \frac {1} {9} \\ log(x) \cdot x^{-2} \AND = \frac {1} {9} \end{aligned}$$ W関数を使いやすいように、わざと $x^{-2}$ を $e^{-2log(x)}$ にしてあげて 、両辺に $-2$ を掛けて、今回は $$\begin{aligned} log(x) \cdot e^{-2log(x)} \AND = \frac {1} {9} \\ -2log(x) \cdot e^{-2log(x)} \AND = - \frac {2} {9} \end{aligned}$$ W関数を適用して、なんか解けそうな形にして、 $$\begin{aligned} W(-2log(x) \cdot e^{-2log(x)}) \AND = W \left(- \frac {2} {9} \right) \\ -2log(x) \AND = W \left(- \frac {2} {9} \right) \\ \end{aligned}$$ $-2$ で割ったり $e$ をまた乗せて、 $$\begin{aligned} -2log(x) \AND = W \left(- \frac {2} {9} \right) \\ log(x) \AND = - \frac {1} {2} W \left(- \frac {2} {9} \right) \end{aligned}$$ 完成です！ $$\begin{aligned} x = e^{- \frac {1} {2} W \left(- \frac {2} {9} \right) } \end{aligned}$$ W関数内の計算どうすんだよ！って思うかもしれませんが、[Wolfram Alpha](https://www.wolframalpha.com/input/?i=e%5E%28%28-1/2%29*ProductLog%280,-2/9%29%29&lang=ja) の、[Product Log](https://reference.wolfram.com/language/ref/ProductLog.html)で計算できます。 つまり、 $$\begin{aligned} x \AND = e^{- \frac {1} {2} W \left(- \frac {2} {9} \right) } \\ \AND \fallingdotseq 1.162... \end{aligned}$$ です。 ちなみにですが、[Product Log は ランベルトのW関数](https://en.wikipedia.org/wiki/Lambert_W_function) と 同じ意味です。 「ちょっとまて。$y=x^2$ と $y=9log(x)$ でプロットしてみたら、2つ解があるぞ？」 そう考えたあなた。鋭いです。 $x=1.162$ は出せました。問題はグラフ上にある $x=3.262$ です。 軽くネタバレすると、ランベルトのW関数は多価関数で、$W(z)$ の $z$ の値によっては多価を返したり、一価を返したりします。 これは次の投稿で書きますので、気になる方は少々お待ち下さい。 [書きました](https://takayoshikane.blogspot.com/2020/10/w2.html) 参考 - [x^2 = 2^x ～ ランベルトのW関数と共に](https://mikan-alpha.hatenablog.com/entry/productlog_W) - [ランベルトのW関数(Wikipedia 日本語)](https://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%B3%E3%83%99%E3%83%AB%E3%83%88%E3%81%AEW%E9%96%A2%E6%95%B0) - [Lambert W function(Wikipedia 英語)](https://en.wikipedia.org/wiki/Lambert_W_function) - [Two Easy-Looking Equations(Youtube)](https://www.youtube.com/watch?v=GKdEbFO-5lY) - [ランベルトのW関数](http://gilbert.ninja-web.net/math/lambert.html)

個人的に新しいインターレース解除の方法(Avisynth)：24pソースな60iから30pにする。

• はじめに(TL;DR)
• Avisynthでのデインターレースと新しい自分なりのインターレース解除の方法
  • まずは自分の環境
  • 主なデインターレースの方法
  • 新しい自分なりのインターレース解除の方法(コード)
• デコード速度と画質の比較
  • 初期条件
  • デコード速度
  • 画質面での比較
    • プログレッシブなフレームでの比較
    • インターレースなフレームでの比較
  • まとめ
• 参考(AVS Meterの結果を貼り付けているだけ)

はじめに(TL;DR)

最近、GTX1660ti買いました。それまではRadeon7970を使っていましたが、技術の進歩は素晴らしいですね。GTX1660tiのグラフィック処理能力も(Radeon7970と比較して)素晴らしいものですが、GPUエンコードの能力も昔(2013～2014年頃)と比較して素晴らしいものになりました。

これを見ている皆さんはご存知かもしれませんが最近のGPU(Geforce)は、CUDAとGPUエンコード/デコードが独立しており、何かしらのゲームをしながら同時にYoutubeを見たり、ゲームをキャプチャして録画or配信も余裕で出来るようになりました。

また、昔のGPUエンコードを使ったことある方ならわかりますが、画質なんて10Mbps積んでもようやく見れるかどうかというとても酷いものでした。しかし、現在のGPUエンコードはHEVCにも対応しており、品質もCPUエンコードと比べて遜色ないものになりました。私はrigaya氏のNVEncを利用しています。

さすがに、極めて細かい点(ファイルサイズ、1フレーム単位でみた動画の画質の比較)を比較するとCPUエンコードが優りますが、文字通り極めて細かい点ですし、どうしてもCPUではないとイヤだ！という場合でなければGPUエンコードでも全く問題ありません。

しかし、GPUエンコードが進化したことによって別の問題が発生するようになりました。それは、Avisynth自体のデコード速度です。

CPUエンコードで品質と処理速度を両立しようとすると、どう頑張っても最大エンコード速度が 20 frame/sec 程度となり、Avisynthのデコード速度が別にその程度でもCPUエンコードがどちらにしろボトルネックになるので、別にAvisynthのデコード速度なんてあんまり考えなくても大丈夫でした。

しかし、今では妥協しない品質の設定でGPUエンコードを行っても 200～300 frame/sec とか余裕でエンコード出来るようになり、むしろボトルネックがAvisynthのデコード速度となりました。

そこで今回は、主にアニメなど24pへのソースを想定しながら、60iから30pへの高いクオリティでのデインターレース(インターレース解除)を行いながらも、高速なデコードを速度を両立したデインターレース方法を紹介したいと思います。

Avisynthでのデインターレースと新しい自分なりのインターレース解除の方法

まずは自分の環境

Avisynth+ 3.6.0 64bit
CPU:3930K
GPU:1660ti
MEM:32GB

TIVTC.dll の x64版 は、pinterf氏の .dllを使っています。この dll の中に TFM 、TDeint 、IsCombedTIVTC などの関数があります。

また、今のうちに書いておきますが yadifmod2.dll の x64版 は asd-g氏の .dll 、nnedi3.dll の x64版 は jpsdr氏の .dll を使っています。

主なデインターレースの方法

Avisynthのデインターレースには、主に有名な方法で、

1. TFM
2. TDeint
3. nnedi3
4. yadifmod2

などがあります。メジャーなのはこんな感じですが、他にもあるので気になる方は調べてみてください。

それぞれ一長一短があり、品質が良いけれども処理が遅いとか、その逆もあります。

新しい自分なりのインターレース解除の方法(コード)

自分なりの新しい方法はこちらです。

LoadPlugin("TIVTC.dll")
##ここに何かしらの60iビデオソース##

ConditionalFilter(DoubleWeave().SelectOdd(), last,"Crop(0,250,0,-180).IsCombedTIVTC()", "=", "true")
#ConditinalFilterの部分が新しい自分なりの方法です。

「くっさ！こんな簡単そうなコードで良いインタレ解除出来るわけ無いやろ！」とか思うのは当然だと思います。

でも自分が研究してみた限りでは、これがいい方法だったんですよね・・・

関数の内容自体は、 IsCombedTIVTC() でインターレースなフレームかプログレッシブなフレームか判定し、インターレースなフレームのみに対し DoubleWeave().SelectOdd() をかけています。

Crop(0,250,0,-180) をしているのは、右から流れるテロップとか、特にBS11に出るAnime+のロゴに誤爆対策にわざとトリミングしてインターレースかプログレッシブか判定を行っています。

技術的な詳細はこちら

こちらや、こちらがわかりやすいのですが、特に元は24pのソースを60iで放送している場合、任意の5フレームを抽出した内、3フレームはプログレッシブなフレーム、2フレームはインターレースなフレームです。

1t	2t	2t	3t	4t
1b	2b	3b	4b	4b

60iなソースから任意に抽出した5フレームをフィールド単位に分割したイメージ
tはtop、 bはbottomの略

欲しいフレームは2フレームのインターレースなフレーム(この場合は、2tと3bと、3tと4bがインターレースなフレーム)を、プログレッシブなフレームに変えて、5フレームの内5フレームともプログレッシブなフレームに変えたものです。

1t	2t	3t	4t	4t
1b	2b	3b	4b	4b

5フレームともプログレッシブなフレームに変えた場合のイメージ

ということは、インターレースなフレームと判定された場合にのみインターレース解除を行えばよいわけです。

ここで、インターレースなフレームと判定するために IsCombedTIVTC() を使っています。

もちろん全てのフレームに対しまずは IsCombedTIVTC() をかけなければ行けないため、そのために ConditinalFilter を使っています。

Cropの部分は前述の通り、誤爆対策です。

その後のインターレース解除は、Doubleweave() でフィールドを合成し、奇数フレームのみプログレッシブなフレームができるため SelectOdd() でプログレッシブなフレームのみ抽出しています。

古典的ですがシンプルで一番キレイな方法です。

デコード速度と画質の比較

初期条件

TFM、TDeint、nnedi3、yadifmod2 と 今回の ConditinalFilter関数でのデインターレースを用いて、比較を行います。

映像ソースは、とある科学の超電磁砲TのTSソース(1920x1080)のOP部分のみで、フレーム数は2696フレームです。

それぞれの関数の内容は以下のとおりです。

ConditionalFilter(DoubleWeave().SelectOdd(), last, "Crop(0,250,0,-180).IsCombedTIVTC()", "=", "true")
TFM(mode=5,pp=7,slow=2,blockx=4,blocky=4,MI=16)
nnedi3(field=-1,nsize=4,nns=4)
TDeint(mode=0,order=-1, field=-1)
yadifmod2(order=-1,field=-1, opt=3)

TDeintとYadifmod2は少しいい加減な設定

デコード速度

最初にデコード速度です。

デコード速度は数値が高ければ良く、処理時間は小さければ良いです。

AVSMeterでデコード速度をそれぞれ1回のみ測りました。
以下の表に示します。

関数	デコード速度(frame/sec)	処理時間(sec)
ConditinalFilter and TIVTC (今回の関数) interf氏の使用	411.2	6.557
Yadifmod2 asd-g氏の使用	416.4	6.457
nnedi3 jpsdr氏の使用	54.0	49.961
TFM interf氏の使用	20.2	133.572
TDeint interf氏の使用	19.8	136.383

デコード速度と処理時間の表

順位は、表の通り

① Yadifmod2
② 今回の関数
③ nnedi3
④ TFM
⑤ TDeint

流石Yadifmod2と言ったところでしょうか、0.1秒の差ながら自分の作った関数よりも速いです。

個人的には nnedi3 が一番遅いのかなと思っていましたが、 jpsdr氏の最適化が進んでいるためか NN で計算速度多そうながらも思ったより速かったです。

ここで処理速度が一番良いのは Yadifmod2 であることはわかりましたが、次は画質の面で比較しましょう。

処理速度が良くても画質が悪ければ意味ないですからね。

画質面での比較

プログレッシブなフレームでの比較

最初は、プログレッシブなフレームで比較してみましょう。
まずはその最初のオリジナルなフレームから。



至って普通ですね。プログレッシブなフレームです。

次に、今回の関数で見てみましょう。



今回の関数は、プログレッシブなフレームは全く触らないようにしているので、左上の字幕以外は全くの同じです。もし違いがわかる方が居たら教えて下さい。

次に TFM で見てみましょう。



TFMで見ても、気持ちプラセボレベルで変わったかな・・・？というぐらいです。99％は同じでしょう。
処理速度は遅いものの、プログレッシブなフレームでの品質は良いですね。

次に nnedi3 で見てみましょう。



結構変わりました。御坂の脚の部分の線と、原作者の文字がオリジナルと比較して結構変わっています。
わかりやすい点は、レールガン独特の明朝フォントが潰れた形になり、NNを使ってもこのような細かい補正は難しいことが伺えます。

次に TDeint で見てみましょう。



nnedi3 ほど文字は潰れていないものの、オリジナルのフレームと比較してみると御坂の脚の部分の黒い線にノイズが少し載っているのがよく見ると分かると思います。すこしぼやけてノイズがかかっているような感じですね。
また、御坂の服の薄い線がオリジナルと比べてやや薄くなっています。

次に Yadifmod2 で見てみましょう。



はい、御坂の脚の部分にコーミングノイズが載っています。オリジナルと比較してもすぐに分かるのではないでしょうか。オリジナルと比較しても御坂の服の薄い線の書き込みがぼやかした状態になり、いくら処理速度が速いと言っても個人的に常用としては採用し難いです。

個人的な主観ではありますが、オリジナルのプログレッシブなフレームの品質を100点満点とすると、それぞれのフレームの品質は以下の表となります。

関数	点数
オリジナル	100
今回の関数	100
TFM	99
nnedi3	70
TDeint	75
yadifmod2	55

プログレッシブな場合の得点表

結構、プログレッシブなフレームでも処理によっては少し画質が下がることがわかりました。

デインターレースの処理を行う以上、どうしても画質の低下は避けられない話にはなりますが、あまり下がりすぎるというのもよくありません。
そのような意味において、今回の関数はインターレースだとは判定されない限りは全く手をつけないので、少なくともAvisynth上においてオリジナルのフレームと同等の物を維持できます。

次にインターレースの場合の画質を見てみます。

インターレースなフレームでの比較

オリジナルのインターレースなフレームを見てみます。



はい。わかりやすいインターレースなフレームですね。これを元にしてデインターレースを行い、画質の比較を行います。

今回の関数の場合を見てみましょう。



御坂が前に行っているフレームを抽出したようですね。
理論的にはこのフレームが綺麗にデインターレースできたフレーム・・・のはず・・・

TFMでデインターレースした場合を見てみましょう。



これ以降、基準フレーム + 1フレーム のフレームを抽出しています。例えば、これよりも上の2枚が50フレームの所を参照していたならば、この1枚の画像は51フレームの所を参照している形です。本来ならば同じフレームを以て比較すべきですが、それだとインターレースの仕様上、アニメの絵が1コマズレる形になり、画質の比較が困難な為やむを得ず1フレームだけズラしています。予めご了承ください。
画質の内容ですが、とても素晴らしく綺麗にデインターレースできていると評価しても良いでしょう。本当に処理時間がネックです。

次に nnedi3 を見てみましょう。



御坂の服の薄い線が少しぼやけているのと、プログレッシブな場合と同じくフォントが潰れているのが分かると思います。

次に TDeint で見てみましょう。



御坂の脚の部分が、これもプログレッシブの場合と同じくややノイズというか、ジャギっているのがわかると思います。文字は潰れていませんし、ジャギー以外は全くもって問題ありませんが、今回の関数と比較するとやや劣ると言えるでしょう。

次に、yadifmod2 を見てみましょう。



御坂の服の部分の線が潰れているのが分かると思います。また、TDeintのインターレースなフレームと比較してみると、ジャギーもコーミングノイズも増えています。今回の関数でのデインターレースがスッキリしていると感じられるのに対し、これはノイズなどの情報量が増えていると感じられても仕方ないでしょう。

個人的な主観ではありますが、今回のデインターレースされたプログレッシブなフレームの品質を100点満点とすると、それぞれのフレームの品質は以下の表となります。

関数	点数
今回の関数	100
TFM	99
nnedi3	75
TDeint	85
yadifmod2	60

インターレースな場合の得点表

まとめ

以上の比較より、結果の表と得点付け、最終的な総合順位をまとめていきます。
今回は、処理速度と画質の両立を狙って総合順位を付けます。

見ている方によって意見は分かれると思いますが、その場合は自分で順位を付けてみてください。

関数	デコード速度(frame/sec)	処理時間(sec)	プログレッシブ得点	インターレース得点	総合順位
ConditinalFilter and TIVTC (今回の関数)	411.2	6.557	100	100	①
Yadifmod2	416.4	6.457	55	60	④
nnedi3	54.0	49.961	75	70	②
TFM	20.2	133.572	99	99	③
TDeint	19.8	136.383	85	75	⑤

結果と総合順位

今回の関数は、処理速度も速く、画質も良いので1位となりました。
Yadifmod2は、処理速度は1番速いですが、画質はいずれも悪く、4位となりました。
nnedi3は、処理速度はこの中では速い(と言っても今回の関数とyadifmod2の7～8倍かかりますが)、ですが文字が潰れる欠点があるので2位となりました。
TFMは、画質は良いものの処理速度が遅いため、3位となりました。
TDeintは、器用貧乏と評価さぜるを得ず、5位となりました。

無論この順位にはいろいろ意見があると思いますが、それでも今回の関数が良いのは揺るがないと思います。

この関数を使ってみて、良いエンコードライフを送っていただければ幸いです。

多くの方はデインターレースした後、逆テレシネの作業に入ると思いますが個人的には、NVEncの --vpp-decimate の blockx, blocky を 4 か 8 にした上で処理にかければ速く誤爆せずに逆テレシネ出来ると思います。

参考(AVS Meterの結果を貼り付けているだけ)

見たい人はどうぞ

今回の関数のAVS Meter Benchmark.



yadifmod2 のAVS Meter Benchmark.



nnedi3 のAVS Meter Benchmark.



TFM の AVS Benchmark.



TDeint の AVS Benchmark.

Written with StackEdit.

kirikiroid2のエロいゲームデータを外部ストレージに保存する

①Kirikiroid2全体設定で、"外部記憶の書き込みの権限を取得する" を行う。
②外部ストレージ → Android → data → org.tvp.kirikiri2 → files に、外部ストレージで保存したいゲームを移す。
※files フォルダーの中にゲーム名フォルダ(例：ねこパラ用フォルダー)を作って、そこに入れても大丈夫。
③実行してみて正常に動くかどうか確認

外部ストレージの中にただ適当にフォルダを作っても、動かないので要注意。

QGIS OpenLayersPluginでもGoogle Mapが使えるようになった

こちらにもあるように、1年前ぐらいからQGISでGoogle Mapが使えなくなっていました。
代替として、QuickMapServiceを使って見ようみたいなポストもありましたが、1.4.0時点において、再び使えるようになりました。2016/9/6時点の最新Verは1.4.1です。
VersionのChangelogの日付を見るとわかるとは思いますが、ほぼ一年ぶりの更新です。
今回のアップデートにおいて、Google Mapを使うにあたりAPI keyが必要になりました。方法としてはこちらやこちらにわかりやすく書かれているので、それを参照しながらAPI keyを取得して下さい。
取得したあと、下記の画像のように Web → OpenLayers plugin → Google Maps → Set API key へ行ってクリックし、取得したAPI keyをコピペして下さい。

無事入力できていれば、下の画像のようにGoogle Mapのレイヤーが出せる思います。(下記画像はGoogle Streetsを選択)

Google Physical など4つの異なるレイヤーが選択できると思いますが、それぞれ、

• Google Physical：地形図
• Google Streets：上記の画像のように一般的なベクター地図
• Google Hybrid：衛星写真に地名や駅名のラベルを付けたもの
• Google Satellite：文字通り衛星写真のみ

となります。
一番最初に述べたQuickMapServiceを使うと上記の4つのほか、渋滞マップ(取得時点？)と地名や駅名のラベルのみのレイヤーも取得できます。
その辺りに関心がある人はQuickMapServiceも使うと面白いかもしれません。

Open Source DEA のインストールでつまずいたのでメモ

2017/01/21 追記
見直してみましたがめっちゃわかりづらいですね・・・
①の所から、「また、swt.jarもJavaの実行環境～」って言っている所まで読むのでいいと思います。
それでも解決しなかったら、これを見ながらトライ＆エラーするしか無いですね・・・

気が向いたら書き直します。

追記終わり。

研究でDEAを使うこととなり、分析しやすそうなOpen Source DEA(OSDEA)を取り敢えず入れてみることにしました。
インストールのステップは、

①、上記のリンクからOSDEAを落として解凍する。
②、lpsolveが必要なので、普通のIDE版を落としてインストールする。
③、Java SE Runtime(JRE)を落として32bit/64bit両方共インストールする。
④、解凍したOSDEAフォルダ内のlpsolve-vX.X.X.Xフォルダを開き、lpsolve55.dllとlpsolve55j.dllを、使っているパソコンの32bit/64bitに合わせて、Windows\System32やWindows\SysWOW64に入れる。
⑤、OSDEAフォルダ内にあるSWTフォルダを開き、同じように自分のパソコンの32bit/64bitに合わせて適したswt.jar(32bitならwin32、64bitならwin64を選ぶ)をOSDEA-GUIのフォルダに入れる。
⑥、csvファイルを用意して適当な分析ができればOK

と書かれていますが、私はトラブルシューティングのLpsolve error messageにも書かれているように、"The lpsolve library could not be found. Please check the installations～"と表示されてしまいました。

結論から言うと、④と⑤のプロセスに問題が有ります。
OSDEAのlpsolve55.dllと、lpsolve55j.dllは、Windows実行環境に何ら関係は無く、Javaの実行環境(64bit-Javaや32bit-Java)と、Lp solve(IDEの方)の実行環境に依存します。(厳密に言えばこの言い方は少しおかしいですが・・・)
また、swt.jarもJavaの実行環境(64bit-Javaや32bit-Java)に依存するので、32bit版のJavaなら、win32のswt.jar、64bit版のJavaならwin64のswt.jarをコピーして貼り付けてください。

よって、Windows(64bit版)、Java(64bit版)、Lp solve-IDE(32bit版)の場合、
④’、Javaは64bit版の為、lpsolve55.dllとlpsolve55j.dllは、OSDEA\lpsolve-vX.X.X.X\Win64のdllをコピーし、
④’’、Lp solve-IDEは32bit版の為、④’でコピーしたものをWindows\System32に貼り付ける。
⑤’、Javaは64bit版の為、swt.jarはwin64のをOSDEA-GUIのフォルダに入れる。
必要があります。

私の場合、これで解決しました。

端的に言えば、
①Java SE Runtime(JRE)を64bit版、32bit版両方共ダウンロードしてインストールして、
②Javaを実行するbitのDLLをコピーし(Ex : 64bitならwin64、32bitならwin32)、
③Lp solve-IDEを実行するbitのフォルダ(64bit版のLp solveならWindows\SysWOW64、32bit版のLp solveならWindows\System32)に貼り付ける。
④Javaを実行するbitのswt.jarをコピーしてOSDEA-GUIに貼り付ける。
事になると思います。

自分が入れる際も、公式の方は舐めまわすように読んだのですが、④のプロセスがよくわからない書き方だったので、今回メモを残すことにしました。
パソコンに長く触っていますが、このようなパターンは初めてです。

実行しているJavaのbit数が分からなければ、コントロールパネルを見てJavaの所を見るか、OSDEAを起動だけしてみて、タスクマネージャーで64bitか32bitか確認してください。
たぶんググったら具体的なやり方が出てくると思います。

今回のLp solveはIDE版で、32bit版しかないようなのでこのような結果となりましたが、これを見ると64bitのCUI版もあるそうです。(中身は未確認)

OSDEA自体はとても使いやすいソフトなので、DEAの分析を考えている方は使ってみると良いと思います。

(追記)
Windows8(64bit)で、Java(32bit)を同じようなプロセスでインストールしてみた結果、Errorが起こりました。
Java(64bit)をインストールしてみても同様な結果が出たので、もしやと思いJava SE Runtimeを入れた所、無事に動きました。
リンク先から"JRE"を選択して入れて下さい。Windowsの64bit版、32bit版両方共インストールするようにおすすめします。
念のため、上のプロセスも書き直しています。

それぞれの場合分けはめんどくさかったのでやりませんでした

pLaTeXの先頭ページだけ別指定のヘッダーにしよう

pLaTeXで大学のレポートを書いているニッチな皆さん！Wordみたく先頭ページのヘッダーを別指定にしたいと思ったことはありませんか？
今回は、それ欲望を叶えるために書きました。

スタイルのサンプルは、ここ(zip)に上げました。
気になる方は、DLして使ってみてください。一応全体の流れはtexファイルの中にコメントとして書いてあるので、たぶんわかると思います。
fancyhdrのパッケージを使っているので、デフォルトでは入っているとは思いますが、ない方はこちらからDLしてください。

一応、コマンドをしている理由をここで書いておきます。
⑥で、 \fancyhf{} を書いておかないと、2ページ以降のヘッダーに、各セクションのタイトルが書かれてしまいます。

また、⑧で、\renewcommand{\headrulewidth}{0pt} を書いておかないと、それぞれのページのヘッダーに罫線のようなものが書かれ、出したいものとは異なってきます。


プリアンブルとか、jsarticleとか何よ！？という方はこちらとかこちらに分かりやすく書かれていますのでそれを参照してください。
fancyhdrの詳しい説明を見てみたい方は、英文ですがこちらにPDFが有りますのでそれを参照してください。

IDLEをバッチファイル(コマンドプロンプト)からPythonスクリプトを実行してみる

Pythonスクリプトをバッチで実行したくなかったので、IDLEで実行できないかと探してみました。
するとあるもんですね。
バッチファイルで動かすとこんな感じかな。

@echo off
if not exist "%~1" exit
if /i　not "%~x1"==".py" exit

start "IDLE" pythonw "C:\Python33\Lib\idlelib\idle.pyw" -r "%~1"

exit

pythonwに環境変数通してね。
普通のpython.exeでも一応実行されるんですけど、python.exeのDOS窓が残ってしまうのでpythonwの方がオヌヌメ。
リンク先にもあるように、 -r オプションは公式ドキュメントにも載ってません。不思議です。
これでPythonスクリプトをバッチファイルにD&Dするだけで、IDLEで実行されるのでとても助かっております。

おいら的UnicodeEncodeErrorの解決方法

PythonのVerは3.3.4です。なんでや！
最近はPythonを使ってTwitterで遊んでたりしてます。
ですが、Twitterには機種依存文字が多く使われており、しばしばUnicodeEncodeError :'cp932' codec can't encode characterに遭遇してました。

text = "✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌"
print(text)

こんな簡単なテキストでも、

と、エラーが出ます。
Python3自体はUTF-8なのになんでなんだろうと思ったら、これはコマンドプロンプトが原因の問題でした。
ということでIDLEで実行すると、

と、無事に実行されました。

Asfc for ICS+べーたを使ってAndroidでもiPhoneの機種依存文字を見よう

こんにちは

最近はTwitterで、(☝ ՞ਊ ՞）☝、(◞‸◟)、( ◠‿◠ )等などキチガイ顔文字を使って楽しくやっております。

ですが、こういう文字はAndroid搭載のフォントが原因で、Androidでは空白になっていたり、いわゆる豆腐文字になっています。

この問題を解決するには、TofuBusterで一応豆腐を消し去ることも出来ますが、”トーフよ消え去れ”をいちいち選択しなければ豆腐を消し去ることは出来ません。
というわけで今回はAsfc for ICS+べーたを使ってTofuBuster抜きでも機種依存文字を見ようというわけです。

手順としては、

①、ツイッターするやつ(fontデータ)を入れる。
②、こいつで上記のapkファイルを抽出する。
③、上記のapkをPCに移す。
④、apktoolでapkファイルを解凍する。
⑤、解凍して、assetsフォルダの中にあるoriginal.zipを解凍する
⑥、解凍したフォルダの中にある original.ttf ファイルを font.ttf にリネームする。
⑦、Asfc/font フォルダに font.ttf にぶち込む

こんな感じです。これは任意のフォントデータをアプリが読み取ってくれるので、もし他にも任意のフォントを読み取ってくれるアプリがあればこの方法をそのまま転用できると思います。
結果としてこうなります。
無事、文字が表示されています。

無論Cerisierだとこんな感じ。
空白になっていますね。

TofuBusterするとちゃんとバスターされます。

このフォントを適用すると、Asfc for ICS+べーたでは韓国語が見れないようになるという話もありますが、まぁ私はたぶんTwitterでハングルを扱わないのでスルーしています。
その解決方法もあるかもしれないので、気になる人は調べてみてください。

あと、このフォントのライセンスがどうなっているか知らないのでわかる方だけやって下さい。

俺提督、E-4突撃作戦成功せず

E-4に出撃してまいりました。
しかし残念ながら失敗しました。



E-4出撃時につけた表です。
40回ほど出撃しましたが、これでも最大で半分ほどしかゲージを削れませんでした。本当に心が折れると思いました。

今見て改善すれば良いなと思ったことは、

出撃時は全員キラキラにすること

資材をもっと(3万以上)貯めること

クリアには丸一日かかると見て、朝から出撃を開始すること

ですかね。
次回のイベント海域時には、この経験を活かして出撃したいと思います。

まだ、普通の海域は3-2をクリアした時点で止まっているので、しばらくは普通の海域を進めたいと思います。

最後に一言

妙高大破しすぎなんじゃ！！！

PCからビープ音5回鳴った件と首都高

朝起きてパソコンつけたら、いきなり長音5回のビープ音が鳴り響きました。

CMOSクリアしても立ち上がらないので、急いでノートPCつけたらGPUのエラーということを発見。
ついでに、HDMIぶっこ抜いたら直ると書かれていたので恐る恐る実行してみると見事に立ち上がった。
HDMIを差し戻しても無事に起動するしこれで一件落着。
後で調べたらGPUの差し込み不良てな感じらしく、たまたまその時はちょっと調子悪かったのかな？

30分程度で直ったんだけどものすんごく焦りましたね。デスクトップが動かないとホントになんも出来ないし。

それでその日の午後からは始めての首都高運転です。

ルートは、
空港中央→石川町JCT→浜崎橋JCT→大橋JCT→板橋JCT→堀切JCT→京橋JCT→レインボー→辰巳第一PA(ここでおいらから同乗者にバトンタッチ)
箱崎JCT→芝浦JCT→辰巳第一PA(同乗者からおいらにバトンタッチ)→箱崎JCT→C1内回り1周→三宅坂JCT→新宿
てなルートでした。

横羽線運転しましたがあそこ舗装悪いですね。まぁ湾岸線と比べちゃ悪いんでしょうけど。
横羽線でパッシングされて車線譲ったら、追い越していったのは野田ナンバーでした。これだから千葉は闇です。
後、山手トンネルは凄いですね。土木技術の凄さを魅せつけられました。ただ空気の流れが悪いのかちょっと暑かったです。
C1の外回り3分の2と、C1内回りの全てを走りましたが、なんだか昔やってたゲームを懐かしみながら運転していました。じじくさいですね。

首都高を運転していい経験になりましたし、車からの東京は新鮮でとてもよかったです。
一人でちゃんと運転できる自信も付きました。が、首都高は運転し慣れた同乗者を乗せないと事故るから運転できないですね。湾岸線は大丈夫ですけど。

あとは思い切ってウインカーを炊いて入れさせてもらう勇気かな？鼻さえ入れば入れるだろうし。

その後有楽町に行って愛媛フェスティバル見に行きました。

愛媛フェスティバルとか言いながら、みきゃんとバリィさん関連と西予市(なんで？)の物販しか無かったし、いつか見た他県のイベント(秋田だったかな？)と比べれば見劣りしてしまいました。
他県のイベントは祭りの山車みたいなのを持ってきてたので、せっかくなら太鼓でも持って行ってｿｰﾘｬｴｲﾘｬｴｲﾘｬとやれば良かったのにと思います。ヤクザが湧いても俺は知らね

やっぱりこの動画が好きです。



ｿｰﾘｬｴｲﾘｬｴｲﾘｬの動画です。祭りの時期になると何処のスーパーに行ってもこれが流れます。
ヤーさんっぽい人が多くなるし、太鼓でうるさいし、人が多いので僕はあまり好きじゃなかったです。

扇風機とかPCとかの掃除

久々の投稿です。
最近は学校とか教習所とかで忙しかったので、扇風機とかPCにホコリがたまっていました。
というわけで今日はそれの掃除です。

まずは、扇風機のカバーから



うわぁこれはひどいですねぇ・・・
という訳で掃除後



綺麗になりました。

比較画像

次に扇風機の羽。
めんどくさいので比較画像だけ

さぁ次は本命のPCです。



掃除をする前のご尊体です。
見ての通りホコリを吸いまくってます。



中もホコリだらけと思っていましたが、それまでではありませんでした。(ケーブル裏配線したかったんだけどね・・・長さが足りなくてね・・・)



PC内で1番吸気する部分がここなので、ホコリだらけです。

ケース内の掃除前と掃除後の比較です。
ちょっとは綺麗になったかな・・・？

ケース外の掃除前と掃除後の比較です。
写真ではあまりわからないかもしれませんが、これでも相当外見は綺麗になりました。

以上です。

追記

初めてjQueryをほんの少しだけ触ってみました。(ほんの少しだけ触ったというレベルなのか・・・？)
jQueryが便利そうだなということは十二分に分かったのですが、ページを作ったりするという機会は殆ど無いので、もう使うことはないかな？
でもこの画像比較は便利でつね。

ソース参考

CLASS.PM ClassyCompare
jQuery ClassyCompare Plugin
定年退職後の暇人 画像比較プラグインの紹介（jquery classycompare)

Windows7でTVTestがカクカクになる件

OS：Windows7 64bit
TVTest：0.7.23.0 32bit
デコーダ：ATI Mpeg Decoder
レンダラ：EVR

デコーダ、レンダラ変えてもカクカクになるし、TVTestを64bitのやつにしても結果は同じ。

結論から言うとAeroが原因だった。というわけでTVTestを右クリック→プロパティ→互換性の中にある、
「デスクトップコンポジションを無効にする」にチェックすればおｋ。
TVTestを起動するたびにAeroが無効になってしまうけど仕方ないね。

こちらの真ん中辺りに同じ事が書いてあるので、良ければどうぞ。

追記
正確に書くと、起動した時はちゃんと60pにデインタレされています。
ですが、しばらくするとなぜか30pになったり60pになったりという訳分からん状況になっていました。

テンプレート変えました

余りにもデザインがダメダメだったので変えてみました。
Bloggerにあるテンプレだけでここまでスタイリッシュになるなんて、世の中は便利になりましたね。

amazon.comから荷物が届いた

Amazon.comから荷物が届きました。
Amazon.co.jpではありませんよ。

ヤマトの輸送状況はこんな感じです。

Expedited Shippingで頼んでAmazon.comから「2週間くらいかかるよ～」的なメールが来たのですが、DHLGM シカゴ支店から自宅まで一週間もたたずに届いたので正直びっくりしました。

Amazon.comの梱包はこんな感じ。
外見


中身


緩衝材も何もないかもしれないとは思っていましたが、エアークッションが入っていました。
梱包に関しては思っていたよりも良かったです。

僕のgmailアカウントがクラックされた・・・

※殴り書きで書きました。自分用に書いたので非常に分かり難いと思います。

gmailにログインしようとするといきなり、

お使いのアカウントで不正な操作が検出されました。

と出ました。

passとかも変更してログインしてみると、Mail Delivery Subsystem が大量に受信トレイに入っていました。
送り主は mailer-daemon@googlemail.com でしたし怪しい添付ファイルもありませんでした。

Message rejected. See http://mail.google.com/support/bin/answer.py?answer=69585 for more information.

と、書かれていたので見たところ、どうやらgmailはメールを送る方もスパムメールかどうかチェックしていて、
今回はスパムメールだと判断されたので、わざとgmail側はメールを送ることを拒否していたようです。

送られずには幸い済んだけど、クラックされてしまいました・・・。


アカウント アクティビティの詳細から最近のアクティビティを見れるので見たところ、メキシコからIMAP経由でアクセスされていました。
僕はIMAPを使っていないので速攻無効にしました。

今、念のためウイルススキャンをしていますが、もし変なのが検出したらどうしよう・・・

なぜ最近のアマゾンの配送は郵便なのか調べてみた

自分のところは今まで佐川だったのですが、3回連続で郵便で配達されましたし、2chやいろいろなところでも郵便で配達されたという情報が大多数でした。
さすがにこれはおかしいなと思い、調べてみたらこんなページが引っかかりました。

これによると、ヤマトは『信書を配達した』として、どっかから怒られたらしいです。
その信書に該当する文書というのはこのガイドラインに載っていて、納品書や、領収書も信書に該当するらしいです。
ただし、郵便法第4条第3項には、

「運送営業者、その代表者又はその代理人その他の従業者は、その運送方法により他人のために信書の送達をしてはならない。ただし、貨物に添付する無封の添え状又は送り状は、この限りでない。」

と書いてあります。

という事は、今までは

「『ただし、貨物に添付する無封の添え状又は送り状は、この限りでない。』と、書かれているんだから貨物と一緒に納品書を送っても大丈夫だね。」

的な感じでやっていたとは思うけれど、ヤマトはどっかから怒られてしまって、信書かどうかを厳しくチェックするようになってしまい(たとえそれが法律的にセーフだとしても)、
それを察知した佐川も信書かどうかを厳しくチェックするようになったという事だと思います。

ヤマトも佐川も信書に該当するような荷物を取り扱わなくなったら当然アマゾンは困るわけですから、ある程度信頼できて、納品書等も一緒に送れると明言している郵便に切り替えたのではないかと思います。

ちょっと気になったところ
郵便に変わったのはメール便関連のみ？それとも全般？
ヤマトや佐川は荷物と一緒に納品書が送れないのに、なんで郵便だけ送れるの？
納品書等を同封させずに商品を送って、必要な人にはPDFで落とせるようにするとか、別途郵便で郵送させれば問題ないんじゃね？

参考
ヤマト運輸 信書に関する重要なお知らせ
総務省 信書の送達についてのお願い
総務省 信書のガイドライン
総務省 「信書に該当する文書に関する指針」Q＆A集
日本郵便 ご利用案内

こちらもあわせて読むことをお勧めします。

※これはあくまで個人的な見解を書いたものですから、これを絶対に鵜呑みにしないで下さい。まぁ誰も見てないとは思うけど