(57)【要約】【課題】既存の更新管理ＤＢ（データベース）では、ファイル単位で新規の登録および更新登録を行っているので、複数のレイヤーが含まれている１つのデザインファイルにおいて、少数のレイヤーのみを更新した場合であっても、デザインファイル全体に対してＤＢへの更新処理が実行されてしまう。その結果として、デザインファイル全体に占める変更量がわずかであるにも拘わらず、新旧のデザインファイル同士の比較時間またはＤＢへの転送時間が長期化してしまう。【解決手段】デザインファイルに含まれるレイヤーごとに更新が必要か否かの判断をし、その判断に基づいて実際の更新処理を行う。その結果、大量のレイヤーが含まれるデザインファイルであっても、実際に更新処理が行われるのは変更が加えられたレイヤーのみとなるので、デザインファイル全体の効率的な更新処理が行える。【選択図】図１
2009175783.tif 000002
【特許請求の範囲】
【請求項１】
複数の画像構成要素と、前記画像構成要素に関連したメタデータとを含んだデザインファイル情報を作成および／または編集するデザインファイル編集手段と、
前記画像構成要素と、前記メタデータとを記憶する記憶手段と、
前記メタデータに基づいて、前記画像構成要素が更新されているか否かを判定し、更新されていると判定した場合には、前記画像構成要素と、前記メタデータとを前記記憶手段へ登録する登録制御手段と、
を備えることを特徴とする画像処理装置。
【請求項２】
請求項１に記載の画像処理装置において、
前記画像構成要素は、二次元画像からなるレイヤーであることを特徴とする画像処理装置。
【請求項３】
請求項１に記載の画像処理装置において、
前記画像構成要素は、三次元画像であることを特徴とする画像処理装置。
【請求項４】
請求項１〜３のいずれか一項に記載の画像処理装置において、
前記画像構成要素は木構造を有することを特徴とする画像処理装置。
【請求項５】
複数の画像構成要素と、前記画像構成要素に関連したメタデータとを含んだデザインファイル情報を作成および／または編集するデザインファイル編集工程と、
前記画像構成要素と、前記メタデータとに基づいて、前記画像構成要素が更新されているか否かを判定し、更新されていると判定した場合には、前記画像構成要素と、前記メタデータとを記憶手段へ登録する登録制御工程と、
を備えることを特徴とする画像処理方法。
【請求項６】
請求項５に記載の画像処理方法において、
前記画像構成要素は、二次元画像からなるレイヤーであることを特徴とする画像処理方法。
【請求項７】
請求項５に記載の画像処理方法において、
前記画像構成要素は、３次元画像であることを特徴とする画像処理方法。
【請求項８】
請求項５〜７のいずれか一項に記載の画像処理方法において、
前記画像構成要素は木構造を有することを特徴とする画像処理方法。
【請求項９】
請求項５〜８のいずれかの一項に記載の方法をコンピュータにより実行させることを特徴とする画像処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カーナビゲーション装置などの情報端末装置におけるヒューマン・マシン・インタフェース（以下、ＨＭＩという）の画面デザインに好適な画像処理装置、画像処理方法およびプログラムに関する。
【背景技術】
【０００２】
情報端末装置の開発を多人数で行う場合、効率的な開発を行うために開発情報が共有されている。開発情報の共有を行う場合には、単一の更新管理ＤＢ（データベース）を用いて開発情報を集約している。そして、開発情報を更新する都度、上記ＤＢへ新しいファイルを登録することが行われている（非特許文献１）。例えばＨＭＩのデザインを行う場合、まず画像エディタを用いて、ボタンや表示枠などの表示部品の画像データを作成する。作成された複数の画像データは、それぞれが個別のレイヤーとしてデザインファイルに保存される。そして、上記のように複数の画像データが含まれたデザインファイルが更新管理ＤＢへ登録される。次に、レイアウトエディタにより表示部品の配置を行う。レイアウトエディタは、更新管理ＤＢから適切なデザインファイルを取り出し、デザインファイル内の画像データを用いて表示部品を描画する。
【０００３】
【非特許文献１】CollabNet, Inc.、“subversion.tigris.org”、［online］、［平成１９年９月２８日検索］、インターネット〈URL：http://subversion.tigris.org〉
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述した既存の更新管理ＤＢでは、ファイル単位で新規の登録および更新登録を行っている。したがって、複数のレイヤーが含まれている１つのデザインファイルにおいて、少数のレイヤーのみを更新した場合であっても、デザインファイル全体に対してＤＢへの更新処理が実行されてしまう。その結果として、デザインファイル全体に占める変更量がわずかであるにも拘わらず、ＤＢへの転送時間が長期化してしまうので、ＤＢに対する更新処理時間を短縮することができないという問題が生じる。
【課題を解決するための手段】
【０００５】
請求項１に係る本発明は、複数の画像構成要素と、画像構成要素に関連したメタデータとを含んだデザインファイル情報を作成および／または編集するデザインファイル編集手段と、画像構成要素と、メタデータとを記憶する記憶手段と、画像構成要素と、メタデータとに基づいて、画像構成要素が更新されているか否かを判定し、更新されていると判定した場合には、画像構成要素と、メタデータとを記憶手段へ登録する登録制御手段と、を備えることを特徴とする画像処理装置である。
請求項２に係る本発明は、請求項１に記載の画像処理装置において、画像構成要素は、二次元画像からなるレイヤーである。
請求項３に係る本発明は、請求項１に記載の画像処理装置において、画像構成要素は、三次元画像である。
請求項４に係る本発明は、請求項１〜３のいずれか一項に記載の画像処理装置において、画像構成要素は木構造を有する。
請求項５に係る本発明は、複数の画像構成要素と、画像構成要素に関連したメタデータとを含んだデザインファイル情報を作成および／または編集するデザインファイル編集工程と、画像構成要素と、メタデータとに基づいて、画像構成要素が更新されているか否かを判定し、更新されていると判定した場合には、画像構成要素と、メタデータとを記憶手段へ登録する登録制御工程と、を備えることを特徴とする画像処理方法である。
請求項６に係る本発明は、請求項５に記載の画像処理方法において、画像構成要素は、二次元画像からなるレイヤーである。
請求項７に係る本発明は、請求項５に記載の画像処理方法において、画像構成要素は、３次元画像である。
請求項８に係る本発明は、請求項５〜７のいずれか一項に記載の画像処理方法において、画像構成要素は木構造を有する。
請求項９に係る本発明は、請求項５〜８のいずれかの一項に記載の方法をコンピュータにより実行させる画像処理プログラムである。
【発明の効果】
【０００６】
本発明によれば、メタデータに基づいて、画像構成要素ごとにデータベースの更新を行うことができるので、更新時間の短縮を図ることができる。すなわち、データベースへの更新処理がデザインファイル単位ではなく画像構成要素単位で行われるので、デザインファイルが画像構成要素を多量に含んでいたとしても、データベースへの更新処理に要する時間は、変更を加えた画像構成要素の数に応じた処理時間となる。
【発明を実施するための最良の形態】
【０００７】
＜第１の実施の形態＞
図１は、本発明を適用した画像処理装置の全体構成を示すブロック図である。
【０００８】
画像処理装置１は、デザインファイル編集機能を有する画像エディタ１０と、画面レイアウト編集機能を有するレイアウトエディタ２０と、表示部品の画像データを保存するリソース管理ＤＢ（データベース）３０から構成される。画像エディタ１０とレイアウトエディタ２０はそれぞれリソース管理ＤＢ３０と相互に接続されている。画像エディタ１０は、デザインファイル入力部１１と、デザインファイル出力部１２と、デザインファイル編集部１３と、レイヤー登録部１４を備えている。
【０００９】
以上のように構成された画像処理装置１は、演算処理およびプログラム実行処理を行うＣＰＵと、プログラムおよびデータを記憶する記憶装置と、ＣＰＵがプログラムを実行するに際し必要なデータを入力する入力装置と、ＣＰＵがプログラムを実行した結果を表示する表示装置とを含んだコンピュータ（いずれも図示せず）によって実現される。すなわち、図１に示した各ブロックが有するそれぞれの機能は、上記コンピュータのＣＰＵがその記憶装置に記憶された所定のプログラムを実行することによって実現される。
【００１０】
なお、本実施形態において、画像処理装置１は、１台のコンピュータにより実現しているが、複数台のコンピュータによって実現できることは勿論である。例えば、図１において、画像エディタ１０、レイアウトエディタ２０およびリソース管理ＤＢ３０のそれぞれに対して別個のコンピュータを割り当て、そのそれぞれのコンピュータをネットワークを介して相互に接続しておき、それら複数のコンピュータにより画像処理装置１としての機能を実現するようにしてもよい。
【００１１】
以下、画像処理装置１を構成する各ブロックの機能について説明する。
デザインファイル編集機能を有する画像エディタ１０の各ブロックは、以下に述べる機能を有する。デザインファイル入力部１１は、デザインファイルの読み込みを行う。デザインファイル出力部１２は、デザインファイルの書き出しを行う。デザインファイル編集部１３は、デザインファイルに含まれる各レイヤー毎の画像データおよびメタデータを、図示しない入力装置からの入力内容および画像エディタ１０の処理内容に応じて編集する。レイヤー登録部１４は、デザインファイルに含まれるレイヤーをリソース管理ＤＢ３０へ登録する。既にリソース管理ＤＢ３０に登録されているレイヤーを更新登録する場合は、まず登録済みのレイヤー内容から変更があったか否かを判別し、そのレイヤーに変更があった場合のみ、そのレイヤーの更新処理を行う。この更新処理が行われた場合、リソース管理ＤＢ３０に登録済みのレイヤーが新しい内容のレイヤーに置き換えられる。このように、内容が更新されているレイヤーのみをリソース管理ＤＢ３０に登録する。
【００１２】
画面レイアウト編集機能を有するレイアウトエディタ２０は、表示部品をレイアウトすることで表示画面を作成する。また、リソース管理ＤＢ３０に登録されている画像データを取得し、表示部品の外観として利用する。
【００１３】
リソース管理ＤＢ３０は、開発情報の新規登録、更新登録および共有を行うためのデータベースである。リソース管理ＤＢ３０には画像データがレイヤー単位で登録される。登録されている各レイヤーには、元になったデザインファイルのタイムスタンプが記憶されている。また、画像データと共に付随するメタデータも記憶される。
【００１４】
図２は、本実施形態で処理対象とするデザインファイルの構成を説明する図である。デザインファイル５０は、画像領域５１とメタ領域５２とから構成される。画像領域５１には複数の画像データが個別のレイヤーとして保存され、メタ領域５２には画像領域５１に存在する各レイヤーに対応するメタデータが保存される。図２において、画像領域５１には５００、５０１、５１０、５１１、５２０、５２１、５３０、５３１の８つのレイヤーが存在している。また、メタ領域５２には、画像領域５１に存在するレイヤー毎に名称、ＩＤ、リビジョン、座標、タイムスタンプが保存されている。各レイヤーはグループに分けられている。各レイヤーと異なり、各グループ（図２の丸ボタン、三角ボタン、四角ボタン、背景）にはメタデータとして“名称”と“ＩＤ”のみが保存されている。
【００１５】
以下、本実施形態におけるメタデータを、図２に基づいて説明する。“名称”は、ユーザが図示しない入力装置によって各レイヤーへ任意に割り当てる識別名である。“ＩＤ”は、レイヤーおよびグループに自動的に割り当てられる一意な整数であり、デザインファイル中でレイヤーとグループを特定し且つ識別するために用いられる。“リビジョン”は、レイヤーの変更を管理するための整数であり、初期値は１となっている。“リビジョン”は、変更されたレイヤーおよびグループがリソース管理ＤＢ３０へ更新登録されるたびに増加する。“座標”は、ユーザが図示しない入力装置によって各レイヤーへ任意に割り当てる二次元座標値である。“タイムスタンプ”は、最後にレイヤーに対して変更が加えられた日時であり、画像領域５１に存在する各レイヤーまたは各レイヤーに対応したメタデータへ変更を加えた場合、自動的に更新される。
【００１６】
図３は、レイヤー登録部１４（図１参照）がリソース管理ＤＢ３０の画像データおよびメタデータを更新する処理を説明するためのフローチャートである。まずステップＳ３０において、デザインファイル５０のメタ領域５２を調べて、グループ（丸ボタン、三角ボタン、四角ボタン、背景）を１つ選択する。ステップＳ４０では、選択したグループに含まれるレイヤーの中から１つを選択する。ステップＳ５０では、選択したレイヤーのリビジョンが、デザインファイル５０とリソース管理ＤＢ３０とで一致しているか否かを判定する。リビジョンが一致しなければ、ステップＳ５０により否定判定がなされ、ステップＳ５１へ進む。ステップＳ５１では、他のユーザによって既に当該レイヤーが更新済みであったことを、本更新処理を実行したユーザへ通知して、処理を終了する。他方、ステップＳ５０において肯定判定がなされた場合には、ステップＳ６０へ進む。
【００１７】
ステップＳ６０では、選択したレイヤーのタイムスタンプが、デザインファイル５０とリソース管理ＤＢ３０との間で一致するか否かを判定する。タイムスタンプが一致しなければ、ステップＳ６０により否定判定がなされ、ステップＳ６１へ進む。ステップＳ６１では、現在選択されている１つのグループに含まれる全てのレイヤーを、リソース管理ＤＢ３０に登録する。他方、ステップＳ６０において肯定判定がなされた場合にはステップＳ７０へ進み、ステップＳ３０で選択したグループ内に未だ選択していないレイヤーが存在するか否かを判定する。ステップＳ７０により否定判定がなされると、ステップＳ４０へ戻る。他方、ステップＳ７０により肯定判定がなされた場合には、ステップＳ８０へ進む。ステップＳ８０では、ステップＳ３０において選択したグループの他に未だ選択していないグループが存在するか否かを判定する。ステップＳ８０により否定判定がなされた場合には、ステップＳ３０へ戻る。他方、ステップＳ８０により肯定判定がなされた場合は、全てのグループについて更新処理が終わったということなので、処理を終了する。
【００１８】
上述した第１の実施の形態による画像処理装置によれば、次の作用効果が得られる。
（１）デザインファイルに含まれるレイヤーごとに更新が必要か否かの判断をし、その判断に基づいて実際の更新処理を行うようにした。その結果、大量のレイヤーが含まれるデザインファイルであっても、実際に更新処理が行われるのは変更が加えられたレイヤーのみとなるので、デザインファイル全体の効率的な更新処理が行えるようになる。
【００１９】
＜第２の実施の形態＞
上述した第１の実施の形態では、画像データとして二次元画像を扱っていた。さらに、レイヤーのグループ分けを行っていた。
しかし、複数の要素から構成されるような画像データであればその種類を問わず、また、単純なグループ分けではなく、より複雑な構造を持つデータに対しても本発明を適用することができる。以下に詳述する第２の実施の形態ではそのような例として、３Ｄモデラーを利用する場合について述べる。
【００２０】
図４は、第２の実施の形態で用いるデザインファイル１５０の構成を示した図である。第１の実施形態と同様に、画像領域１５１とメタ領域１５２とが存在する。画像領域１５１には、三次元の画像として建物用シンボルが定義されている。建物用シンボルは、三次元図形および色情報からなるモデルデータによって構成されている。メタ領域１５２には、画像領域１５１に存在するモデルデータ毎に、名称、ＩＤ、リビジョン、演算子（ＯＰと表記）、座標、タイムスタンプが保存されている。
【００２１】
各モデルデータは木構造で管理されている。モデルデータ５４０は、モデルデータ５４３および５４４から構成されており、モデルデータ５４３は、モデルデータ５４５、５４６および５４７から構成されている。メタ領域１５２には、モデルデータ５４６および５４７の演算子（ＯＰ）として「−」が記録されている。つまり、モデルデータ５４３は、モデルデータ５４５から５４６、５４７それぞれのモデルデータを減算したものを意味する。
【００２２】
第１の実施形態と異なる点は、木構造の構成を有している点と、画像データの形式が二次元画像ではなく三次元のモデルデータである点と、メタデータの種別が異なっている点のみである。従って、リソース管理ＤＢ３０へのデータ更新手続きは、木構造中の全てのモデルデータについて更新処理を実行できるよう、構成要素の巡回方法を変更するだけでよい。
【００２３】
図５は、画像エディタ１０（図１参照）において、リソース管理ＤＢ３０の画像データを更新する処理を実施した際の処理を示すフローチャートである。まずステップＳ１３０において、デザインファイル１５０のメタ領域１５２を調べて、モデルデータを１つ選択する。ステップＳ１５０では、選択したモデルデータのリビジョンが、デザインファイル１５０とリソース管理ＤＢ３０とで一致しているか否かを判定する。リビジョンが一致しなかった場合は、ステップＳ１５０により否定判定がなされ、ステップＳ１５１へ進む。ステップＳ１５１では、他のユーザによって既に当該モデルデータが更新済みであったことを、本更新処理を実行したユーザへ通知して、処理を終了する。他方、ステップＳ１５０において肯定判定がなされた場合には、ステップＳ１６０へ進む。ステップＳ１６０では、選択したモデルデータのタイムスタンプが、デザインファイル１５０とリソース管理ＤＢ３０とで一致しているか否かを判定する。タイムスタンプが一致しなかった場合は、ステップＳ１６０により否定判定がなされ、ステップＳ１６１へ進む。ステップＳ１６１では、現在選択されているモデルデータをリソース管理ＤＢ３０へ登録する。他方、ステップＳ１６０により肯定判定がなされると、ステップＳ１８０へ進む。ステップＳ１８０では、全てのモデルデータについて選択済みであるか否かを判定する。ステップＳ１８０により否定判定がなされた場合には、ステップＳ１３０へ戻る。他方、ステップＳ１８０により肯定判定がなされた場合は、全てのモデルデータについて更新処理が終わったということなので、処理を終了する。
【００２４】
上述した第２の実施の形態による画像処理装置によれば、第１の実施の形態による画像処理装置で得られる作用効果に加えて、次の作用効果が得られる。
（１）全てのモデルデータについて、更新が必要であるか否かの判定と更新処理を行うようにした。その結果、画像データが複雑な木構造で構成されていても、変更が加えられているモデルデータのみを確実に更新登録することができる。
【００２５】
次のような変形も本発明の範囲内である。
（１）デザインファイルの構成要素を必ずしも木構造で管理する必要はない。デザインファイルの全構成要素について順に更新処理を行えるような構造であれば、その種類を問わない。例えば、単純に複数の要素の集合であってもよい。
（２）メタ領域には任意のデータ項目を追加してもよい。また、レイヤー等に対応した項目ではなく、デザインファイル全体に関連したメタデータを作成してもよい。
（３）リビジョンを、個々の構成要素ごとに用意するのではなく、デザインファイル全体に対して１つだけ用意するようにしてもよい。
（４）なお、第１の実施の形態として述べた図２の画像データ（構成要素）は木構造を有していないが、木構造を有する構成要素とすることは、勿論可能である。
【００２６】
本発明の特徴を損なわない限り、本発明は上記実施の形態に限定されるものではなく、本発明の技術的思想の範囲内で考えられるその他の形態についても、本発明の範囲内に含まれる。
【００２７】
なお、以上説明した実施の形態における画像処理装置の各構成要素と特許請求の範囲の各構成要素との対応関係は以下の通りである。
デザインファイル編集部１３はデザインファイル編集手段に相当し、リソース管理ＤＢ３０は記憶手段に相当し、レイヤー登録部１４は登録制御手段に相当する。
【００２８】
なお、以上の対応関係の説明は一例であり、権利解釈に際して何ら拘束されるものではない。
【図面の簡単な説明】
【００２９】
【図１】本発明を適用した画像処理装置の全体構成を示すブロック図である。
【図２】第１の実施の形態におけるデザインファイルを示す図である。
【図３】第１の実施の形態において、画像エディタ１０によるデザインファイル更新処理手順を示すフローチャートである。
【図４】第２の実施の形態で用いるデザインファイルを示す図である。
【図５】第２の実施の形態において、画像エディタ１０によるデザインファイル更新処理手順を示すフローチャートである。
【符号の説明】
【００３０】
１  画像処理装置
１０  画像エディタ
１１  デザインファイル入力部
１２  デザインファイル出力部
１３  デザインファイル編集部
１４  レイヤー登録部
２０  レイアウトエディタ
３０  リソース管理データベース
５０、１５０  デザインファイル
５１、１５１  画像データ領域
５２、１５２  メタ領域
【図１】
2009175783.tif 000003
【図２】
2009175783.tif 000004
【図３】
2009175783.tif 000005
【図４】
2009175783.tif 000006
【図５】
2009175783.tif 000007