0

画像処理が必要な WinRT アプリに取り組んでいます。私はこれまでに似たようなことをしましたが、Javaでは、WinRTアプリでも簡単なことをしたいと思います...しかし、APIで自分のやり方を管理できないようです...

簡単に言えば、私のページの xaml にはimage、ファイル ピッカーで画像を取得する があります。次に、「否定」ボタンをクリックすると、画像が否定されるはずです。

さて、否定ボタンのメソッドは、次のようになると思いました：

private void OnNegativateButtonClick(object sender, RoutedEventArgs e)
    {
        var imageToNegativate = ImagePanel.Source as WriteableBitmap ;

        if (imageToNegativate == null) //Actually is ALWAYS null :(
        {
            //Wrong code here...
            var bitmapSource = ImagePanel.Source as BitmapSource;
            imageToNegativate = new WriteableBitmap(imageToNegativate.PixelWidth, imageToNegativate.PixelHeight);
        }
        imageToNegativate = ImageUtil.Negativate(imageToNegativate);
        ImagePanel.Source = imageToNegativate;
    }

これは私が見つけたこのサンプルと非常によく似ていますが、そのサンプルプロジェクトはロードされないので、ファイルを個別に開こうとしました...私のコードはwb = new WriteableBitmap(bs);、彼のif (wb==null) { ... }.

imageから WriteableBitmap を取得し、ピクセル操作を行ってから、新しい WriteableBitmap でイメージのソースを設定するアプローチは何ですか...

私が言ってWriteableBitmapいるのは、否定の方法が入力に 1 つを使用し、何らかの処理を行って出力するためです。(同型、WriteableBitmap.

どんな提案や助けも大歓迎です、ありがとう!

4

2 に答える 2

2

最初の問題は、次のコード行です。

var imageToNegativate = ImagePanel.Source as WriteableBitmap ;
if (imageToNegativate == null) //Actually is ALWAYS null :(

null は、それが typeでImagePanel.SourceはないWriteableBitmapことを示しています。タイプキャストが失敗しました。これは予期されることです。ピッカーは読み取り専用の画像を提供します。これは、読み取り専用の画像の方がパフォーマンスが高いためです (画像のコンテンツが変更されないことがわかっている場合、WinRT はいくつかの最適化を実行できます)。WriteableBitmap明示的に作成した場合にのみ取得できます。

ブロックの本体ifもあまり意味がありません-WriteableBitmap元の画像と同じサイズの新しい空の画像を作成しようとしていて、その空の画像で逆ビデオを実行しようとしています。そこまで行っても、別の空の画像が表示されるだけです。元の画像のピクセルを保持するために何もしていません。

WriteableBitmapピクセル バッファーにアクセスするには が必要ですが、元の画像のコピーを作成する必要があります。ifキャストとブロックを取り除き、代わりにこれを試してください：

var imageToNegativate = new WriteableBitmap(ImagePanel.Source);
于 2012-12-30T18:29:03.590 に答える
0

ジョーはあなたのコードの何が問題なのかを言っていますが、彼の答えはおそらく WPF で機能しますが、彼が言及しているコンストラクターは実際には WinRT/XAML には存在しません。実際、BitmapImage から WriteableBitmap を作成する方法はなく、それを攻撃する唯一の方法は、BitmapImage のソースから WriteableBitmap を作成することです。

その場合の 1 つの方法は、新しい 1x1 サイズの WriteableBitmap を作成し、その SetSource メソッドを BitmapImage のソースで使用することです。BitmapImage.UriSource プロパティは Uri であり、WriteableBitmap.SetSource() には Stream が必要であるため、実際の画像ファイルを検索またはダウンロードし、ストリームを開いて読み取るには、少し操作する必要があります。私のツールキットにはいくつかの拡張メソッド ( WriteableBitmap.FromBitmapImage() ) があり、画像がアプリケーション パッケージから取得され、ダウンロードした画像でも動作するようにかなり簡単に拡張できる場合に役立ちます。

問題は-そのようにいくつかの非効率性が得られることです-1つはファイルを2回開いてデコードする必要があることです(ARMデバイス上の大きな画像では遅くなる可能性があります-そこにあった場合はそれを行います)、2つ目はファイルがネットワークから来た場合はファイルを再ダウンロードし、関連するイメージ コントロールの CacheMode を BitmapCache に設定すると、WinRT/XAML にバグがあり、BitmapImage の UriSource プロパティが null になるため、必要になる場合があります。とにかくソースを別々に追跡してください。

多くの点で最善の解決策は、ソース イメージを最初から WriteableBitmap として開いていることを確認することです。そのため、変更したい場合でも別のビットマップを作成する必要はありません。あなたの場合、ユーザーは画像ファイルを選択するため、ファイルは1つしかなく、後で処理される可能性が非常に高いように見えるため、 WriteableBitmap として開くのは正しいことのように聞こえます。

画像の元のバージョンと処理されたバージョンの両方を保持したい場合でも、同じサイズの新しい WriteableBitmap を作成して元のピクセルをコピーする方が、大きな画像ファイルを 2 回デコードするより (特に ARM デバイスの場合) 高速になる場合があります。

于 2012-12-31T07:26:26.793 に答える