What New

●2009.11.08 　オシロスコープ＆±電源付きブレッドボード

●2009.04.12 　トロダイルコアの磁気飽和について（ついでに力率補正の試験）

●2008.12.25 　CalendarMemo ver 1.8.5 を公開します

　前回公開した CalendarMemo ver 1.8.4 のバグフィックス版および目次シートを強化した ver 1.8.5 を公開します。ダウンロードからどうぞ。ver 1.8.4 のユーザは ver 1.8.5 に交換した方が良いと思います。
　なお目次シートに追加（改良）した簡易アウトラインプロセッサの機能は下記で紹介した通りです。また各種シートに戻るボタンを追加しています。メモシートから Web 検索を実行し、また元のメモシートに戻るとき等に使用して下さい。メモシートのプログラマブルなボタンは止めました（殆ど使っていなかったので）。その分、少々ですがメモシートの領域が広くなっています。

注意：インストールする時は必ず diary フォルダをバックアップしてから行って下さい。

良いお年を！　
これが今年最後のアップデート...... になれば嬉しいのですが

●2008.12.23 　目次シートに追加したアウトラインプロセッサ機能

　前回公開した CalendarMemo ver 1.8.4 ですが、前回紹介したようバグが沢山見つかっています。これらバグは解消したのですが目次シートが気になり簡易アウトラインプロセッサ機能を少し強化してみました。目次シートの表示に本文のインデント（字下げ）を反映させただけです。インデントを反映させると drag & drop にもインデントを反映させたくなり、結果的に少々変なアウトラインプロセッサになってしまいました。
　本式のアウトラインプロセッサはトップダウン形式で文章作成支援する機能ですが、CalendarMemo の簡易アウトラインプロセッサはとりあえずメモを書き、書いているうちに全体の構成を考えようとするボトムアップ形式の文章作成を支援する機能になっています。それでは「新しいアウトラインプロセッサ機能について」をどうぞ。
　なお、バグフィックスし本機能を持つ CalendarMemo は今週中に公開するよていです。

●2008.12.23 　LC メーター（ストロベリー・リナックスのキット）

　久しぶりのハード関連の記事です。ストロベリー・リナックスに「ポケットＬ／Ｃメーターキット」なるものがありまして、欲しいと思ったのに発売が停止していた訳で「LC共振周波数を利用したインダクタンスメータ」のように自作するはめになったのです。その後、 Ver 2 として発売されるようになったのですが。残念ながら代引きが 10000円以上でないと使えないという理由で購入できなかったのです（私は代引きしか使わない主義）。久しぶりにストロベリー・リナックスにアクセスすると、何と郵便の代引きなら 10000円以下でも使えるようになったではありませんか。
　本当は既に自作で作っているのでわざわざ購入する必要はないのですが、「LC共振周波数を利用したインダクタンスメータ」で発売が終了していると書いてしまった手前、というか義理もあり、早速購入してみました（本当は比較してみたかっただけですが）。

（１）マニュアルが非常に丁寧に書かれています。
（２）１時間程で作れました。
（３）一発で動作します。お金をとるだけの仕事をしていると思います。
（４）パターン配置も違和感がありません。
（５）L1 には驚きました。
（６）周波数が高いですね（私の２～３倍）
（７）良いですね、このキット久々のヒットでした。
（８）ケースに入れる作業は５時間でした。

　作ってみたいではなく実際に必要としているアマチュアは「LC共振周波数を利用したインダクタンスメータ」で苦労するよりこのキットを購入した方が良いと思います。残念ながら期待した回路図が添付されていなかったので周波数カウンターやタンク回路共振周波数計測への改造は出来ませんでした。普通に使う分には十分実用的なものだと思います（私がこれだけ褒めるのはあまり無い）。それでは計測中の様子を紹介します。

●2008.12.16 　早くも沢山のバグが見つかっています

　新しい機能を追加すると必ず付いて来るのがバグ。蜘蛛は虫でないって知ってました？　私には蜘蛛は立派な虫なんですが、六足じゃ無いんでムシではないそうです。それはそうと見つかっているバグは次の通りです。

（１）年月日フォルダで管理していないファイルの対処
（２）マニュアルの検索（検索シートでマニュアル内が検索できない）
（３）検索シートからの Web検索
（４）メインエディタ以外でファイルリンクや URL リンク不良
（５）メインエディタ以外で gnuplot コマンドの実行が出来ない
（６）年月日の文字列を drag & drop すると動作が変
（７）getClipData 関数の動作不良
（８）インデント処理に不具合
（９）シート幅が保存されない

　いや～沢山バグが出てきました。いずれも単純な copy & paste で発生したバグ。確認すれば良かっただけなんですが。次回の公開はこれらを修正したバグフィックス版になります。それから、今回の Ver 1.8.4 の公開は「新しもの好き」さんだけだったので累積ダウンロード数の奇麗なグラフが得られました。

●2008.12.08 　CalendarMemo ver 1.8.4 を公開します

　ようやく CalendarMemo Ver 1.8.4 が完成しました。これまで小出しに、しかもテストバージョンでご迷惑をおかけしたとことお詫びします。新しいバージョン、１～２ヶ月使ってみて CalendarMemo は新しい次元に入ったと自画自賛しています。単に検索とリンク機能を強化しただけなのですが、もう前バージョンの CM がとても陳腐に見えます（ちょっと興奮気味）。
　前から使っているユーザなら新しい CM の力がすぐに判ると思います。残念ながら新しいユーザは何の事かさっぱり判らないでしょう。でも１～２週間、いや一ヶ月程使い続けると今回のバージョンアップの便利さが判ると思います。ある程度のメモが溜まらないと CM の本当の良さが見えてきませんので。
　とまあ興奮気味に書いていますが、冷静に考えると改良した部分は「CM184 の紹介」の程度で何故かさめてしまうような感じ。何故なんでしょう？　よく考えたらこれまでの機能を使い易くしただけでまったく新しいナンタラカラというものが無いからなんでしょうね。
　一応。新しい部分は

（１）検索シートでは Spotlight を使った全文検索に変更しスペースで区切ると絞り込み検索になります。
（２）メモシートはドキュメントリンクの表示用になりました（これ絶品）。
（３）メモシートや検索シートの表示部で編集と保存ができるようになりました（思った以上に便利な機能です）。
（４）リンク機能、特にシンボリックリンクが強化されています（過去のメモを開いて⌘+shift+Lで面白い事が！）。
（５）何かとても重要な点があったような気がしますが、忘れてしまいました（何だったかな～）。
（６）おまけで備忘録機能を追加しました（まだ良さが判らない！）。
（８）思い出した。[検索文字列] をダブルクリックすると Spotlight による全文検索ができます。
　　　　単純なのですがメモの書き方が変わると思います。
（７）OpenGL の作図と gnuplot コマンドの実行ができるようになりました（まだ暫定板です）。

　ダウンロードは「download」からできます。なお ver 1.8.3 は Universal Binary 化がメインでした。 ver 1.8.4 では CalendarMemo 自体の機能強化になります。なお今回のアップデートでソースを触っていないのに何故かファイルブラウザが不安定に。どうしたんでしょうね？

●2008.11.30 　リンク機能の強化

　前にも紹介したように現在 CalendarMemo のリンク機能強化の作業をしています。といっても見た目には変化がなく使ってみて初めてわかるような機能です。このリンク機能強化に伴いエディタの改良を行っています。これまではメモの編集と保存・mc プログラムの実行はメインエディタ部でしか出来ませんでした。ドキュメントのリンク先をメモシートに変更した事からメモシートでも編集・保存が出来ても不都合はないだろうということでメモシートを改良してみました。ところが何故に検索シートの表示部で編集できないんだということになり、結局はエディタ部の殆どで編集・保存・実行が可能となるよう改良してしまいました。単にリンク機能の強化が CalendarMemo 全体の改良になってしまい.......
　そんな訳で CalendarMemo の改良はほぼ終了し使える状態にまでなっています。ただマニュアルの追加・編集が終わらずまだ公開できない状態です。今日紹介する「リンク機能の強化」はマニュアル増強の一環として書いてみたものです。新しい CalendarMemo ver 1.8.4 が公開されるまで、退屈でしょうが「リンク機能の強化」でも読んでお待ちください。

●2008.11.21 　グラフィックエンジンの差

　CalendarMemo のコンパイルをしていると warning が煩い。Apple はどうしても QuickDraw ルーチンを使わせたくないようだ。回避しようとマニュアルを開くと更に忠告が。しょうがないので CM の改良を中断し作図ルーチンを OpenGL に移行する事に決定。これでまた CM のリリースが遅れる。 CM の作図ルーチンは 15年以上昔のものなので諦めるしかないのだろう。
　でも困った事が。何故かグラフィックエンジンはマシンによって個性があるようです（使用しているグラフィックエンジン）。G5 で使用している NVIDIA GeoForce 6600 OpenGL Engin 1.5 NVIDIA-1.4.18 では何の問題も無のだが MacBook に搭載されている Intel GMA X3100 OpenGL Engine 1.2 Apple-1.5.30 ではライン描画で変なところにラインが走る。さらに OpenGL で描画中にスリープに入り復帰させると G5 の方では何事もなかったように描画を続けるのだが MacBook ではオブジェクトが消え何の反応もない。いや、スリープの時間によって短ければ復帰するのだがスリープが長いと何故か背景だけで、あるべきものが消えている。このようにグラフィックエンジンによって動作・描画の仕方が異なるようである。いつも同じ状態であれば我慢できるのだが、システムの状態により異なるのは気になる。Apple OS の忠告に従い作図ルーチンを OpenGL に移行しようと思っても意図するような結果が得られないのであれば....昔の Spotlight に似ている。 GeoForce 6600 OpenGL Engin って優秀なんだな～

　CM の改良、作業し始めると次から次えと問題が発生。何時になっらた改良・改悪が終わるか、さっぱり分からない。右上の画像だが parametricPlot3D 関数を OpenGL に移行して得られたサンプル画像。奇麗なのだが、実際問題としてこんな画像使う用途があるんだろうか。問題ばかり発生すると嫌になってくる。

P.S.
　gnuplot の件だが、CM にバンドルする事もできるのだが gnuplot 以外に必要なライブラリもある。何をするかによって異なるので gnuplot を取込むのは止めにする。 CalendarMemo から gnuplot を使いたければユーザが自分でインストールするということでお願いする。

●2008.11.13 　CalendarMemo から gnuplot のコマンドを実行してみる

　10 日ぶりの書込みです。雑用が重なり CalendarMemo の改良が中断。その間も色々と改良項目を探し週末の作業目標をたてている。Xcode(cocoa) も色々と思い出しだいぶ慣れてきた。今日は CalendarMemo (CM) の改良とまではいかないが CM をユーザ・インターフェースにする試みについてのお話です。

　CM には私的に実用的だと思う作図関数が比較的多くあります。ただ処理データを簡単に視覚化するというコンセプトで開発しているので誰かに見せる、または発表するには少々、いやだいぶ見劣りする機能です。一般には gnuplot が使われているようで、かゆいところに手が届くというか、すばらしいソフトのようです（ちらっと使ってみた）。

　で、この gnuplot を CM のエディタから起動できたら面白いだろうと思い立ちまして、その機能を追加してみました。単に選択した文字列の先頭に #gnuplot という文字列があればその文字列を mc (matrix calculator) に飛ばすのを止めて gnuplot に飛ばしているだけの単純なものです。
　残念ながら、まだ gnuplot のコマンドをよく理解しておらず http://gnuplot.sourceforge.net/demo_4.1/index.html にあるサンプルを手当り次第に実行してみました。それが「gnuplot の試験」です。サンプルの Web ページに載っている結果とは若干の差はあるようです。たぶんこれは gnuplot バージョンの違いだと思います。確認した訳ではありませんが実行できないコマンド、例えば set style fill transparent solid ..... は ver 4.2 ではエラーになるようです（外すと作図は出来るが透過にならない）。CM としては単に gnuplot を起動しているだけなので次回のアップデートバージョンから使えるようになると思います。

　それから Spotlight 検索ですが、現バージョンでは指定した文字列を含むファイルを探していました（時間がかかる）。検索結果もシステムの Spotlight 検索と違いはなくあまり意味が無いようなので wcd から wc に変更しました。この変更により私の日記メモフォルダー、約６GB10万件（約10年分の記録）のファイル検索が数秒以内と高速検索ができるようになりました。 wcd から wc に変更しても不都合はないようなので次バージョンからこれに統一します。またスペースで区切ると絞り込み検索になるようにしています。公開はいつになることやら。 OpenCV 関連は現在停止中。リハビリ科の要望がまとまった時点で作業を開始する予定です。

●2008.11.01 　高速で画像を描き換えるウインドウを追加

　CalendarMemo を使ったデータ処理は基本的にバッチ処理で十分であると思っていた（リアルタイムな処理は考えていなかった）。OpenCV を知りこの考えに自信が無くなる。とりあえず mc で作成した画像を高速で描き換えることができる仕組みを作っておくことにした。第一弾は pictWindow 関連関数の追加である。 openPictWindow(pict#,title$) を実行すると pict# と同じ大きさのサブウインドウを表示しその中に画像(pict#)を表示する。ウインドウのタイトルは title$ で指定し、ウインドウはこのタイトルで管理する。既に同じタイトルのウインドウがあればウインドウは作らずに画像だけを取り替える（ここが高速描換）。ウインドウを閉じる場合には closePictWindow(title$) で、移動は movePictWindow(title$,|x,y|)、ウインドウの大きさは sizePictWindow(title$,|h,v|) で変更できるようにした。640x480 程度の画像であれば 20～30msec で書換可能なのでリアルタイムの画像表示には使えそうな気がする。
　CalendarMemo にある mc (matrix calculator) で取り扱う画像は Macintosh が出始めの頃から使っている QuickDraw の PICT である。PICT は Draw データと Paint データを混在させることができる。特に Draw データは画像を拡大させても奇麗なままである。何故か MacOSX では Paint データのみ（私が知らないだけかもしれないが）。PICT を Cocoa プログラムで使うには NSImage に変換する必要がある。これまではクリップボード経由やファイル経由で NSImage に変換してきた。今回の高速表示では PICT を NSImage に変換する部分がネックになりそうだったので PICT-->NSImage に挑戦してみた。インターネットで検索すると色々プログラムが見つかった。どれも何故か長い。これまでの画像表示の動作を思い出すと PICT データは NSImage になっても Draw 系のデータとして扱われている。わざわざ Paint データに変換しなくても NSImage の NSData に直接放り込んだら画像として認識してくれるのでは。そう思って下記のプログラムを作ってみた。

    // PICT データを NSImageに変換する
    NSImage *image = nil;
    HLockHi((Handle) pic);
    NSData *data =[[NSData alloc] initWithBytes:*pic length:GetHandleSize((Handle) pic)];
    image =[[[NSImage alloc] initWithData:data] autorelease];

　これであっさりと PICT データを NSImage に変換することができた。何で今まで悩んでいたんだろう。

●2008.10.30 　最近は OpenCV にハマりっぱなし！

　CalendarMemo の改良そっちのけで OpenCV にハマりっぱなし。OpenCV-Private-Framework を導入した事は前に書いたが、色々と問題が発生している。http://opencv.jp/ に載っているサンプルを試しているのだが関数の引数が異なる（パラメータが追加されている）場合や足りない関数があるようだ。他の方が作ったサンプルプログラム、簡単には動かないのが普通。それを動かすようにするための作業が勉強になっているので悪い面だけではない。 OpenCV は発展途上にあるライブラリなんだろう。

　OpenCV を試していて気が付いた事。その多くは CalendarMemo に既にある関数で実現できると思う。10年以上前になるが医療画像のセグメンテーションを試みたときに勉強した内容と一致するところが殆ど。唯一大きく異なっているのが処理速度が速いこと。それに関数がスマートな点（これは凄い！）。そうそう忘れられないのが固有値を使った特徴点の抽出。画像処理で必要なのは画像の平行移動、回転、拡大縮小で変化しない特徴量（不変量）、私はモーメント統計量（平均・分散）くらいしか思い浮かばなかった。あのとき固有値に気が付いていれば面白いことできたのに残念。そうそうサンプルにクラスター分析の K-mean 法（距離）があった、懐かしい。期待値を最大にする EM法（正規分布）も入れておいた方が良かったのではと思う（まだよく見ていないので入っているかも？）。

　新しい CalendarMemo の件だが、 OpenCV の機能を追加するには時間がかかりそうである。私の趣味だけでリリースが遅れるのは申し訳ないので OpenCV 無しで公開しようかと思っている。また OpenCV を体験できるバージョンがあれば面白いかも（サンプルでも実際に応用できそうなもの。10/28 に紹介した処理）。

●2008.10.28 　OpenCV.framework

　Mac OS X OpenCV Port からOpenCV-Private-Framework-1.1.dmgをダウンロードし /Library/Frameworks/ にインストール。lkDemo の main を適当な名前に変更し CalendarMemo の中に取込んでみた。問題なく実行、物体の追跡処理ができた。ところが ESC で終了したら処理は CalendarMemo の方に戻るのだがウインドウがそのまま表示される。終わりに cvDestroyWindow を実行しているのにウインドウが閉じません！　サンプルではプロセス自体が終了するのでウインドウも自動で閉じるので気が付かなかった。まあこれは何とかなるでしょう？
　と調べてみたら cvGetWindowHandle で WindowRef が返って来るはずなのにいつも NULL 。ソースを調べたらきちんと WindowRef を調べて result に保存しているのに return result ではなく何故か return NULL 。これじゃ WindowRef が得られない。たぶん書き換えるのを忘れたのでは。
　Framework をいじる気は無いので GetFrontWindowOfClass, GetNextWindowOfClass を使って探す事に。ウインドウのタイトルから探し出す事ができました。当然ながらウインドウ自体の破棄もばっちり成功。でも何でウインドウの破棄自体をしないんだろう？　意図的なのかそれとも単なるバグか？

ここからは失敗談

　OpenCV.framework 自体は問題なく動作し喜んだのですが別のマシンで実行しようとしたら CalendarMemo 自体が起動しない。ログを見たら OpenCV.framework がロードできないとの事。Xcode ではリンクもエラーも無く終了するのでプログラムの問題ではない。これで半日以上悩みました。実は CalendarMemo にはオープンソースのテキスト検索機能である OgreKit.framework をバンドルしています。OgreKit.framework か使えて OpenCV.framework が利用できないのは変だ。という訳で調べたらビルドフェースに OpenCV.framework のコピーを追加するのを忘れていました。考えてみたら１年以上も CalendarMemo の改良というか Xcode を使っていなかったので細かい事を忘れていただけでした。
　framework のコピーで CalendarMemo の大きさが 14MB に。CalendarMemo の本体なんて 2.5MB程、 OgreKit.framework も 2.5MB 程度。ということは OpenCV.framework って 9MB になる。

ここからは追加の成果

　画像処理の LKDemo を CalendarMemo から起動し特徴点追跡結果の情報を処理するプログラムと結果のグラフを紹介する。この追跡は私の眼球２点の十数秒間の移動の結果である。特徴点追跡関数は暫定的に test_cv 関数としている。下記はそのプログラムである。

a = test_cv(0);
t =(a[#,1]-a[1,1])/60;
a# = parametricPlot(t,a[#,2|nsize(a)]);
b# = parametricPlot(a[#,2],a[#,3],|50,450,50,50,350,50|);
c# = parametricPlot(a[#,4],a[#,5],|50+100,450+100,50,50,350,50|);
d# = changePictSize(a#,2)/(b#*c#);
e# = changePictSize(d#,1/2);
e#;

結果は

　何の説明も無いグラフであるが上はX,Y軸の時間的変化で下がX-Yプロットである。この試験により CalendarMemo から OpenCV の関数およびプログラムが実行できる事を確認した。後は OpenCV の関数群を mc の関数として使えるようにすることと OpenCV の基本的バグが修正されることである。

●2008.10.26 　OpenCVって凄い！

　画像補正関連で Web サーフをしていたら面白い記事を発見。【コラム】OS X ハッキング! (203) OpenCV+iSightで顔を認識 ...　というページ。最近流行の画像認識ライブラリである。サンプルプログラムを試してみたら記事の通りに画像認識ができた。特に面白いと思ったのは lkdemo 。マウスで指定した点が画像の合わせて追跡できるプログラム。
　更に OpenCV というサイトを発見。ライブラリの説明やサンプルプログラムが沢山紹介されていた。calendarMemo の開発環境である Xcode で実行できるか試してみたらサンプルが問題なく実行（試したのは iSight のキャプチャ）できた。まだ説明を読んでいる段階だが Wikipedia の OpenCV を読むと、画像処理（Image Processing）、構造解析（Structural Analysis）、モーション解析と物体追跡（Motion Analysis and Object Tracking）、パターン認識（Pattern Recognition）、etc、とまあ豊富な機能。病理の画像とかリハビリの評価とか夢は膨らみます。術場の外回り、どれだけ仕事をしているか、いや効率的に作業しているかの評価とか、とても嫌らしい分析に使えますな～　いやいや、例えば薬理作用の評価のラットの行動を追跡するとか、冗談抜きに本当に使えそうです。思うにこのライブラリは、そのオリジナルは軍事利用のような。ディスカバリーチャンネルでよく見るアッパッチヘリの照準カメラの映像に良く似ています。
　OpenCV をを使いこなすには相当の力量が必要でしょう。また公開しているのはライブラリなので研究用に利用するには自分でプログラムを記述する必要があります。応用しようとアイデアがあってもプログラミングに慣れていない方には少々敷居が高いのでは。これはどうしても素人が簡単に使えるプログラム環境を作っておく必要があるのでは。
　もし OpenCV の関数を mc (matrix calculator) の関数にできるなら CalendarMemo から OpenCV がインターラクティブに使えるでしょう。試してみる価値がありそうです。でも OpenCV を一読するかぎりにおいて基本的なコアな部分ばかり。はたして mc の関数としてインプリメントできるか心配です。更に mc プログラムはバッチ処理が基本。どのように整合性をとるかが課題になりそうです。今年最後の改良は OpenCV かな？　あまり期待はしないように。
　そうそう改良版の CalendarMemo は近いうちに公開します。

P.S.
　自分で OpenCV を試してみたいな～と思う方は最初に MacPorts をインストールした方が良いと思います（必要なアプリがインストールできる）。後は http://www.0093-style.net/0093/2008/10/macosxmacportso.html とか【コラム】OS X ハッキング! (203) OpenCV+iSightで顔を認識 ...を参考にすると試す事ができます。また OpenCV etc のような検索で色々な情報が得られるので試してみて下さい。

●2008.10.25 　リンクに埋込んだプログラムが実行できるようになった

　リンクに mc (matrix calculator) のプログラムを埋め込みクリックで実行できるようにしてみた。考えてみたらリンク名を関数の識別子と考えるとまるでサブルーチンのようだ。これって Web に埋め込まれた JAVA スクリプトと同じでは。これは新しい考えだと思っていても実現してみると似ているものがある。きっと無意識のうちに影響されているんだろう。
　この処理、関数と考えた時、問題になるのは引数。引数を渡せないということは引数無しの関数。関数とすれば威力半減。何か解決策はないものだろうか。そういえば昔の mc にはグローバル変数の設定ができた。まだ残っているかと調べてみたら奇麗に削除されていた。グローバル変数の副作用を嫌い CalendarMemo の mc ではグローバル変数が利用できないようにしてしまったようだ（自分で作っていても何年経てば忘れてしまいます）。如何にして引数を渡すか、これにしばらく悩みそう。それまでは唯一使えるクリップボードを利用するしかないだろう。

　と、ここまで書いて基本的な疑問が「何に使えるのだろうか」。これまでも何に使えるか判らず単に面白そうだと加えた機能が沢山ある。これもその一つかもしれない。時間が経てば次第に淘汰され便利であれば残るだろうし、使えなければグローバル変数のように使わなくなり、最後には消えてしまうだろう。

　色々やっているうちにとあるメーリングリストに流れた話題を思い出してしまった。丁度いま CalendarMemo で見直しているファイルリンクに関連した話題。そこでちょっと「CalendarMemo の利用法------リンクについて」という Webページを作ってみた。興味があればどうぞ。

●2008.10.24 　フーリエ変換でも画像処理可能？

　10/22 で紹介した画像補正関数の件ですが似たようなノイズ補正は二次元フーリエ変換を利用しても実現可能です。左画像はその例です。左画像の左上がオリジナル画像。これに20％のランダムノイズを加えたのが右上画像。左下が前回紹介した gazoHosei 関数によるノイズ除去。右下が２次元フーリエ変換(CZT2)関数を利用したローパスフィルターの結果です。
　見て判るよう２次元フーリエ変換を利用した画像のローパスフィルタでも十分にノイズが除去でき見掛上はオリジナルに近い画像が得られます。でもよく見ると何かが違うでしょう。オリジナルとの差の変化率を見ると100%以上も変化するピクセルがあります。見た目だけで良いのなら２次元フーリエ変換によるノイズ除去は有効だと思います。しかし、ピクセルの数値そのものが重要な場合、画像の補正は gazoHosei 関数を使った方が良いと思います。

●2008.10.22 　画像補正用関数の試験

　CalendarMemo の改良だけだと気がめいってくる。そこで CalendarMemo に新しい gazoHosei 関数を追加した（気になっていた処理を試してみた）。この関数はピクセル欠陥・欠損のある画像もしくは画像データ（行列）で欠損ピクセル周囲の情報から欠損ピクセルを補う機能を持つ。ここで欠陥．欠損のピクセルとは周囲とは明らかに異なる値を持つピクセルと言う意味です。

→
左：ピクセル欠陥(10%)を持つ画像。右：欠陥ピクセルの周囲から補った画像
30％程度のピクセル欠陥まで対応できそうな感じです

　上記画像が gazoHosei 関数の実行結果である。左は画像の10%にピクセル欠陥を持つ画像補正対象の画像。右は gazoHosei 関数実行後に得られた。見て判るよう欠陥ピクセルの殆どが補正できている（それでどうしたと言われればそのれまでですが）。この処理の原理は非常に簡単で、5x5ピクセル範囲で濃淡の平均と標準偏差を計算し（上記画像の例だと標準偏差が１を超えるピクセルを欠陥・欠損値を持つとし）。欠陥を持つピクセルを周囲5x5ピクセルの標準偏差が１を超えない値の平均と入れ替えるという処理を行っている。

　この関数を作ったのは良いのだが使える場面があるかどうか。少なくても現時点で使える場面が想定できないのが欠点である。ちなみに上記画像のような変化の乏しい画像であれば有効だが変化の大きい画像、例えば文字のような場合には文字が奇麗に消えてしまう。

→
ペイントソフトを使わなくても文字が消える点に注目！

　上記が文字を含む画像（⌘+opt+V でキャプチャーした私の肩近くの画像：左）を gazoHosei関数で処理した結果（右）です。このように文字は周囲に比べ標準偏差が１を超えるため消えてしまいます（ノイズと判断された！）。文字以外は画像の変化が緩やかなので殆どそのままになっています、面白いですね。そういえば MRI のオリジナル画像はノイズが多いのですが、この処理を使ったら奇麗になるかも。学問的に考えるとどうなんでしょうね？　少なくても方法が既知であり誰が実行しても上記左画像が右画像に変換される、すなわち再現性が保証されているので大丈夫のような気がします。ピクセル欠損のあるCCDを誤摩化してデジタルカメラに使うに便利な処理です。ひょっとしてもう使っているかも。ビデオキャプチャー画像に含まれるタイムスタンプを自動で奇麗に消すにはこの処理が便利だろうな。悪用してはいけません！

P.S.
　自分で作っておいて矛盾していると思うかもしれませんが、この手の処理は嫌いです。理由はスッキリしない処理（記述）、というか目的を実現するために仕方なく取る姑息な手段のような気がして。もう少しエレガントな方法で解決したいのが本音です。同じような姑息な処理に grEdit 関数があり、似たようなものです。この手の処理が mc (matrix calculator) の記述で解決できればスッキリするのですが、現時点で処理を記述できないのが mc の欠点です。処理が記述できないという事は、この手の関数が無限に増える可能性があるということになります。
　上記処理例では欠陥・欠損ピクセルの判断を周囲±２ピクセルの範囲で計算している。この範囲の広さを±２ピクセル以上に大きくしても処理に時間がかかるだけであまり大きな効果はないようです。効果の判定に使う具体的な指標が思い浮かばないだけに、これは私の感じたところです（主観的）。
　次回の CalendarMemo で公開するかは未定（追加はしています）。

●2008.10.18 　シンボリックリンク

　そういえば CalendarMemo にシンボリックリンクの機能も有ったな～と調べてみました。シンボリックリンクを選択すると表示編集はできます。でも保存するとシンボリックリンクが実体に変わってしまうようです。リンク元のファイルの編集ができると思っていたのですが。きちんと確認していなかったのが悪かったようです。シンボリックリンクのリンク元ファイルが更新されるよう改良しています。

　この機能を使えば CalendarMemo が管理していない diary フォルダー以外の場所にあるメモも表示編集ができるので便利だと思います。シンボリックリンクの方法は日記メモリスト（ウインドウ右上のリスト）に Finder からファイルを drag & drop する。もしくはメニューバーの「ファイル」からシンボリックリンクの「ドキュメントのシンボリックリンク」を選択すると可能です。

　ドキュメントリンクは日記メモ本文中から別のメモをリンク（開く）機能で、シンボリックリンクは日記メモリストで指定日の年月日フォルダーに CalendarMemo で管理していない場所にあるファイルをあたかも管理しているように誤摩化す機能です。

　そうそう、ちょっとした改良を思い出しました。ドキュメントリンク文字列をダブルクリックするとリンクされたメモが表示されます。ちょっと参照したいだけなのにメモが切り替ってしまうのが気になります。そこで openDocumentOnMemo 関数を追加しました。openDocumentOnMemo(0); を実行するとこれまでと同じようにメモが切り替ります。openDocumentOnMemo(1); を実行するとメモシートに表示するようにしました。これはメニューバーの「その他」から「リンク表示切替」で切換えることもできます。起動直後からリンクをメモシートに表示したい場合には _startup.mc に openDocumentOnMemo(1); の一文を加えて下さい。この修正は環境設定からできます。

P.S.
　またまた変な現象。10/15 にドキュメントへ Finder からファイルやフォルダーの drag & drop の件である。10/15 にはコピーするかエイリアスにするかの確認ダイアログが表示しなかったのに今日コンパイルした CalendarMemoではまた確認ダイアログが表示されるようになった、不思議である（コンパイルの設定何もいじっていないのだが）。

注意：
　Finder で作るエイリアスがシンボリックリンクになると思っていましたが違うようです。エイリアスを年月日フォルダーに入れてもシンボリックリンクのような使い方はできません。

●2008.10.17 　リンク機能追加

　編集中の文字列を選択し ⌘+option+L を実行すると選択した文字列を検索文字列として Google 検索を行うリンクを埋め込むことにしました。また ⌘+control+L を実行すると選択した文字列を検索文字列として Wikipedia 検索を行うリンクを埋め込むことにしました。これまでのドキュメントリンクである ⌘+L はそのままです。
　本文中にリンクを埋め込む方法。既にEPWING電子辞書検索で実装していたのですが、何故に日記メモ本文で対応していなかったのか、理由を忘れてしまいました。実際に使ってみると、それなりに便利なので大した事が無い理由（面倒とか）で実装していなかったものと思われます。このリンク機能は次のバージョンで公開します。

P.S.
　埋め込み型のリンクはテキストエディットで開いても有効。html 変換しても Web ブラウザで有効になるので。 Web ページの編集に便利だと思います。

●2008.10.15 　TextEdit で変な現象が起こっている

　編集中の日記メモへのファイルの drag & drop で変な現象が発生している。これまで編集中の日記メモへファインダーからファイルを drag & drop すると挿入する対象が drag する本体なのかそれともエイリアスなのかを尋ねるダイアログが表示された。ところが昨日あたりからこのダイアログが表示されず日記メモへ本体そのものがコピーされるようになった。プログラムを変更していないはずなのだが、何故だろうか？
　どうも様子が変である。よって日記メモへのファイルの drag & drop はシステム（TextEdit）の指示どうりにするよう戻した。この変更によりファインダからのファイルの drag & drop は本体そのものがオブジェクトとして本体そのものがドキュメント内コピーされる。またそのオブジェクトアイコンをダブルクリックすると単に開くようにした。例えば drag & drop したファイルが画像であればそのままドキュメントにインサートされ表示される。そのアイコンというか挿入された画像をダブルクリックすると画像であればプレビューで表示される。
　ただしダブルクリックが有効になるのは編集中のドキュメントが保存された以降である。思うに、このダブルクリックが有効になるというのは Apple でもどうしようかと悩んでいるのではないかと思う（動作がスマートではない）。いずれにしろ編集中の日記メモへの drag & drop は Apple の方針が決まるまでペンディングとする。 drag & drop されたファイルは画像をのぞき他と区別できないアイコンである。そこで暫定的にアイコンの後にファイル名を挿入するようにした。
　本改良は暫定的な処置である。今後、大幅に変更する可能性が高い。

P.S.
　私としてはファインダーから drag & drop されたファイルはそのままコピーされた方が楽。特に画像であった場合、テキストエディットでコピーしても画像ではないため他のアプリケーションで認識できないという問題がある。ダブルクリックした画像がプレビューで開くとプレビュー上のコピーで画像としてクリップボードに入り他のアプリケーションで利用できる。これもまた便利である。

●2008.10.13 　バグなのかな～（標準の strlen 関数が遅い）

　ワンセグチューナーの件は高い買い物だったと諦めることに。今日は祝日、気を取り直し CalendarMemo の関数をチェックしてみることに。その中で stringFromShiftJIS 関数を試していたらいつまで経っても答えが返ってこない現象を確認。これは暴走かとドッキリ。この関数、チェックしてから公開したはずなのに。チェック用のプログラムでは上手く実行できたのに変です。ソースを見てもおかしな所は見当たらない。両者の違いは文字列の大きさ。チェック用には1000文字程度で行ったのですが、今回は計測データを使ったので約100万文字。ひょっとしたら文字列の大きさが原因かとデバッガーで動作を追ったら。ありました、 for 文の中に条件として i<strlen(str) の記述が。最適化で strlen(str) が定数に置き換わってくれると期待したのが駄目だったようです。何故か strlen の処理速度が遅いのです。前のコンパイラでは今回と同じプログラムでも処理速度が遅いような事は無かったのですが新しい gcc 4.0 だと strlen の処理速度が遅いではないですか。これには気が付きませんでした。これって CalendarMemo のバグなんでしょうか？　ちなみに NSData の length は速いようです。同じような気がするのですがルーチンが違うのか。構造体にデータの大きさを持っているだけかも。
　そんな訳で今回公開した CalendarMemo にはバグのようなものがあり mc (matrix calculator) で大きな文字列を使用すると CalendarMemo が暴走したように反応が無くなる場合があります。これも次回のバージョンでは何とか解決するよう努力します。いや、私が作った部分なら問題ないのですが Apple が提供している Cocoa のルーチンの中に strlen が使われている場合には個別に試してみないと確認できないですから。それにしても厄介なバグだ！

●2008.10.10 　息抜き

　CalendarMemo の改良ばかりで面白く無い。ちょっと息抜きに自宅の作業場を紹介しましょう。と言っても、いつも使っている実験用の電源三種ですが。一番下にあるボックスが絶縁トランスの入った電源です。この絶縁電源から実験に使用する定電圧電源やストレージオシロ、データロガー(GL200)、その他の電源を供給しています。絶縁トランスを使うとオシロやデータロガーが安定して使用できる点がいいですね。絶縁トランスに25V3Aの端子が余ってあったので「実験用CVCC電源」で紹介した回路が入っています。まだフロントパネルに余裕があったのでトライアックを使った電子スライダックと６時間タイマーを加えました（単なる場所塞ぎです）。このトライアックを使った電子スライダックのノイズが大きく気になったので「パルスジェネレータの波形とパルストランスによるMOS FET 絶縁ドライブの試験」の実験をしていた訳です。その上にある２つも電源です。実験する時は最低でも３台の電源は必要。電源には電流計付きが必須です。テスターだと切換えが面倒、電圧計測と電流計測を間違え頻繁にヒューズを飛ばしますので。配線材は廃棄になった多芯ケーブルを20cm程に切断しペットボトルにさしていつでも使える状態に。基板上では錫メッキ線とホルマル線を使い配線しますがケースに入れ基板と機構部品との配線には被覆線を使うので。モニターケーブルには結構細い線が使われているので配線材には重宝しています。物によっては熱に弱い物もあるので注意が必要。１A以上流すような、例えば「-ΔVに依存しないNiMH充電器」では家庭用の電源ケーブルを使っています。
　そうそう、右上にある電子負荷(0～2.5A)ですが、これもあれば電源回路の負荷試験に便利です。100mA 以下の場合には「定電流負荷装置」のようなものがあれば便利（定電流電源としての使い方もあるので）。その隣のLCメータは最初に作ったもので、基準になるコンデンサーが共通のものです。私の設計が悪いのか基準コンデンサーを共通にすると計測範囲が狭く誤差も大きいので web ページでは基準になるコンデンサーをL計測とC計測で別々にした「LC共振を利用したインダクタンスメータ」を紹介しています。LCメータとして使うより周波数カウンターやタンク回路の共振周波数を調べる方が使用頻度が高いようです。

●2008.10.08 　CalendarMemo ver 1.8.3b12 を公開します

　また暫定版となってしまいましたが ver 1.8.3b12 を公開します。いつもの事ですが前バージョンと交換してお使いください。新規ユーザは全ファイルが入っている ver 1.7.8b4 を指示に従いインストールしてから ver 1.8.3b12 に入れ替えて下さい。
　今回の目玉は byteOrder関数です。この関数を使う事でCPUによって異なるエンディアンを解決しています。 mc (matrix calculator)のユーザも問題なく universal binary が使えるようになったと思います。
　その他、本バージョンでは機能不全であった日記メモへの drag & drop やランチャーシートの不具合を改修しています。同様に機能不全にあった FTP シートですが、この機能を停止しターミナルを起動するよう変更しています。また EPWING 電子辞書機能も問題なく使えると思います。
　そうそう　rtfd→html 変換で問題？のあった pict 形式の画像が FireFox で見えなくなる点ですが、昨晩の通り添付画像を全部 JPEG に自動変換する事で解決しました。遊びついでに日記メモに貼付けられている画像をぜんぶ jpeg に変換する機能や Word で開ける doc 形式への変換もメニューに追加してみました（ただし添付画像は使えません）。

●2008.10.07 　バグではないが（rtfd→html）

　ユーザーさんから CalendarMemo の使用報告が届きました。その中に画像が貼付けられた日記メモ(rtfd) を html に変換すると CalendarMemo 内蔵の Web ブラウザや Safari では画像が見れるが FireFox では見れないというものでした。html 変換に使用している textutil は rtfd ファイルにある画像形式を変換せずそのまま使っているからでしょう。たぶん見えなかったのは Apple 固有の画像書式である PICT 画像ではないかと思います。そうそう画面を opt+shift+⌘+4 でキャプチャーした画像も tiff なんですが内容は pict のようで　FireFox では表示できないようです。
　現在のバージョンを使用している方は暫定的な解決方法として次の操作を行って下さい。日記メモに貼付けた画像を選択しマウスで右クリックします。メニューが表れたら「画像の拡大縮小」で適当な倍率を選択します（まあ普通は100%だが）。この操作で日記メモに貼付けられた画像はすべて jpeg 形式に変換されます。その後、 rtfd→html 変換(opt+⌘+h) を実行すると上記のような画像が見えないという問題は発生しません。
　画像の書式をそのまま残すのか、それとも自動で全部 jpeg に変換してしまうのか、悩むところです。いや、面倒だな～と思っている次第です（マック使いには関係のない作業なので）。

　と、考えているといつまで経っても解決しないので& amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; nbsp;opt+⌘+h を実行すると日記メモに貼付けられている画像を総て強制的に jpeg 画像に変換し html 変換することにしました（これなら文句は無いでしょう）。また jpeg に変換しないバージョンは opt+shift+⌘+h ということに。実に安易な解決方法ではないですか（こういうの好きだな～）。
　ということで、この問題は解決したということでご了承ください。まあ副次的な効果でメモに貼付けた画像を強制的に JPEG に変換するとドキュメントのメモリ容量が極端に小さくなる効果もあるようです。まあどうでもいいような気がするのですが。
　次に公開するバージョンではこの機能を付けるので上記のような面倒な jpeg 変換方法は使う必要はありません。ただし何でもかんでも画像と認識されるアタッチメントは総て jpeg に変換するのでご注意ください（movie のようなObject の場合は消えてしまいます）。こう決めてしまうとまたメールが来るだろうな～　総てを上手いように解決するには、本当にそれが良いのか自分自身が納得するまで時間がかかるのです。どうでもいいような事はあまり気にしないで下さい（気になる質なので）。

●2008.10.06 　RSSBrowser は終了ですね！

　久々に RSSBrowser を起動。使えなかった、知らない間に RSS ver 2.0 に移行してしまったようだ。Safari が RSS に対応した事で RSSBrowser の役目も終了。でも CalendarMemo の RSS が対応していない。そこで CalendarMemo の RSS も ver 2.0 に移行。Safari で読み込んでも問題ないようだ。ちなみにこの作業はすべてマニュアルというかテキストエディタで編集。と、なにげなしに xml ファイルをダブルクリックしたら、何と DashCode というアプリで開くではないか。Developer のアプリに xml を開いてくれるアプリがあったんですね、知らなかった。

CalendarMemo とは全然関係のない話

　Logicool のワイヤレスマウスをK's電気で購入したら、何故かスクロールホイールの戻りだけが反応が鈍い。MacBookだけかと思い G5 で確認したが同じ現象。マックだけに問題があるのかと EeePC で確認。同じ現象でした。さっそく販売店に行って交換してもらうことに。店員に「購入したマウスの調子がおかしいのですが」と言ったら「スクロール」ですか？との答（即答だったのが笑える）。想像するに既に同じ苦情を言うお客さんがいたんですね。この件は交換して解決したのですが、知ってて売るとは何事じゃ～　気が付いた客にだけに対応するとはなさけない。これが今の日本の現実か！

　そういえば、Apple の対応も同じようなもの。iPod nano のバッテリーの問題も問い合わせする場所が無い。というか販売店に行ってもAppleからの連絡は無い、対応はすべて Apple で行っているというだけ。インターネットで検索しても問い合わせ方法がヒットしない。ニュースでは対応すると書いていたのに。

　そういえば昨年の話だが、病院で使っている MacBookPro のバッテリーも似たような対応であった。同僚からマックの底が抜けたとの電話。冗談かと思い行ってみると本当に　MacBookPro の底が抜けていた。下記写真はその様子。バッテリーがこれだけ膨れればマックの底が抜けたとの表現もあながち嘘ではない。

　週末の病院に置いていた MacBookPro、バッテリーの異常に気が付いたのは月曜。バッテリーの膨張は異常に気が付いてから三日間程続いていた！
　発火していないからいいようなものの、もし発火していたら現場は病院なので全国放送だったろうな～　とりあえず販売店に事情をはなし Appleに連絡しバッテリーを交換する事に（このマシンだけ）。交換できるのは悪くはないが同じMacBookProが去年の時点で他に７台程あり。そこで Apple との交渉で、病院にあるMacBook, MacBookProのすべてのバッテリーを新しい物と交換してくれるという事であった。シリアルナンバーを調べ送ったのだが１年経っても音沙汰無し。 Apple さんどうなっているんですか、まだ発火していないので交換は発火してからですか～～～本当にシャレにならないぞ～
　この件いらい通達を出し、病院内で使用する総てのバッテリ駆動のコンピュータ（マック以外も）は帰宅時にACコンセントから電源を抜く事になったのは当然ですね。
　マウス不良の件で去年のAppleの件を思い出してしまった！

●2008.10.04 　機能不全：いろいろ

　FTPを見直していたら機能しないようである。とりあえずFTP機能を停止させ同ボタンおよびメニューからターミナルを起動するよう変更。暫定的な措置であるがターミナルから FTPが使えるので大きな問題は発生しないと思う。FTPの改良は一番最後になるだろう（本当に必要かちょっと疑問）。
　FTP のかわりにターミナルを起動する点。使ってみたら意外に便利。 FTP ブラウザはFTPの機能しか無いがターミナルなら FTP 以外の作業（たとえば telnet）も可能。何でFTP にこだわったんだろう？　FTP の再開よりターミナルのシート追加の方が便利なのではと思ってしまう。

　日記メモへファイルやフォルダーを drag & drop するとリンクが張れる機能。試してみたら使えないようだ。前バージョンでも同様に使えない（いつから使えなくなってしまったんだろう）。原因を調べてみたらメモに貼付けるアイコンが読めないためらしい。ファイルのアイコンは jpeg に変換している。このときコメントにリンク場所を書き加えている。いつのOSからか jpeg に変なコメントを書き加えると読めなくなるようだ。このコメント、ドキュメントの保存前にクリックしたときの予備用として書いたもの。いつのOSバージョンからか保存していなくてもアタッチメントに書いてあればりんくするようだ。よってあまり意味が無いので停止。その結果、前の通りリンクするようになりました。画像ファイルの貼付けは通常の通り option+drag&drop です。ちなみにこれを実行するとカレントディレクトリも変更されます。

追加報告
　byteOrder 関数であるが、 MacBook で作成したデータファイルを G5(ppc) で読み込み、その逆も問題なく動作する事を確認。来週には公開できるかも。

●2008.10.03 　またバグ発見（未公開版だが！）

　未公開版でバグ発見。公開予定のバージョンのチェックをしていたらバグが見つかってしまった。整数データのファイルへの読み書きで負の整数で面白い現象が見つかった。同じプログラム（宣言は異なるが）で２バイト整数と４バイト整数でCFSwapIntXX_ で動作が異なる。原因は判らないがキャストで unit16_t を使い解決。真面目にやれば良かっただけのバグ。でも２バイト整数では偶然に使えていたのだろうか。保存は符号の有無にかかわらずそのまま保存。読み込み時に符号に意味を持たせた。よって１バイト -1 を保存すると読み込み時に unsigned char (UnsignedByte) では 255 になる。そんな訳でチェックが終わらないので公開は来週になるかも。
　週末はハード作りで楽しめそうだったのに虫取りになるのか。ますますフラストレーションが溜まる。

●2008.10.03 　フラストレーションが溜まってきた

　最近の作業はCalendarMemoの改良ばかり。プログラミングばかりでフラストレーションが溜まる。何か作るものがないのか。そういえば先月のトラ技に電源の基板が付録に付いてきたみたいだ。トラ技の付録って面白そう。記事を読むと面白そうだと思うのだが実際に使ってみる事が全然ない。人の褌で相撲をとるような気がして何故か反発が、だから進歩が無いのかも。と言いながら何か作るときは他人の回路を参考にするあたりが一貫性が皆無、まあ気分の問題なのかも。
　電源は幾つ有っても困る事はないので付録を使ってみようか。机の回りを見渡せば可変電圧電源だけでも５台ある。これでも足りない位だからもう２～３台あっても良いか！
　でも、何か忘れているような気がする。そういえば電子スライダックの件が残っていた。パルスジェネレータまで作ってそのままに。電子スライダックは使えそうな MOS-FET が無いのでペンディングになっていたんだった。そうそう輸液チューブの気泡検出も検出コイルを作ってそのままに。出血量計測用に大型のフォトダイオードを手に入れたのに放射線計測に使えないかと遊んでしまった。考えてみたらペンディングの山だ！　一つずつ片付けていくか～

●2008.10.02 　ランチャーシートに関して

　CalendarMemo の他の機能を見直していたらバグが見つかった。ランチャーシートで drag & drop したアプリやファイルをダブルクリックしても起動しません。何故かとソースを見たら mouseUp でダブルクリックを検出。何故か昔は mouseUp でダブルクリックを検出できていたんですね！　ダブルクリックを mouseDown で検出よう変更し解決。これでまたランチャーシートが使えるようになりました。
　ランチャーシートの機能、私は殆ど使っていないような状態。それでバグの確認が相当に遅れました。まあ無くても別に困らないで殆ど影響無いかも。

重要（バグ情報です）
　CalendarMemo のユーザからクラッシュレポートがありました（貴重な情報ありがとうございます）。送っていただいたコンソールログからクラッシュを再現することができました。CalendarMemoの起動時、起動した日時の日記フォルダ先頭に日記メモ以外があるとクラッシュするようです。原因は日記メモを表示する TextView の初期設定不良で、TextViewに何も表示するものが無い場合にクラッシュします。今回公開したCalendarMemoから日記メモ以外のファイルを選択したとき選択したファイル名のメモを開かないようにしています（選択前の日記メモを表示）。起動時には選択前の日記メモが無いため、それが原因のクラッシュでした。そこで起動時には強制で新規メモを作るよう改良しクラッシュの原因を回避するよう改良しています。
　CalendarMemoで画像の管理、そのような利用者も皆無ではなさそうなので出来るだけ早めに次バージョンを公開する予定です。

●2008.10.01 　byteOrder 関数

　CPU のエンディアンの問題、結局自動で解決できる方法が思い浮かばず。結局、CPUに依存するエンディアンの問題は byteOrder 関数で指定する事に（loadB関数の簡易型と loadVolumeData関数は自動です）。この関数で BigEndian を指定すると i386 CPU を使用しているマックでもファイルの入出力は BigEndian で読み書きするようにした。acr_nema 関数もこの方式に変更しています。

　下記は Dr.View 形式のファイルを読むときのプログラム例です。PET データ（脳血流量分布）ファイル（12-123456.PET.001.dvi）の20枚目の画像データを読み込んで濃淡図で表示するプログラムです。

byteOrder("ppc");
a = loadImage("12-123456.PET.001.dvi",20);
densityPlot(a,|8000,0|);

　上は体軸に垂直な断層撮影のデータをそのまま表示した例です。今度は水平に撮影した断層データを縦に積み重ね矢状断（サジタール）で表示する例です。刀で正面からまっぷたつにした時の断面と思って下さい。

byteOrder("ppc");
pp = loadVolume("12-123456.PET.001.dvi",1);
b = getVolumeData(64,"S");
b = flipV(b);
b = hokan(b,pp[1,3]*pp[1,7]/pp[1,6],128);
densityPlot(b,|8000,0|);

　"S"の代わりに "C" を指定すると環状断（コロナル）の画像が得られます。

　前バージョンのCalendarMemoで開発したプログラムが上手く動作しないときは byteOrder("ppc"); を実行すると（たぶん）うまくいくと思います。

追加：

　新バージョンでは cal_getFileType, cal_getFileCreator を何故か使えませんというか何故か使えません。面倒なので対応する予定もありません。正直、何でこんな関数があるのか不思議。OS9の時は必要だったのですが、今は.......

もう少しチェックしたら新バージョンを公開したいと考えています

●2008.09.29 　大失敗（ダウンロードとインストール）

　前バージョンの話ですが、ユーザの方からメールがあり「インストールできない」との事でした。ダウンロードページの記述が変というか、何時の頃からか（最初からかもしれませんが）編集途中のものになっていたようです。今日、直しておきました。全ファイルが入っているのは ver 1.7.8b4 です。 ver 1.8.1b4 は本体のみなので既ユーザは下記（２）の通りインストールして下さい

（１）新規ユーザは

　最初に ver 1.7.8b4 の方をダウンロードして下さい。解凍したらCalendarMemo本体をアプリケーションフォルダに、diaryフォルダを書類フォルダの中に保存して下さい。次に（２）の作業をお願いします。

（２）既ユーザは

　まずは最初に書類のフォルダにある diary フォルダーを他の HDD にバックアップして下さい。次に　ver 1.8.1b4 をダウンロードして下さい。これにはCalendarMemo本体しか入っていません。解凍したらアプリケーションフォルダに保存（上書）して下さい。既ユーザは絶対に（１）から始めないように。既ユーザが（１）から始めるとこれまでに書き留めた日記メモが総て上書きされ消えてしまいます。
　もし間違えて diary フォルダを上書きしてしまったら最初に行ったバックアップを使い元に戻して下さい。一番大事なのは diary フォルダなのでくれぐれも消してしまわないように。

　混乱させてしまい、まことに申し訳ございませんでした。

●2008.09.28 　デフォルトのカレントディレクトリ

　mc (matrix calculator)でデータの入出力する場所、デフォルトのカレントディレクトリを変更した。これまでは起動した年月日のメモフォルダをカレントディレクトリにしていた。これを、新しいバージョンではユーザのディクストップをフォルダをカレントディレクトリにするよう変更した。
　ついでにカレントディレクトリ変更のショートカットを alt+⌘+c にした。同じショートカットを現バージョンでは計算に割り当てていたが esc や enter で同じ動作をするので、このショートカット（ alt+⌘+c ）はカレントディレクトリ変更にした。問題は無いだろう。
　Finder からファイルやフォルダを月齢アイコンに drag & drop しカレントディレクトリを変更するこれまでの機能はそのまま残している。

●2008.09.27 　メモの html 変換 (rtfd→html)

　これまでメモを html 変換するのに自作のプログラムを使っていた。あまりにもお粗末だったのでこの機能は殆ど使っていなかったのが実情。今回、 rtfd を html に変換できる Apple 標準の textutil ツールが使える事が判り、これを使う事にした。今回は「2008.09.22 のおまけ」で紹介した機能をメニューに追加してみた。

　開いている日記メモを html 変換したい場合には「alt+⌘+h」を入力する。結果はデスクトップに「mcHTML_folder」を作り、その中に日記メモのファイル名と同じ名前（＋htmld）のフォルダーを作り保存する。同じ名前のメモがある場合には上書きされるので注意すること。確認のため結果は CalendarMemo 内蔵のWebブラウザ・シートに表示するようにしている。変換は非常に高速で普通のメモであれば瞬時に変換が終了し表示できる。画像が貼付けられているメモでも問題ないようだ。
　Wordで読める .doc に変換するメニューも追加しようと思ったがメモに貼付けた画像が有効にならないので止めた。OpenDocumentに変換できるようになったら追加しようかと思っている。

備考
　普通のアプリでは他形式で保存するとき、保存ダイアログで形式を選択するようになっている。CalendarMemoのように自動的に所定の場所に保存するアプリでは保存という行為自体が不自然である（保存するに決まっていたら自動保存の方が便利だろう）。そう考えると型式変換（今回は html 変換）は保存ダイアログで選ぶ必要は無いのでメニューからの実行で十分。保存する場所もデスクトップにでも置いておけば後でFinderで必要な所に移動できるだろう。だから html 変換では勝手にデスクトップに保存するようにしている。これって変かな～

　本機能は次のバージョンから利用できるようにする予定（もうできているが）。

P.S.
　CalendarMemo の評判が気になりWebで検索していると気になる記述が。メモを一つしか開けないのが問題だとか。CalendarMemoでメモを表示させ ⌘+o を入力すると別ウインドウで開きますよ。同時に何個でも開くことができるので複数のメモを参照したい場合には ⌘+o を利用して下さい。
　複数のメモを開く機能は悪くないのですが沢山のウインドウでディスクトップが五月蝿くなります（私は嫌い）。そんな理由で止めたものです。私が不要と思っても使いたいというユーザがいるかもしれないということで ⌘+o の機能が残っています。必要ならこの機能を利用して下さい。CalendarMemo 開発当初からある機能なので現バージョンでも利用できます。

愚痴かな？
　ここからはアルコールによって血液濃度が減少してきた状態での話。考えてみたらCalendarMemoのアップデートは一年ぶりではないだろうか、いやもっとかな～　
　久しぶりに使う Cocoa 、不思議な感触。したいことは解っていてもどう実現するか思いつかない。30歳を過ぎてから勉強した事って簡単に忘れてしまうもの。結局、今回の textutil の件も平凡な C のルーチンを使ってしまった。というよりリストから必要な関数を呼んだだけ。ボケてもプログラムの資産があると頭を悩ませなくても実現できてしまうのです。副作用の無い関数を呼べば答えは確実に帰って来る。私にとって関数は資産。
　思うに老人用のプログラミング言語は副作用の少ない関数型だな！　そうそう、それとAPLかな。APLは A Programming Language の略なんだが、どっちかと言うと教科書に書いてある式がそのまま利用できるから Array Processing Language の方が正確な表現だろう。なにせ若い時に覚えた式がそのまま何の変更も無く利用できる（どうして流行らないんだろう、不思議だ）。
　老人プログラマー諸君、我々が信奉するプログラミング言語は APL+関数型言語である。アルツハイマーやパーキンになっても副作用が無いだけに無条件で過去の資産が利用できる。どう実現したかなんて関係無し。それは若い時に苦労し作ったのであって、いまさら年を取ってから同じ苦労をする必要は無い。 APL+関数型言語さえあれば無敵だ !　老後を面白く生きるには過去の資産を如何に有効に利用できるかにかかっていると思う。

●2008.09.26 　CalendarMemo の Universal Binary 化（その２）

　残っていた夏休みをとり CalendarMem(CM) の Universal Binary(UB) 化を行っている。作業は電子辞書関連を除き順調に進んでいる。電子辞書データが読めない事は無いのだが外字が変。 OpenPicture で16x8の外字の大きさを指定しても何故か4096x2048となる。これを解決するには時間がかかりそう。電子辞書のUB化はたぶん一番最後になるだろう。
　CM を UB に変換し最初に感じたのは起動が速いこと。これまでの半分以下の時間で起動できている。CM の起動が遅いのは mc (matrix calculator)のモジュールをロード・コンパイルするに要するため。ということは実質的に mc が高速化されているようだ。
　QuickDraw やCocoa関係は殆どソースの変更は無し。特にQuickDrawがビックエンディアン固定というのが嬉しい（変更不要な点）。そんな訳で CM の日記メモだけを使っているユーザは現状でも問題ないだろう。UB化の問題は mc (matrix calculator) のファイルの入出力である。これは i386 で保存した数値データが ppc で読み込めない問題（ppcからi386も同じ）。
　まずは loadB 関数の改良をしてみた。方針として ppc&i386で書込んだファイルは区別無く読み込めるようにすること。ただし saveB 関数は ppc ならビッグエンディアンで保存、i386 ならリトルエンディアンで保存することにした。loadB 関数が両者を区別無く読めるなら saveB 関数の改良は不要と考えた訳である。幸いな事に saveB 関数で保存したファイルには行と列の情報が long で保存されている（倍精度浮動小数点簡易保存版）。これを読み込んでファイルの大きさと一致しない場合にバイトスワップすることに。困った事に無条件に倍精度浮動小数点のバイトスワップする CFSwapFloat64 が見当たらない。そこでこれを追加した。結果として ppc, i386 で保存した行列データファイルは saveB 関数で区別無く読めるようになった。
　上記は loadB 関数はデータとファイル名を指定するだけで保存できる簡易版の方である。簡易版ではファイルの行列の大きさが書込まれているのでビックエンディアンなのかリトルエンディアンなのか判断できる。しかし型式を指定して保存する版では行列の大きさが書込まれていない。そこで loadBSwap関数を追加してみた。ユーザが自分で区別する必要がある（面倒だが！）。
　同じような関数に loadVolumeData がある。これは loadB 関数と同じくファイルの大きさが保存されているので自動で区別できる。これも自動で判別できるように変更した。

　ハード製作記事でないだけに書いていても面白みが無い。また何か作ろうかな～～～～

●2008.09.22 　CalendarMemoの Universal Binary化

　まだ夏休みが残っていたのでCalendarMemo(CM)のUniversalBinary(UB)化に着手。プログラミングガイドを読んだら、バイト順に問題があるようです（これは予想されていたことなのですが）。ところが構造体が絡むとまでは想像していなかった（これは面倒です）。まずはi386でビルドすることに。エラーは発生せず、問題なく終了。実行したらクラッシュしてしまいます。デバッガーでクラッシュしたソースを見たら、なんと電子辞書のルーチンでJISコードをSJISに変換する部分で発生していました。この部分は15年以上も前に作ったルーチンです。問題なく実行できるのでそのままにして来た部分。自分でも読めません。
　UB化では電子辞書は後回しすることに。これでCMが順調に起動できるようになった。CocoaやQuickDrawのようなAppleが提供しているルーチンではUB化の基本的な問題は解決しているようです。それじゃ～という訳で matrix calculator (mc) を試験。計算は問題ありません。それでは作図も大丈夫です........と思ったら、作図は出来るのだが作図結果（画像）の演算ができません。エラーになります。mcの作図関連のルーチンは古いQuickDrawを使用。プログラミングガイドを読むとPicFrameに問題が。どうも私は画像の大きさを得るためPicFrameのフィールドに直接アクセスしているようです。幸いにもAppleはQDGetPictureBounds関数を用意してあり、これを使う事で作図関連のルーチンは解決しました。
　この他にも色々ありそうです。PPCで保存した数値ファイル（saveB）をi386で読めません。典型的なエンディアンの問題です。PPCではビックエンディアンで書込んでいるのにi386ではリトルエンディアンで読み込もうとします。この際だからどちらかに統一すべきなんでしょう。そうなると

１：古いデータファイルを尊重しファイルを総てビックエンディアンにする。
２：これからはi386なので総てリトルエンディアンにする。

古いファイルは特別なファイルとして読み込みだけができるようにする。

　どちらを選択したらベターなのか？

　CalendarMemo の universal binary 化には時間がかかりそうです。

---------- おまけ ----------

　下記プログラムをメモシートにおいて実行すると編集中の日記メモのドキュメントが html に変換されます。結果はWebブラウザのシートに表示されるので確認できると思います。

~ 現在開いているドキュメントを保存
cal_saveDocument(0);
~ 現在開いているドキュメントのパスを取得
a$ = cal_getDocumentPath(0);
~ 保存パスを作成、htmlファイルはmcDataに保存
b$ = getTempDataPath(0)+"/"+lastPathComponent(a$)/".rtfd";
~ 既にフォルダがあれば削除する
c$ = "\""+b$+"\"";
system("rm -r "+c$);
~ 新しくフォルダを作成
createFolder(b$);
~ textutilコマンドで html変換を行う
d$ = b$+"/index.html";
dd$ = "\""+d$+"\"";
e$ = "textutil -convert html -output "+dd$+" \""+a$+"\"";
system(e$);
~ 貼付け画像のパスを変更
e$ = loadText(d$);
f$ = swapTextString(e$,"file:///","");
save(f$,d$);
~ WebBrowser で開いてみる
cal_webBrowser("file://"+d$);

　結果は mcData に保存されているので利用して下さい。このプログラムは最近見つけたシステム標準の textutil コマンドを利用したものです。本プログラムは現行バージョンでも動作するのでユーザメニューに登録したら便利だと思います。

●2008.09.18 　メモ(rtfd)を html に変換

　インターネットをサーフしていたらtextutilというページを見つけた。これを読むとCaendarMemoのメモに使っている rtfd ファイルを html に変換したり doc に変換できるようだ。これは面白そうだとメモを html に変換してみたら、あっというまにメモと同じ体裁で html に変換できてしまった。CalendarMemoにある html 変換は後で編集することを前提にし適当に変換しているのだがtextutilはこれを完璧に変換、後の編集は全く必要としていない。これは素晴らしいツールである。ところが、画像を含むメモを変換したら、残念ながら画像が表示されない。どうも画像は絶対アドレス？で書き込まれるようだ。その程度ならプログラムで何とかできる。このツールをCalendarMemo に取り込んでしまおうと思った。
　そこで色々調べている途中「rtfd2html」なる free ソフトを見つけてしまった。もう既に同じ考えで作っている方が居たのですね。そんな訳でCalendarMemoに組込むのを中止。 CalendarMemoの改良は Universal Binary 化の方が先ということで（ガリバーさんのために相当に苦労しそう！）。それにしても作者の方はアイコン作るの上手いですね。私にもこんなセンスがあれば......
　そういえば、私が使っている html エディタは KompoZer です（昔は Nvu を使用）。シンプルでなかなか便利な html エディタです。rtfd2htmlで変換した html ファイルが上手く編集できれば良いのですが。

P.S.
　そういえば、最近ハードの記事がありませんね。何も作っていない訳じゃないのですが紹介するほど面白い物ではないので。それにしてもインターネットって凄い、宝箱のよう。

●2008.09.04 　CalendarMemoに Videoキャプチャー機能（既にあった！）

　スライド作成にVideo画像をキャプチャーする必要がありCalendarMemoに機能を追加しようとソースを見たら、何故か既に作っている。試しにと⌘+Opt+vを実行したら突然に自分の顔が。MacBookってカメラ内蔵だったんですね、忘れていました。どのバージョンからVideoキャプチャー機能があったんだろう？　ボケのせいか自分で追加した機能忘れていました。
　最近、このページはハードの製作記事ばかりです。ストレスが溜まるとハードに走るので、相当にストレスが溜まっているのかも。そろそろCalendarMemoのアップデートでも考えようかな。 CalendarMemoは毎日使っているのですが、いまのところ大きな不満はありません。一年以上アップデートしていないので知らず知らずに私が CalendarMemoに合わして使っているのかも。CalendarMemoを改良するか、まったく新しいCalendarMemoに似たアプリを作るか。どうしようかな～

●2008.06.01 　NiMH充電池用1.8V電源

　最近、ニッケル水素充電池を沢山使うように。なにせ単三・単四型が一本100円(\105)ですから。使っていて不満になるのは充電器。私が多用しているのは NEXcellのNC-60FC。この充電器、稀に充電不良というか１本だけ極端に充電量が少なかったりします。ノイズでΔVを誤検知してしまうのでしょうか。このNC-60FCは一本からでも充電できるので重宝しているのですが。まあ電池にしてみれば秋月のユニバーサル・チャージャーのようにΔVを検知し忘れ充電しっぱなしで高温になるよりはましですが。そこで充電器を作ろうかな～と思い立った訳。
　それにはまず充電用の電源を確保しようと。今回は充電器ではなく充電用の電源のお話です。普通の三端子レギュレータ LM317をチョッパー型のDC-DCコンバータにするというチョット変わった回路の紹介です（データシートに載っていた回路そのままですが）。

　それでは『NiMH充電用1.8V電源』へGO

●2008.05.28 　匂いセンサーTGS2450を使ってみる

　最近どうしたんだろう、いつもは更新に数ヶ月要しているのに。Webページの更新って一度始めると..... まあそんな訳で調子にのって２～３ヶ月前に作った匂いセンサーTGS2450の回路を紹介します。これもまた秋月電子から購入したもの。特に目的があって購入した訳ではないのですが、新しい物を見るとついつい買ってみたくなりまして（そういえば照度計センサーもあったな～）。インターネットで検索してみてもTSG2450の情報があまり見当たらないので参考になればと思います。
　このセンサー、職場（病院）で使ってみたら場所によっては100～800ppmを示す。酔っぱらってしまうのではと心配。なにせ秋田県の県職員は飲酒運転で捕まると一発で懲戒免職ですから。

　それでは『匂いセンサー』へGO

備考：私が紹介する製作記事、そのまま作って上手くできるかどうかは保証できません本当に参考程度にしてください。なにせ私は他の人の回路を参考に他の人と必ず異なる回路を組みますから（アルコール中の血液濃度が低下している状態で書いているので何を言っているのか自分でも解らない (^o^);

●2008.05.27 　紫外線LED(?)を使ったペン型ライト

　電源絡みになるかな～　忘れていた紫外線LEDを使ったペン型ライトの回路を紹介します。単四電池一本で紫外線LEDを点灯させるので電源絡みになるのでは。これはまだHT7750Aを購入する前だったのでトランジスタ式です。HT7750Aを使った方は特性試験の配線図・実機で紹介したものです。
　紫外線LEDペンライトの目的はＵＶ硬化接着剤用なんですが、問題は接着剤が無くこれで本当に硬化するのか不明な点です。望遠鏡のレンズ張り合わせに使えそうなのですが最近望遠鏡もご無沙汰で。組織標本のバルサの代わりに使えそうな気もするのですが、その方面の仕事もいまのところ無いし。結局は作って終わりの話題だけのようです。そういえば20年以上前の話ですが脳の微小血管の吻合に光が使えるとかで低出力の赤外線レーザを使った手術を見た事があります（うちの病院で！）。その先生（最近テレビによく出演している！）も旭川の病院に帰られ光を使った血管吻合も行われなくなってしまいました。赤外線ではなく紫外線ならどうなんでしょうね？

　それでは『紫外線LEDを使ったペン型ライト』へGO

●2008.05.25 　LC共振を利用したインダクタンスメータ

　今日はオペアンプ用の負電源の話だけだったんですが電源絡みでPFM ステップアップDC-DCコンバータの話になり特性試験用の自動化変電圧電源や定電流負荷装置の話になってしまいました。まあWebページの更新も半年に一回になってしまったので少々増えても良いかなと思った次第です。
　こうなったら電源絡みでインダクタンスメータのお話もついでに紹介したいと思います。回路を組み立てるとき抵抗やコンデンサーの容量を測ってみることはあってもコイルのインダクタンスを測ってみる事は殆どありません。まあ私のようなアマチュアレベルではインダクタンスを計測できる装置なんて持っていませんからコイルに書かれた値を信じて使っているような状態。言ってみれば「闇夜の鉄砲」で使ってみてダメだったら別のコイルに交換する、そんな適当な使い方をしてきた訳です。
　でも最近、電源をAC100Vから電池に変更するようになりDC-DCコンバータの回路が必須になるとコイルの特性と言うかインダクタンスを確認しなければならなくなってきた訳です。まあインダクタンス、事の始まりは「金属探知器」から始まった訳ですが.....
　で、今回紹介するのはLC共振回路を利用したインダクタンスメータです。インダクタンスメータとは言ってもLC共振回路を利用しているだけにコンデンサーの容量も計測できます。またLC 共振回路なのでタンクコイルの共振周波数まで計測できます。更には共振回路に使っている回路がフランクリン発振回路で外部信号と共振するありがたい特性があります。これを利用すると周波数カウンターにもなるという一つで４つも美味しいインダクタンスメータになってしまいました。

　それでは『インダクタンスメータ』へGO

●2008.05.25 　PFMステップアップDC-DCコンバータの特性

　電源絡みでDC-DCコンバータの話を。最近、微量流量計や眼球荷重計測など小物の電子回路を作る仕事が多くなってきました。普通電源はAC100Vから取るのですが感電などの医療事故防止の観点と装置回りの配線の煩雑さの観点から電池を使う事が多くなっています。私が作る回路はオペアンプ１～２個程度なので、消費電流は多くても20mA以下。006P型の乾電池でも10～20時間は持ちます。この時間が微妙。一回の手術は普通４～５時間程度。２～３回の使用で電池切れ。この２～３回というのが微妙で、もったいないが使う度に電池交換という事に。それでも使用頻度が月に１～２回であれば気にならないのですが週に１～２回ともなれば普通の乾電池ではなく充電池の方が.....という訳で006P型乾電池の代わりに普通の単三型・単四型充電池で動作させる事を考えてみました。
　共立電子に面白そうなHT7750Aというチップを見つけました。今回は電源絡みでPFMステップアップDC- DCコンバータの特性試験を紹介します。なお同様の試験は「DC -DCコンバーター2 - henteko.org」や「DC/DC コンバータIC HT7750で遊ぶ」にも紹介されているので同じデバイスでも試験によって色々と違う結果になるのが面白いです。
　で、HT7750Aの特性試験の結果から使えるチップであることが判りました。ただしデータシートに載っているタンタルコンデンサーではなく安価な普通の電解コンデンサーを使う場合には容量を１０倍以上にしたほうが良いという結果でした。

　それでは『PFMステップアップDC- DCコンバータの特性試験』へGO

●2007.03.12 　波数制御によるドリルモータ回転数調節装置の動作中の動画ファイル

　2/28 に紹介した波数制御によるドリルモータ回転数制御の動画を作ったので紹介します。内容はAC電源の10サイクルのうち指定したサイクル数をONにし残りのサイクル数をOFFにするパルス幅変調(PWM: Pulse-Width Modulatiom)でドリルモータに電力を供給した方式とAC電源の10サイクルの中にまんべんなく指定したサイクル数を入れ込む疑似周波数変調 (Qusai-Frequency Modulation)で電力を供給した方式の二例です。

１：QFM で10段階の回転制御をしている様子 (3.4MB)
２：20％出力のQFM回転制御でアクリル板に穴を空けている例 (1.8MB)
３：PWMで10 段階の回転制御をしている様子 (3.6MB)
４：20％出力のPWM回転制御でアクリル板に穴を空けている例 (1.3MB)

　動画の形式は MPEG4 の .avi です。もしブラウザ上で見れなかった場合にはダウンロード後に対応しているプレーヤでご覧下さい。

● 備考

　アクリル板にドリルで穴を空けるとき、回転数が高いとドリルの先端が熱を持ちアクリルが融けてしまうことがあります。そのためできるだけ回転数を下げてドリルを使うのですが普通の電子スライダックでは回転数を下げると力が極端に弱くなります。今回、私が作った波数制御は確実に１サイクルの電力がドリルモータに供給されるので回転数が少なくても力はそれほど低下しません。動画をみていただくと判りますが電力の20％出力でもドリルが力強くアクリルを掘削しています。また掘削屑も二本奇麗に伸びているのが判ると思います。掘削の途中でドリルの先端を見ても、穴の中央を見てもアクリルが融けている様子は無く完璧に動作しているようです。皆さんも興味があれば一つ作ってみては如何でしょうか。

●2007.03.11 　半田ごて温度調節装置（追加）

　前回紹介した半田ごて温度調節装置ですが、とても便利なのでもう一台作ってしまいました。これに伴い回路に若干の追加があったので、その紹介です。

ーーーつづきを読むーー

●2007.02.28 　波数で制御する電子スライダック

　久々の更新、今年始めてですね。今回はドリルモータの回転を制御する電子スライダックのようなもの紹介します。工作用に使っているドリルなんですが、皆さんはアクリル板に穴を空けるときヒビが入ったり材料が持ち上がり穴が斜めに空けてしまった経験はありませんか？　私なんてしょっちゅうです。で、できるだけドリルの回転数を下げて使うのですが、このとき使うのは一般的な電子スライダック、回転数を下げるとドリルは回転するのに材料に当たると止まってしまうのです。これを何とかできないかと。それで思いついたのがゼロクロス・スイッチ。これを利用し波数の数を変えて電力制御するならモーターに加わる電圧は確実に100Vなので低速でも力が強いのでは。そう考え波数で電力を制御する電子スライダックを作ってみました。

ーーーつづきを読むーー

●2006.08.06 　電子辞書検索機能

　CalendarMemoに電子辞書(EPWING)の検索機能を追加。私が持っている理化学事典第５版と広辞苑第５版が検索できる程度の機能です。EPWING ver 6.0 のようです。最新の電子辞書は持っていないので使えるかどうか、たぶん大丈夫とは思うのですが、判りません。少なくても ver 6.0 以前の辞書は読めると思います。理化学事典の公式（図）や広辞苑のJPEGの画像は表示できますが動画やサウンドのプレイ機能はありません。
　実は、mc(matrix calculator)の時に既に電子辞書検索機能があったのですがインターネット検索の方が便利だったのでCalendarMemoにはペンディングになっていたものです。でも最近のインターネット検索、ヒットはするが望んでいた情報でないということが多くなりまして。またヒットした内容が本当に信用できるか、インターネットで検索してもまた別に調べなければならない事が多くなってしまいました。結局、面倒だったのでまたCalendarMemoに電子辞書検索機能を追加したという訳です。
　最新版のCalendarMemoの公開の件ですが、何の問題も無ければ今週中に公開できると思います。下の方で書いたアップデート項目が使えるようになります。

ーーーつづきを読むーー

P.S. 理化学事典と広辞苑の最新版は第５版なんだろうか。インターネットで検索しても第５版以降がヒットしない。私が購入したのはCalendarMemoを開発する前なので４～５年バージョンアップしていないことになる。EPWINGってマイナーな辞書規格なんだろうか。そういえば最近EPWINGの話って聞かないな～

●2006.07.17 　最近のアップデートのまとめ

　最近、色々と mc (matrix calculator) 関連の機能拡張をしているので、そのまとめとして書いておきます（半分自分用です）。

（　１）濃淡図のマスクデータを作る densityPlotEdit 関数
（　２）濃淡図のマスクデータを作る densityPlotEdit2 関数（拡張）

これらはROI (region of interest)分析用です。

（　３）画像の位置情報を得る getPictPoints 関数
（　４）画像の位置情報を得る getPictPoints_2 関数

三角形パッチを自動で作る機能を追加

紙のグラフから数値情報を得る時に利用できそうです。

（　５）散布図から任意の領域のデータを取得する grEdit 関数

ちょっと怖い関数ですが上手く使えばとても便利な関数です。

（　６）画像データを変形する morphingData 関数
（　７）画像を変形する morphingPicture 関数

お見合い写真用に使えるかも。私は嫌いですが！

（　８） movie 関連の関数

保存している画像を動画に変換するに使えるかもしれません。振り子のシミュレーションの例をサンプルとして書いています。理科教育用のシミュレーション動画を作るのに使えるかもしれませんね。

（　９）ポイントデータから尤もらしい三角形パッチを作る pointsToSankaku 関数

モーフィング変形用なので単独で使う事はまず無いと思います。

（１０）指定した閉曲線の中にあるデータを選択する region 関数

これはselectIf関数の代わりに使える便利な関数です。

（１１）三角形パッチデータから等高線を描く sankakuContourPlot 関数

計測場所が等間隔ではないデータの等高線を描くとき使えます。例えば天気図の等圧線とか田んぼの凹凸をグラフ化するのに使えるのでは。

（１２）三角形パッチの重心に新しい点を加える sankakuHokan 関数

上記sankakuContourPlot関数で使うデータが荒い間隔で計測している場合に使うと誤摩化せます。

　まだ有りそうなので探しているのですが、試験用に作った関数なのか判らず今のところこの12種類です。メモを残しているはずなのですが、面倒で記録を残さない事が多く、、、、、、これじゃ何のためのCalendarMemoだか！

　これら関数はCalendarMemoは次回の ver 1.7.9 もしくは ver 1.8.0 で使えるようになります。CalendarMemoを普通のメモ書き用としてだけ使っている方はアップデートの必要はありません。