WO2020129434A1 - 画像ファイル生成装置、画像ファイル生成方法、及びプログラム - Google Patents

画像ファイル生成装置、画像ファイル生成方法、及びプログラム Download PDF

Info

Publication number
WO2020129434A1
WO2020129434A1 PCT/JP2019/043118 JP2019043118W WO2020129434A1 WO 2020129434 A1 WO2020129434 A1 WO 2020129434A1 JP 2019043118 W JP2019043118 W JP 2019043118W WO 2020129434 A1 WO2020129434 A1 WO 2020129434A1
Authority
WO
WIPO (PCT)
Prior art keywords
metadata
image file
image
item
stored
Prior art date
Application number
PCT/JP2019/043118
Other languages
English (en)
French (fr)
Inventor
昌敬 深田
Original Assignee
キヤノン株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by キヤノン株式会社 filed Critical キヤノン株式会社
Publication of WO2020129434A1 publication Critical patent/WO2020129434A1/ja
Priority to US17/345,004 priority Critical patent/US20210303616A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/58—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/583—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using metadata automatically derived from the content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164—File meta data generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/51—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/55—Clustering; Classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/58—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/583—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using metadata automatically derived from the content
    • G06F16/5846—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using metadata automatically derived from the content using extracted text
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/58—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/5866—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using information manually generated, e.g. tags, keywords, comments, manually generated location and time information

Definitions

  • the present invention relates to a technique for storing one or more image data in an image file.
  • MPEG Moving Pictures Experts Group
  • HEIF High Efficiency Image File Format
  • ISO base media file format ISO Base Media File Format
  • HEIF is being standardized under the name "Image File Format" in ISO/IEC 23008-12.
  • HEIF also defines a normative structure including metadata, a method of associating metadata with an image, and a configuration of metadata of a specific format.
  • Patent Document 1 describes that a derivative image is stored in an image file conforming to HEIF.
  • image generation apparatuses with image generation functions such as cameras and smartphones have various functions in recent years, and not only shooting date and time, image size and image quality, but also information at the time of shooting and image data taken. It is possible to generate various information such as metadata of. For example, various information associated with the image data such as shooting position information, what the subject or scene of the image data is, and an image pickup mode at the time of shooting is generated together with the image data. Information about such image data can be stored in the HEIF file as metadata.
  • an image file for example, HEIF file
  • an image file for example, HEIF file
  • the metadata is stored for each image. Therefore, the device that processes the HEIF file cannot confirm that the metadata of each image is common unless the metadata of each image and its configuration information are sequentially confirmed. Therefore, when a plurality of images in the HEIF file all correspond to common metadata, or when two or more of the plurality of images correspond to common metadata, batch processing is performed on each image. The processing load when performing was large.
  • each tile image is stored as a derived image
  • metadata such as Exif data for each derived image is inefficient in terms of file generation load and file size. ..
  • Exif is an abbreviation for Exchangeable image file format. That is, although the metadata of each tile image (for example, image size, color information, encoding information, etc.) is often common, conventionally, the metadata is defined for each of a plurality of (derived) images. It was not efficient.
  • the information when constructing the metadata adapted (corresponding) to the image only the information as to whether or not the metadata is essential can be stored. That is, in the case of adapting a plurality of metadata to one image, it was not possible to select any one from the same kind of metadata and adapt it.
  • the text information for each language can be selectively applied to the image. ..
  • HTML Long desc information for acquiring information from other URIs is stored and multilingual is supported.
  • the information corresponding to each language is stored in the file. Need to be kept. At that time, it was not possible to select any one of the text information in a plurality of languages and adapt it to the image.
  • the present disclosure provides a technique for efficiently performing a process related to image file generation.
  • the image file generation device of the present invention has the following configuration. That is, an image file generation device for storing one or more images in an image file according to a predetermined image file format, and an acquisition unit for acquiring a plurality of metadata to be stored in the image file; Among the metadata, the grouping means for grouping according to the type of metadata, and the storage means for storing the grouped metadata in the image file.
  • the accompanying drawings are included in and constitute a part of the specification, illustrate the embodiments of the present invention, and are used together with the description to explain the principle of the present invention.
  • the figure which shows an example of the ItemPropertyAssociationBox structure in the image file format in embodiment The figure which shows another example of the ItemPropertyAssociationBox structure in the image file format in embodiment.
  • the figure which shows an example of the ItemPropertyBox structure in the image file format in embodiment The figure which shows an example of ItemReferenceBox in the image file format in embodiment.
  • the figure which shows another example of the ItemPropertyAssociation structure in the image file format in embodiment The figure which shows an example of the ItemPropertyToGroupPropertyBox structure in the image file format in embodiment.
  • the figure which shows the processing flow of the image file generation apparatus in 3rd Embodiment The figure which shows the processing flow of the image file generation apparatus in 3rd Embodiment.
  • the figure which shows an example of ItemPropertyBox in the image file format in 3rd Embodiment The figure which shows another example of ItemPropertyBox in the image file format in 3rd Embodiment.
  • FIG. 1 shows the configuration of an image file generation device 101 of this embodiment.
  • the image file generation device 101 of FIG. 1 is a communication device having a photographing function such as a camera, a smartphone, a tablet PC, or the like.
  • the image file generation device 101 of this embodiment generates an image file conforming to a predetermined image file format.
  • the image file generation device 101 has a system bus 102, and has a nonvolatile memory 103, a ROM 104, a RAM 105, a control unit 106, an imaging unit 107, and an operation unit 108.
  • the image file generation device 101 further includes a file output unit 109, a metadata processing unit 110, an encoding unit 111, a display unit 112, an image recognition unit 113, and a LAN control unit 114, each of which is connected to the system bus 102. It has a hardware configuration.
  • the system bus 102 transfers data between the connected blocks.
  • image is mainly used, but this is not intended to be limited to a still image.
  • the control unit 106 is composed of one or more CPUs and executes a program stored in the ROM 104.
  • the programs executed by the control unit 106 include an OS (operating system), drivers, applications, and the like.
  • the control unit 106 executes the program to perform overall control of the image file generation device 101.
  • the control unit 106 controls the display on the display unit 112 based on an instruction input by the user from the operation unit 108, issues an image capturing instruction to the image capturing unit 107, and issues a connection instruction to the LAN control unit 114. Perform processing such as.
  • the imaging unit 107 has an image sensor such as a CMOS sensor, and inputs an image signal according to an instruction from the control unit 106.
  • the input image signal is encoded into digital data by the encoding unit 111.
  • the image file generation device 101 may also function to decrypt the image file.
  • the control unit 106 causes a decoding unit (not shown) to decode the image file according to a user operation related to the reproduction process via the operation unit 108, and displays the decoded image data on the display unit 112. Display it.
  • the metadata processing unit 110 acquires the data encoded by the encoding unit 111 and generates an image file that complies with a predetermined file format (for example, HEIF). It should be noted that the metadata processing unit 110 is not limited to HEIF, and can also generate a file conforming to, for example, another moving image file format defined in MPEG or a format such as JPEG. In addition, the metadata processing unit 110 may acquire encoded data from another device, not limited to the encoding unit 111, and generate an image file.
  • a predetermined file format for example, HEIF
  • HEIF a predetermined file format
  • the metadata processing unit 110 may acquire encoded data from another device, not limited to the encoding unit 111, and generate an image file.
  • the file output unit 109 outputs the image file generated by the metadata processing unit 110.
  • the output destination is not particularly limited, but may be output to, for example, a display device that displays an image based on an image file or a printing device that prints an image based on the image file.
  • the image file may be output to a storage device that stores the image file or a storage medium (nonvolatile memory 103) that stores the image file.
  • the non-volatile memory 103 is an SD card, compact flash (registered trademark), flash memory, or the like.
  • the image recognition unit 113 executes recognition processing of a person, an object, a scene, etc.
  • the control unit 106 sends an instruction to the display unit 112 based on the result of the recognition process, or issues an instruction to the image pickup unit 107 to automatically release the shutter.
  • the control unit 106 also performs processing such as notifying the metadata processing unit 110 of the metadata to be stored in the image file. In the present embodiment, the description will be made assuming that the metadata and the property information have almost the same meaning.
  • each functional block is configured by a separate circuit in the present embodiment, the processing (operation) of at least one functional block may be realized by executing a program by the control unit 106 or the like.
  • the RAM 105 is a main storage unit of the image file generation apparatus 101, and is mainly used as a temporary storage area for data when processing of each functional block is executed.
  • the ROM 104 is a non-volatile storage unit that stores a software program executed by each functional block. The program stored in the ROM 104 is transferred to the RAM 105, read by each functional block, and executed.
  • the LAN control unit 114 is a communication interface connected to the LAN and executes communication control of a wired LAN or a wireless LAN. For example, when the image file generation device 101 is connected to another device via a wired LAN, the LAN control unit 114 includes PHY and MAC (transmission media control) hardware circuits of transmission media.
  • the LAN control unit 114 corresponds to an Ethernet (registered trademark) NIC (Network Interface Card).
  • the LAN control unit 114 has a controller, an RF circuit, an antenna that executes wireless LAN control such as IEEE 802.11a/b/g/n/ac. including.
  • FIG. 2 is a diagram showing a flow of image file generation processing according to the present embodiment. This processing flow can be executed by each circuit shown in FIG. 1 according to a user operation. Alternatively, the present processing flow can be realized by the control unit 106 executing a program stored in the ROM 104 in a timely manner, calculating and processing information, and controlling each hardware.
  • the image file generation device 101 acquires an image to be stored in the HEIF file. Specifically, the image signal acquired by the image capturing unit 107 is encoded by the encoding unit 111, and the encoded image signal (digital data) is input to the metadata processing unit 110.
  • the image file generation device 101 can acquire image signals corresponding to a plurality of images. For example, when the image capturing unit 107 performs burst shooting (continuous shooting), a plurality of continuously shot images are acquired. When the image captured by the image capturing unit 107 is divided into tiles and encoded by the encoding unit 111, each tile image is acquired as a plurality of images.
  • the image file generation device 101 can acquire not only the image capturing unit 107 but also one or a plurality of images from other devices.
  • the metadata processing unit 110 analyzes the metadata of the encoded image signal.
  • the metadata processing unit 110 acquires (extracts) metadata corresponding to the image acquired in step S201.
  • the metadata processing unit 110 acquires an image file conforming to ISOBMFF (ISO base media file format) as an encoded image signal.
  • the metadata processing unit 110 acquires the property information stored in the item property box (iprp) in the image file and the property information referred to by the item in the image property association box.
  • the metadata processing unit 110 acquires Exif data when, for example, an image file including Exif data is acquired as an encoded image signal. Not limited to Exif data, XMP (Extensible Metadata Platform) and MPEG-7 metadata may be used. Further, for example, a part of the Exif data may be acquired in S203.
  • the image recognition unit 113 recognizes what kind of scene the image is, whether a specific subject is included in the image, and the result (scene recognition result or subject information) as metadata. May be input to the metadata processing unit 110. Metadata based on the result of the recognition process can also be the target of common metadata described later.
  • the metadata processing unit 110 determines whether or not one or more images are already stored in the HEIF file, and if so, the process proceeds to S205, and if not, the process proceeds to S207.
  • the metadata processing unit 110 determines whether the metadata already stored in the HEIF file matches the metadata corresponding to the image acquired this time, or whether the metadata is within a predetermined range. If they match, or if they are within a predetermined range, the process proceeds to S206, where the metadata processing unit 110 adds the item ID (image identification) of the image acquired this time to the metadata (that is, common metadata) already stored in the HEIF file. (Information) are stored in association with each other.
  • the metadata processing unit 110 stores the item ID of the image acquired this time in association with the metadata of the image as the common metadata acquired this time in the new HEIF file. ..
  • the metadata processing unit 110 stores the item of the image acquired this time in the generated HEIF file in association with the metadata of the image as the common metadata acquired this time. ..
  • step S208 the metadata processing unit 110 determines whether there is an unprocessed image. If no unprocessed image exists, the process proceeds to S209, and if an unprocessed image exists, the process proceeds to S201. Note that the determination in S208 may be made based on the setting of the shooting conditions (for example, the number of burst shootings), the number of images set by the user, and other predetermined conditions.
  • the metadata processing unit 110 deletes metadata that is not common to two or more images from the common metadata storage area.
  • the metadata that is not common to two or more images is deleted, but the deletion may be determined by a threshold value other than two.
  • the metadata corresponding to only a single image may be stored in the common metadata storage area.
  • Such a configuration is effective, for example, in a case where only one image is stored in the HEIF file, or in a use case where an image item in which specific metadata is recorded is to be quickly taken out. That is, the information stored in the common metadata storage area can be used as an index of an image associated with specific metadata.
  • the metadata processing unit 110 stores the common metadata in the HEIF file.
  • the timing of storing the common metadata in the HEIF file may be S206 or S207. If the metadata of each image becomes unnecessary by storing the common metadata in the HEIF file, the metadata processing unit 110 deletes the metadata from the HEIF file. For example, when the item property associations are grouped, the item property associations for each item are unnecessary and are deleted.
  • FIG. 3 shows an example of the format of the HEIF file.
  • a general and simple HEIF file 301 is composed of a management data section 302 and a media data section 303.
  • the management data unit 302 stores file management data including information regarding encoding of media data and information regarding a method of storing in a HEIF file.
  • the media data section 303 stores data (media data) obtained by encoding content data (moving image, still image, and audio), metadata that refers to an external standard, and the like.
  • a coded image, Exif data, and the like are stored in a box called MediaDataBox.
  • Storage areas 316, 317, and 318 indicate storage areas for each image
  • storage areas 319, 320, and 321 indicate storage areas for metadata such as Exif data defined by an external standard.
  • the management data section 302 has a box structure, and each box is identified by a type identifier.
  • Box 304 is a FileTypeBox identified by the identifier ftyp.
  • FileTypeBox is used to identify the type of file, and the file format is identified by a four-character identifier called brand.
  • the HEIF file is represented by using a 4-character identifier for identifying a brand such as mif1 or msf1.
  • Box 305 is called MetaBox and is identified by the identifier meta.
  • Various boxes are further stored in the box 305 (MetaBox). For example, a box for storing untimed metadata such as an image (image item) and a metadata item related to the image (image item) is included in the box 305 (MetaBox).
  • Box 306 is called the HandlerReferenceBox and is identified by the identifier hdrlr.
  • the structure and format of the content included in the box 305 (MetaBox) is identified by the handler type in the HandlerReferenceBox.
  • the 4-character identification code "pict" is applied to the type of this handler.
  • Box 307 is called the ItemLocationBox and is identified by the identifier iloc.
  • ItemLocationBox information indicating the ID (identification information of each image) of each item and the storage location (location) is described.
  • the metadata processing unit 110 can know where the data of the item defined in the management data unit 302 exists by referring to this information.
  • the box 308 is called ItemInformationBox and is identified by the identifier iinf.
  • An ItemInformationEntry is defined for each item in a box 308 (ItemInformationBox), and information such as an item ID, an item type, and an item name is stored in this entry.
  • the box 309 is called ItemReferenceBox and is identified by the identifier iref.
  • a box 309 (ItemReferenceBox) stores information such as a reference type regarding association of items having a reference relationship.
  • the item IDs to be referred to are described in order. For example, when the thumbnail image of item 1 is item 2, thmb indicating a thumbnail image is stored as a reference type, item_item_id stores the item ID indicating item 1, and to_item_id stores the item ID indicating item 2. .. Further, when one image is divided into a plurality of tiles and stored in the HEIF file, the box 309 (ItemReferenceBox) stores information indicating the relationship between them.
  • the whole image is item 1, and the plurality of tile images is item 2, item 3, item 4, and item 5.
  • information that item 1 is an image formed by item 2, item 3, item 4, and item 5 is stored.
  • dim indicating a derived image is stored as a reference type
  • ID indicating item 1 is stored in from_item_id.
  • to_item_id stores all item IDs indicating item 2, item 3, item 4, and item 5.
  • a box 309 (ItemReferenceBox) can also describe a reference relationship between metadata defined by an external standard such as Exif data and an image item.
  • cdsc is used as the reference type
  • the item ID indicating the Exif data is stored in the from_item_id
  • the item ID indicating the image item is stored in the to_item_id.
  • the box 310 is called ItemPropertyBox and is identified by the iprp identifier.
  • a box 310 (ItemPropertyBox) stores a box of property information applied to each item and a method of configuring the property.
  • the box 311 is called ImagePropertyContainerBox and is identified by the identifier ipco.
  • a box for describing each property is stored in the box 311.
  • the box 311 (ImagePropertyContainerBox) has various boxes. For example, a box indicating the size of an image, a box indicating color information, a box indicating pixel information, a box storing HEVC parameters, etc. are stored as necessary. It These file formats are common with the box structure defined in ISO/IEC23008-12.
  • the box 312 is called ItemPropertyAssociationGroupBox, and is identified by an ipag identifier.
  • a box 312 (ItemPropertyAssociationGroupBox) is defined by the structure shown in FIG. 7.
  • FIG. 7 is a diagram showing an example of the ItemPropertyAssociationGroupBox structure in the file format.
  • the box 312 is a box for grouping ItemProperty associations for each item defined by the entry of the ItemPropertyAssociationBox defined in ISO/IEC23008-12. By using this ItemPropertyAssociationGroupBox, items to which common item properties are applied can be grouped. The grouped items can be identified by item_association_group_id.
  • the box 313 is called ItemPropertyAssociationBox, and is identified by the ipma identifier.
  • Box 313 is defined by the structure shown in FIG.
  • FIG. 8 is a diagram showing an example of the ItemPropertyAssociationBox structure in the image file format.
  • the group bit is set to 0, and the index of the property applied to the item is described in order.
  • setting the group bit to 1 makes it clear that the property configuration for the item group is described.
  • the property configuration applied to the group identified by the item_association_group_ID is described in order.
  • the box shown in Fig. 7 is newly defined.
  • the method of similarly grouping and describing may be adopted by using the EntityToGroupBox defined in ISO/IEC23008-12 and expanding the box of FIG. 8 accordingly.
  • the box structure of FIG. 7 shown in this embodiment has a structure in which the number of bits used can be reduced, so that the metadata can be more efficiently associated with the image.
  • the existing EntityToGroupBox can be used to achieve the purpose of defining the grouping of items.
  • grouping_type is newly defined.
  • the grouping of items is defined in the ItemPropertyBox.
  • FIG. 9 is a diagram showing another example of the ItemPropertyAssociationBox structure in the image file format
  • FIG. 10 is a diagram showing another example of the ItemPropertyAssociationGroupBox structure in the image file format.
  • This is not a method of grouping items, but a method of grouping and describing item properties applied to an image. That is, in this method, a part of the property information described for each item is described as a property group.
  • an identifier indicating a grouping type may be defined and stored.
  • the identifier indicating the group type a value such as “join” indicating that the properties are combined and adapted to all images is used for identification.
  • the 4-character code of the group type may be stored instead of the'ipag' shown in the box type, or the group type may be defined and stored as one of the structure members.
  • the box structure shown in FIG. 10 is defined in the ItemPropertyBox, but it may be defined in the GroupListBox defined in ISO/IEC23008-12. This makes it possible to reduce the amount of data when describing in the file format.
  • FIG. 17 is a diagram showing an example of the ItemPropertyToGroupPropertyBox structure in the image file format.
  • the box shown in FIG. 17 is an ItemPropertyToGroupPropertyBox, which is equivalent to the above-mentioned ItemPropertyAssociationGroupBox.
  • an identifier indicating the type of group can be stored in the four-character code indicating the box type. This makes it possible to determine what kind of group the item property is.
  • num_properties_in_group indicates the number of item properties to be grouped.
  • the essential information indicates whether or not the item property indicated by each property_index is essential.
  • the item information in the ItemPropertyAssociationBox when the index information indicating the ItemPropertyToGroupPropertyBox is stored in the ItemPropertyAssociationBox indicates whether or not the item group itself is required.
  • the property_index describes the item property information indicated by the index order starting from 1 in the ItemPropertyContainerBox, as in the ItemPropertyAssociationBox. Index number 0 is reserved.
  • the ItemPropertyToGroupPropertyBox itself is also shown in the same index order, but information indicating the self-indexing order should not be stored in this box. If your index is stored, ignore it. This makes it possible to avoid an infinite loop. Since this box is defined as one of the item properties, the property type is the Descriptive type. In addition, it is desirable, but not limited to, that the Descriptive type and the Transformative type are grouped separately for each item property grouped by the list of property_index. At that time, the Item property of the Descriptive type is described, and then the ItemPropertyToGroupPropertyBox in which the Descriptive types are grouped is described.
  • the Transformative item property it is preferable to describe the Transformative item property, and then describe the ItemPropertyToGroupPropertyBox in which the Transformative type item properties are grouped. It should be noted that the Grouping_type or flags of the ItemPropertyToGroupPropertyBox may be used to distinguish between the Descritive type group and the Transformative type group.
  • FIG. 16 is a diagram showing another example of the ItemPropertyAssociationBox structure in the image file format. According to the box structure shown in FIG. 16, a plurality of item properties can be applied to a plurality of items. That is, it is possible to group the items in each entry of the ItemPropertyAssociationBox without explicitly grouping the item properties and the items, and to describe the properties applicable thereto.
  • Box 314 is called CommonItemPropertyBox and is identified by the cipr identifier. Box 314 is defined by the structure shown in FIG. FIG. 11 is a diagram illustrating an example of a CommonItemPropertyBox structure.
  • a box 314 (CommonItemPropertyBox) is a box for indicating item properties commonly applied to all items. By using the box 314, properties (metadata) that are commonly applied to all items are easily extracted. That is, if the common metadata is stored using the box 314, the common metadata can be extracted without searching all the entries of the ItemPropertyAssociationBox. This improves the search efficiency when accessing the file.
  • the search efficiency is improved by defining a box indicating a property commonly applied to all items.
  • the present invention is not limited to this example, and information that can be identified as being applicable to all such items may be stored in the box of each item property defined in the ItemPropertyContainerBox.
  • the box 315 is called CommonItemPropertyGroupBox, and is identified by the identifier cipg.
  • Box 315 is defined by the structure shown in FIG. FIG. 12 is a diagram illustrating an example of a CommonItemPropertyGroupBox structure.
  • a box 315 (CommonItemPropertyGroupBox) is a box that makes it possible to identify items to which common properties (metadata) are applied.
  • box 315 (CommonItemPropertyGroupBox) is a box that describes a list of items to which common properties apply.
  • the metadata processing unit 110 can specify the item to which the specific property is applied without checking all entries of the ItemPropertyAssociationBox.
  • the efficiency in the case of reading the image file and picking up and processing only the items to which the specific property is applied is improved, and the search efficiency in accessing the file is improved.
  • batch operation becomes easy when editing a file or the like.
  • the item property indicated by property_index is a property indicating the image size
  • the plurality of image items to which the image properties defined in the ItemPropertyContainerBox are applied are represented by the box 315, so that the metadata processing unit 110 can easily identify the plurality of images to which the common properties are applied.
  • a box 310 (ItemPropertyBox) for storing a box representing a common property has a structure shown in FIG.
  • FIG. 13 is a diagram illustrating an example of an ItemPropertyBox (ItemPropertiesBox) structure.
  • the box 310 (ItemPropertyBox) specifically stores the ItemPropertyAssociationBox in the ItemPropertiesBox identified by the identifier iprp. Further, the ItemPropertyContainerBox, ItemPropertyAssociationGroupBox, CommonItemPropertyBox, and CommonItemPropertyGroupBox are stored.
  • FIG. 14 is a description example of the box 309 (ItemReferenceBox) of FIG.
  • FIG. 15 is a description example of the box 308 (ItemInformationBox) of FIG.
  • FIG. 4 shows Exif data blocks 401, 402, 403, 404, 405.
  • the ItemInformationBox shown in FIG. 15 is made up of nine entries, and item_IDs 1, 2, 3, and 4 are image items.
  • the image item with item_ID 5 is in the Exif data block 401
  • the image item with item_ID 6 is in the Exif data block 402
  • the image item with item_ID 7 is in the Exif data block 403
  • the image item with item_ID 8 is in the Exif data block 404.
  • Item_ID of 9 corresponds to the Exif data block 405, respectively.
  • the ItemReferenceBox shown in FIG. 14 indicates the reference relationship of each item. It can be read from FIGS. 14 and 15 that item_ID5 is an Exif data block relating to the image of item_ID1.
  • item_ID6 is an Exif data block related to the image of item_ID2
  • item_ID7 is an Exif data block related to the image of item_ID3.
  • item_ID8 is an Exif data block relating to the image of item_ID4.
  • item_ID9 refers to item_ID5, 6, 7, and 8. This description indicates that item_ID9 is an Exif data block obtained by extracting a common part (common metadata) from the Exif data blocks of item_ID5, 6, 7, and 8.
  • the Exif data block 401 shown in FIG. 4 includes an image width 410, an image height 411, an X resolution 412, a Y resolution 413, a maker name 414, a model name 415, a shooting date and time 416, an ISO sensitivity 417, and an Exif tag (meta information 418) Data).
  • These tags are generated at the time of imaging. Further, tags may be added, changed, or deleted by a separate editing process.
  • the Exif data block 405 is a block that stores common data (common metadata) of the Exif data blocks 401, 402, 403, and 404.
  • the value “320pixel” is stored in the image width tag 450 in the Exif data block 405.
  • the value “240pixel” is stored in the image height tag 451 in the Exif data block 405.
  • “96 dpi” indicated by the X resolutions 412, 422, 432, and 442 is stored in the area 452.
  • “96 dpi” indicated by the Y resolutions 413, 423, 433, and 443 is stored in the area 453.
  • “Company A” indicated by manufacturer names 414, 424, 434, and 444 is stored in area 454.
  • “11” indicated by the model names 415, 425, 435, and 445 is stored in the area 455.
  • the shooting date and time varies depending on the image.
  • the (shooting) date and time 416 and 426 is “June 13, 2018”
  • the date and time 436 is “June 14, 2018”
  • the date and time 446 is “June 15, 2018”. is there. Therefore, the shooting date/time is not stored in the Exif data block 405 in which the common data of each Exif data block is extracted.
  • the metadata common to all image items is stored in the Exif data block 405.
  • the ISO sensitivity values 417, 427, 437, and 447 have different values, they are not stored in the Exif data block 405.
  • the time information is omitted at the dates 416, 426, 436, 446.
  • the GPS information 418, 428, 438, 448 which is the position information, is stored in the Exif data block 405 if it is within the predetermined range even if the values do not completely match. .. This is because the GPS information 418, 428, 438, and 448 match as information indicating a specific location, even if they do not completely match. That is, the GPS information 418, 428, 438, and 448 all indicate the location of the company A, and the locations derived by geocode etc. are all the company A and coincide with each other.
  • the metadata processing unit 110 of the present embodiment treats a plurality of GPS information within a specific range as common metadata.
  • some types of metadata for example, GPS information
  • which range is common may be specified separately by the user or may be appropriately determined according to the settings of a specific system.
  • all the GPS information on the premises of the company A is treated as common metadata
  • the GPS information stored in the GPS information 458 is a representative of the company A represented by a geocode or the like. Represents a point. For example, when the GPS information in Tokyo is treated as common GPS information, the position information of the representative point in Tokyo is stored in the GPS information 458.
  • the HEIF file of this embodiment does not store information indicating at what granularity the GPS information is handled, but it may be stored in the file.
  • FIG. 4 shows an example in which data common to all Exif data blocks of each image is stored in the common Exif data block.
  • the Exif data block common to two or more Exif data blocks may be stored in the common Exif data block.
  • the Exif data block to be referred to may be defined in the ItemReferenceBox shown in FIG.
  • the (shooting) dates and times 416 and 426 are also included in the extraction target because they are common Exif data.
  • the metadata processing unit 110 of the present embodiment extracts all the common data in the Exif data block corresponding to each image
  • the common data may be extracted only for certain specific Exif data. You can For example, it may be a determination target whether or not only the shooting date and time is common. Further, for example, the commonality of the shooting dates and times may be determined only for images whose shooting dates and times fall within a specific range. As described above, it should be noted that the commonality may be determined only for a specific type of metadata, and that there are various variations in determining the specific type.
  • the image file generation device 101 generates common metadata from metadata (property information) associated with each of a plurality of images stored in an image file (HEIF file) conforming to the image file format. Extract. Then, the image file generation device 101 stores the extracted metadata as common metadata in the metadata area. Further, the image file generation device 101 may store in the HEIF file information indicating whether the metadata is common metadata common to all images or common metadata to some of a plurality of images. .. In the case of common metadata common to some images, the item ID (image identification information) of the some images is stored. Further, the image file generation apparatus 101 also extracts common metadata from the metadata of each image and holds it as common metadata for metadata based on an external standard (for example, Exif data).
  • an external standard for example, Exif data
  • the processing load can be reduced when specific processing is performed only on one or more images associated with specific metadata among the plurality of images stored in the HEIF file.
  • the processing of searching for a specific image from the plurality of images stored in the HEIF file can be performed with a low load.
  • the size of the image file can be reduced by sharing the metadata for each image in common.
  • the configuration of the image file generation device 501 of this embodiment is shown in FIG.
  • the image file generation device 501 of FIG. 5 is a communication device having a file editing function, such as a server device that performs processing by a Web service such as a tablet PC, desktop PC, or cloud.
  • the components having the same reference numerals as those in FIG. 1 are the same as those in FIG.
  • the metadata processing unit 502 performs processing for editing an image file and extracting common metadata from images and metadata stored in the image file.
  • the image file generation device 501 according to the present embodiment is characterized by editing an image file, and thus may be configured without the imaging unit 107.
  • FIG. 6 is a diagram showing a processing flow of the image file generation device 501 in the second embodiment.
  • This processing flow can be executed by each circuit shown in FIG. 5 according to a user operation.
  • the present processing flow can be realized by the control unit 106 executing a program stored in the ROM 104 in a timely manner, calculating and processing information, and controlling each hardware. It is assumed that an image file (HEIF file) conforming to one or more image file formats is stored in the image file generating device 501 in advance.
  • step S ⁇ b>601 the metadata processing unit 502, based on the metadata associated with each of the plurality of images stored in the HEIF file, information regarding the metadata to be extracted, such as the metadata value, range, and type. Determine (extraction target metadata). This determination may be made based on a user designation via the operation unit 108, or may be made based on a predetermined system setting or the like. Also, multiple decisions may be made.
  • the metadata processing unit 502 acquires the metadata of each of the plurality of images stored in the HEIF file.
  • the metadata processing unit 502 is not limited to one HEIF file, but may process a plurality of HEIF files. Further, not only the HEIF file but also a JPEG file or the like may be processed. In addition, the metadata processing unit 502 may acquire only the metadata already recorded in the HEIF file, or may acquire the metadata newly generated by the processing of the image recognition unit 506 as the acquisition target.
  • step S603 the metadata processing unit 502 determines whether the metadata acquired in step S602 matches the extraction target metadata determined in step S601. If they match, the process proceeds to S604, and if they do not match, the process proceeds to S605.
  • step S603 the metadata processing unit 502 determines whether the range of both metadata is within a predetermined range. If the range is within the predetermined range, the process proceeds to step S604. If the range is not within the predetermined range, the process proceeds to step S605. Is also good.
  • step S604 the metadata processing unit 502 extracts matching metadata as common metadata, stores the common metadata in the storage area of the common metadata in association with the item ID for identifying the image.
  • the metadata processing unit 502 creates a new HEIF file and stores the image item and the item ID corresponding to the HEIF file.
  • step S605 the metadata processing unit 502 determines whether processing has been completed for all images for which metadata is to be acquired. When it is completed, the process proceeds to S606, and when it is not completed, the process proceeds to S602 and is repeated.
  • step S606 the metadata processing unit 502 deletes metadata that is not common to other images from the extracted common metadata. That is, the metadata processing unit 502 does not store the metadata applied to only a single image as the common metadata.
  • step S607 the metadata processing unit 502 stores the common metadata in the HEIF file.
  • the metadata processing unit 502 stores the common metadata in the HEIF file according to the formats shown in FIGS. 7 to 17 based on the common metadata and the item ID of the image.
  • the metadata corresponding to only a single image is not stored as the common metadata, but the metadata common only to the images of which the number is smaller than the predetermined threshold is not stored as the common metadata. You may do it.
  • the metadata corresponding to only a single image may be stored in the area for storing the common metadata.
  • Such a configuration is effective, for example, in a case where only one image is stored in the HEIF file, or in a use case where an image item in which specific metadata is recorded is to be quickly taken out. That is, the information stored in the common metadata storage area can be used as an index of an image associated with specific metadata.
  • the image file generation device 501 of the present embodiment extracts common metadata from the generated image file and newly generates a HEIF file in which the common metadata is stored. This makes it possible to generate an image file storing common metadata from an image file not recorded as common metadata.
  • the image file generation device 501 according to the present embodiment extracts common metadata from a plurality of images (including videos) stored in a plurality of image files (including video files) and stores the common metadata. Generate a new file.
  • the image file generation apparatus 101 also extracts common metadata from the metadata of each image and holds it as common metadata for metadata based on an external standard (for example, Exif data). This can reduce the processing load when handling a plurality of images stored in the HEIF file.
  • the processing load can be reduced when specific processing is performed only on one or more images associated with specific metadata among the plurality of images stored in the HEIF file. Further, the processing of searching for a specific image from the plurality of images stored in the HEIF file can be performed with a low load. Further, the size of the image file can be reduced by sharing the metadata for each image in common.
  • FIGS. 18A and 18B are flowcharts showing the image file generation processing flow in this embodiment.
  • This processing flow is typically started in response to the input of an editing instruction from the user.
  • this processing flow is performed by the image file generation device 501 shown in FIG.
  • a user operation, each circuit shown in FIG. 5, or the control unit 106 executes a program stored in the ROM 104 in a timely manner to execute information calculation and processing and control of each hardware.
  • step S1801 the metadata processing unit 502 acquires the metadata (metadata to be added) to be stored in the HEIF file.
  • the metadata processing unit 502 may acquire the addition target metadata based on a user designation via the operation unit 108, or may acquire the metadata based on a predetermined system setting or the like.
  • step S1802 the metadata processing unit 502 acquires one or more pieces of metadata stored in the HEIF file, and acquires the type of each metadata. Details of the type of metadata will be described later.
  • step S1803 the metadata processing unit 502 determines whether the HEIF file includes the same type of metadata as the addition target metadata acquired in step S1801. That is, the metadata processing unit 502 determines whether or not there is one that matches the type of the addition target metadata acquired in S1801 among the one or more metadata types acquired in S1802. When it exists, it progresses to S1804, and when it does not exist, it progresses to S1805. It should be noted that the determination can be made based on a knowledge base such as a dictionary stored in advance in the image file generation device 502. Further, instead of the type of metadata, other information such as the property or attribute of metadata may be compared.
  • the metadata processing unit 502 has applied (applied) the same type of metadata determined to exist in S1803 to the image to which the addition target metadata is applied (the image to which the addition target metadata is applied). To confirm. If it has been adapted, the process proceeds to S1807, and if it has not been adapted, the process proceeds to S1805. If there are a plurality of images to which the addition target metadata is applied, the metadata processing unit 502 confirms each image, and if any one is applied, the process proceeds to step S1807.
  • step S1805 the metadata processing unit 502 stores information on the metadata to be added in the HEIF file. This mainly corresponds to storing as ItemProperty in the element of ItemPropertyContainerBox.
  • step S1806 the metadata processing unit 502 stores the association information between the stored addition target metadata and the image (the image adapted to the addition target metadata), and ends the processing. This mainly corresponds to the storage of the association information for each image item in the ItemPropertyAssociationBox.
  • the metadata processing unit 502 stores the index order of ItemPropertyContainerBox of item properties as an association of each item ID.
  • the metadata processing unit 502 confirms whether metadata of the same type applied to the same image has already been grouped. If the same type of metadata is grouped, the process advances to step S1806. If not grouped, the process proceeds to S1810. It should be noted that even if the metadata is of the same type, it is not selectively applied, and if it is applied in a different meaning, it is not considered as the same type of metadata, and the process proceeds to S1810.
  • step S1808 the metadata processing unit 502 stores the information of the addition target metadata in the HEIF file as in step S1805.
  • step S1809 the metadata processing unit 502 adds the information of the addition target metadata stored in step S1808 to the already grouped metadata group, and ends the processing. As a result, the options within the group of item properties that are already associated with the item ItemItemBox are added to the image item.
  • the metadata processing unit 502 stores the information of the addition target metadata in the HEIF file, as in S1805 and S1808.
  • the metadata processing unit 502 stores information for grouping metadata adapted to the same image into the same type of metadata. That is, the metadata processing unit 502 stores information for grouping the metadata applied to the image to which the addition target metadata is applied and the addition target metadata as the same kind of metadata.
  • the metadata processing unit 502 deletes the previously stored information that associates the same type of metadata with the image item. Specifically, it corresponds to deleting the corresponding index information in the item property in the ItemAssociationBox.
  • the metadata processing unit 502 stores information that associates the grouped metadata with the image item. Specifically, it corresponds to storing the association information indicating the item property group in the ItemAssociationBox.
  • the property (metadata) applied to the image from the plurality of properties selectively adapt the property (metadata) applied to the image from the plurality of properties (selectively associate the property related to the image from the plurality of properties). ..
  • the property of may be grouped and stored. At that time, when an image to be stored in the image file format of S201 is input, the same kind of metadata group information is stored when the related metadata is stored. Further, in the present embodiment, the grouping of properties is shown by the above box structure, but any box structure that can achieve this object may be used.
  • FIG. 19 is a diagram showing an example of the AccessibilityTextPropertyBox structure
  • FIGS. 20 and 21 show an example of the ItemPropertyBox.
  • the box shown in FIG. 19 is AccessibilityTextPropertyBox.
  • This box is a box for storing the information of the alternative text character string of the HTML specification.
  • Alt_text stored in this box is a parameter for storing the alternative text of the HTML specification.
  • alt_lang is a character string of a language tag conforming to RFC4646 or BCP47, and stores an identifier indicating a language such as'en-US','fr-FR','zh-CN', or'ja-JP'. Text information in the language indicated by alt_lang is stored in alt_text.
  • this box it is possible to store text information such as what kind of content the image item has.
  • this box as an item property for each language in which it is desired to store, it becomes possible to store text information corresponding to the language.
  • the alternative text of the HTML specification is stored in the present embodiment, the text information may be stored without being limited to the HTML specification.
  • the ItemPropertiesBox shown in FIG. 20 is a diagram showing an example of applying the item properties stored in the image file to the image.
  • this image file four sub-pictures are stored as item IDs 1 to 4, and one image item that configures it as a grid derived image is configured as item ID 5.
  • the four sub-pictures are images having an image size of 512 in width and 512 in height, and one image which is a derivative image thereof stores an image of 1024 in width and 1024 in height.
  • Common properties are applied to the four sub-pictures, and one derived image stores text information indicating what the image is (indexes 1 to 6).
  • an ItemPropertyContainerBox and an ItemPropertyAssociationBox are stored in the ItemPropertiesBox. Further, the ItemPropertyContainerBox stores six various item properties.
  • the first HEVCConfigurationBox is a box indicated by the identifier hvcC, and stores the encoding parameter of the image item.
  • the second ImageSpacialExtentsPropertyBox is a Box indicated by the identifier ispe, and stores information indicating the size of the image.
  • the third to fifth AccessibilityTextPropertyBoxes are boxes having the structure shown in FIG. 19 and are identified by'altt'.
  • en-US is stored in alt_lang, which indicates English in the American region.
  • alt_text an English text character string'dog' is stored.
  • ja-JP is stored in alt_lang, which indicates Japanese in the Japanese region.
  • a Japanese text character string "dog" is stored in alt_lang.
  • fr-FR is stored in alt_lang, which indicates French in the French region.
  • a French text character string'chien' is stored in the alt_text.
  • a text character string having the same meaning is stored in each language. That is, the types of the text information related to the same image have the same meaning.
  • the image file generating device 501 (or 101) stores learning data and a knowledge base such as a dictionary in advance and can determine whether or not the types of metadata are the same.
  • property_index which is the index order of ItemPropertyContainerBox, indicates 3, 4, and 5, and the above-mentioned AccessibilityTextPropertyBox is grouped.
  • the three AccessibilityTextPropertyBoxes can be grouped together using the ItemPropertyToGroupPropertyBox, and the ItemPropertyToGroupPropertyBox can be adapted as a group to the item using the ItemPropertyToGroupPropertyBox.
  • ItemPropertyAssociationBox is a box indicated by the identifier ipma, and stores information indicating the relationship between each image item and item property.
  • the entry_count indicates 1, indicating that the item property association of one image is stored.
  • the association_count indicates that the image whose item_ID is 1 is associated with three item properties.
  • essential indicates 1 and indicates that it is an essential property.
  • 1 in property_index indicates that the above-mentioned HEVCConfigurationBox, which is 1 in the order of index of ItemPropertyContainerBox, is associated.
  • the essential indicates 0, indicating that the property is not essential.
  • 2 in property_index indicates that the above-mentioned ImageSpacialExtentsPropertyBox is associated.
  • the essential indicates 0, indicating that the property is not essential.
  • the property_index indicates 6, and the ItemPropertyToGroupPropertyBox is associated with the property_index. Accordingly, the device that reads the image file can refer to the image item to which the ItemPropertyToGroupPropertyBox is applied by the group type altr by selecting one of the three AccessibilityTextPropertyBoxes.
  • any one of the item properties grouped by altr is selectively applied to the image item, but a plurality of properties may be selectively applied.
  • the item properties are explicitly grouped by using ItemPropertyToGroupPropertyBox and adapted to the image item.
  • ItemPropertyAssociationBox when the same kind of item property is adapted to ItemPropertyAssociationBox, the image is implicitly and selectively selected.
  • the configuration may be adapted to the item.
  • not only the alternative text information but also related text may be stored as a label. In that case, it is also possible to apply a plurality of pieces of text information grouped according to meaning and selectively apply label information for each group.
  • item properties of the Transformative type can also be grouped in the same manner. At that time, it is desirable to group the properties of the Descriptive type and the Transformative type without mixing them. At that time, flags may be used to indicate what type of property is to be grouped, or grouping_type may be used to define the group type so that it can be identified. Further, by describing the Descriptive type property and then describing the Descriptive type group, it is possible to describe the index number described in advance. Further, after that, the Transform type item property is described. After that, it is preferable to describe ItemPropertyToGroupPropertyBox in which item properties of the Transformative type are similarly grouped. As a result, it becomes possible to adapt without changing the constraint condition when adapting the item property.
  • the ItemPropertyContainerBox and the ItemPropertyAssociationBox are stored in the ItemPropertiesBox. Further, the ItemPropertyContainerBox stores nine various item properties.
  • the first HEVCConfigurationBox is a box indicated by the identifier hvcC, and stores the encoding parameter of the image item. Different coding parameters are stored in the second HEVCConfigurationBox.
  • the third and fourth ImageSpacialExtentsPropertyBoxes are Boxes indicated by the identifier ispe, and information indicating the size of the image is stored. Information of different image sizes is stored in each of the two Image Spatial Extenders PropertyBoxes.
  • the fifth to seventh AccessibilityTextPropertyBoxes are boxes having the structure shown in FIG. 19 and are identified by'altt'. Texts in different languages are stored in the three AccessibilityTextPropertyBoxes.
  • the ItemPropertyToGroupPropertyBox identified by the group type'altr', groups three item properties. In this embodiment, AccessibilityTextProperty of index order 5, 6, and 7 is grouped as a property of the same type. Further, in the ItemPropertyToGroupPropertyBox indicated by the group type'join', two item properties are grouped.
  • the HEVCConfigurationBox with an index order of 1 and the ImageSpatialExtentsPropertyBox with an index order of 3 are grouped as a common item property.
  • ItemPropertyAssociationBox property related information of five items is stored. Items having item_IDs 1 to 4 are applied to the item group of the “join” type, which is the ninth index order item, and the first and third item properties in the index order item are all commonly applied. Further, the item property of item ID 5 is adapted to the item properties of index order 2, 4, and 8.
  • the 8th item property in the index order is an item property group of the altr type, and the 5th, 6th, and 7th item properties in the index order are selectively applied.
  • AccessibilityTextPropertyBox is defined as the item property of the same type in the present embodiment, other item properties may be selectively applicable.
  • different versions may be stored as properties of the same type, and may be adapted as a box of a version supported by the reading device.
  • the CleanApertureBox for each of a plurality of specific persons can be defined, and the reading device can selectively display only the specific person.
  • Various other expansions are also possible.
  • the image file generation device 101 or 501 of the present embodiment uses common or similar metadata among a plurality of metadata (property information) related to an image stored in an image file (HEIF file) conforming to the image file format. To extract. Then, the extracted metadata is grouped and stored in the metadata area. At that time, an identifier capable of determining the grouped type is stored. The grouped metadata is stored in the image file in association with the image in the same manner as other ungrouped metadata. This makes it possible to handle a plurality of metadata (property information) stored in the HEIF file as a group, reduce the processing load when handling an image, and selectively adapt metadata. The selective adaptation makes it possible to adaptively handle the image based on the situation, conditions, and judgment of the device that reads the image file. Further, the size of the image file can be reduced by sharing the metadata for each image in common.
  • the processing relating to the image file can be efficiently performed.
  • the metadata is selectively applied to the image file. It can be performed.
  • the present invention supplies a program that implements one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program. It can also be realized by the processing. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.
  • a circuit for example, ASIC

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Library & Information Science (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

１つ以上の画像を所定のイメージファイルフォーマットに従った画像ファイルに格納するための画像ファイル生成装置は、該画像ファイルに格納する複数のメタデータを取得し、該複数のメタデータのうち、メタデータの種別に応じてグループ化し、該グループ化されたメタデータを該画像ファイルに格納する。

Description

画像ファイル生成装置、画像ファイル生成方法、及びプログラム
　本発明は、１つ以上の画像データを画像ファイルに格納するための技術に関する。
　ＭＰＥＧ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅｓ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ）では、単一の静止画像、複数の静止画像、又は、画像シーケンス（静止画像のバースト等）を１つのファイルに格納するための標準を開発している。本標準は、ＨＥＩＦ（Ｈｉｇｈ　Ｅｆｆｉｃｉｅｎｃｙ　Ｉｍａｇｅ　Ｆｉｌｅ　Ｆｏｒｍａｔ）と呼ばれ、画像と画像シーケンスの交換、編集、及び表示を可能とする。またＨＥＩＦは、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ：ＩＳＯ　Ｂａｓｅ　Ｍｅｄｉａ　Ｆｉｌｅ　Ｆｏｒｍａｔ）で定められるツールを基に拡張された格納フォーマットである。ＨＥＩＦは、ＩＳＯ／ＩＥＣ２３００８―１２において「Ｉｍａｇｅ　Ｆｉｌｅ　Ｆｏｒｍａｔ」という名称で標準化が進行している。またＨＥＩＦは、メタデータを含む規範的な構造を定めており、メタデータと画像を関連付けする方法、特定の形式のメタデータの構成について定めている。特許文献１には、ＨＥＩＦに準拠した画像ファイルに派生画像を格納することが記載されている。
　一方、カメラやスマートフォン等、画像生成機能を備えた画像生成装置は近年様々な機能を有しており、撮影日時や、画像サイズ、画像品質だけでなく、撮影時の情報や、撮影した画像データのメタデータなど様々な情報を生成可能となっている。例えば、撮影した位置情報や、画像データの被写体やシーンが何であるかといったことを識別する情報、また、撮影時の撮像モード等画像データに付随する多様な情報が画像データとともに生成される。このような画像データに関する情報は、メタデータとしてＨＥＩＦファイルに格納できる。
米国特許出願公開第２０１６／３７１２６５号明細書
　所定の画像フォーマットに応じた画像ファイル（例えばＨＥＩＦファイル）内に格納される複数の画像のうち２以上の画像が共通のメタデータに対応する場合において、その処理を効率的に行うことが困難であった。つまり、ＨＥＩＦファイルに格納される２以上の画像に同じメタデータが対応する場合であってもそのメタデータは画像毎に格納されていた。そのため、ＨＥＩＦファイルを処理する装置は、各画像のメタデータやその構成情報を順に確認しなければ各画像のメタデータが共通であることを確認できなかった。したがって、ＨＥＩＦファイル内の複数の画像がすべて共通なメタデータに対応する場合や、複数の画像のうちの２以上が共通のメタデータに対応している場合に、各画像に対して一括処理を行うときの処理負荷が大きかった。
　また、例えば１つの画像をタイルに分割し、各タイル画像を派生画像として格納する場合、Ｅｘｉｆデータ等のメタデータを派生画像ごとに定義すると、ファイル生成負荷やファイルサイズの観点から効率が悪かった。なお、ＥｘｉｆはＥｘｃｈａｎｇｅａｂｌｅ　ｉｍａｇｅ　ｆｉｌｅ　ｆｏｒｍａｔの略である。つまり、各タイル画像のメタデータ（例えば画像サイズ、カラー情報、及び符号化情報等）は共通であることが多いにもかかわらず、従来は、複数の（派生）画像ごとにメタデータが定義されていたため、効率的でなかった。
　一方で、画像に適応する（対応する）メタデータを構成する際の情報には、そのメタデータが必須であるか否かの情報しか格納することができなかった。つまり、複数のメタデータを１つの画像に適応させる場合において、同種のメタデータからいずれか１つを選択して適応させることができなかった。例えば、ＨＴＭＬ仕様で定義されているような代替テキスト情報を格納する場合や、複数の言語に対応した情報を格納しようとした場合、言語ごとのテキスト情報を、画像に選択的に適応できることが好ましい。ＨＴＭＬでは他のＵＲＩから情報を取得するためのＬｏｎｇｄｅｓｃ情報を格納して多言語に対応しているが、イメージファイル内に閉じて格納する場合はそれぞれの言語に対応した情報をファイル内に格納しておく必要がある。その際、複数の言語のテキスト情報からいずれかを選択して画像に適応させることができなかった。
　本開示は、上記課題に鑑み、画像ファイル生成に関する処理を効率的に行うための技術を提供する。
　上記の課題を解決するための一手段として、本発明の画像ファイル生成装置は、以下の構成を有する。すなわち、１つ以上の画像を所定のイメージファイルフォーマットに従った画像ファイルに格納するための画像ファイル生成装置であって、前記画像ファイルに格納する複数のメタデータを取得する取得手段と、前記複数のメタデータのうち、メタデータの種別に応じてグループ化するグループ化手段と、前記グループ化されたメタデータを前記画像ファイルに格納する格納手段と、を有する。
　本発明によれば、画像ファイル生成に関する処理を効率的に行うことが可能となる。
　本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。
　添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
第１実施形態における画像ファイル生成装置の構成を示す図。 第１実施形態における画像ファイル生成装置の処理フローを示す図。 実施形態におけるファイルフォーマットの一例を示す図。 実施形態におけるＥｘｉｆデータの一例を示す図。 第２実施形態における画像ファイル生成装置の構成を示す図。 第２実施形態における画像ファイル生成装置の処理フローを示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘ構造の一例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏＢｏｘ構造の一例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏＢｏｘ構造の別の例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏＧｒｏｕｐＢｏｘ構造の別の例を示す図。 実施形態におけるイメージファイルフォーマット内のＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ構造の一例を示す図。 実施形態におけるイメージファイルフォーマット内のＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＧｒｏｕｐＢｏｘ構造の一例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ構造の一例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘの一例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｏｘの一例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎ構造の別の例を示す図。 実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘ構造の一例を示す図。 第３実施形態における画像ファイル生成装置の処理フローを示す図。 第３実施形態における画像ファイル生成装置の処理フローを示す図。 第３実施形態におけるイメージファイルフォーマット内のＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘ構造の一例を示す図。 第３実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘの一例を示す図。 第３実施形態におけるイメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘの別の例を示す図。
　以下、添付の図面を参照して、本発明をその実施形態の一例に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
　＜第１実施形態＞
　第１実施形態では、画像ファイル生成時に共通のメタデータを抽出して画像ファイル内に格納する例を説明する。
　（画像ファイル生成装置１０１の構成）
　図１は、本実施形態の画像ファイル生成装置１０１の構成を示す。図１の画像ファイル生成装置１０１は、カメラやスマートフォン、タブレットＰＣ等の撮影機能を有した通信装置である。本実施形態の画像ファイル生成装置１０１は、所定のイメージファイルフォーマットに準拠した画像ファイルを生成する。画像ファイル生成装置１０１はシステムバス１０２を有し、不揮発メモリ１０３、ＲＯＭ１０４、ＲＡＭ１０５、制御部１０６、撮像部１０７、操作部１０８を有する。画像ファイル生成装置１０１は更に、ファイル出力部１０９、メタデータ処理部１１０、符号化部１１１、表示部１１２、画像認識部１１３、ＬＡＮ制御部１１４を有し、それぞれがシステムバス１０２に接続されるハードウェア構成となっている。システムバス１０２は、接続する各ブロック間でデータを伝達する。なお、本実施形態では、主に「画像」という言葉を用いるが、これは静止画に限定することを意図しない。
　制御部１０６は、１つ以上のＣＰＵにより構成され、ＲＯＭ１０４に記憶されるプログラムを実行する。制御部１０６が実行するプログラムには、ＯＳ（オペレーティングシステム）やドライバ、アプリケーション等が含まれる。制御部１０６はプログラムを実行することにより、画像ファイル生成装置１０１の全体制御を行う。例えば、制御部１０６は、ユーザが操作部１０８より入力した指示を基に、表示部１１２への表示制御を行ったり、撮像部１０７へ撮影の指示を行ったり、ＬＡＮ制御部１１４への接続指示を行ったりといった処理を行う。撮像部１０７はＣＭＯＳセンサー等の画像センサーを有し、制御部１０６からの指示により画像信号を入力する。入力された画像信号は符号化部１１１によってデジタルデータに符号化される。また画像ファイル生成装置１０１は、画像ファイルを復号化するように機能しても良い。例えば、制御部１０６が、操作部１０８を介した再生処理に関するユーザ操作に応じて、復号化部（不図示）に画像ファイルの復号化を行わせ、復号化された画像データを表示部１１２に表示させる。
　メタデータ処理部１１０は、符号化部１１１によって符号化されたデータを取得し、所定のファイルフォーマット（例えばＨＥＩＦ）に準拠した画像ファイルを生成する。なお、メタデータ処理部１１０は、ＨＥＩＦに限らず、例えば、ＭＰＥＧにおいて規定される他の動画ファイルフォーマットやＪＰＥＧ等のフォーマットに準拠したファイルを生成することもできる。また、メタデータ処理部１１０は、符号化部１１１に限らず、他の装置から符号化済みのデータを取得し、画像ファイルを生成しても良い。
　ファイル出力部１０９は、メタデータ処理部１１０により生成された画像ファイルを出力する。出力先は特に限定しないが、例えば、画像ファイルに基づいて画像を表示する表示装置、または、画像ファイルに基づく画像を印刷する印刷装置などに出力されるようにしても良い。また、画像ファイルは、画像ファイルを格納するストレージ装置、または、画像ファイルを格納するストレージメディア（不揮発メモリ１０３）に出力されるようにしても良い。不揮発メモリ１０３は、ＳＤカード、コンパクトフラッシュ（登録商標）、又はフラッシュメモリ等である。画像認識部１１３は、撮像部１０７から入力された画像信号や、不揮発メモリ１０３に格納された画像ファイルから人物や物体、シーン等の認識処理を実行し、その結果（シーン情報や被写体情報）を制御部１０６へ送る。制御部１０６は、認識処理の結果を基に表示部１１２へ指示を送ったり、撮像部１０７へ自動でシャッターを切ったりなどの指示を行う。また制御部１０６は、メタデータ処理部１１０に対し、画像ファイルに格納するメタデータを通知する等の処理を行う。なお、本実施形態においてメタデータとプロパティ情報はほぼ同じ意味であるものとして説明する。
　なお、本実施形態では各機能ブロックを別回路による構成としたが、少なくとも１つの機能ブロックの処理（動作）が制御部１０６等によるプログラムの実行により実現されるようにしてもよい。
　ＲＡＭ１０５は、画像ファイル生成装置１０１の主記憶部であって、主に、各機能ブロックの処理実行時にデータの一時記憶領域として使用される。ＲＯＭ１０４は、各機能ブロックが実行するソフトウェアプログラムが格納される不揮発性の記憶部である。ＲＯＭ１０４に格納されるプログラムは、ＲＡＭ１０５に転送され、各機能ブロックによって読み出されて実行される。ＬＡＮ制御部１１４は、ＬＡＮに接続する通信インターフェースであり、有線ＬＡＮもしくは無線ＬＡＮの通信制御を実行する。例えば、画像ファイル生成装置１０１が有線ＬＡＮによって他の装置と接続する場合、ＬＡＮ制御部１１４は伝送メディアのＰＨＹ及びＭＡＣ（伝送メディア制御）ハードウェア回路を含む。この場合、ＬＡＮ制御部１１４はＥｔｈｅｒｎｅｔ（登録商標）のＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）に相当する。また、画像ファイル生成装置１０１が無線ＬＡＮにより他の装置と接続する場合、ＬＡＮ制御部１１４は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ等の無線ＬＡＮ制御を実行するコントローラ、ＲＦ回路、アンテナを含む。
　（処理の流れ）
　次に、イメージファイルフォーマット（ＨＥＩＦ）に準拠した画像ファイル（ＨＥＩＦファイル）の生成処理フローについて、図２を参照して説明する。図２は、本実施形態における画像ファイルの生成処理フローを示す図である。本処理フローはユーザ操作に応じて、図１に示す各回路により実行され得る。あるいは、本処理フローは、制御部１０６が適時にＲＯＭ１０４に格納されるプログラムを実行し、情報の演算及び加工並びに各ハードウェアの制御を実行することにより実現され得る。
　Ｓ２０１において、画像ファイル生成装置１０１は、ＨＥＩＦファイルに格納する画像を取得する。具体的には、撮像部１０７により取得された画像信号は符号化部１１１によって符号化され、符号化済みの画像信号（デジタルデータ）がメタデータ処理部１１０へ入力される。なお、画像ファイル生成装置１０１は複数の画像に対応する画像信号を取得できる。例えば、撮像部１０７がバースト撮影（連続撮影）をした場合は、連続的に撮影された複数の画像が取得される。また、撮像部１０７による撮影画像が符号化部１１１によってタイルに分割されて符号化された場合は、各タイル画像が複数の画像として取得される。なお、画像をタイルに分割して符号化する方法には、ＨＥＶＣにおいて規定されているタイル符号化を用いる方法、各分割領域を個別に符号化する方法、その他の方法があり、その方法は限定しない。また、画像ファイル生成装置１０１は、撮像部１０７のみならず、他の装置から１又は複数の画像を取得することもできる。
　Ｓ２０２において、メタデータ処理部１１０は、符号化済みの画像信号のメタデータを解析する。次にＳ２０３において、メタデータ処理部１１０は、Ｓ２０１において取得された画像に対応するメタデータを取得（抽出）する。例えば、メタデータ処理部１１０が、符号化済み画像信号として、ＩＳＯＢＭＦＦ（ＩＳＯベースメディアファイルフォーマット）に準拠する画像ファイルを取得した場合について説明する。この場合、メタデータ処理部１１０は、当該画像ファイル内のアイテムプロパティボックス（ｉｐｒｐ）に格納されるプロパティ情報や、イメージプロパティアソシエーションボックスにおいてアイテムが参照するプロパティ情報を取得する。
　また、メタデータ処理部１１０は、例えば、符号化済み画像信号として、Ｅｘｉｆデータを含む画像ファイルを取得した場合、Ｅｘｉｆデータを取得する。なおＥｘｉｆデータに限らず、ＸＭＰ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍｅｔａｄａｔａ　Ｐｌａｔｆｏｒｍ）及びＭＰＥＧ－７のメタデータ等でも良い。また、例えばＥｘｉｆデータの一部がＳ２０３において取得されるようにしても良い。
　また、画像認識部１１３によって認識された画像情報をメタデータとするケースも考えられる。例えば、画像認識部１１３は、画像のシーンがどのようなシーンであるか、特定の被写体が画像に含まれているかといったことを認識し、その結果（シーンの認識結果や被写体情報）をメタデータとしてメタデータ処理部１１０へ入力されても良い。認識処理の結果に基づくメタデータも後述する共通メタデータの対象となりうる。
　Ｓ２０４において、メタデータ処理部１１０は、すでにＨＥＩＦファイルに１以上の画像が格納されているかを判定し、格納されている場合はＳ２０５へ進み、格納されていない場合はＳ２０７へ進む。Ｓ２０５において、メタデータ処理部１１０は、すでにＨＥＩＦファイルに格納されているメタデータと、今回取得した画像に対応するメタデータが一致するか、または、所定の範囲内のものかを判定する。一致、または、所定の範囲である場合はＳ２０６へ進み、メタデータ処理部１１０は、すでにＨＥＩＦファイルに格納済みのメタデータ（すなわち共通メタデータ）に、今回取得した画像のアイテムＩＤ（画像の識別情報）を対応付けて格納する。一方、メタデータ処理部１１０は、Ｓ２０４からＳ２０７に進んだ場合は、新規のＨＥＩＦファイルに、今回取得した共通メタデータとしての画像のメタデータに今回取得した画像のアイテムＩＤを対応付けて格納する。また、メタデータ処理部１１０は、Ｓ２０５からＳ２０７に進んだ場合は、生成済みのＨＥＩＦファイルに、今回取得した共通メタデータとしての画像のメタデータに今回取得した画像のアイテムを対応付けて格納する。
　なお、メタデータをすべて共通メタデータの対象とするか、一部のみとするかは任意の設定によって決定されるようにしても良い。例えば、Ｅｘｉｆデータのみが共通メタデータの対象となっても良いし、イメージプロパティアソシエーションボックス内のメタデータのみが共通メタデータの対象となっても良いし、撮影日時の情報のみが共通メタデータの対象となっても良い。
　Ｓ２０８において、メタデータ処理部１１０は、未処理画像の有無を判定する。未処理画像が存在しない場合はＳ２０９へ進み、未処理画像が存在する場合はＳ２０１へ進む。なお、Ｓ２０８の判定は、撮影条件の設定（例えばバースト撮影の枚数）や、ユーザによる画像数の設定や、その他の予め決定された条件などに基づいて行われ得る。
　Ｓ２０９において、メタデータ処理部１１０は、２以上の画像において共通ではないメタデータを、共通メタデータの格納領域から削除する。なお、本実施形態では２以上の画像において共通でないメタデータを削除することとしたが、２以外の閾値などによって削除の判定をするようにしても良い。また、場合によっては、単一の画像にのみ対応するメタデータが、共通メタデータの格納領域に格納されるようにしても良い。このような構成は、例えば、ＨＥＩＦファイルに画像が１つしか格納されない場合や、特定のメタデータが記録されている画像アイテムをすばやく取り出したいといったユースケースにおいて有効である。つまり、共通メタデータの格納領域に格納される情報は、特定のメタデータが対応付けられている画像のインデックスとして利用できる。
　次にＳ２１０において、メタデータ処理部１１０は、共通メタデータをＨＥＩＦファイルに格納する。なお、共通メタデータをＨＥＩＦファイルに格納するタイミングは、Ｓ２０６またはＳ２０７であっても良い。なお、ＨＥＩＦファイルに共通メタデータを格納することで、各画像のメタデータが不要となる場合、メタデータ処理部１１０はそのメタデータをＨＥＩＦファイルから削除する。例えばアイテムプロパティアソシエーションをグループ化した場合は、それぞれのアイテム毎のアイテムプロパティアソシエーションは不要となるため削除される。
　（ＨＥＩＦファイルのフォーマットの構成例）
　次に、画像ファイル生成装置１０１によって生成されるＨＥＩＦファイルのフォーマットの構成例を、図３を参照して説明する。図３は、ＨＥＩＦファイルのフォーマットの一例を示す。
　一般的でシンプルな形式のＨＥＩＦファイル３０１は、管理データ部３０２と、メディアデータ部３０３で構成される。管理データ部３０２には、メディアデータの符号化に関する情報や、ＨＥＩＦファイルへの格納方法に関する情報などを含んだファイル管理データが格納される。メディアデータ部３０３には、コンテンツデータ（動画像、静止画像及び音声）を符号化したデータ（メディアデータ）や外部規格を参照するメタデータ等が格納される。メディアデータ部３０３内には、ＭｅｄｉａＤａｔａＢｏｘというボックス内に、符号化された画像やＥｘｉｆデータ等が格納される。格納領域３１６、３１７、３１８は各画像の格納領域を示し、格納領域３１９、３２０、３２１はＥｘｉｆデータ等の外部規格で定義されたメタデータの格納領域を示している。
　管理データ部３０２はボックス構造となっており、各ボックスはｔｙｐｅ識別子によって識別される。ボックス３０４は、識別子ｆｔｙｐにより識別されるＦｉｌｅＴｙｐｅＢｏｘである。ＦｉｌｅＴｙｐｅＢｏｘはファイルの種類を識別するために用いられ、ファイル形式はｂｒａｎｄと呼ばれる４文字の識別子によって識別される。ＨＥＩＦファイルはｍｉｆ１やｍｓｆ１等のｂｒａｎｄを識別する４文字の識別子を用いて表される。ボックス３０５は、ＭｅｔａＢｏｘと呼ばれ、識別子ｍｅｔａにより識別される。ボックス３０５（ＭｅｔａＢｏｘ）内にはさらに様々なボックスが格納される。例えば、画像（画像アイテム）や画像（画像アイテム）に関連したメタデータアイテム等のアンタイムドなメタデータを格納するボックスが、ボックス３０５（ＭｅｔａＢｏｘ）に含まれる。ボックス３０６は、ＨａｎｄｌｅｒＲｅｆｅｒｅｎｃｅＢｏｘと呼ばれ、識別子ｈｄｌｒにより識別される。ＨａｎｄｌｅｒＲｅｆｅｒｅｎｃｅＢｏｘ内のハンドラタイプによって、ボックス３０５（ＭｅｔａＢｏｘ）に含まれるコンテンツの構造やフォーマットが識別される。ＨＥＩＦファイルにおいては、本ハンドラのタイプにｐｉｃｔという４文字の識別コードが適用される。ボックス３０７は、ＩｔｅｍＬｏｃａｔｉｏｎＢｏｘと呼ばれ、識別子ｉｌｏｃにより識別される。ボックス３０７（ＩｔｅｍＬｏｃａｔｉｏｎＢｏｘ）には各アイテムのＩＤ（各画像の識別情報）や格納場所（ロケーション）を示す情報が記述される。メタデータ処理部１１０は、この情報を参照することで、管理データ部３０２で定義されたアイテムのデータがどこに存在するかを知ることができる。ボックス３０８は、ＩｔｅｍＩｎｆｏｍａｔｉｏｎＢｏｘと呼ばれ、識別子ｉｉｎｆにより識別される。ボックス３０８（ＩｔｅｍＩｎｆｏｍａｔｉｏｎＢｏｘ）内にはアイテム毎にＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＥｎｔｒｙが定義され、このエントリー内にアイテムＩＤやアイテム種別、アイテム名称等の情報が格納される。
　ボックス３０９は、ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘと呼ばれ、識別子ｉｒｅｆにより識別される。ボックス３０９（ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ）は、参照関係のあるアイテムの関連付けに関して、どのような参照タイプであるかといった情報が格納される。１つのアイテムが複数のアイテムを参照して構成される場合は、参照するアイテムＩＤが順に記述される。例えば、アイテム１のサムネイル画像がアイテム２である場合、参照タイプとしてサムネイル画像を示すｔｈｍｂが格納され、ｆｒｏｍ＿ｉｔｅｍ＿ｉｄにはアイテム１を示すアイテムＩＤが、ｔｏ＿ｉｔｅｍ＿ｉｄにはアイテム２を示すアイテムＩＤが格納される。また、１枚の画像を複数のタイルに分割してＨＥＩＦファイルに格納する場合には、ボックス３０９（ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ）には、それらの関連を示す情報が格納される。例えば、全体画像をアイテム１とし、複数のタイル画像をアイテム２、アイテム３、アイテム４、及びアイテム５とする。この場合、アイテム１は、アイテム２、アイテム３、アイテム４、及びアイテム５によって形成される画像であることがわかる情報が格納される。具体的には、参照タイプとして派生画像を示すｄｉｍｇが格納され、ｆｒｏｍ＿ｉｔｅｍ＿ｉｄにはアイテム１を示すＩＤが格納される。さらにｔｏ＿ｉｔｅｍ＿ｉｄにはアイテム２、アイテム３、アイテム４、及びアイテム５を示すアイテムＩＤがすべて格納される。このようにすることで、タイルに分割した複数の画像アイテムを１つの画像として再構成するための情報が表される。また、ボックス３０９（ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ）は、Ｅｘｉｆデータ等の外部規格で定義されたメタデータと画像アイテムとの参照関係を記述することもできる。この場合、参照タイプとしてｃｄｓｃが用いられ、ｆｒｏｍ＿ｉｔｅｍ＿ｉｄにＥｘｉｆデータを示すアイテムＩＤが、ｔｏ＿ｉｔｅｍ＿ｉｄに画像アイテムを示すアイテムＩＤがそれぞれ格納される。
　ボックス３１０はＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘと呼ばれ、ｉｐｒｐ識別子により識別される。ボックス３１０（ＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ）には各アイテムに適用するプロパティ情報や、そのプロパティの構成方法について示すボックスが格納される。ボックス３１１は、ＩｍａｇｅＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘと呼ばれ、識別子ｉｐｃｏにより識別される。ボックス３１１内には各プロパティを記述するためのボックスが格納される。ボックス３１１（ＩｍａｇｅＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ）は様々なボックスを有しており、例えば画像のサイズを示すボックスや、カラー情報を示すボックス、ピクセル情報を示すボックス、ＨＥＶＣパラメータを格納するボックス等が必要に応じて格納される。これらファイルフォーマットは、ＩＳＯ／ＩＥＣ２３００８―１２で規定されているボックス構造と共通である。
　ボックス３１２は、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘと呼ばれ、ｉｐａｇ識別子により識別される。ボックス３１２（ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘ）は、図７で示す構造で定義される。図７は、ファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘ構造の一例を示す図である。ボックス３１２は、ＩＳＯ／ＩＥＣ２３００８―１２において規定されているＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘのエントリーで定義するアイテム毎のＩｔｅｍＰｒｏｐｅｒｔｙの関連付けをグループ化するためのボックスである。本ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘを用いることで、共通のアイテムプロパティが適用されるアイテムをグループ化できる。グループ化されたアイテム群はｉｔｅｍ＿ａｓｓｏｃｉａｔｉｏｎ＿ｇｒｏｕｐ＿ｉｄによって識別可能である。
　ボックス３１３は、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏＢｏｘと呼ばれ、ｉｐｍａ識別子により識別される。ボックス３１３は図８で示す構造で定義される。図８は、イメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏＢｏｘ構造の一例を示す図である。アイテム毎にアイテムプロパティの構成を記述する場合はｇｒｏｕｐビットを０に設定して、そのアイテムに適用されるプロパティのインデックスが順に記述される。一方で、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘを用いてグループ化されたアイテムについては、ｇｒｏｕｐビットを１に設定することで、アイテムグループに対するプロパティ構成が記述されることがわかるようにする。そしてｉｔｅｍ＿ａｓｓｏｃｉａｔｉｏｎ＿ｇｒｏｕｐ＿ＩＤにより識別されるグループに対して適用するプロパティ構成が順に記述される。こうすることで、アイテム毎にアイテム構成をすべて記述していた従来の構造から、共通のプロパティを適用するアイテムについてはグループ化して記述できるようになる。これにより、ファイルフォーマットに記述されるデータ量を削減できる。
　なお、本実施形態では図７に示すボックスを新しく定義した。しかし、ＩＳＯ／ＩＥＣ２３００８―１２において規定されているＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘを利用して、それに合わせて図８のボックスを拡張することによって、同様にグループ化して記述をする方法を採用しても良い。
　本実施形態で示した図７のボックス構造では、使用するビット数を削減できるような構造としたため、より効率的に、メタデータの画像への対応付けが可能となる。一方で、既存のＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘを利用しても、アイテムのグループ化を定義するという目的を達成することは可能である。この場合は新たにｇｒｏｕｐｉｎｇ＿ｔｙｐｅを定義することとなる。本実施形態では、アイテムプロパティに関するグループ化であるためＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ内にアイテムのグルーピングを定義する構成とした。
　以上、本実施形態では上記方法でアイテム構成を効率的に記述する方法を示したが、変形例として、図９及び図１０で示すボックス構造を採用しても良い。図９は、イメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘ構造の別の例を示す図であり、図１０は、イメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏＧｒｏｕｐＢｏｘ構造の別の例を示す図である。これはアイテムをグループ化するのではなく、画像に適用するアイテムプロパティをグループ化して記述する方法である。つまり、この方法では、アイテム毎に記載するプロパティ情報の一部がプロパティグループとして記述される。なお、図１０で示すボックス構造では記述していないが、グループ化するタイプを示す識別子を定義して格納するようにしてもよい。この際のグループタイプを示す識別子として、プロパティを結合してすべて画像に適応させることを示す‘ｊｏｉｎ’等の値を用いて識別する。詳細は記載しないが、これにより共通プロパティ以外のプロパティグループを適応可能となる。その際、ボックスタイプに示した‘ｉｐａｇ’の代わりにグループタイプの４文字コード格納するようにしてもよいし、構造体メンバのひとつとしてグループタイプを定義して格納するようにしてもよい。また本実施形態では、図１０に示すボックス構造をＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ内に定義したが、ＩＳＯ／ＩＥＣ２３００８―１２において規定されるＧｒｏｕｐＬｉｓｔＢｏｘ内に定義されるようにしても良い。これにより、ファイルフォーマットに記述する際のデータ量を削減できる。
　また、図１７に示すボックス構造をＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ内に定義される各アイテムプロパティのボックスの１つとして格納してもよい。図１７は、イメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘ構造の一例を示す図である。図１７に示すボックスは、ＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘであり、前述したＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘと同等のボックスである。本ボックスをＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ内の１つのＩｔｅｍＰｒｏｐｅｒｔｙとして格納することで、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘの構造を変更せずにアイテムプロパティをグループ化して、画像に適用することが可能となる。本ボックスではボックスタイプを示す４文字コードにグループのタイプを示す識別子を格納可能とした。これにより、どのようなグループのアイテムプロパティなのかを判別可能となる。ｎｕｍ＿ｐｒｏｐｅｒｔｉｅｓ＿ｉｎ＿ｇｒｏｕｐはグループ化するアイテムプロパティの個数を示している。またｅｓｓｅｎｔｉａｌ情報では各ｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘで示されるアイテムプロパティが必須か否かを示す。なお、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘでＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘを示すインデックス情報が格納した際のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘ内のｅｓｓｅｎｔｉａｌ情報は、アイテムグループ自体が必須か否かを示すものとなる。ｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘでは、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘと同様に、ＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ内の１から始まるインデックス順で示されるアイテムプロパティの情報が記述される。インデックス番号０はｒｅｓｅｒｖｅｄである。なお、ＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘ自身も同様のインデックス順で示されるが、本ボックス内に自信のインデックス順を示す情報を格納してはならない。もし自身のインデックが格納されていた場合は、無視するようにする。これにより無限ループすることを避けることが可能となる。なお、本ボックスはアイテムプロパティのひとつとして定義されるため、プロパティのタイプはＤｅｓｃｒｉｐｔｉｖｅタイプとなる。またｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘのリストによりグループ化される各アイテムプロパティはＤｅｓｃｒｉｐｔｉｖｅタイプとＴｒａｎｓｆｏｒｍａｔｉｖｅタイプを別々にグループ化することが望ましいがその限りではない。またその際、Ｄｅｓｃｒｉｐｔｉｖｅタイプのアイテムプロパティを記述した後にＤｅｓｃｒｉｐｔｉｖｅタイプをグループ化したＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘを記述する。その後にＴｒａｎｓｆｏｒｍａｔｉｖｅのアイテムプロパティを記述し、その後Ｔｒａｎｓｆｏｒｍａｔｉｖｅタイプのアイテムプロパティをグループ化したＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘを記述する方が望ましい。なお、ＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘのｇｒｏｕｐｉｎｇ＿ｔｙｐｅまたはｆｌａｇｓを用いてＤｅｓｃｒｉｐｔｉｖｅタイプのグループなのか、Ｔｒａｎｓｆｏｒｍａｔｉｖｅタイプのグループなのかを識別可能な構成としてもよい。
　本実施形態では、以上のボックス構造を定義することにより、画像ファイルに記述されるデータ量を削減することを可能とした。しかしながら、２以上のアイテム（画像アイテム）に適応されるメタデータ（プロパティ）をグループ化して定義する方法であれば別のボックス構造を用いてもよい。また、ボックス内のエントリーとして扱ったデータ構造を別のボックスとして定義して格納してもよい。その他のボックス構造として例えば図１６に示すボックス構造であってもよい。図１６は、イメージファイルフォーマット内のＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘ構造の別の例を示す図である。図１６に示したボックス構造によれば、複数のアイテムに対して複数のアイテムプロパティを適応可能となる。つまり明示的にアイテムプロパティやアイテムをグループ化せずに、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘの各エントリー内でアイテムをグループ化して、それに適応するプロパティを記述可能となる。
　ボックス３１４はＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘと呼ばれ、ｃｉｐｒ識別子により識別される。ボックス３１４は図１１で示す構造により定義される。図１１は、ＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ構造の一例を示す図である。ボックス３１４（ＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ）は、すべてのアイテムに共通で適用されるアイテムプロパティを示すためのボックスである。ボックス３１４を用いることによって、すべてのアイテムに共通で適用されるプロパティ（メタデータ）が容易に抽出される。すなわち、ボックス３１４を利用して共通メタデータを格納すれば、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘのエントリーをすべて検索せずに共通メタデータを抽出することが可能となる。これにより、ファイルアクセス時の検索効率が向上する。
　なお、本実施形態ではすべてのアイテムに共通で適用されるプロパティを示すボックスを定義することで、検索効率を向上する例を説明した。しかし、この例に限らず、ＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ内に定義される各アイテムプロパティのボックス内にそのようなすべてのアイテムに適用することが識別可能な情報を格納しても良い。
　ボックス３１５はＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＧｒｏｕｐＢｏｘと呼ばれ、識別子ｃｉｐｇにより識別される。ボックス３１５は図１２で示す構造により定義される。図１２は、ＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＧｒｏｕｐＢｏｘ構造の一例を示す図である。ボックス３１５（ＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＧｒｏｕｐＢｏｘ）は共通のプロパティ（メタデータ）が適用されているアイテムを識別することを可能とするボックスである。言い換えると、ボックス３１５（ＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＧｒｏｕｐＢｏｘ）は、共通のプロパティが適用されるアイテムのリストを記述するボックスである。メタデータ処理部１１０は、ボックス３１５を用いることで、特定のプロパティが適用されているアイテムを、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘのエントリーをすべて確認せずとも特定できる。また、ボックス３１５によれば、画像ファイルを読み込んで、特定のプロパティが適用されているアイテムのみをピックアップして処理を行う場合の効率が向上し、ファイルアクセス時の検索効率が向上する。また、ボックス３１５によれば、ファイルを編集する場合等において、一括操作が容易になる。例えばｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘに示すアイテムプロパティが画像サイズを示すプロパティであった場合、同じサイズの画像アイテムをグループ化して記述することが可能となる。その他にもＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ内に定義された画像プロパティが適用される複数の画像アイテムをボックス３１５によって表すことで、メタデータ処理部１１０は、共通のプロパティが適用される複数の画像を容易に特定できる。
　共通プロパティを表すボックスを格納するためのボックス３１０（ＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ）は、図１３に示す構造を有する。図１３は、ＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ（ＩｔｅｍＰｒｏｐｅｒｔｉｅｓＢｏｘ）構造の一例を示す図である。ボックス３１０（ＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘ）は、具体的には、識別子ｉｐｒｐにより識別されるＩｔｅｍＰｒｏｐｅｒｔｉｅｓＢｏｘ内にＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘを格納する。さらにＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘと、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＧｒｏｕｐＢｏｘとＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘとＣｏｍｍｏｎＩｔｅｍＰｒｏｐｅｒｔｙＧｒｏｕｐＢｏｘを格納する。
　次に、メディアデータ部３０３に格納される各格納領域（ボックス）３１９、３２０、及び３２１が示す外部定義メタデータ（例えばＥｘｉｆデータ）を共通メタデータとして格納する方法について、図１４、図１５、及び図４を用いて説明する。図１４は、図３のボックス３０９（ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ）の記述例である。図１５は、図３のボックス３０８（ＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｏｘ）の記述例である。図４は、Ｅｘｉｆデータブロック４０１、４０２、４０３、４０４、４０５を示す。図１５に示すＩｔｅｍＩｎｆｏｍａｔｉｏｎＢｏｘは９つのエントリーで構成されており、ｉｔｅｍ＿ＩＤ１、２、３、４は画像アイテムである。またｉｔｅｍ＿ＩＤが５の画像アイテムはＥｘｉｆデータブロック４０１に、ｉｔｅｍ＿ＩＤが６の画像アイテムがＥｘｉｆデータブロック４０２に、ｉｔｅｍ＿ＩＤが７の画像アイテムがＥｘｉｆデータブロック４０３、ｉｔｅｍ＿ＩＤが８の画像アイテムがＥｘｉｆデータブロック４０４、ｉｔｅｍ＿ＩＤが９の画像アイテムがＥｘｉｆデータブロック４０５にそれぞれ対応する。図１４に示すＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘは各アイテムの参照関係を示している。図１４及び図１５より、ｉｔｅｍ＿ＩＤ５はｉｔｅｍ＿ＩＤ１の画像に関するＥｘｉｆデータブロックであることが読み取れる。また同様にしてｉｔｅｍ＿ＩＤ６はｉｔｅｍ＿ＩＤ２の画像に関するＥｘｉｆデータブロックであり、ｉｔｅｍ＿ＩＤ７はｉｔｅｍ＿ＩＤ３の画像に関するＥｘｉｆデータブロックである。またｉｔｅｍ＿ＩＤ８はｉｔｅｍ＿ＩＤ４の画像に関するＥｘｉｆデータブロックである。またｉｔｅｍ＿ＩＤ９はｉｔｅｍ＿ＩＤ５、６、７、８を参照している。この記述により、ｉｔｅｍ＿ＩＤ９はｉｔｅｍ＿ＩＤ５、６、７、８のＥｘｉｆデータブロックから共通部分（共通メタデータ）を抽出したＥｘｉｆデータブロックであることを示している。
　図４に示すＥｘｉｆデータブロック４０１は、画像幅４１０、画像高４１１、Ｘ解像度４１２、Ｙ解像度４１３、メーカ名４１４、モデル名４１５、撮影日時４１６、ＩＳＯ感度４１７、ＧＰＳ情報４１８のＥｘｉｆタグ（メタデータ）を有する。Ｅｘｉｆデータブロック４０２、４０３、及び４０４も同様である。これらタグは撮像時に生成される。また別途編集処理等によってタグを追加、変更、削除が行われることもある。Ｅｘｉｆデータブロック４０５はＥｘｉｆデータブロック４０１、４０２、４０３、及び４０４の共通データ（共通メタデータ）を格納するブロックである。画像幅４１０、４２０、４３０、及び４４０により示される値はすべて「３２０ｐｉｘｅｌ」で共通のため、Ｅｘｉｆデータブロック４０５内の画像幅タグ４５０に値「３２０ｐｉｘｅｌ」が格納される。同様に、画像高４１１、４２１、４３１、及び４４１に示される値はすべて「２４０ｐｉｘｅｌ」で共通のため、Ｅｘｉｆデータブロック４０５内の画像高タグ４５１に値「２４０ｐｉｘｅｌ」が格納される。また、Ｘ解像度４１２、４２２、４３２、及び４４２により示される「９６ｄｐｉ」が領域４５２に格納される。また、Ｙ解像度４１３、４２３、４３３、及び４４３により示される「９６ｄｐｉ」が領域４５３に格納される。また、メーカ名４１４、４２４、４３４、及び４４４により示される「Ａ社」が領域４５４に格納される。また、モデル名４１５、４２５、４３５、及び４４５により示される「１１」が領域４５５に格納される。
　一方、撮影日時は画像によって異なっている。図４の例においては、（撮影）日時４１６と４２６は「２０１８年６月１３日」、日時４３６は「２０１８年６月１４日」であり、日時４４６は「２０１８年６月１５日」である。そのため、撮影日時については各Ｅｘｉｆデータブロックの共通データを抽出したＥｘｉｆデータブロック４０５には格納されない。このように、図４の例においては、すべての画像アイテムに共通するメタデータのみがＥｘｉｆデータブロック４０５に格納される。また、ＩＳＯ感度４１７、４２７、４３７、４４７についてもそれぞれ値が異なっているため、Ｅｘｉｆデータブロック４０５には格納されない。なお、図４では、日時４１６、４２６、４３６、４４６において、時刻の情報は省略されている。
　ただし、図４の例において、位置情報であるＧＰＳ情報４１８、４２８、４３８、４４８は、完全に値が一致していなくても所定範囲内に収まっていれば、Ｅｘｉｆデータブロック４０５に格納される。これは、ＧＰＳ情報４１８、４２８、４３８、及び４４８は完全に一致しないまでも特定の場所を示す情報としては一致しているためである。つまり、ＧＰＳ情報４１８、４２８、４３８、及び４４８はすべてＡ社の場所を示しており、ジオコード等で導き出される場所はすべてＡ社となり一致する。
　そのため、本実施形態のメタデータ処理部１１０は、特定の範囲内に収まる複数のＧＰＳ情報は、共通メタデータとして扱う。このように、いくつかのタイプのメタデータ（例えばＧＰＳ情報）については、値が完全に一致していなくても共通メタデータを格納するための領域に格納させることができる。なお、どの範囲をもって共通とするかについては、ユーザが別途指定しても良いし、特定のシステムの設定等に応じて適宜決められる。図４の例においては、Ａ社の敷地内のＧＰＳ情報はすべて共通のメタデータであるものとして扱われており、ＧＰＳ情報４５８に格納されるＧＰＳ情報はジオコードなどで表されるＡ社の代表地点を表している。例えば、東京都内のＧＰＳ情報を共通のＧＰＳ情報として扱う場合は、東京都の代表地点の位置情報がＧＰＳ情報４５８に格納されることになる。本実施形態のＨＥＩＦファイルはどの粒度でＧＰＳ情報を扱うかを示す情報を格納していないが、ファイル内に格納するようにしてもよい。
　また、図４は、各画像のＥｘｉｆデータブロックすべてに共通するデータを共通のＥｘｉｆデータブロックに格納する例を示している。しかしながら、２以上のＥｘｉｆデータブロックに共通するＥｘｉｆデータブロックを共通のＥｘｉｆデータブロックに格納するようにしても良い。その場合、図１４に示すＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘにおいて、参照するＥｘｉｆデータブロックを定義するようにすればよい。例えば、ｉｔｅｍ＿ｉｄ５と６のみの共通Ｅｘｉｆデータブロックを抽出する場合、ｔｏ＿ｉｔｅｍ＿ＩＤに５と６を格納する。そのようにした場合、（撮影）日時４１６、４２６についても共通のＥｘｉｆデータとなるため抽出対象に含まれる。また、共通のＥｘｉｆデータブロックとして抽出するＥｘｉｆデータブロックは複数あってもよく、ｉｔｅｍ＿ＩＤ５と６に共通するものと、ｉｔｅｍ＿ＩＤ５、６、７、及び８に共通するものというように、抽出する元データが重複してもよい。
　また、本実施形態のメタデータ処理部１１０は、各画像に対応するＥｘｉｆデータブロックにおいて共通しているデータをすべて抽出したが、ある特定のＥｘｉｆデータについてのみ、共通しているデータを抽出するようにしても良い。例えば撮影日時のみを共通しているか否かの判定対象としても良い。また、例えば、撮影日時が特定の範囲に収まる画像についてのみ、撮影日時の共通性を判定するようにしても良い。このように、特定の種類のメタデータについてのみ共通性を判断するようにしてもよく、特定の種類の決めかたにも種々のバリエーションが存在することに留意されたい。
　以上、本実施形態の画像ファイル生成装置１０１は、イメージファイルフォーマットに準拠した画像ファイル（ＨＥＩＦファイル）に格納する複数の画像のそれぞれに対応付けられたメタデータ（プロパティ情報）から共通するメタデータを抽出する。そして、画像ファイル生成装置１０１は、抽出されたメタデータを共通メタデータとしてメタデータ領域に格納する。また、画像ファイル生成装置１０１は、すべての画像に共通する共通メタデータなのか、複数の画像のうちの一部に共通する共通メタデータなのかを示す情報をＨＥＩＦファイル中に格納しても良い。一部の画像に共通する共通メタデータである場合は、当該一部の画像のアイテムＩＤ（画像の識別情報）を格納する。また、画像ファイル生成装置１０１は、外部規格に基づくメタデータ（例えばＥｘｉｆデータ）についても、画像毎のメタデータから共通のメタデータを抽出し、それを共通メタデータとして保持する。これにより、ＨＥＩＦファイルに格納された複数の画像を扱う際の処理負荷が低減できる。例えば、ＨＥＩＦファイルに格納された複数の画像のうち、特定のメタデータに対応付けられた１以上の画像に対してだけ特定の処理を行う場合において処理負荷を低減できる。また、ＨＥＩＦファイルに格納された複数の画像の中から特定の画像を検索する処理が低負荷で行えるようになる。また、画像ごとのメタデータを共通化して格納することにより、画像ファイルのサイズを低減できる。
　＜第２実施形態＞
　第１実施形態では、画像ファイル生成時に共通のメタデータを抽出して画像ファイル内に格納する例を中心に説明した。以下に示す第２実施形態では、画像ファイルに格納済みの画像やメタデータから共通するメタデータを抽出する例を詳細に説明する。
　（画像ファイル生成装置５０１の構成）
　本実施形態の画像ファイル生成装置５０１の構成を図５に示す。図５の画像ファイル生成装置５０１は、タブレットＰＣやデスクトップＰＣ、クラウド等のＷｅｂサービスで処理を行うサーバ装置等の、ファイル編集機能を有した通信装置である。図１と同じ参照番号の構成要素は、図１と同様のため、説明を省略する。メタデータ処理部５０２は、画像ファイルを編集し、画像ファイルに格納済みの画像やメタデータから共通するメタデータを抽出するための処理を行う。なお、本実施形態における画像ファイル生成装置５０１は、画像ファイルの編集に特徴があるため、撮像部１０７を有さない構成としてもよい。
　（処理の流れ）
　次に、イメージファイルフォーマットに準拠した画像ファイル（ＨＥＩＦファイル）のから共通メタデータを抽出する処理（編集処理）のフローについて、図６を参照して説明する。図６は、第２実施形態における画像ファイル生成装置５０１の処理フローを示す図である。本処理フローは、ユーザ操作に応じて、図５に示す各回路により実行され得る。あるいは、本処理フローは、制御部１０６が適時にＲＯＭ１０４に格納されるプログラムを実行し、情報の演算及び加工並びに各ハードウェアの制御を実行することにより実現され得る。なお、１つ以上のイメージファイルフォーマットに準拠した画像ファイル（ＨＥＩＦファイル）が、予め画像ファイル生成装置５０１に格納されているものとする。
　Ｓ６０１において、メタデータ処理部５０２は、ＨＥＩＦファイルに格納された複数の画像のそれぞれに対応付けられたメタデータに基づいて、メタデータの値、範囲、種別といった、抽出対象とするメタデータに関する情報（抽出対象メタデータ）を決定する。この決定は、操作部１０８を介したユーザ指定に基づいて行われるようにしても良いし、あらかじめ決められたシステム設定などに基づいて行われるようにしても良い。また、複数の決定が行われるようにしても良い。
　Ｓ６０２において、メタデータ処理部５０２は、ＨＥＩＦファイルに格納された複数の画像のそれぞれのメタデータを取得する。メタデータ処理部５０２は、１つのＨＥＩＦファイルに限らず、複数のＨＥＩＦファイルを処理対象としても良い。また、ＨＥＩＦファイルに限らず、ＪＰＥＧファイルなども処理対象としても良い。また、メタデータ処理部５０２は、ＨＥＩＦファイルに記録済みのメタデータのみを取得対象としてもよいし、画像認識部５０６の処理によって新規に生成されたメタデータ等を取得対象としても良い。
　次にＳ６０３において、メタデータ処理部５０２は、Ｓ６０２において取得されたメタデータとＳ６０１において決定された抽出対象メタデータが一致するかを判定する。一致する場合はＳ６０４へ進み、一致しない場合Ｓ６０５へ進む。なお、Ｓ６０３では、メタデータ処理部５０２が両メタデータの範囲が所定の範囲内か否かを判定し、所定の範囲内の場合にＳ６０４へ進み、所定の範囲内でない場合にＳ６０５へ進むようにしても良い。
　Ｓ６０４において、メタデータ処理部５０２は、一致するメタデータを共通メタデータとして抽出し、当該共通メタデータに、画像を識別するためのアイテムＩＤを対応付けて共通メタデータの格納領域に格納する。複数の画像ファイルを処理対象としている場合には、メタデータ処理部５０２は新規にＨＥＩＦファイルを作成し、当該ファイルに画像アイテムとそれに対応するアイテムＩＤを格納する。Ｓ６０５において、メタデータ処理部５０２は、メタデータの取得対象となるすべての画像について処理が完了したか判定する。完了した場合はＳ６０６に進み、完了していない場合はＳ６０２に進み、処理が繰り返される。
　Ｓ６０６において、メタデータ処理部５０２は、抽出した共通メタデータのうち、他の画像と共通しないメタデータを削除する。つまり、メタデータ処理部５０２は、単一の画像にのみ適用されるメタデータを、共通メタデータとして格納しない。次にＳ６０７において、メタデータ処理部５０２は、共通メタデータをＨＥＩＦファイルに格納する。このとき、メタデータ処理部５０２は、共通メタデータとその画像のアイテムＩＤを基に、図７から図１７に示したフォーマットに従って、ＨＥＩＦファイル内に共通メタデータを格納する。本実施形態では単一の画像のみに対応するメタデータは共通メタデータとして格納しないこととしたが、所定の閾値よりも少ない数の画像のみに共通しているメタデータは共通メタデータとして格納しないようにしても良い。また、場合によっては、単一の画像にのみ対応するメタデータが、共通メタデータを格納するための領域に格納されるようにしても良い。このような構成は、例えば、ＨＥＩＦファイルに画像が１つしか格納されない場合や、特定のメタデータが記録されている画像アイテムをすばやく取り出したいといったユースケースにおいて有効である。つまり、共通メタデータの格納領域に格納される情報は、特定のメタデータが対応付けられている画像のインデックスとして利用できる。
　以上、本実施形態の画像ファイル生成装置５０１は、生成済みの画像ファイルから共通メタデータを抽出し、当該共通メタデータが格納されたＨＥＩＦファイルを新規に生成する。これにより共通メタデータとして記録していない画像ファイルから共通のメタデータを格納した画像ファイルを生成できる。また本実施形態の画像ファイル生成装置５０１は、複数の画像ファイル（ビデオファイルも含む）に格納される複数の画像（ビデオも含む）から共通のメタデータを抽出し、共通メタデータを格納した画像ファイルを新規に生成する。
　これにより、複数の装置で生成された画像ファイルや、異なる条件下で生成された画像ファイルから編集処理によって１つのＨＥＩＦファイルを生成することが可能となる。その際、第１実施形態で説明したように、すべての画像群に共通する共通メタデータなのか、画像群のうちの一部に共通する共通メタデータなのかを示す情報を格納しても良い。一部に共通する共通メタデータである場合は、当該共通メタデータに対応する画像のアイテムＩＤがさらに格納される。また、画像ファイル生成装置１０１は、外部規格に基づくメタデータ（例えばＥｘｉｆデータ）についても、画像毎のメタデータから共通のメタデータを抽出し、それを共通メタデータとして保持する。これにより、ＨＥＩＦファイルに格納された複数の画像を扱う際の処理負荷が低減できる。例えば、ＨＥＩＦファイルに格納された複数の画像のうち、特定のメタデータに対応付けられた１以上の画像に対してだけ特定の処理を行う場合において処理負荷を低減できる。また、ＨＥＩＦファイルに格納された複数の画像の中から特定の画像を検索する処理が低負荷で行えるようになる。また、画像ごとのメタデータを共通化して格納することにより、画像ファイルのサイズを低減できる。
　＜第３実施形態＞
　第１実施形態及び第２実施形態では、共通のメタデータを抽出して画像ファイル内に格納する例を中心に説明した。以下に示す第３実施形態では、同種のメタデータをグループ化して、同一の画像に適応させて格納する例を説明する。本実施形態の画像ファイル生成装置は、撮影機能を有した装置の場合、図１に示した構成となる。また画像ファイルに格納済みの画像やメタデータに同種のメタデータを追加して格納する場合、図５に示した構成となる。
　（処理の流れ）
　次にイメージファイルフォーマットに準拠した画像ファイル（ＨＥＩＦファイル）への同種メタデータの付加処理フローについて、図１８Ａと図１８Ｂを参照して説明する。図１８Ａと図１８Ｂは、本実施形態における画像ファイルの生成処理フローを示す図である。本処理フローは、典型的には、ユーザからの編集指示の入力に応じて開始される。なお、説明のため、本処理フローは、図５に示した画像ファイル生成装置５０１により行われるものとする。例えば、本処理フローは、ユーザ操作により、図５に示す各回路により、あるいは、制御部１０６が適時にＲＯＭ１０４に格納されるプログラムを実行し、情報の演算及び加工並びに各ハードウェアの制御を実行することにより実現され得る。なお、１つ以上のイメージファイルフォーマットに準拠した画像ファイル（ＨＥＩＦファイル）が、予め画像ファイル生成装置５０１に格納されているものとする。また、付加されるメタデータ（後述の付加対象メタデータ）に適応し得る画像が予めＨＥＩＦファイルに存在するものとする。
　Ｓ１８０１においてメタデータ処理部５０２は、ＨＥＩＦファイルに格納するメタデータ（付加対象メタデータ）を取得する。メタデータ処理部５０２は、操作部１０８を介したユーザ指定に基づいて付加対象メタデータを取得しても良いし、あらかじめ決められたシステム設定などに基づいてメタデータを取得しても良い。
　Ｓ１８０２においてメタデータ処理部５０２は、ＨＥＩＦファイルに格納された１つ以上のメタデータを取得し、それぞれのメタデータの種別を取得する。メタデータの種別の詳細については、後述する。次にＳ１８０３において、メタデータ処理部５０２は、ＨＥＩＦファイル内に、Ｓ１８０１で取得された付加対象メタデータと同種のメタデータが存在するかを判定する。すなわち、メタデータ処理部５０２は、Ｓ１８０２において取得された１つ以上のメタデータの種別のうち、Ｓ１８０１で取得した付加対象メタデータの種別と一致するものが存在するか判定する。存在する場合はＳ１８０４へ進み、存在しない場合Ｓ１８０５へ進む。なお、当該判定は、画像ファイル生成装置５０２に予め格納されている辞書等の知識ベース等に基づいて行われ得る。また、メタデータの種別に替えて、メタデータの性質や属性といった他の情報が比較されても良い。
　Ｓ１８０４において、メタデータ処理部５０２は、付加対象メタデータを適応する画像（付加対象メタデータが適用される画像）に、Ｓ１８０３で存在すると判定された同種のメタデータが適応（適用）されているかを確認する。適応されている場合はＳ１８０７へ進み、適応されていない場合はＳ１８０５へ進む。なお、付加対象メタデータを適応する画像が複数存在する場合は、メタデータ処理部５０２は、それぞれの画像に対して確認を行い、いずれか一つでも適応されている場合はＳ１８０７へ進む。
　Ｓ１８０５において、メタデータ処理部５０２は、付加対象メタデータの情報をＨＥＩＦファイルに格納する。これは主に、ＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘの要素にＩｔｅｍＰｒｏｐｅｒｔｙとして格納することに対応する。次にＳ１８０６において、メタデータ処理部５０２は、格納された付加対象メタデータと画像（付加対象メタデータに適応する画像）の関連づけ情報を格納して処理を終了する。これは主にＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘ内の画像アイテム毎の関連付け情報の格納に対応する。詳細には、メタデータ処理部５０２は、アイテムプロパティのＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘのインデックス順を各アイテムＩＤの関連づけとして格納する。
　Ｓ１８０４でＹｅｓの場合のＳ１８０７において、メタデータ処理部５０２は、同一の画像に適応される同種のメタデータがすでにグループ化されているかを確認する。同種のメタデータがグループ化されている場合はＳ１８０６へ進み。グループ化されていない場合はＳ１８１０へ進む。なお、同種のメタデータであっても選択的に適応されず、異なる意味で適応されている場合は同種のメタデータであるとみなさず、Ｓ１８１０へ進む。
　Ｓ１８０８において、メタデータ処理部５０２は、Ｓ１８０５と同様に付加対象メタデータの情報をＨＥＩＦファイルに格納する。Ｓ１８０９において、メタデータ処理部５０２は、すでにグループ化されているメタデータグループに、Ｓ１８０８で格納された付加対象メタデータの情報を追加して、処理を終了する。これにより、すでに画像アイテムへＩｔｅｍＡｓｓｏｃｉａｔｉｏｎＢｏｘで関連付けられているアイテムプロパティのグループ内の選択肢が追加されることとなる。
　Ｓ１８０７でＹｅｓの場合のＳ１８１０において、メタデータ処理部５０２は、Ｓ１８０５やＳ１８０８同様に、付加対象メタデータの情報をＨＥＩＦファイルに格納する。Ｓ１８１１において、メタデータ処理部５０２は、同一の画像に適応されるメタデータを同種のメタデータをしてグループ化するための情報を格納する。すなわち、メタデータ処理部５０２は、付加対象メタデータが適応される画像に適応されるメタデータと、付加対象メタデータとを、同種のメタデータとしてグループ化するための情報を格納する。Ｓ１８１２において、メタデータ処理部５０２は、すでに格納されていた同種のメタデータと画像アイテムを関連付ける情報を削除する。具体的には、ＩｔｅｍＡｓｓｏｃｉａｔｉｏｎＢｏｘ内のアイテムプロパティにおいて該当するインデックス情報を削除することに対応する。Ｓ１８１３において、メタデータ処理部５０２は、グループ化されたメタデータを画像アイテムに関連付ける情報を格納する。具体的には、ＩｔｅｍＡｓｓｏｃｉａｔｉｏｎＢｏｘにアイテムプロパティグループを示す関連付け情報を格納することに対応する。
　以上により、画像に適応されるプロパティ（メタデータ）を、複数のプロパティの中から選択的に適応させる（画像に関連するプロパティとして、複数のプロパティの中から選択的に対応付ける）ことが可能となる。なお、本実施形態では、画像ファイルに格納済みの画像やメタデータに同種のメタデータを追加して格納するフローを説明したが、図２に示したフローで画像ファイルの生成処理の際に同種のプロパティをグループ化して格納する形態であってもよい。その際、Ｓ２０１のイメージファイルフォーマットに格納する画像を入力した際に、関連するメタデータを格納する際に、同種のメタデータグループ情報を格納する。また、本実施形態では上記ボックス構造でプロパティのグループ化を示したが、本目的を達成可能なボックス構造であればよい。
　（アイテムプロパティグループボックスの構成例）
　次に、アイテムプロパティグループとしてアイテムプロパティ（メタデータ）格納する際の、画像へ適応例を図１９、図２０、図２１を用いて説明する。図１９は、ＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘ構造の一例を示す図であり、図２０と図２１は、ＩｔｅｍＰｒｏｐｅｒｔｙＢｏｘの例を示す。
　図１９に示したボックスはＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘである。このボックスはＨＴＭＬ仕様の代替テキスト文字列の情報を格納するボックスである。本ボックスに格納されるａｌｔ＿ｔｅｘｔはＨＴＭＬ仕様の代替テキストを格納するパラメータである。またａｌｔ＿ｌａｎｇはＲＦＣ４６４６やＢＣＰ４７準拠の言語タグの文字列でたとえば‘ｅｎ－ＵＳ’や‘ｆｒ－ＦＲ’、‘ｚｈ－ＣＮ’、‘ｊａ－ＪＰ’等の言語を示す識別子が格納される。ａｌｔ＿ｌａｎｇに示される言語のテキスト情報がａｌｔ＿ｔｅｘｔに格納される。本ボックスを用いることで、画像アイテムがどのような内容の画像であるか等のテキスト情報を格納することができる。また本ボックスを格納したい言語毎にアイテムプロパティとして格納することで、言語に対応したテキスト情報を格納することが可能となる。なお、本実施形態ではＨＴＭＬ仕様の代替テキストを格納することとしたが、ＨＴＭＬ仕様に限らずテキスト情報を格納するようにしてもよい。
　図２０に示したＩｔｅｍＰｒｏｐｅｒｔｉｅｓＢｏｘは、画像ファイルに格納されるアイテムプロパティの画像への適応例を示した図である。本画像ファイルは４つのサブピクチャがアイテムＩＤ１から４として格納されており、それをグリッドの派生イメージとして構成する１つの画像アイテムがアイテムＩＤ５として構成されている。４つのサブピクチャは画像サイズが幅５１２、高さ５１２の画像であり、その派生イメージである１つの画像は幅１０２４、高さ１０２４の画像が格納されている。４つのサブピクチャには共通のプロパティが適応されており、１つの派生画像にはその画像が何であるかを示すテキスト情報が格納されている（インデックス１～６）。
　具体的には、ＩｔｅｍＰｒｏｐｅｒｔｉｅｓＢｏｘ内にはＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ及び、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘが格納されている。また、ＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘには６個の各種アイテムプロパティが格納されている。
　１番目のＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘは、識別子ｈｖｃＣで示されるボックスであり、画像アイテムの符号化パラメータが格納されている。２番目のＩｍａｇｅＳｐａｔｉａｌＥｘｔｅｎｔｓＰｒｏｐｅｒｔｙＢｏｘは、識別子ｉｓｐｅで示されるＢｏｘであり、画像のサイズを示す情報が格納されている。
　３番目～５番目のＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘは図１９に示した構造を持つボックスであり、‘ａｌｔｔ’で識別される。３番目のＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘには、ａｌｔ＿ｌａｎｇにｅｎ－ＵＳが格納されており、アメリカ地域の英語を示している。また、ａｌｔ＿ｔｅｘｔには、英語のテキスト文字列‘ｄｏｇ’が格納されている。同様にして、４番目のＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘには、ａｌｔ＿ｌａｎｇにｊａ－ＪＰが格納されており、日本地域の日本語を示している。また、ａｌｔ＿ｌａｎｇには、日本語のテキスト文字列‘犬’が格納されている。同様にして、５番目のＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘには、ａｌｔ＿ｌａｎｇにｆｒ－ＦＲが格納されており、フランス地域のフランス語を示している。またａｌｔ＿ｔｅｘｔには、フランス語のテキスト文字列‘ｃｈｉｅｎ’が格納されている。これら３つのＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘは、いずれも同じ意味のテキスト文字列がそれぞれの言語で格納されている。すなわち、同一の画像に関連するテキスト情報の意味としての種別が同じである。なお、上述のように、画像ファイル生成装置５０１（または１０１）において、予め学習データや辞書等の知識ベースが格納されており、メタデータの種別が同一か否かを判定できるものとする。
　６番目のＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘは、図１７に示すように識別子ｉｐｍａで示されるボックスである。本ボックスを用いて、ＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘのインデックス順３、４、５番目のＡｃｃｅｓｓｉｂｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘが同種のアイテムプロパティとしてグループ化されている。具体的には、ａｌｔｒのグルーピングタイプを用いて、同種のアイテムプロパティとしてアイテムプロパティがグループ化されている。また、ｎｕｍ＿ｐｒｏｐｅｒｔｉｅｓ＿ｉｎ＿ｇｒｏｕｐは３を示しており、これは、３つのアイテムプロパティがグループ化されていることを示している。また、ｅｓｓｅｎｔｉａｌ情報は必須のアイテムプロパティであることを示している（１＝必須）。また、ＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘのインデックス順であるｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘが３、４、５を示しており、前述したＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘをグループ化している。このように、３つのＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘは、ＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘを用いてグループ化され、ＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘを用いてアイテムにグループとして適応させることができる。
　次に、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘは識別子ｉｐｍａで示されるボックスであり、各画像アイテムとアイテムプロパティの関連を示す情報が格納されている。ｅｎｔｒｙ＿ｃｏｕｎｔは１を示しており、１つの画像のアイテムプロパティの関連が格納されていることを示している。ｉｔｅｍ＿ＩＤが１である画像は３つのアイテムプロパティに関連づけられていることをａｓｓｏｃｉａｔｉｏｎ＿ｃｏｕｎｔで示している。ｅｓｓｅｎｔｉａｌは１を示し必須のプロパティであることを示す。また、ｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘの１はＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘのインデックス順１である、前述したＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘが関連付けられていることを示している。次に、２つ目のエントリーはｅｓｓｅｎｔｉａｌが０を示しており、必須ではないプロパティであることを示している。ｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘの２は前述したＩｍａｇｅＳｐａｔｉａｌＥｘｔｅｎｔｓＰｒｏｐｅｒｔｙＢｏｘが関連付けられていることを示している。次に、３つ目のエントリーはｅｓｓｅｎｔｉａｌが０を示しており、必須ではないプロパティであることを示している。ｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘは６を示しており、ＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘが関連付けられている。これにより、画像ファイルを読み出す装置は、ＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘがグループタイプａｌｔｒで適応されている画像アイテムを参照する際には、３つのＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘのうち１つを選択することで参照することができる。
　なお、本実施形態ではａｌｔｒでグループ化されたアイテムプロパティのうちいずれか１つが選択的に画像アイテムに適応される構成としたが、選択的に複数のプロパティが適応されてもよい。また、本実施形態では明示的にＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘを用いてアイテムプロパティをグループ化して画像アイテムに適応させる構成としたが、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘに同種のアイテムプロパティが適応されていた場合は、暗黙的に選択的に画像アイテムに適応させる構成としてもよい。また代替テキスト情報に限らず、関連するテキストをラベルとして格納するようにしてもよい。その場合意味毎にグループ化したテキスト情報を複数適応し、そのグループ毎にラベル情報を選択的に適応することも可能である。図２０ではＤｅｓｃｒｉｐｔｉｖｅタイプのみ記述しているが、Ｔｒａｎｓｆｏｍａｔｉｖｅタイプのアイテムプロパティも同様にグループ化可能である。その際、ＤｅｓｃｒｉｐｔｉｖｅタイプとＴｒａｎｓｆｏｒｍａｔｉｖｅタイプのプロパティは混在せずにグループ化することが望ましい。またその際、ｆｌａｇｓを用いてグループ化するプロパティのタイプがなんであるかを示すようにしてもよいし、ｇｒｏｕｐｉｎｇ＿ｔｙｐｅを用いてグループタイプを識別可能なように定義してもよい。またＤｅｓｃｒｉｐｔｉｖｅタイプのプロパティを記述した後にＤｅｓｃｒｉｐｔｉｖｅタイプのグループを記述することで、あらかじめ記述されたインデックス番号を記述可能である。またその後にＴｒａｎｓｆｏｒｍａｔｉｖｅタイプのアイテムプロパティを記述する。その後同様にＴｒａｎｓｆｏｒｍａｔｉｖｅタイプのアイテムプロパティをグループ化したＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘを記述する方が望ましい。これにより、アイテムプロパティを適応する際の制約条件を変更することなく適応可能となる。
　本実施形態のように明示的にグループ化して画像アイテムに適応させることにより、異なるグループタイプのグループ化が可能となるだけでなく、同種ではあるが意味が異なるプロパティを複数グループ化して画像アイテムに適応させることが可能となる。これにより、異なる意味で適応された同種のアイテムプロパティを、グループ毎に選択的に画像アイテムに適応させることができる。
　次に、図２１を用いて、同種のアイテムプロパティと共通のアイテムプロパティのそれぞれのアイテムグループを適応した画像ファイルのＩｔｅｍＰｒｏｐｅｒｔｉｅｓＢｏｘの例を示す。
　ＩｔｅｍＰｒｏｐｅｒｔｉｅｓＢｏｘ内にはＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘ及び、ＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘが格納されている。またＩｔｅｍＰｒｏｐｅｒｔｙＣｏｎｔａｉｎｅｒＢｏｘには９個の各種アイテムプロパティが格納されている。１番目のＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘは、識別子ｈｖｃＣで示されるボックスであり、画像アイテムの符号化パラメータが格納されている。２番目のＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘには、異なる符号化パラメータが格納されている。３番目と４番目のＩｍａｇｅＳｐａｔｉａｌＥｘｔｅｎｔｓＰｒｏｐｅｒｔｙＢｏｘは識別子ｉｓｐｅで示されるＢｏｘであり、画像のサイズを示す情報が格納されている。２つのＩｍａｇｅＳｐａｔｉａｌＥｘｔｅｎｔｓＰｒｏｐｅｒｔｙＢｏｘには、それぞれ異なる画像サイズの情報が格納されている。
　５番目から７番目のＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘは、図１９に示した構造を持つボックスであり、‘ａｌｔｔ’で識別される。３つのＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘには、それぞれ異なる言語のテキストが格納されている。グループタイプ‘ａｌｔｒ’で識別されてＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘは、３つのアイテムプロパティをグループ化している。本実施形態ではインデックス順５、６、７のＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙが同種のプロパティとしてグループ化されている。またグループタイプ‘ｊｏｉｎ’で示されるＩｔｅｍＰｒｏｐｅｒｔｙＴｏＧｒｏｕｐＰｒｏｐｅｒｔｙＢｏｘは２つのアイテムプロパティがグループ化されている。本実施形態ではインデックス順１のＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘとインデックス順３のＩｍａｇｅＳｐａｔｉａｌＥｘｔｅｎｔｓＰｒｏｐｅｒｔｙＢｏｘが共通アイテムプロパティとしてグループ化されている。次にＩｔｅｍＰｒｏｐｅｒｔｙＡｓｓｏｃｉａｔｉｏｎＢｏｘには５つのアイテムのプロパティ関連情報が格納されている。ｉｔｅｍ＿ＩＤが１から４のアイテムはインデックス順９番目の‘ｊｏｉｎ’タイプのアイテムグループが適応されており、インデックス順１番目と３番目のアイテムプロパティがすべて共通に適応される。またアイテムＩＤが５のアイテムはインデックス順２、４、８のアイテムプロパティが適応されている。インデックス順８番目のアイテムプロパティはａｌｔｒタイプのアイテムプロパティグループでインデックス順５、６、７番目のアイテムプロパティが選択的に適応される。
　本実施形態では同種のアイテムプロパティとしてＡｃｃｅｓｓｉｂｉｌｉｔｙＴｅｘｔＰｒｏｐｅｒｔｙＢｏｘを定義して説明したが、その他異なるアイテムプロパティが選択的に適応可能であってもよい。例えば、同一のアイテムプロパティが複数のバージョンを持つ場合、異なるバージョンそれぞれを同種のプロパティとして格納しておき、読み出し装置が対応しているバージョンのボックスとして適応してもよい。またその他‘ｃｌａｐ’で識別されるＣｌｅａｎＡｐｅｒｔｕｒｅＢｏｘを同種のプロパティとして複数適応し、読み出し装置の選択により、１６：９や４：３での切り出しを可能とすることが可能である。またその他、複数人の特定の人物ごとのＣｌｅａｎＡｐｅｒｔｕｒｅＢｏｘを定義し、読み出し装置が選択的に特定の人物のみを表示するといったことが可能となる。またその他にもさまざまな拡張が考えられる。
　以上、本実施形態の画像ファイル生成装置１０１または５０１は、イメージファイルフォーマットに準拠した画像ファイル（ＨＥＩＦファイル）に格納する画像に関連する複数のメタデータ（プロパティ情報）のうち共通または同種のメタデータを抽出する。そして抽出したメタデータをグループ化してメタデータ領域に格納する。その際グループ化した種別を判定可能な識別子を格納する。グループ化したメタデータを他のグループ化していないメタデータ同様にして画像に関連付けて画像ファイルに保持する。これにより、ＨＥＩＦファイルに格納された複数のメタデータ（プロパティ情報）をグループとして扱うことが可能となり、画像を扱う際の処理負荷の低減や、選択的なメタデータの適応ができる。選択的な適応により、画像ファイルを読み出す装置の状況や条件、判断に基づいて適応的に画像を扱うことが可能となる。また、画像ごとのメタデータを共通化して格納することにより、画像ファイルのサイズを低減できる。
　このように、上記にのべた各実施形態によれば、所定のファイルフォーマットに応じた画像ファイル内に格納される複数の画像のうち２以上の画像が共通のメタデータに対応する場合において、その画像ファイルに関する処理を効率的に行うことができる。また、所定のファイルフォーマットに応じた画像ファイル内に格納される複数のメタデータのうち２以上の同種のメタデータを１つの画像に適応させる場合において、その画像ファイルにメタデータの選択的な適応を行うことができる。
（その他の実施例）　
　本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
　本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。
　本願は、２０１８年１２月１８日提出の日本国特許出願特願２０１８－２３６７２２を基礎として優先権を主張するものであり、その記載内容の全てを、ここに援用する。

 

Claims (11)

  1. 　１つ以上の画像を所定のイメージファイルフォーマットに従った画像ファイルに格納するための画像ファイル生成装置であって、
    　前記画像ファイルに格納する複数のメタデータを取得する取得手段と、
    　前記複数のメタデータのうち、メタデータの種別に応じてグループ化するグループ化手段と、
    　前記グループ化されたメタデータを前記画像ファイルに格納する格納手段と、
    を有することを特徴とする画像ファイル生成装置。
  2. 　前記グループ化手段は、同一の画像に適応される、同じ種別を有するメタデータをグループ化し、前記格納手段は、前記グループ化されたメタデータを前記同一の画像に対応付けて前記画像ファイルに格納することを特徴とする請求項１に記載の画像ファイル生成装置。
  3. 　前記グループ化手段は、前記同一の画像に関連するテキスト情報の意味としての種別が同じメタデータをグループ化することを特徴とする請求項２に記載の画像ファイル生成装置。
  4. 　前記グループ化手段は、前記テキスト情報の意味が同じで異なる言語で表された複数のメタデータをグループ化することを特徴とする請求項３に記載の画像ファイル生成装置。
  5. 　前記グループ化手段は、２つ以上の画像に共通の種別を有するメタデータをグループ化し、前記格納手段は、前記グループ化されたメタデータを前記２つ以上の画像に対応付けて前記画像ファイルに格納することを特徴とする請求項１から４のいずれか１項に記載の画像ファイル生成装置。
  6. 　前記取得手段は、ユーザによる入力により、または、あらかじめ決められた設定に基づいて、前記複数のメタデータを取得することを特徴とする請求項１から５のいずれか１項に記載の画像ファイル生成装置。
  7. 　前記画像ファイルを外部へ出力する出力手段を更に有することを特徴とする請求項１から６のいずれか１項に記載の画像ファイル生成装置。
  8. 　前記所定のイメージファイルフォーマットは、ＩＳＯ／ＩＥＣ２３００８―１２において規定されるフォーマットであることを特徴とする請求項１から７のいずれか１項に記載の画像ファイル生成装置。
  9. 　前記取得手段は、前記メタデータとして、ＩＳＯベースメディアファイルフォーマットに準拠する画像ファイルのメタデータを取得し、
    　前記グループ化手段は、前記ＩＳＯベースメディアファイルフォーマットに準拠する前記画像ファイルから、アイテムプロパティボックスに格納されるプロパティ情報を抽出し、当該抽出の結果に基づいてグループ化を行うことを特徴とする請求項８に記載の画像ファイル生成装置。
  10. 　１つ以上の画像を所定のイメージファイルフォーマットに従った画像ファイルに格納するための画像ファイル生成方法であって、
    　前記画像ファイルに格納する複数のメタデータを取得する取得工程と、
    　前記複数のメタデータのうち、メタデータの種別に応じてグループ化するグループ化工程と
    　前記グループ化されたメタデータを前記画像ファイルに格納する格納工程と、
    を有することを特徴とする画像ファイル生成方法。
  11. 　コンピュータを、請求項１から９のいずれか１項に記載の画像ファイル生成装置として機能させるためのプログラム。
     
PCT/JP2019/043118 2018-12-18 2019-11-01 画像ファイル生成装置、画像ファイル生成方法、及びプログラム WO2020129434A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/345,004 US20210303616A1 (en) 2018-12-18 2021-06-11 Image file generation apparatus, image file generation method, and computer-readable storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018236722A JP7303625B2 (ja) 2018-12-18 2018-12-18 画像ファイル生成装置、画像ファイル生成方法、及びプログラム
JP2018-236722 2018-12-18

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/345,004 Continuation US20210303616A1 (en) 2018-12-18 2021-06-11 Image file generation apparatus, image file generation method, and computer-readable storage medium

Publications (1)

Publication Number Publication Date
WO2020129434A1 true WO2020129434A1 (ja) 2020-06-25

Family

ID=71101261

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/043118 WO2020129434A1 (ja) 2018-12-18 2019-11-01 画像ファイル生成装置、画像ファイル生成方法、及びプログラム

Country Status (3)

Country Link
US (1) US20210303616A1 (ja)
JP (2) JP7303625B2 (ja)
WO (1) WO2020129434A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112667114A (zh) * 2020-12-21 2021-04-16 北京小早科技有限公司 一种信息处理方法、装置以及计算机存储介质
CN114727001A (zh) * 2021-01-05 2022-07-08 北京小米移动软件有限公司 一种处理图像数据的方法、装置及介质

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7501372B2 (ja) * 2018-12-28 2024-06-18 ソニーグループ株式会社 情報処理装置および情報処理方法
WO2021020142A1 (ja) * 2019-07-30 2021-02-04 ソニー株式会社 ファイル処理装置、ファイル処理方法、及び、プログラム
KR102595278B1 (ko) * 2020-12-29 2023-10-27 부산대학교 산학협력단 표면결함검출 스캐너를 위한 이미지 데이터 저장 장치 및 방법

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005038006A (ja) * 2003-07-15 2005-02-10 Fujitsu Ltd 情報共有装置および情報共有処理プログラム
JP2007013939A (ja) * 2005-05-30 2007-01-18 Matsushita Electric Ind Co Ltd メタデータ付与装置及びメタデータ付与方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4072302B2 (ja) 1999-04-13 2008-04-09 キヤノン株式会社 データ処理方法及び装置及び記憶媒体
US7197158B2 (en) 2002-06-28 2007-03-27 Microsoft Corporation Generation of metadata for acquired images
JP5121285B2 (ja) 2007-04-04 2013-01-16 キヤノン株式会社 被写体メタデータ管理システム
KR20090088772A (ko) * 2008-02-15 2009-08-20 삼성전자주식회사 슬라이드 쇼를 위한 영상파일을 생성 및 재생하기 위한시스템 및 방법
JP2010176429A (ja) 2009-01-29 2010-08-12 Dainippon Printing Co Ltd 電子コンテンツ配信システム
JP5381437B2 (ja) 2009-07-14 2014-01-08 富士ゼロックス株式会社 画像情報送信装置及び画像情報送信プログラム
US10291561B2 (en) * 2015-02-09 2019-05-14 Nokia Technologies Oy Apparatus, a method and a computer program for image coding and decoding
US9922680B2 (en) * 2015-02-10 2018-03-20 Nokia Technologies Oy Method, an apparatus and a computer program product for processing image sequence tracks
GB201502205D0 (en) 2015-02-10 2015-03-25 Canon Kabushiki Kaisha And Telecom Paris Tech Image data encapsulation
GB2539461B (en) 2015-06-16 2020-01-08 Canon Kk Image data encapsulation
EP3107011B1 (en) * 2015-06-16 2018-12-12 Nokia Technologies Oy Method, apparatus, and computer program product for storage of dynamically derived images in an image container file
JP6848358B2 (ja) 2016-05-12 2021-03-24 株式会社リコー 情報処理システム、情報処理装置、プログラム及び画面生成方法
JP7501372B2 (ja) * 2018-12-28 2024-06-18 ソニーグループ株式会社 情報処理装置および情報処理方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005038006A (ja) * 2003-07-15 2005-02-10 Fujitsu Ltd 情報共有装置および情報共有処理プログラム
JP2007013939A (ja) * 2005-05-30 2007-01-18 Matsushita Electric Ind Co Ltd メタデータ付与装置及びメタデータ付与方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MISKA M. ET AL.: "ITU-T SG 16 WP3 and ISO/IEC JTC1/SC29/WG11", JCTVC-V0072, 7 October 2015 (2015-10-07), pages 1 - 12 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112667114A (zh) * 2020-12-21 2021-04-16 北京小早科技有限公司 一种信息处理方法、装置以及计算机存储介质
CN114727001A (zh) * 2021-01-05 2022-07-08 北京小米移动软件有限公司 一种处理图像数据的方法、装置及介质
CN114727001B (zh) * 2021-01-05 2024-01-19 北京小米移动软件有限公司 一种处理图像数据的方法、装置及介质

Also Published As

Publication number Publication date
US20210303616A1 (en) 2021-09-30
JP2023112059A (ja) 2023-08-10
JP2020098499A (ja) 2020-06-25
JP7483102B2 (ja) 2024-05-14
JP7303625B2 (ja) 2023-07-05

Similar Documents

Publication Publication Date Title
WO2020129434A1 (ja) 画像ファイル生成装置、画像ファイル生成方法、及びプログラム
JP6566330B2 (ja) 映像編集方法
JP5801395B2 (ja) シャッタクリックを介する自動的メディア共有
CN101405758A (zh) 用于自动处理数字信息的智能共享技术
JP2007166541A (ja) 画像処理方法およびその装置
KR20170020550A (ko) 참석자들에 의한 이벤트 검색
JP6234146B2 (ja) 記録制御装置、記録制御方法、及び、プログラム
JP7267703B2 (ja) 画像データ格納装置、画像データ格納方法、及び、プログラム
US11157546B2 (en) Information processing apparatus, control method, and storage medium
JP5849177B2 (ja) 画像情報処理システム
CN113615158A (zh) 文件生成设备、文件生成方法、文件再现设备、文件再现方法和程序
US20150109464A1 (en) Apparatus for and method of managing image files by using thumbnail images
JP2006195807A (ja) 映像検索システム、映像検索方法及びプログラム
KR101764654B1 (ko) 영상 촬영장치의 메타데이터 관리 시스템 및 방법
JP5202605B2 (ja) コンテンツデータ管理装置、コンテンツデータ管理システム、コンテンツデータ管理プログラム、コンテンツデータ管理方法
US8161086B2 (en) Recording device, recording method, computer program, and recording medium
KR100510404B1 (ko) 전자 앨범 및 전자 앨범의 이미지 데이터 검색방법
JP5909734B2 (ja) 画像表示方法
KR101990689B1 (ko) 클라우드 서버의 이미지 데이터 제공 방법
JP2010093342A (ja) 映像サーバ装置、映像クライアント装置、映像送受信システム及び情報処理方法
JP2007193616A (ja) アルバム作成システム、アルバム作成方法、およびアルバム作成プログラム
JP2023112455A (ja) 情報処理装置および情報処理方法
JP2022109138A (ja) 情報処理装置、情報処理方法、及びプログラム
JP2014203347A (ja) 文書検索システム、文書検索装置、文書検索方法及びプログラム
JP2005149483A (ja) ファイル生成方法及びファイル検索方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19898421

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19898421

Country of ref document: EP

Kind code of ref document: A1