ResizeImage

 先日 tbasic Ver.1.62を公開しました。今回,このバージョンに対応したプログラムを作ってみましたので,それを紹介します。

 tbasicのVer.1.6での更新内容は主として,動作環境の整備でしたが,グラフ関係で

ResizeImageコマンド

も追加しました。このコマンドは,画像サイズの拡大縮小を行うコマンドです。また,Ver.1.61では,利用可能最大グラフ画面が4500×4500ピクセルになりました。また,Ver.1.62では,更にいくつかの機能の改良を行いました。

 近年の携帯のカメラの高度化により,1200万画素も標準的ともいわれます。これはピクセルで言えば,4000×3000の解像度を意味します。このような状況に対応できるように,Ver.1.61では,最大4500×4500のグラフ画面を利用可能へと修正しました。これで,4032×3024の画像も扱えるようになります。
 しかし,これらの画像は普通は数メガバイト以上のメモリを必要としており,メールに添付したりして利用するには大きすぎます。例えば,次の画像は,私のケータイで撮影したものですが,画面上は小さく見えますが,4160×3120ピクセルの画像で5.29Mバイトの容量を持ちます。

画像1

 容量に余裕があれば,これをこのまま利用することも良いでしょう。しかし,場合によっては,メモリサイズをより小さくして,利用したいこともあるかもしれません。このような場合,画像サイズを小さくすれば,必要とするメモリも少なくなります。例えば,上の例でサイズを縦横4分の1にすると,1040×780ピクセルの画像でメモリは302Kバイトになります。これを以下に表示するとなります。このように表示すると見た目はあまり変わりませんが,画面サイズは1/16,メモリは1/17になりました。

画像2

 このように,必要に応じて,画面の縮小ができると便利です。
 画像1を画像2に変換する方法は色々あり,画像縮小ツールとしてwebで検索すれば多くのツールが見つかるでしょう。しかしここでは,tbasicを利用することを考えます。

(1) tbasicのプログラムを作成する。

 tbasicでグラフ処理に慣れた人であれば,ResizeImageコマンドを利用して,プログラムは簡単に作成できます。それは,グラフ処理の定型的方法:「画像のロード」,「画像処理」,「画像の保存」での,「画像処理」の部分で,ResizeImage処理をするだけです。詳細な説明は避けますが,例えば,次のプログラムで可能です。

ChDir GetProgramDir
' プログラム,画像のあるフォルダをカレントディレクトリに設定
SI$="IMGSample.jpg" :' 入力画像名
TI$="IMGResize.jpg" :' 出力画像名
IMS$=GetImageSize$(SI$) :' 入力画像サイズの取得
WidthG =Val(Left$(IMS$,4)) :' 画像幅
HeightG =Val(Right$(IMS$,4)):' 画像高さ
GScreen(WidthG,HeightG,WidthG/4,HeightG/4)
' 画像用スクリーンの設定,表示は1/4画面を使う
LoadPicture(SI$)
GStretch On :' 全体を縮小して表示
ReSizeImage(1/4) :' 画像を縮小
SavePicture(TI$) :' 画像を保存
End

上のプログラムでは,画像1の名前がIMGSample.jpg,画像2の名前がIMGResize.jpgとしています。

 これはこれで,実用上良いのですが,色々な画像に対して同様な処理を行うとすると,面倒と思うかもしれません。そこで,これらの処理を行う汎用的なプログラムを作ってみました。

(2) tbasic で画像縮小ツールを作成する。

 このプログラムは全体で200行を超えるものですが,ReSizeImage.tbtという名前にしました。プログラムは以下にあります。(ファイルはzip圧縮されています。)

 実は,このプログラムの動作には,tbasic 1.62以上が必要です。ResizeImageコマンドは,1.6でサポートされましたが,このプログラムでは,1.61,1.62で新たにサポートされた機能を使っています。
 
 プログラムの骨格は上のものと本質的に同じですが,コントロール画面を利用したメニューを使って操作します。起動直後は次のようになります。

ここで,「読み込み」をクリックすると,

ダイアログが開き,対象とする画像を選択します。選択すると,画像の大きさを判定し,それに応じたグラフ画面が開かれます。大きな画像の場合は,800×800の画面を開き,縮小して表示します。画像1のファイルを選択した場合は,800×800の画面が開かれ,次のようになります。

この状態で,例えば1/4として,縮小率のボックスに1/4を入力して,Enterキーを押すと,メニュー部分が次のようになります。

画像ファイルの解像度が,4160×3120ですが,縮小率1/4で縮小すると,解像度が1040×780になると示されています。
 ここで,変換実行,保存とすることで,画像2のファイルが保存されます。プログラムは少し長いですが,一度作成すれば,色々な画像の縮小が簡単にできるので,使い道はあるのではと思います。 

tbasic でのMediaPlayer の扱いについて(ver.1.62公開しました)

 tbasicでは,mediaplayerの機能を利用できます。この機能はWindowsに含まれるMediaPlayer(従来版)へのインターフェイスを提供することで実現しています。従来からWindowsではこのMediaPlayerが標準的に利用できていましたが,最近ではこの状況が変化してきました。
 tbasicで利用しているMediaPlayerは現在MediaPlayer(従来版), あるいは,MediaPlayer legacyと言われているもので,Microsoft での開発・更新はすでに終了しています。Windows 11 で利用はできますが,最近では,オプションでの利用となり,クリーンインストールでは,含まれていないようです。

 従来のtbasicでは,MediaPlayerを必須としていましたので,これがインストールされていない環境では,tbasicは起動できませんでした。
 この場合,起動するためには,Windowsでのsystem option 機能からMediaPlayer(従来版)をインストール必要があります。この追加は比較的簡単に可能ではありますが,面倒・不便と思われる人もいるかもしれません。
 元々tbasicでのmediaplayer機能は,追加的なもので,本格的なプログラミング言語を利用して,動画機能等をもつアプリを作成するときのお試しのような位置づけでした。ですから,tbasic を利用している人で,このmediaplayer機能を利用している人は僅かと思います。

 このようなことから今回,Ver.1.62より,MediaPlayerをインストールしていない環境でも,tbasicを起動できるようにしました。起動は,MediaPlayeがインストールされていても,されていなくても,特にアラートはなく起動します。勿論インストールされていなければ,tbasicの中でMediaPlayer機能は使用できません。使用すると,「エラー: MediaPlayer がインストールされていません。」と表示されて,プログラム実行が停止されます。
 MediaPlayer機能を必要としていない人にとっては,この方が良いでしょう。

tbasic 1.61を公開しました。

tbasicセット1.61を公開しました。

tbw161set.zip 
https://www.tbasic.org/downloads/index.html

です。

Ver. 1.6 及び 1.61の更新の詳細は,https://tbasic.org/documents/202501WhatsnewTBasic161.pdf
にあります。


Ver.1.6及び1.61の更新は主として,ユニコード,日本語処理関連のものです。tbasicがユニコード対応になったのは,2010年 Ver.1.2ですから,もう大分前のことです。この間,コンピューター利用環境の世界では,ユニコードが徐々に浸透し,今では意識しないでユニコードを利用する状況になりました。

しかし,それでも日本語環境になかで,旧来型のShift_JISエンコーディングが広く使われています。またメール環境の中では 今でも7ビットJISエンコーディングが普通に使われています。昔作成したデータやプログラムがShift_JISで記述されていることも多いでしょう。また,現在でも青空文庫で提供されてる文書は殆ど(すべて?)Shift_JISです。

このような中で,tbasicは初級インタプリタ言語として,できる限りそれらの環境に応じた処理ができるようなツールとして心がけています。種々のBASICがある中で,これはtbasicの特徴の一つとも思えます。それらは主として,読み取り,書き込みが種々のエンコーディングで可能ということで実現できます。今回の更新では,それらをより使いやすいように改良を加えました。

扱えるエンコーディングとしては,普通の使用では,Shift_JISとUTF-8があれば,ほぼ十分と思えます。しかし,tbasicでは,JIS,EUC,UTF-16,UTF-32も扱えます。これらを判定する関数として,GetFileEncodingName関数をサポートしています。

この関数でこれらすべてのエンコーディングを完全に判定することはできませんが,日本語を含むファイルについてはかなり正確に判定できると思っています。元々エンコーディング判定は原理的に完全にはできません。それは,同じファイルがいくつかのエンコーディングでファイルとして意味の持つものが存在するからです。

例えば,内容が”NX”というファイルをShift_JISで作ったとします。このファイルのバイナリとしての内容は,16進数で表すと,2バイトで,

4E 58

となります。これは,単純なアスキーファイルになりますから,UTF-8,JIS,EUCで読んでも内容は “NX”になります。ところが,このファイルをUTF-16のBigEndian として読むと,内容は”乘”になります,また,UTF-16のLittleEndianとして読むと,”塎”となります。ですから,この2バイトのファイルが与えられたとき,エンコーディングの情報が与えられていなければ,なんと読んでよいのか分かりません。

このように,ファイルのエンコーディングは,読む側が,予め知っているというのが原則になります。しかし,それも限界があり,GetFileEncodingName関数それを補完するものとしての位置づけです。

今回の更新では,このGetFileEncodingName関数の改良及び,種々のエンコーディングでの読み書きの改善を図りました。種々のエンコーディングを利用する状況は少ないかもしれませんが,必要になった場合,有効なツールとなると思われます。

1 2 3 11