A better compressed bitset Roaring bitmaps are compressed bitmaps. They can be hundreds of times faster. Grab one of our research papers Roaring Bitmaps on GitHub Widely used Roaring is found in Google Procella: YouTube’s SQL Engine, Apache Lucene and derivative systems such as Solr and Elasticsearch, Apache Druid, Apache Spark, Apache Hive, Apache Tez, Apache Zeppelin, Apache Doris, Apache Carbon
ずいぶん前に画像をモザイク風に加工するエントリを書きましたが、あれを少しいじったらだいぶ早くなりましたよ、というご報告です。 こんなコードでモザイク処理に350～360msくらいかかってました @Override public void onPictureTaken(byte[] data, Camera camera) { BitmapFactory.Options options = new BitmapFactory.Options(); options.inSampleSize = 8; bitmap = BitmapFactory.decodeByteArray(data, 0, data.length, options); Bitmap b = bitmap.copy(Bitmap.Config.ARGB_8888, true); Log.d("CameraSample",St
今の端末だと10Mピクセルを越えるカメラを搭載した端末が普通になってきており、そのファイルサイズも数MBに及びます。 AndroidでBitmapFactoryを利用してフォトライブラリーから画像を読み込んだりすると思いますが、そのままその画像を読み込んでしまうと、しばしばOutOfMemoryとなりアプリが強制終了してしまいます。 そこで、実際に画像を読み込む前にある程度縮小してから読み込むことで、メモリが足りなくなることを防ごうというのが今回のネタです。 ##BitmapFactory.OptionsのinSampleSizeを指定して画像を縮小した状態で読み込む 処理の流れ的にはまず画像のサイズを取得して、サイズが大きかったら縮小指定してから読み込もう、という感じです。 InputStream inputStream = getContentResolver().openInputS
久しぶりにAndroidでカスタムViewを書いている。内容はiOSで作ったUIViewからの移植であり、画像の加工前のプレビューを表示するものだ。技術的には別に難しくは無いのだが、画像をassetからロードするとエミュレータでは発生しなかった例外が出る。 サンプルコード //アセットに配置したイメージをロードする try { InputStream is = context.getResources().getAssets().open("sample.png"); this.setImageBitmap(BitmapFactory.decodeStream(is)); } catch (IOException e) { e.printStackTrace(); } 発生した例外 11-26 13:51:28.825: W/OpenGLRenderer(9048): Bitmap too
[GN, VGA Preview YUV420SP->ARGB Java only] Q. Javaは遅いのですか？ A. お前がそう思うんならそうだろう お前ん中ではな Androidでは撮影（takePicture）とは別にPreview画像を連続して取得することができます。 昔はPreviewの取得と取得したデータの処理が順次動作していたのですが、API Lv.8（FroyoなのでこのAPIの追加も十分昔なのですけどね）からsetPreviewCallbackWithBufferと「キューイングされたバッファに対して順次プレビューを取得しろ」というものが増えたので、バッファがある限りパラで動作できる様になりました。 Single CoreでJava heapが16M/24M時代には色々苦しかったのですが、Quad Coreとか48M/64Mとかの世界になってくると、Java層でえいや
![Camera Previewのbyte[] YUV420SPをBitmapのint[] ARGBにする話 - ReDo](https://cdn-ak-scissors.b.st-hatena.com/image/square/2358de581ab6e457b20a72246da28f8108fabe11/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fgreety.sakura.ne.jp%2Fredo%2F2013%2F02%2F25%2Fgn-java.png)
Vous pouvez dès à présent lui associer un hébergement, en choisissant la solution la plus adaptée à vos besoins : Hébergement Web Une solution économique pour héberger vos projets Web : site Internet, boutique en ligne, landing page... En savoir plus VPS Alliez la flexibilité du Cloud à la liberté du dédié avec nos solutions VPS clef en main. Accompagnez vos projets Web vers une nouvelle étape. En
Android : Canvas: trying to use a recycled bitmap
Android で、Bitmap をごにゅごにゅしていると、 java.lang.RuntimeException:"Canvas: trying to use a recycled bitmap" ってのに、出くわすことがあります。Web でいろいろ調べてみると、怪しげな解説がかなりあるので、本当のところ何が正しい理解なのかをまとめておきたいと思います。 そもそも、Bitmap#recycle() をやらないといけないのは、主に Android のこの辺の実装がよろしくなくて、recycle() してやらないと、メモリリークになるよ、といわれていることが、大きな要因です。勢い、メモリリーク怖さになんでも recycle() しようとして、件の例外に遭遇することとなる訳です。しかし、どういったケースでそれが必要になるのか、筋の通った記事をあまり見かけません。 まず、誰が ”trying
お久しぶりです。daichi1128です。 GWも終了です。楽しいひとときを過ごせましたでしょうか。 最近気温の変化が激しいですね。最高気温が一桁かと思えば、猛暑になったり、体が追いつきません。もはや日本に四季はなくなってしまったのかもしれませんね。昔は春があったんだよ、なんていう会話をする日がくるのでしょうか。 さて、Androidの開発に戻りますよ。ええ。 今回はBitmapから反射画像を作るサンプルです。 package jp.co.techfirm.bitmaptest; import android.graphics.Bitmap; import android.graphics.Canvas; import android.graphics.LinearGradient; import android.graphics.Matrix; import android.graph
BitmapFactory.Options inSampleSize
BitmapFactory.Options inSampleSize 私は、inSampleSizeに３を代入すれば、(Bitmapの大きさが)３分の１になるものと思い込んでいました。しかし、挙動が変なので、調べてみたのです。 BitmapFactory.Options inSampleSizeに関しては、次のサイトで動作検証がなされています。 BitmapFactory.Options inSampleSize の性能テストとか動作とか 貴重なデータを公開して頂きありがとうございます。手間が省けました。 上記サイトでの検証結果では、inSampleSizeに３を代入しても(Bitmapの大きさが)２分の１になってしまうのです。むむむ！ 検証結果からすると、inSampleSizeに関して次のように解釈できます。 inSampleSizeを用いて縮小する場合、inSampleSizeに代入
LruCacheの使い方
TwitterのツイートをListViewに表示するという処理で、TwitterアイコンのキャッシュにLruCacheを使ってみたメモです。 TwitteアイコンのキャッシュにSoftReferenceを使っていたのですが、2.2 と 2.3 / 4.xで挙動が違って困っていたところ、以下のツイートに出会う。 2.3 から GC の方式が変わったので、SoftReference や WeakReference で Bitmap をキャッシュするのはあんまり意味ないからオススメしないそうだ — Yuki Anzaiさん (@yanzm) 8月 14, 2012 これどこ情報なんだろう？ListViewに表示するTwitterアイコンのキャッシュにSoftReference使ってるけど、確かに2.2、2.3、4.xで動き違って困ってた。2.3と4.xはすぐキャッシュが解放されてて再取得が走る.
この中の pose() メソッドですが、どの Bitmap でも必ず 0 を返してしまうようです。なので、現状は使用できないことになります。何故そうなっているかは不明ですが、傾きはとても必要な情報だと思うので、使えるようになることを切に願っています。。 また、 FontDetector クラスは APIレベル1から存在するクラスなので、どのバージョン向けのアプリにも組み込むことができます。 顔検出アプリを作る 1.画像を取得する まずはじめに、検出する画像が必要です！ということで、以前の記事と同様の方法でギャラリーから画像を取得しましょう。 ContentProvider クラスで端末内の画像を取得します。選択するしくみなどは特に必要ないので、最新の画像を一枚だけ取得するロジックにしておきます。 FaceDetectorActivity.java package jp.classmetho
Android Bitmap 読み込みのコードを github に公開しました。
・大きい画像を効果的に読み込む ・バックグラウンドで Bitmap を処理する ・Bitmap をキャッシュする をまとめて、DiskLruCache として Displaying Bitmaps Efficiently のサンプル BitmapFun.zip の DiskLruCache.java をベースにしたコードを github に公開しました。Google I/O 2012 のコードも参考にしています。 github - yanzm/ImageLoadLib - 特徴は API Level 4 から使えるようにしてあることです（BitmapFun や Google I/O 2012 のコードはそうなっていません）。 こんな感じで使います。 private ImageFetcher mImageFetcher; @Override public void onCreate(Bund
Android バックグラウンドで Bitmap を処理する
Processing Bitmaps Off the UI Thread の内容に補足を付けて解説してます。 前回のエントリーで大きい画像を効果的に読む込む方法を解説しましたが、デコードするデータがディスクやネットワークにある場合、BitmapFactory の decode* メソッドは UI スレッドで行ってはいけません（というかメモリ上以外のデータを読み込む場合は全部だめ）。 これらの処理はディスクやネットワークのスピード、画像のサイズ、CPUのパワーなどさまざまな要因で完了までの時間が変わり、いつ完了するのかわかりません。 もし画像のデコード処理で UI スレッドをブロックしてしまうと、最悪 ANR が発生します。 そこで、AsyncTask を使ってバックグランドで Bitmap を読み込むようにします。 ■ AsyncTask を使う 特に何も考えないで作ると、きっとこんな感じ
Android 大きい画像を効果的に読み込む
Loading Large Bitmaps Efficiently の内容なのですが、補足も入れてメモっておきます。 端的にいうと、 実際に表示するサイズより大きい Bitmap を読みこむのはメモリの無駄 （拡大させるとかなら話は別だけど） ・高解像度のカメラで取られた写真は往々にしてディスプレイのピクセルサイズより大きい ・サムネイルとして使うのに元のサイズのまま読み込むのはばかげてる ・大きいサイズの Bitmap をメモリに展開したら OutOfMemoryException になる ステップとしては3つ 1. メモリに Bitmap 展開せずに、サイズや MimeType だけを取得する 2. 1. の情報をもとにサブサンプルにサイズを決める 3. 2. で決めたサブサンプルで Bitmap をメモリに読み込む 1. メモリに Bitmap 展開せずに、サイズや MimeType
Android Bitmap をキャッシュする
Caching Bitmaps に補足をつけて解説しています。 前回のバックグラウンドで Bitmap を処理するで、最後に（でもキャッシュは、、、？）と書きました。 そう！キャッシュ！キャッシュ大事。 前回までの段階でもまだ ListView で使うには問題が残っています。 既にタスクが走り終わって ImageView に画像がセットされている行をいったんスクロールアウトし、再度スクロールして画面に表示すると、またタスクが走ってしまいます。 スクロールするたびに読み込み状態になるのはユーザーとしてはうれしくないですよね。 そこでキャッシュを使って、一旦読み込んだ画像が再度必要になったときに利用できるようにします。 キャッシュとしてはメモリキャッシュとディスクキャッシュを利用することができます。 ■ メモリキャッシュ メモリキャッシュの利点は読み込みが速いこと、欠点はメモリを消費することで
開発してるとActivityにBitmapを持たせたいことってよくある でもメンバで持ってると自前で解放しなくてはならない。 Bitmapのメモリ管理はネイティブ側で管理されてるので明示的に開放する必要がある。 マジで？って思ったので実験してみた 実験内容 以下のパターンでBitmapActivityがどのように変化するかを確認 実験1 ImageViewを持たないActivity 実験2 レイアウトでImageViewを持ったActivity 実験3 レイアウトでImageViewを持ち、メンバ変数でもImageViewをもつActivity 実験4 ImageViewを持ち、メンバ変数でBitmapをもつActivity 実験5 Bitmap#recycleの正しい使い方 使うアプリ こんな感じのアプリ 実験2〜4 MainActivity>BitmapActivity>（戻るキーで）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
