アカウント名:
パスワード:
演算能力、帯域、メディア容量がどんどん強化されていけば将来、静止画像は「サイズを無視できるほど小さなデータ」扱いされて、一々圧縮しなくなるのではないかな。
それどころかバイナリである必要すら全然無くて、csv形式とかxml形式の画像ファイルフォーマットがあってもいいんじゃね?とか思う。
画像の自動生成が楽になるとか、diffとかpatchで色々出来るようになるとか、htmlとかの中にインラインで画像を置けるとか、いろいろ捗りそうなものだが。
動画も静止画の延長上にありますから、静止画の圧縮技術は動画の圧縮に直結してるわけで…。
あと、バイナリである必要性ですが、むしろテキストにする必要性があるとは思えません。
画像生成・画像処理についても、ビットマップデータ的なモデルを想定してるのかもしれませんが、考え方としてはビット単位でコチョコチョいじるのはむしろ処理のやり方としてやりやすいとは思えません。
風景写真の画像を AWK、Perl などのテキスト・ツールで2次元FFTをかけたり、移動平均フィルターをかけたり、エッジ検出したり?考え方として良いとは思えません。
餅は餅屋といいますが、画像にはバイナリーの方が向いているんでは?
…と個人的な感想です。
PNMはテキスト形式有りますが、結構便利です。読み込みはともかく、書き出す時がとても楽。バイナリやcsvをsedで加工するだけで画像フォーマットになる。その後、ImageMagicでPNGに変換したりできるし。
バイナリをsedで加工するのは比較的ハードルが高い気がするんですが。
つsed "s/\(.\)/\1\1/g"
それだけだとバイナリ中に 0x0a などが出てくると失敗すると思うのだが
うっ…
(ほぼ)倍なり…
「-z」オプションが使えるsedならなんとか…。
書き間違えました。テキストデータです。テキストやcsvをsedやらtrやらで加工して画像にしてます。
何でもかんでもテキストにすべきとは思いませんが、別コメにも挙がってるテキストフォーマットのPNM(PBM/PGM/PPMの総称)は、ちょっと簡単に機械生成するときに便利なんですよね。Excelのシートで計算させて、そこからコピペでPGMにしたりとかもたまにやります。A1=「P2」/A2=「幅」/B2=「高さ」/A3=「画素数値最大値」を入れて、あとはA4以降に画素数値を埋め込むようなワークシートを作ってをけば、そのままコピペ(でタブ区切りになって、そのままPGMと解釈可能)で画像化できるというお手軽便利。
Perlとかの使い捨てスクリプトでPPMを出力するのが一番手軽。まあ、Perlなどバイナリ出力が容易なスクリプトを使う時は、P1~P3(テキスト形式)ではなく、P4~P6(バイナリ形式)を使いますけど、それでもヘッダはテキストなので簡単に間違いなくヘッダ生成できるのですごくお手軽です。
ビットマップ的なものには既にベクタ形式がありますしね。
Perl などのテキスト・ツールで2次元FFT
むかしどこかの.pmで聴いた気がしましたが、あれはWAV変換でした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
静止画像ごときを一々圧縮しなくなる日が来るのでは (スコア:0)
演算能力、帯域、メディア容量がどんどん強化されていけば将来、
静止画像は「サイズを無視できるほど小さなデータ」扱いされて、
一々圧縮しなくなるのではないかな。
それどころかバイナリである必要すら全然無くて、csv形式とかxml形式の
画像ファイルフォーマットがあってもいいんじゃね?とか思う。
画像の自動生成が楽になるとか、diffとかpatchで色々出来るようになるとか、
htmlとかの中にインラインで画像を置けるとか、いろいろ捗りそうなものだが。
Re:静止画像ごときを一々圧縮しなくなる日が来るのでは (スコア:0)
動画も静止画の延長上にありますから、静止画の圧縮技術は動画の圧縮に直結してるわけで…。
あと、バイナリである必要性ですが、むしろテキストにする必要性があるとは思えません。
画像生成・画像処理についても、ビットマップデータ的なモデルを想定してるのかもしれませんが、
考え方としてはビット単位でコチョコチョいじるのはむしろ処理のやり方としてやりやすいとは思えません。
風景写真の画像を AWK、Perl などのテキスト・ツールで2次元FFTをかけたり、移動平均フィルターをかけたり、エッジ検出したり?
考え方として良いとは思えません。
餅は餅屋といいますが、画像にはバイナリーの方が向いているんでは?
…と個人的な感想です。
Re:静止画像ごときを一々圧縮しなくなる日が来るのでは (スコア:1)
PNMはテキスト形式有りますが、結構便利です。
読み込みはともかく、書き出す時がとても楽。
バイナリやcsvをsedで加工するだけで画像フォーマットになる。
その後、ImageMagicでPNGに変換したりできるし。
TomOne
Re: (スコア:0)
バイナリをsedで加工するのは比較的ハードルが高い気がするんですが。
Re:静止画像ごときを一々圧縮しなくなる日が来るのでは (スコア:1)
つsed "s/\(.\)/\1\1/g"
-- う~ん、バッドノウハウ?
Re: (スコア:0)
それだけだとバイナリ中に 0x0a などが出てくると失敗すると思うのだが
Re:静止画像ごときを一々圧縮しなくなる日が来るのでは (スコア:1)
うっ…
(ほぼ)倍なり…
-- う~ん、バッドノウハウ?
Re: (スコア:0)
「-z」オプションが使えるsedならなんとか…。
Re:静止画像ごときを一々圧縮しなくなる日が来るのでは (スコア:1)
書き間違えました。テキストデータです。
テキストやcsvをsedやらtrやらで加工して画像にしてます。
TomOne
Re:静止画像ごときを一々圧縮しなくなる日が来るのでは (スコア:1)
何でもかんでもテキストにすべきとは思いませんが、
別コメにも挙がってるテキストフォーマットのPNM(PBM/PGM/PPMの総称)は、ちょっと簡単に機械生成するときに便利なんですよね。
Excelのシートで計算させて、そこからコピペでPGMにしたりとかもたまにやります。A1=「P2」/A2=「幅」/B2=「高さ」/A3=「画素数値最大値」を入れて、あとはA4以降に画素数値を埋め込むようなワークシートを作ってをけば、そのままコピペ(でタブ区切りになって、そのままPGMと解釈可能)で画像化できるというお手軽便利。
Perlとかの使い捨てスクリプトでPPMを出力するのが一番手軽。
まあ、Perlなどバイナリ出力が容易なスクリプトを使う時は、P1~P3(テキスト形式)ではなく、P4~P6(バイナリ形式)を使いますけど、それでもヘッダはテキストなので簡単に間違いなくヘッダ生成できるのですごくお手軽です。
Re: (スコア:0)
ビットマップ的なものには既にベクタ形式がありますしね。
Perl などのテキスト・ツールで2次元FFT
むかしどこかの.pmで聴いた気がしましたが、あれはWAV変換でした。