ユーザーが画像の色に基づいて検索を実行できる webapp を作成する必要があります。私の質問は、カラーデータを保存する方法ですか? 最善の解決策は、画像の色を減らし、r、g、b チャネルごとにヒストグラムを作成することだと思いますが、データベースの設計方法がわかりません。MySQL DBMS を使用したい。誰かが私を正しい方向に向けることができますか?
よろしく
ヒストグラム データを格納するためのアイデアがいくつか思い浮かびます。明らかな選択は、(正規化された) ヒストグラムを表す 1 つのテーブル (または個別の R/G/B チャネルの場合は 3 つ) を持ち、各ビンの列を持ちます。24 ビット カラー (8 ビット/チャネル) の場合、各チャネルを 16 個のビン ([0-15]、...、[240-255]) に分割し、各列にピクセルの割合を格納できます。それはそのビンに落ちました。
このようなもの:
id imgID R_0_15 ... R_240_255 G_0_15 ... G_240_255 B_0_15 ... B_240_255
1 1234 0.1 0.23 0.023 0.234 0.11 0.01
この設計では、各画像の (正規化された) ヒストグラム全体がテーブル内の 1 つの行として表されます。
クエリは少し難しいものです。対象の値の範囲に適切な列名を挿入するには、クエリを動的に生成する必要があります。
おそらくより良い方法は、各画像と各ビンの行エントリを持つ HistogramBins テーブルです。
id imgID component bin_min bin_max percentage
1 1234 R 0 15 0.1
....omitted rows...
1 1234 R 240 255 0.23
...etc...
そのストレージ形式を使用すると、動的に計算するのではなく、クエリを準備できます。私が行ったようにコンポーネントを分割する必要があるのか 、それとも3つのカラーコンポーネントすべての「ビン1」に対して1行を保存する必要があるのか は明確ではありません。おそらく、いくつかのクエリを作成して、アプリケーションに最適なものを確認したいと思います。
また、私が「正規化された」と言い続ける理由は、このスキームがビニングを画像サイズに依存しないようにするためです。
これが開始に役立つことを願っています。最終的にどうなるか教えてください!
RGB 値は人間の知覚には意味がありませんが、人間にとってより感覚的な色相、彩度、輝度に簡単に変換できます。残念ながら、彩度と輝度は非常に直感的です: 豊かな: 淡い、明るい: 暗いですが、色には自然な順序がないため、色相は円の周りの任意の度数として表されます。実際には、特にまだ見たことのないものを探す場合、人々に細かい色相の識別を求めるのはかなり難しい. したがって、カテゴリを図 "a"の六角形の頂点に制限することをお勧めします。
では、写真の代表的な色は何ですか?空が半分、日焼けが半分というイメージは、サンドブルーですか、それとも日焼けですか?あなたは優勢な色合いを選んでいますか?大きなガウスぼかしを適用してから、結果の色相を平均化することができます。おそらく、質問と目標をさらに絞り込む必要があります。
HSL にも記述上の制限があります。砂の色として、上記の「タン」について言及しました。ほとんどの読者はおそらくそれを認識したり名前を付けたりすることにまったく問題はありませんが、色で遊んだ経験があまりない限り、黄褐色の色相がオレンジ色であるが淡い (彩度が低い) 明るい (値が高い) ことは明らかではありません。また、色相環の約 3 分の 1 は緑などに当てられます。