iPromenade

「モザイク処理」について、簡単なアプリを作成しました。

下図はそれによる処理結果の1例です。

対象画像Aを縦横に等分（100x100）し、その各部分に別の画像B（25個）の中から最も色合いの近いものを自動選択して貼り合わせてみました。

● モザイク対象画像A

● 画像B

● モザイク画像

アプリの詳細はこちら　－＞ モザイク処理アプリ

モザイク（mosaic）とは「小片を寄せあわせ埋め込んで、絵や模様を表す装飾美術の手法」のことですが、画像の一部や全体をマス目で区切ってぼかす処理としての「モザイク処理」について簡単なアプリが作成できないか検討中です。

下記はその試作版での処理結果の1例です。

対象画像Aを縦横に等分し、各部分に別の画像B（1個）の明るさを変化させたものを貼り合わせてみました。

●対象画像 A（元画像）と モザイク画像

●画像 B
　右上のモザイク画像の各部は下記画像の明るさを変えたものとなっています。

（オオミノトケイソウ：　広島市植物公園 2013/2/27）

詳細は　－＞　画像のモザイク処理（０）

ダウンロードなどで入手したテキストファイルをWindowsのメモ帳で開くと改行されずに1行で表示されることがあります。

ホームページで「ソースの表示」を選択してHTML形式で表示させると正しく改行されても、これをコピーしてメモ帳に貼り付けると改行がされないこともあります。

これらはシステムによる改行コードの違い：LF(0a) ＜－＞ LF(0a)+CR(0d) から起こります。

ネットなどからの情報をもとに、ここに当方の覚え書きとして、改行させる方法を1つ記しています。

～～～～～～～～～

気象庁HP:　広島の本日のアメダスデータ画面 の「ソースの表示」（一部）：

・
<tr>
<td colspan="2"><li>&nbsp;<a href="/jp/funkasokuho/">噴火速報</a></li></td>
</tr>
<tr>
<td colspan="2"><li>&nbsp;<a href="/jp/ashfall/">降灰予報</a></li></td>
</tr>
・

これをコピーしてメモ帳に貼り付けると次のように連続した1行になってしまいます。

<tr><td colspan="2"><li>&nbsp;<a href="/jp/funkasokuho/">噴火速報/a></li></td></tr><tr><td colspan="2"><li>&nbsp;<a href="/jp/ashfall/">降灰予報</a></li></td></tr>

正しく改行させるには、

（１）上記のメモ帳のデータをファイルに出力する（x.txt）。
（２）コマンドプロンプト画面で、typeコマンドを使って表示させる。
　　　　type x.txt
（３）表示された文字列をコピーして、メモ帳に貼り付けると
　　　　正しく改行された文字列が得られる。

（注１）上記（２）で、type x.txt > xx.txt としても正しく改行されない。
（注２）コマンドプロンプト画面の文字列のコピーについては下記参照。
　　　　　－＞ コマンドプロンプト画面の表示文字列をコピーするには　

コマンドプロンプト画面に表示されている文字列をコピーして、「メモ帳」などのテキストエディタに貼り付ける方法についてはネット上に色々紹介されています。

ここでは当方の覚え書きとして1例を記しています。

（１）マウスを右クリックしてメニューを表示する。

（２）「マーク」を選択する。　　(注）版によっては「範囲指定」

（３）マウスでコピーする範囲を指定する。

（４）Enterを押す（または マウス右クリック）。
　　　　これで指定範囲がコピーされる。

（５）メモ帳を起動し、「貼り付け」を実行する。

（注）メニューの表示方法
　　コマンドプロンプトのメニューは下記方法でも表示できる。
　　（１）コマンドプロンプト画面左上のアイコンをクリック。
　　（２）「編集」を選択
　　すると、「マーク（K)」から始まるメニューが表示される。

企業や団体のHPを閲覧していると、時々おかしな表記に出くわすことがあります。

例えば、某自動車学校のHPに「シュミレータ室あり」とあったので、これは「シミュレータ室あり」が正しい旨連絡したところ、早速お礼の返事がありました。

模擬実験に関するは英語では simulator, simulationですから、日本語ではシミュレータ、シミュレーションでしょう。

また以前、あるハウスメーカの太陽光発電に関するサイトには発電量の単位として「kwh」と記されていましたので、ワットは大文字にして「kWh」が正しいと連絡しました。

こちらもすぐにHPの修正がなされました。

インターネット百科事典「コトバンク」の中の「マジョリカ陶器」の説明文には2016年3月時点で、

　・・、イタリア半島の東部に浮かぶマジョルカ島を経由して運ばれていたため・・

とありましたが、マジョリカ島（or マヨリカ島、or マヨルカ島）はスペインの東200kmほどの地中海の島、・・、従って、

　・・、イベリア半島の東部に浮かぶマジョルカ島を経由して運ばれていたため・・

とすべきと思われる旨連絡しました。

連絡して１～２か月後に見てみましたが、直っていませんでした。　ところが、最近確認したところ、正しく修正されていました。

私の連絡が反映されたのか、その後他の方からの指摘があったのかはわかりませんが・・・。

誤りを何度連絡しても知らん顔のところもあります。

広島県内では有名な某観光農園のHPに各果物の収穫時期を示したカレンダが載っていますが、そこには英語で「Calender」とあります。

「Calendar」ですと連絡しても直す気配がありません。

辞書を調べると、「calender」という英語もありますが、こちらは紙やプラスチックなどの表面に光沢を付ける機械「カレンダー」だそうです。

同名ファイルをUpしたとき、例えば、サーバ上のあるフォルダにファイル：a.datがあるときにPC上のa.datをUpすると、サーバ上には次の名前のファイルができます。

　a.dat　　　　　　：元々あるファイル
　a.dat.tmpxxxx　　：今回Upしたファイル

このとき、「このフォルダ内に同名ファイルがあります。　置き換え or　取り消し」のメッセージが出て選択できます。

ところが、予めサーバ上のファイル：a.datを削除後にPC上のa.datをUpしたときに、サーバ上のファイル一覧に a.datがなく、a.dat.tmpxxxxのみが表示される不具合が発生することがあります。

本件、昨年の夏頃から発生し出して、現在も直っていません。

プロバイダさんにはその都度状況を連絡しているのですが、なかなか進展しません。

当初はブラウザのせいではないかとの回答もありましたが・・・。

最近頂いた回答は：
　このような状況になったときには
　（１）a.dat.tmpxxxx を削除
　（２）a.dat を再度Up
　してください。
　原因を調査することは不可能です。

とのこと。

これでは困るのですが・・・。

今朝もプロバイダさんに連絡を入れました。

●参考： 本件に関連する過去の記事
１．エンジョイ！ブログが使いやすくなった！（２）
２．エンジョイ！ブログが使いやすくなった！（３）
３．エンジョイ！ブログの不具合：削除ファイルと同名のファイルをUpしたとき

エンジョイ!ブログのアクセス解析機能でサイトを訪れた日毎の数を表示する棒グラフの高さがおかしい問題、昨年12月初旬に初めてプロバイダさんに連絡した後、何度かやり取りしました。

当方からの指摘に対して回答が２転3転し、ついに今日最後通告（？）が・・・。

・アクセス解析には一部に外部ソフトを使用しており、その処理内容が非公開のため詳細不明である。
　詳細不明な外部ソフトを利用しているので誤差が出ることも考えられる。

・今後大幅にシステム変更予定であるが、直近での変更は全体への影響が大きすぎることもあってできない。

・Google Analytics の利用を検討してみてはどうか。

との回答。

処理内容（というより外部仕様）のはっきりしない外部ソフトを平気で使用しているとはビックリです。

これではこれ以上の進展が望めないので本件は the end です。

エンジョイ!ブログのアクセス解析機能でサイトを訪れた日毎の数を表示する棒グラフの高さがおかしい問題、先日（2017/1/5）Blogシステムの問題であるとの回答がありました。

「棒グラフはUTC（協定世界時）より集計して表示、数値（page views）はブログ閲覧者のPC等の時刻より集計した値を表示している」と。

表示される数値（page views）とグラフの高さの集計時間帯が異なるという、全くおかしな（？）システムであるようです。

今まではブラウザやユーザ側の問題であるかのような回答でしたので、漸くBlogシステム側の非を認めたことで1件落着と思いましたが、そうでもなさそうです。

例えば、1月4日のアクセス数について、page views は日本時間の1/4 0:00～24:00の間の値ですが、グラフの高さは、
・1/5 　回答：　UTCの1/4　0:00～24:00（日本時間1/4　9:00～1/5　9:00）
・1/8朝 回答：　UTCの1/3　6:00～1/4　6:00（日本時間1/3　15:00～1/4　15:00）
・1/8夕 回答：　1/5回答のとおり

と変化しています。

ーーーーーーーーーーーーーー

そこで、アクセス数グラフを少し調べてみました（2016/12/9 ～ 2017/1/7）。

日毎のpage viewsとグラフ高さ（グラフから読み取った概算値）を下に示します。

・グラフの高さの上下変動はpage views値と連動しているように見える。
・両者が9(or 15)時間シフトした関係であれば、グラフの高さの変化とviews値の変化の間に多少のズレがあってもよさそう。
・グラフの高さは全域にわたってviews数より高目である。
・30日間の総アクセス数はpage views：1811、グラフの目盛りからの概算では2950で大幅に異なる。

日毎のpage views（X）とグラフ高さ（概算、Y）の関係をプロットすると下図のようになり、両者の間にはほぼ次式が成り立ちます。
　Y  =　X　＋　40
（注）前記表の1日あたりのアクセス数の差 38： 60＜－＞98とも符合する。

以上により、アクセス数グラフの問題は日本時間/UTCの問題というより、単純にグラフ描画プログラムの問題のような気がしてなりません。

エンジョイ!ブログではアクセス解析機能により、サイトを訪れた日毎の数が棒グラフで表示されます。

ところがよく見ると、棒グラフの高さが縦軸目盛と微妙にずれています（IE使用）。

この問題、昨年12月初め（2016/12/4）にプロバイダさんに指摘しましたが、当初の回答は、現象を確認できない、ブラウザ（IE）の問題？、ディスプレイ設定/拡大表示の問題？、他ユーザからの指摘はない等々で、あまりにも誠意に欠けるものでした。

昨日（2017/1/5）漸く不具合の原因が判明したとの連絡がありました。

・棒グラフはUTC（協定世界時）より集計して表示
　数値（page views）はブログ閲覧者のPC等の時刻より集計した値を表示している
　－＞つまり集計期間に9時間のズレがある！

・本機能は根本的な改修を検討中、個別の修正対応はすぐには難しい状況
　現状では簡易的な機能として目安程度に利用してほしい

とのこと。

修正がそんなに難しいとは思えませんが、Blogシステム側の問題であることを認めた点は評価しましょう。

ただ、原因特定まで1か月も掛かるとは・・・。

（注）UTC（協定世界時）とGMT（グリニッジ標準時）はほぼ同じと考えて通常は問題ない。

最近のエアコンには外気温や体感温度を表示できるものがあることを以前紹介しました。

体感温度は皮膚の水分が蒸発したり、熱が奪われたりすることで人間の肌が感じる温度ですが、これは気温、湿度、風速などによって変化します。

これに関するアプリを作成しました。

　ー＞ 体感温度を算出するアプリ

● アプリ画面の例