WO2021182090A1 - ファイル処理装置、ファイル処理方法、及び、プログラム - Google Patents

ファイル処理装置、ファイル処理方法、及び、プログラム Download PDF

Info

Publication number
WO2021182090A1
WO2021182090A1 PCT/JP2021/006575 JP2021006575W WO2021182090A1 WO 2021182090 A1 WO2021182090 A1 WO 2021182090A1 JP 2021006575 W JP2021006575 W JP 2021006575W WO 2021182090 A1 WO2021182090 A1 WO 2021182090A1
Authority
WO
WIPO (PCT)
Prior art keywords
image
file
box
data
heif
Prior art date
Application number
PCT/JP2021/006575
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 ソニーグループ株式会社
Priority to JP2022505894A priority Critical patent/JPWO2021182090A1/ja
Priority to CN202180018881.8A priority patent/CN115211104A/zh
Priority to US17/797,962 priority patent/US20230039708A1/en
Priority to EP21767892.9A priority patent/EP4106325A4/en
Publication of WO2021182090A1 publication Critical patent/WO2021182090A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal

Definitions

  • the present technology relates to a file processing device, a file processing method, and a program, and more particularly to, for example, a file processing device, a file processing method, and a program that enable a user to reduce the number of images lost.
  • HEIF High Efficiency Image File Format
  • the HEIF file can store a plurality of still images, such as images captured by continuous shooting.
  • a plurality of images in a HEIF file the larger the number of images, the longer the writing time required for writing (recording) the HEIF file. If the writing time is long, there is a high possibility that an abnormal HEIF file will be generated due to the battery being removed, the power being turned off due to the outlet being unplugged, or the media being unplugged while writing the HEIF file. It is expected to be.
  • An abnormal HEIF file is a file that does not have the format as a HEIF file.
  • the HEIF file that is not normal cannot be played back, and the user loses all the images that should be stored in the HEIF file.
  • This technology was made in view of such a situation, and makes it possible to reduce the number of images lost by the user.
  • the first file processing device or program of the present technology includes a file control unit that writes restoration data for repairing the HEIF file into a HEIF (High Efficiency Image File Format) file in which a still image is stored.
  • a file control unit that writes restoration data for repairing the HEIF file into a HEIF (High Efficiency Image File Format) file in which a still image is stored.
  • the first file processing method of the present technology is a file processing method including writing restoration data for repairing the HEIF file into a HEIF (High Efficiency Image File Format) file in which a still image is stored.
  • HEIF High Efficiency Image File Format
  • the restoration data for repairing the HEIF file is written in the HEIF (High Efficiency Image File Format) file in which the still image is stored. Is done.
  • HEIF High Efficiency Image File Format
  • the second file processing device or program of the present technology repairs the HEIF (High Efficiency Image File Format) file in which the still image is stored.
  • the HEIF file in which the repair data is written is used for the repair. It is a file processing device provided with a file control unit for repairing using data, or a program for operating a computer as such a file processing device.
  • the second file processing method of the present technology is to use the repair data to repair the HEIF file in which the repair data for repairing the HEIF (High Efficiency Image File Format) file in which the still image is stored is written.
  • a file processing method that includes repairing.
  • the HEIF file in which restoration data for repairing a HEIF (High Efficiency Image File Format) file in which a still image is stored is written. Is repaired using the repair data.
  • HEIF High Efficiency Image File Format
  • the file processing device may be an independent device or an internal block constituting one device.
  • the program can be provided by transmitting via a transmission medium or by recording on a recording medium.
  • FIG. 1 is a block diagram showing a configuration example of an embodiment of a digital camera to which the present technology is applied.
  • the digital camera 10 includes an optical system 11, an image sensor 12, a signal processing unit 13, media 14, I / F (Interface) 15 and 16, buttons / keys 17, touch panel 18, liquid crystal panel 19, viewfinder 20, and I. It has / F21 etc.
  • the optical system 11 collects the light from the subject on the image sensor 12.
  • the image sensor 12 receives light from the optical system 11 and performs photoelectric conversion for imaging to generate image data as an electric signal and supply it to the signal processing unit 13.
  • the signal processing unit 13 includes an optical system / image sensor control unit 41, a coding control unit 42, a file control unit 43, a media control unit 44, an operation control unit 45, a display control unit 46, and a UI control unit 47.
  • the optical system / image sensor control unit 41 controls the optical system 11 and the image sensor 12, and supplies (data) an image (data) obtained by imaging performed according to the control to the coding control unit 42.
  • the coding control unit 42 supplies the image from the optical system / image sensor control unit 41 to the display control unit 46, encodes it as necessary, and supplies it to the file control unit 43. Further, the coding control unit 42 decodes the image supplied from the file control unit 43 as necessary, and supplies the image to the display control unit 46.
  • the file control unit 43 generates a file in which the image supplied from the coding control unit 42 is stored and supplies the file to the media control unit 44. Further, the file control unit 43 plays back a file supplied from the media control unit 44, that is, reads out data such as an image stored in the file. For example, the image read from the file is supplied from the file control unit 43 to the coding control unit 42.
  • the media control unit 44 controls the exchange of files between the media 14 and the I / Fs 15 and 16. For example, the media control unit 44 causes the media 14 to record the file from the file control unit 43, or causes the I / F 15 and 16 to transmit the file. Further, the media control unit 44 reads a file from the media 14 or causes the I / Fs 15 and 16 to receive the file and supplies the file to the file control unit 43.
  • the operation control unit 45 supplies an operation signal corresponding to the operation of the button / key 17 or the touch panel 18 by the user to a necessary block.
  • the display control unit 46 performs display control and the like to supply the image and the like supplied from the coding control unit 42 to the liquid crystal panel 19, the viewfinder 20, and the I / F 21 for display.
  • the UI control unit 47 is in charge of UI (User Interface) control.
  • the media 14 is a storage medium such as an SD card.
  • the I / F 15 is, for example, a LAN (Local Area Network) I / F such as WiFi (registered trademark) or Ethernet (registered trademark).
  • the I / F 16 is, for example, a USB (Universal Serial Bus) I / F.
  • the buttons / keys 17 and the touch panel 18 are operated by the user when inputting commands and other information to the digital camera 10.
  • the touch panel 18 can be integrally configured with the liquid crystal panel 19.
  • the liquid crystal panel 19 and the viewfinder 20 display an image or the like supplied from the display control unit 46.
  • the I / F 21 is an I / F that transmits at least an image such as HDMI (High-Definition Multimedia Interface) (registered trademark) or DP (DisplayPort).
  • the optical system / image sensor control unit 41 uses, for example, a RAW image from an image of RAW data (hereinafter, also referred to as a RAW image) obtained by imaging the image sensor 12.
  • a YUV image having the same resolution (number of pixels) (size) is generated and supplied to the coding control unit 42 together with the RAW image.
  • the coding control unit 42 generates a master image or the like of the HEIF file from the YUV image from the optical system / image sensor control unit 41.
  • the YUV image from the optical system / image sensor control unit 41 can be used as the main image of the HEIF file as it is.
  • the coding control unit 42 has a lower resolution than, for example, a main image of the YUV as a first other image based on the main image for display on a liquid crystal panel 19 or an external display. Generates a YUV image (hereinafter also referred to as a screen nail image) and has a higher resolution than, for example, a screen nail image as a second other image based on the main image for use in index display (list display). Generates a low YUV image (hereinafter also referred to as a thumbnail image). For example, the coding control unit 42 supplies the screen nail image to the liquid crystal panel 19 via the display control unit 46 and displays it as a so-called through image.
  • a YUV image hereinafter also referred to as a screen nail image
  • thumbnail image Generates a low YUV image
  • thumbnail image for example, an image having a long side of 320 pixels or less can be adopted.
  • the ratio of the size (number of pixels) of the main image to the screen nail image as the first other image based on the main image or the thumbnail image as the second other image based on the main image is, for example, 200. Can be doubled or less.
  • the size ratio of the screen nail image as the first other image based on the main image and the thumbnail image as the second other image based on the main image can be 200 times or less.
  • the screen nail image for example, an image having a resolution of 4K or higher can be adopted. Further, as the screen nail image, for example, a 4K (QFHD) or FHD image can be adopted according to the user's selection.
  • the main image and the screen nail image an image having the same resolution can be adopted.
  • both the main image and the screen nail image can be stored in the HEIF file, or the main image and the screen nail image are not stored. Images can be stored.
  • the main image is stored in the HEIF file without storing the screen nail image, the main image can be resized and used as the screen nail image.
  • the coding control unit 42 needs a main image, a screen nail image, and a thumbnail image (a main image, a screen nail image, and a thumbnail image generated from the same RAW image) corresponding to the RAW image. It is encoded accordingly and supplied to the file control unit 43 together with the RAW image.
  • the file control unit 43 includes a RAW file in which a RAW image is stored, a corresponding main image, a screen nail image, and a thumbnail image (a main image generated from the same RAW image, a screen nail image, etc.). And / or a JPEG file or the like in which the HEIF file (thumbnail image) is stored is generated and supplied to the media control unit 44.
  • a HEIF file is a file conforming to HEIF (High Efficiency Image File Format)
  • a JPEG file is a file conforming to JPEG (Joint Photographic Experts Group).
  • the media control unit 44 records the RAW file, HEIF file, and JPEG file from the file control unit 43 on the media 14, or causes the I / F 15 or 16 to transmit the RAW file, the HEIF file, and the JPEG file.
  • the file type (for example, RAW file, HEIF file, JPEG file, etc.) generated by the file control unit 43 can be selected according to, for example, a user operation (designation). Further, as will be described later, the HEIF file has an image item format and an image sequence format, and which of the image item format and the image sequence format should be adopted is selected according to, for example, the user's operation. be able to. Further, the file control unit 43 can perform mutual conversion between the HEIF file and the JPEG file according to the operation of the user.
  • the file control unit 43 can generate a plurality of files having the same image content with different codecs, image sizes (resolutions), color formats, and bit depths.
  • the coding control unit 42 selects an image stored in each of the plurality of files from the YUV image from the optical system / image sensor control unit 41.
  • Stream (file stream) is generated.
  • the coding control unit 42 can generate a stream of images having different codecs, image sizes (resolutions), color formats, and bit depths.
  • the coding control unit 42 generates an image of a predetermined size, a predetermined color format, and a predetermined bit depth from the YUV image supplied from the optical system / image sensor control unit 41, and creates the image.
  • a first stream encoded by a predetermined codec (encoding method) can be generated.
  • the coding control unit 42 generates an image of another size, another color format, and another bit depth from the same YUV image supplied from the optical system / image sensor control unit 41, and generates an image thereof.
  • a second stream can be generated in which the image is encoded by another codec.
  • the file control unit 43 can generate a file in which the first stream is stored and a file in which the second stream is stored.
  • FIG. 2 is a diagram showing an example of a JPEG file format conforming to JPEG (Joint Photographic Experts Group).
  • the JPEG file is, for example, Exif (EXIF) metadata, thumbnail image, XMP (Extensible Metadata Platform) (registered trademark) metadata, MPF representing the storage location (position) of the main image and the simple display image, etc.
  • EXIF Exif
  • thumbnail image thumbnail image
  • XMP Extensible Metadata Platform
  • MPF representing the storage location (position) of the main image and the simple display image
  • An image and a simple display image are stored and configured.
  • As the simple display image for example, a screen nail image can be adopted.
  • FIG. 3 is a diagram showing an example of an ISO base media file format.
  • HEIF (ISO / IEC 23008-12) is a file format that conforms to the ISO base media file format (ISO / IEC 14496-12), and therefore HEIF files conform to the ISO base media file format.
  • the ISO-based media file format is composed of units called boxes as containers for storing data, and has a structure called a box structure.
  • the box has a type (box type), actual data (data), and the like.
  • the type represents the type of actual data in the box.
  • the actual data includes images (still images, moving images), playable media data such as audio and subtitles (subtitles), and attribute values (fields) of attribute names (field names) and their attribute names (variables represented by). Value) and various other data can be adopted.
  • a box can be adopted as the actual data. That is, the box can have a box as actual data, whereby it can have a hierarchical structure.
  • the base media file conforming to the ISO base media file format can have an ftyp box, a moov box (MovieBox), a meta box (MetaBox), an mdat box (MediaDataBox), and the like.
  • the ftyp box stores identification information that identifies the file format.
  • the moov box can store a trak box and the like.
  • the meta box can store an inf box, an iprp box, an iref box, an iloc box, and the like.
  • the mdat box can store media data (AV data) and any other data.
  • HEIF conforms to the above ISO-based media file format.
  • FIG. 4 is a diagram showing an example of a HEIF file format conforming to HEIF.
  • HEIF files are roughly divided into image item format and image sequence format. Further, the image item format includes a single image format having only one item, which will be described later, and an image collection format having a plurality of items.
  • the HEIF file in the image item format has an ftyp box, a meta box, and an mdat box.
  • the image sequence format HEIF file has an ftyp box, a moov box, and an mdat box.
  • the HEIF file can have both, not just one of the meta box and the moov box.
  • the ftyp box stores identification information that identifies the file format, for example, that the file is a HEIF file in image item format or image sequence format.
  • the meta box and moov box store metadata such as the storage location of media data, which is necessary for playing and managing the media data stored in the mdat box.
  • which of the HEIF files of the image item format and the image sequence format is generated can be selected, for example, according to the user's operation.
  • an image is encoded and stored in the mdat box of the HEIF file
  • intra-encoding is permitted for the image item format
  • intra-encoding and inter-encoding are permitted for the image sequence format. .. Therefore, for example, when giving priority to high-speed access to the data stored in the HEIF file, selecting the generation of the HEIF file in the image item format and giving priority to reducing the size (data amount) of the HEIF file. You can choose to generate a HEIF file in image sequence format.
  • FIG. 5 is a diagram showing an example of the format of the HEIF file in the image item format.
  • image item format HEIF file information indicating that it is an image item format HEIF file, for example, mif1 etc., is stored (as an attribute value) in the ftyp box.
  • the meta box stores the iinf box, iref box, iprp box, and iloc box.
  • the iinf box stores the number of items (attribute name and attribute value) that are media data (AV data) stored in the mdat box.
  • An item is one piece of data stored in the mdat box of a HEIF file in the image item format.
  • one image is an item.
  • one image regardless of whether it is a still image or a moving image, is also referred to as a frame.
  • One frame is one item.
  • the iref box stores information that indicates the relationship between items.
  • the mdat box can store the corresponding main image, screen nail image, and thumbnail image as items. If the mdat box contains item I1 as the main image, item I2 as the screen nail image, and item I3 as the thumbnail image, then item I2 is the screen nail of the main image as item I1 in the iref box. Information indicating that it is an image and information indicating that item I3 is a thumbnail image of the main image as item I1 are stored.
  • Information about item properties is stored in the iprp box.
  • the iloc box stores information about the storage location of the items stored in the mdat box.
  • the mdat box (of the HEIF file) in the image item format stores, for example, an image frame as an item.
  • One or more items can be stored in the mdat box.
  • the frame as an item can be encoded and stored in the mdat box.
  • the coding of the frame as an item stored in the mdat box of the image item format is limited to the intra coding.
  • a coding method (codec) for encoding a frame as an item for example, HEVC or the like can be adopted.
  • FIG. 6 is a diagram showing an example of the iprp box of FIG.
  • the iprp box stores the ipco box and ipma box related to item properties.
  • the ipco box stores the property of the item stored in the mdat box, for example, the codec information regarding the codec of the image as an item and the image size information regarding the size.
  • the ipma box stores the index (pointer) of the item stored in the mdat box to the property stored in the ipco box.
  • FIG. 7 is a diagram showing an example of the format of the HEIF file in the image sequence format.
  • the ftyp box stores information indicating that the image sequence format HEIF file is, for example, msf1.
  • the trak box is stored in the moov box.
  • the trak box stores information about the tracks stored in the mdat box.
  • a track is composed of one independent media data such as an image or sound that is played back according to a timeline.
  • a track is composed of one or more frames of images that are elementary streams.
  • the tracks stored in the mdat box a plurality of tracks, for example, images and sounds recorded at the same time, can be played back at the same time.
  • the media data of a truck is composed of units called samples.
  • the sample is the smallest unit (access unit) when accessing the media data in the HEIF file. Therefore, it is not possible to access the media data in the HEIF file in smaller units than the sample.
  • one frame or the like is one sample.
  • the audio media data for example, one audio frame defined by the standard of the audio media data is one sample.
  • the media data of the track is arranged in units called chunks.
  • a chunk is a set of one or more samples arranged at logically contiguous addresses.
  • the multiple tracks are interleaved and arranged in chunk units.
  • one or more tracks composed of media data such as images and sounds are stored in the mdat box in the image sequence format.
  • the frames of the images that make up the track can be encoded and stored.
  • long GOP can be adopted as the GOP (Group of Picture), and both intra-coding and inter-coding can be adopted.
  • a codec that encodes a frame constituting a track for example, HEVC or the like can be adopted.
  • FIG. 8 is a diagram showing an example of a trak box.
  • the tkhd box and mdia box can be stored in the trak box.
  • the tkhd box stores track header information such as the creation date and time of the track managed by the trak box.
  • the minf box and the like are stored in the mdia box.
  • the stbl box is stored in the minf box.
  • the stbl box contains stsd boxes, stsc boxes, stsz boxes, and stco boxes that store sample tracks and, by extension, information for accessing chunks.
  • the stsd box stores codec information about the track's codec.
  • the chunk size (number of samples per chunk) is stored in the stsc box.
  • the sample size is stored in the stsz box.
  • the stco box stores the chunk offset, that is, the offset of the placement position of each chunk of the track stored in the mdat box.
  • the HEIF file in the image item format is also referred to as a collection file
  • the HEIF file in the image sequence format is also referred to as a sequence file.
  • the digital camera 10 can generate a HEIF file in which one or both of the main image, the necessary screen nail image, and the thumbnail image are stored.
  • FIG. 9 is a diagram showing an example of a collection file in which a main image and a thumbnail image are stored.
  • the frame (item) is encoded by HEVC and stored in the mdat box of the collection file.
  • heic indicating that it is an image item format and that the codec is HEVC is stored as identification information that identifies the file format.
  • the number of items (number of items) stored in the mdat box is stored in the iinf box.
  • the main image specified by the item ID # 1 hereinafter, also described as the main image Item # 1
  • the thumbnail image specified by the main image Item # 2 and the item ID # 101 (hereinafter, the thumbnail).
  • a total of four items (frames), including image Item # 101) and thumbnail image Item # 102, are stored in the mdat box. Therefore, the number of items is 4.
  • the thumbnail image Item # 101 is a thumbnail image of the main image Item # 1
  • the thumbnail image Item # 102 is a thumbnail image of the main image Item # 2.
  • an infe box is stored for each item stored in the mdat box.
  • the item ID that identifies the item and the item type are registered.
  • FIG. 9 there are infe boxes for the main images Item # 1 and Item # 2, and thumbnail images Item # 101 and Item # 102, respectively.
  • the thmb box is stored as information for associating the items stored in the mdat box with each other.
  • a reference source and a reference destination as information for associating the main image with the thumbnail image of the main image are stored in association with each other.
  • the reference source represents the item ID of the main image
  • the reference destination represents the item ID of the thumbnail image of the main image specified by the item ID of the reference source. Therefore, according to the reference destination associated with the reference source, the item ID of the thumbnail image of the main image specified by the item ID represented by the reference source can be recognized. Further, according to the reference source associated with the reference destination, the item ID of the main image of the thumbnail image specified by the item ID represented by the reference destination can be recognized.
  • the iprp box stores the ipco box and the ipma box.
  • the ipco box stores frame properties as items stored in the mdat box, for example, codec information related to the codec and image size information related to the size.
  • the ipma box stores the index of the item stored in the mdat box to the property stored in the ipco box.
  • the iloc box stores information about the storage location of items in the mdat box as explained in FIG. In FIG. 9, the number of items is stored in the iloc box. Further, in the iloc box, the offsets and sizes of the main images Item # 1 and Item # 2 stored in the mdat box and the storage locations of the thumbnail images Item # 101 and Item # 102 are associated with the item ID. Is stored.
  • FIG. 10 is a diagram showing an example of a sequence file in which the track of the main image and the track of the thumbnail image of the main image are stored.
  • the frame is encoded by HEVC and stored in the mdat box of the sequence file.
  • hevc indicating that it is in the image sequence format and that the codec is HEVC is stored as identification information for identifying the file format.
  • the moov box stores a trak box that manages each track stored in the mdat box.
  • the track of the main image specified by track ID # 1 (hereinafter, also referred to as track # 1) and track # 2 of the thumbnail image of the main image of track # 1 are placed in the mdat box. It is stored. Therefore, the moov box stores a trak box that manages track # 1 and a trak box that manages track # 2.
  • the nth thumbnail image (frame) of track # 2 (from the beginning) is the thumbnail image of the nth main image of track # 1.
  • the sequence file is useful, for example, when continuous shooting is performed by the digital camera 10, and the main image and the thumbnail image of a plurality of frames obtained by the continuous shooting are recorded as one track, respectively.
  • the tkhd box of the trak box that manages track # 1 of the main image contains the track ID # 1 that identifies track # 1, the image size of the main image that composes track # 1, and the digital camera when the main image is captured. Rotation information indicating the direction of 10 and the creation date and time of track # 1 are stored.
  • the tkhd box of the trak box that manages the track # 2 of the thumbnail image stores the track ID # 2 that identifies the track # 2 and the creation date and time of the track # 2.
  • the tref box can be stored in the trak box.
  • a track ID that identifies another track related to the track managed by the truck box in which the tref box is stored, information indicating the contents of the track, and the like are stored.
  • a tref box is provided in the trak box that manages the track # 2.
  • the mdia box of the trak box can store the hdlr box.
  • the hdlr box stores information indicating the types of data that make up the tracks managed by the trak box in which the hdlr box is stored.
  • Information (pict) indicating that the data constituting track # 1 is a picture (frame) is stored in the hdlr box stored (in the stored mdia box) in the trak box that manages track # 1 of the main image.
  • the hdlr box which is stored and stored in the trak box that manages track # 2 of the thumbnail image, stores information indicating that the data constituting track # 2 is a picture.
  • the minf box is as explained in FIG.
  • FIG. 11 is a diagram showing an example of a HEIF file in which a tile image is stored.
  • a grid image whose item type is grid is formed by tiling one or more tile images.
  • tile image for example, a divided image obtained by dividing an image captured by a digital camera 10 or the like can be adopted.
  • tile image the image itself captured by the digital camera 10 or the like
  • a grid image can be formed from one or more of such tile images.
  • a plurality of images captured by a plurality of cameras can be used as tile images, and a grid image can be formed from such a plurality of tile images.
  • the divided image obtained by dividing the image captured by the digital camera 10 or the like is adopted as the tile image.
  • each tile image (1 or more) that forms the grid image is stored as an item in the HEIF file.
  • the grid image itself is not stored in the HEIF file, but the tile image forming the grid image is stored in the HEIF file.
  • the HEIF file in which the tile image is stored is also referred to as the HEIF file in which the grid image formed from the tile image is stored.
  • FIG. 11 shows an example of a HEIF file in which a grid image (a tile image forming a tile image) is stored.
  • tile image Item nine images obtained by dividing an image captured by the digital camera 10 (hereinafter, also referred to as an captured image) into 3 ⁇ 3 (horizontal ⁇ vertical) pieces are tile image Item.
  • the tile images Item # 1 to Item # 9 are stored as items in the mdat box as # 1 to Item # 9.
  • the items stored in the mdat box are nine items of tile images Item # 1 to Item # 9, but the number of items in the iinf box and the iloc box is 10. This is because, in addition to the nine items of the tile images Item # 1 to Item # 9, the grid image (reconstructed image) formed from the tile images Item # 1 to Item # 9 is counted as an item. .. In FIG. 11, the item ID of the grid image is 10, and for convenience of explanation, the grid image is also described as the grid image Item # 10.
  • media data is not stored in the mdat box, but instead the idat box is stored in the meta box.
  • the idat box stores the metadata of the grid image such as the number of tiles horizontal, the number of tiles vertical, output_width, and output_height.
  • the number of tiles horizontally and the number of tiles vertically represent the numbers of tile images # 1 to # 9 constituting the grid image Item # 10 in the horizontal and vertical directions, respectively.
  • Output_width and output_height represent the horizontal and vertical sizes (number of pixels) of the canvas, which is the image area in which the tile images forming the grid image are tiling (arranged). If the number of horizontal and vertical pixels of the tile image is expressed as tile_width and tile_height, respectively, the tile_width ⁇ number of tiles width must be output_width or more, and the tile_height ⁇ number of tiles length must be output_height or more.
  • information (offset and size) regarding the storage location of the grid image Item # 10 is stored in the iloc box, and this information is stored in the idat box of the grid image Item # 10. Represents a place.
  • the HEIF file of FIG. 11 stores 10 items of tile images Item # 1 to Item # 9 and tile images Item # 10 formed from the tile images Items # 1 to Item # 9. Depending on it, it has 10 infe boxes. As described with reference to FIG. 9, the infe box stores (registers) the item ID that identifies the item and the item type, but the infe box of the grid image Item # 10 contains the grid image Item # 10. As an item type, a grid representing a grid item is stored. An item whose item type is grid, here grid image Item # 10, is called a grid item.
  • the dimg box is stored in the iref box.
  • the dimg box stores information that associates the grid item with the tile images that make up the grid item.
  • the item ID of the tile image is stored as a reference destination
  • the item ID of the grid image formed from the tile image is stored as a reference source.
  • the item IDs # 1 to # 9 of the tile images Item # 1 to Item # 9 are stored as reference destinations
  • the item ID # 10 of the grid image Item # 10 is stored as a reference source.
  • the dimg box stores a reference counter that represents the number of tile images that form the grid image.
  • the file control unit 43 uses the item type grid stored in the infe box of the grid image Item # 10 to form a grid item (a grid image in which the grid image Item # 10 is one or more tile images). It can be recognized that it is a reconstructed image). Further, the file control unit 43 is used to form the item ID # 10 of the grid image Item # 10 formed from the tile image and the grid image Item # 10 from the reference source and the reference destination stored in the dimg box. It is possible to identify the item IDs # 1 to # 9 of the tile images Item # 1 to Item # 9.
  • the file control unit 43 determines the horizontal and vertical directions of the tile images # 1 to # 9 forming the grid image # 10 from the horizontal and vertical number of tiles stored in the idat box and the output_width and output_height.
  • the number and the horizontal and vertical sizes of the canvas on which the tile images # 1 to # 9 are placed when forming the grid image # 10 can be specified.
  • the file control unit 43 uses the tile images Item # 1 to Item # 9 of the item IDs # 1 to # 9 specified from the dimg box to obtain the number of tile images in the horizontal and vertical directions specified from the idat box. By arranging it on the canvas of the specified size from the box, it is possible to form the grid image Item # 10 of the item ID # 10 specified from the dimg box.
  • FIG. 12 is a diagram illustrating an outline of the HEIF file with a repair function generated by the file control unit 43.
  • the HEIF file can store a plurality of still images (main images), such as images captured by continuous shooting.
  • main images such as images captured by continuous shooting.
  • main images such as images captured by continuous shooting.
  • plural of images does not mean a plurality of images having the same content, such as a main image and a thumbnail image, but is captured separately, such as an image captured by continuous shooting. Means multiple images.
  • an abnormal HEIF file that is, a file that does not have the format as a HEIF file
  • the unexpected event during writing to the media 14 is, for example, a power failure due to the media 14 being removed by the user, the battery being removed, or the outlet being removed.
  • the HEIF file that is not normal cannot be played back, and the user loses all the images that should be stored in the HEIF file.
  • the file control unit 43 can generate a HEIF file with a repair function, which is a HEIF file having a function of repairing an abnormal HEIF file into a normal HEIF file, that is, a file having a format as a HEIF file. ..
  • a HEIF file with a repair function is a HEIF file that is used to generate (repair) images and metadata (hereinafter, also referred to as management metadata) stored in the meta box for playback and management of the images.
  • the repair data for repairing is stored.
  • a HEIF file with a repair function that stores three images and repair data for each image, that is, repair data for generating image management metadata for each of the three images.
  • the image restoration data is arranged immediately before the image. That is, immediately after the restoration data, an image in which the management metadata is restored (generated) using the restoration data is arranged.
  • the file control unit 43 uses the repair data to perform an abnormal repair function. Repairs a HEIF file with a normal (with repair function) HEIF file.
  • the file control unit 43 generates management metadata for an image that has been normally written and stored in a HEIF file with an abnormal repair function, using the repair data corresponding to the image. Further, the file control unit 43 generates a normal HEIF file in which the management metadata is stored in the meta box.
  • FIG. 13 is a diagram illustrating an outline of repairing an abnormal (with repair function) HEIF file using repair data.
  • the meta box of temporary data is written, and then the mdat box is filled with the restoration data of the first image, the restoration data of the first image, the restoration data of the second image, and the second image.
  • the meta box of temporary data is the metadata in which the metadata that has been confirmed at the time of writing the meta box (hereinafter, also referred to as the confirmed metadata) is written, and the metadata that has not been confirmed is the metadata. It means a fixed length (fixed size) meta box in which an area for writing data is secured. The same applies to boxes other than the meta box.
  • the file control unit 43 deletes (truncates) the third image written halfway. Further, the file control unit 43 uses the normally written restoration data of the first image and the second image and the metadata stored in the meta box of the temporary data to obtain a normal HEIF file. Generates metadata other than the definite metadata required for, and generates a normal meta box in which the metadata and the definite metadata are stored. Then, the file control unit 43 creates a normal HEIF file (repairs an abnormal HEIF file) by writing a normal meta box to the HEIF file instead of the temporary data meta box.
  • the HEIF file in the image item format is adopted as the HEIF file with the repair function
  • the HEIF file in the image sequence format can also be adopted as the HEIF file with the repair function.
  • the meta box in which the metadata of the data stored in the mdat box is stored becomes the moov box.
  • FIG. 14 is a flowchart illustrating an example of processing for generating a HEIF file with a repair function.
  • the digital camera 10 generates three images, a main image, a screen nail image, and a thumbnail image, for one imaging, and these three images (main image, screen nail image, and It is possible to generate a HEIF file in which EXIF and XMP as metadata (of imaging) of the three images (thumba image) and EXIF and XMP as metadata of the three images are collectively stored as image-related data related to one main image.
  • HEIF file in which the main image and EXIF and XMP are collectively stored as image-related data related to one main image is generated.
  • step S111 the file control unit 43 sets the variable capnum representing the number of imagings to the number of imagings of the main image stored in one HEIF file (with a repair function). For example, if the user operates the release button (not shown) only once to perform one imaging, the variable capnum is set to 1. Further, for example, when the user performs continuous shooting, the variable capnum is set to the number of times the imaging is performed by continuous shooting.
  • step S111 the file control unit 43 sets the variable n for counting the number of main images stored in the HEIF file to 1 as an initial value, and the process proceeds to step S112.
  • the file control unit 43 stores the nth main image (the main image generated in the nth imaging) and the imaging information in an image memory (not shown), and displays the codec information. It is stored in the memory for the meta, and the process proceeds to step S113.
  • the imaging information is information related to (imaging) the main image used for generating EXIF and XMP, for example, an F value at the time of imaging the main image, a focal length, an imaging date and time, and the like.
  • the codec information is information related to a codec such as a main image, and is, for example, SPS (Sequence Parameter Set), PPS (Picture Parameter Set), VPS (Video Parameter Set) information, and the like. The codec information is used to generate a normal meta box.
  • step S113 the file control unit 43 causes the coding control unit 42 to encode the nth main image, and the process proceeds to step S114.
  • step S114 the file control unit 43 generates repair data for repairing the nth main image, that is, repair data for repairing the metadata (management metadata) of the nth main image.
  • the process proceeds to step S115.
  • step S115 the file control unit 43 generates EXIF and XMP of the nth main image using the imaging information of the nth main image, and the process proceeds to step S116.
  • step S116 the file control unit 43 determines whether or not the variable n is 1.
  • step S116 If it is determined in step S116 that the variable n is 1, that is, if the image-related data of the first main image has not yet been written to the media 14, the process proceeds to step S117.
  • step S117 the file control unit 43 generates an ftyp box and a meta box for temporary data. Further, in step S117, the file control unit 43 writes to the media 14 in the form of arranging the ftyp box and the meta box of the temporary data in that order from the beginning of the HEIF file by controlling the media control unit 44. , The process proceeds to step S118.
  • step S118 the file control unit 43 writes the EXIF and XMP of the nth main image to the media 14 in the form of arranging them immediately after the data written immediately before in the mdat box of the HEIF file, and the processing is performed.
  • the process proceeds to step S119.
  • the EXIF and XMP of the first main image are written so as to be arranged from the beginning of the ftyp box and the mdat box immediately after the temporary data written immediately before.
  • step S119 the file control unit 43 arranges the restoration data of the nth main image immediately after EXIF and XMP of the nth main image written immediately before in the mdat box of the HEIF file. , Writing to the media 14, the process proceeds to step S120.
  • step S120 the file control unit 43 arranges the nth main image on the media 14 immediately after the restoration data of the nth main image written immediately before in the mdat box of the HEIF file. Writing and processing proceed to step S121.
  • step S121 the file control unit 43 increments the variable n by 1, and the process proceeds to step S122.
  • step S122 the file control unit 43 determines whether or not the variable n is equal to or less than the number of times of imaging (a variable representing) capnum.
  • step S122 when it is determined that the variable n is equal to or less than the number of imaging capnums, that is, when all the main images captured by the imaging of the number of imaging capnums have not yet been written to the media 14, the process is stepped. Return to S112. Then, the same process is repeated thereafter.
  • step S122 when it is determined that the variable n is not less than or equal to the number of imaging capnums, that is, when all the main images captured by the imaging of the number of imaging capnums are written to the media 14, the process is performed in step S123. move on.
  • step S123 the file control unit 43 uses the stored contents of the meta memory to generate a normal ftyp box and a meta box for image-related data including the main image normally written to the media 14, and the process is performed. , Step S124.
  • step S124 the file control unit 43 overwrites the ftyp box and meta box of the temporary data written on the media 14 with the normal ftyp box and meta box.
  • the file control unit 43 generates a HEIF file with a repair function in which the normal ftyp box and meta box and the normal image-related data (the mdat box having the normal image) are stored, and ends the process.
  • the main image, EXIF, and XMP as image-related data are arranged in the order of EXIF, XMP, and main image.
  • the arrangement order is not limited to this.
  • the restoration data of the main image is arranged immediately before the main image (the main image is arranged immediately after the restoration data of the main image).
  • the arrangement relationship between the main image and the restoration data of the main image is not limited to this.
  • the restoration data is first arranged, and then the main image, EXIF, and XMP as image-related data are arranged.
  • the main image and EXIF and XMP are used as image-related data related to one main image.
  • image-related data related to one main image a main image and a related image related to the main image, that is, a screen nail image having the same content as the main image and a small number of pixels, and A thumbnail image and EXIF and XMP which are metadata such as a main image can be adopted.
  • restoration data is generated for each image. That is, restoration data for each of the main image, the screen nail image, and the thumbnail image is generated.
  • the arrangement order of the image-related data and the restoration data includes, for example, EXIF, thumbnail image restoration data, thumbnail image, main image restoration data, main image, screen nail image restoration data, and the like.
  • the order of screen nail image and XMP can be adopted.
  • FIG. 15 is a diagram showing an example of an HEIF file with an abnormal repair function.
  • FIG. 15 for the sake of simplicity, only the image and the restoration data of the image are arranged in the order of the restoration data and the image in the mdat box, and the ftyp box is not considered. And. The same applies to FIGS. 16 to 19 described later.
  • a meta box of temporary data is written, and then the restoration data of the first image, the restoration data of the first image, the second image, the second image, and the third image.
  • the data for repairing the image of is written in the mdat box in that order.
  • an unexpected event occurs, for example, a HEIF file with a repair function is written.
  • the writing is interrupted in the middle of writing the third image, and an abnormal HEIF file with a repair function is generated.
  • the digital camera 10 When the media 14 on which such an abnormal HEIF file with a repair function is recorded is reattached to the digital camera 10 and the HEIF file with an abnormal repair function is detected, the digital camera 10 has an abnormal HEIF with a repair function. The repair process to repair the file is started.
  • the interrupted part where writing was interrupted is detected.
  • the file control unit 43 seeks from the beginning of the meta box of the HEIF file with an abnormal repair function by a fixed length, which is the size of the meta box of temporary data (a variable indicating the read / write position of the file). Set the desired read / write position in the file pointer, etc.). Since the position after the seek is the position at the beginning of the restoration data of the first image, the file control unit 43 reads the restoration data of the first image from the position after the seek.
  • EXIF In the generation of HEIF file with repair function, for example, if EXIF is placed before the repair data, seek is performed as much as the size of the EXIF. In this case, the size of EXIF shall be a fixed length.
  • the file control unit 43 uses the restoration data of the first image to restore the first image. Recognize the size of the data to be used and the size of the first image that follows.
  • the restoration data has a field recovery_data_size indicating the size of the restoration data and a field image_size indicating the size of the image following the restoration data at the beginning thereof.
  • the file control unit 43 recognizes the size of the restoration data of the first image and the size of the first image from the recovery_data_size and image_size fields of the restoration data of the first image.
  • the file control unit 43 seeks only the size of the restoration data of the first image and the size of the first image combined. Since the position after the seek is the position at the beginning of the restoration data of the second image, the file control unit 43 reads the restoration data of the second image from the position after the seek.
  • the file control unit 43 uses the restoration data of the second image in the same manner as the restoration data of the first image, the restoration data of the second image, and the subsequent two images. Recognize the size of the eye image.
  • the file control unit 43 seeks only the size of the restoration data of the second image and the size of the second image combined. Since the position after the seek is the position at the beginning of the restoration data of the third image, the file control unit 43 reads the restoration data of the third image from the position after the seek.
  • the file control unit 43 uses the restoration data of the third image in the same manner as the restoration data of the first image, the restoration data of the third image, and the subsequent three images. Recognize the size of the eye image.
  • the file control unit 43 seeks only the size of the restoration data of the third image and the size of the third image combined.
  • the position after seeking will be the beginning position of the repair data of the fourth image (or the end of the HEIF file with the repair function).
  • the writing is interrupted in the middle of the third image, it is not possible to seek to the head position of the restoration data of the fourth image, and the seek fails.
  • the interrupted portion where the writing is interrupted due to the failure of seeking only the size of the data for repairing the third image and the size of the third image combined is the third image. Detects that it is (position).
  • FIG. 16 is a diagram illustrating an example of repair processing after detecting an interrupted portion.
  • the file control unit 43 When the file control unit 43 detects the interrupted part, the image of the interrupted part and the data for repairing the image are deleted from the mdat box of the HEIF file with the repair function.
  • the mdat box of the HEIF file with the repair function is in a state where only the data that was normally written is stored.
  • the first and second images written before the interruption point are displayed.
  • the restoration data of the first and second images is stored.
  • interruption point is not the third image but the restoration data of the third image before the third image is written, for example, only the restoration data of the third image is available. Will be deleted.
  • image-related data related to one main image for example, a main image, a screen nail image, a thumbnail image, EXIF, and XMP are adopted, and together with the image-related data, a main image, a screen nail image, and ,
  • the restoration data of each of the thumbnail images is written, when any of these image-related data and the restoration data is detected as the interruption part, all the image-related data including the interruption part and the restoration data are deleted.
  • the thumbnail image is detected as an interrupted portion or when EXIF is detected as an interrupted portion
  • the thumbnail image or all the image-related data including EXIF and the restoration data are deleted.
  • the image-related data and the restoration data are, for example, EXIF, thumbnail image restoration data, thumbnail image, main image restoration data, main image, screen nail image restoration data, screen nail image, and XMP in this order.
  • EXIF thumbnail image restoration data
  • thumbnail image thumbnail image
  • main image restoration data main image
  • screen nail image restoration data screen nail image
  • XMP XMP
  • FIG. 17 is a diagram illustrating an image of the interrupted portion and an example of the restoration process after deleting the restoration data of the image.
  • the file control unit 43 When the file control unit 43 deletes the image of the interrupted portion and the restoration data of the image, the file control unit 43 uses the restoration data of the image normally written in the HEIF file with the restoration function after the deletion of the image. Generate (repair) a normal meta box that contains administrative metadata.
  • the file control unit 43 uses the normally written restoration data of the first image and the second image and the metadata stored in the meta box of the temporary data to generate a normal HEIF file. Generates management metadata other than the definite metadata required for, and writes the management metadata and definite metadata to the meta memory to generate a normal meta box.
  • FIG. 18 is a diagram illustrating an example of repair processing after generation of a normal meta box.
  • the file control unit 43 When the file control unit 43 generates a normal meta box, it seeks to the first position of the meta box of the temporary data of the HEIF file with the repair function, and overwrites the normal meta box of the meta memory from the position after the seek. Write in the form of. As a result, the file control unit 43 generates a normal (with a repair function) HEIF file (repairs an abnormal HEIF file).
  • FIG. 19 is a flowchart illustrating an example of the repair process.
  • the file control unit 43 starts the repair process when, for example, an abnormal HEIF file with a repair function is detected from the HEIF files with a repair function recorded on the media 14. Whether or not the HEIF file is a HEIF file with a repair function is determined, for example, by providing a new field or box indicating that the HEIF file is a HEIF file with a repair function in the meta box and depending on the new field or box. be able to.
  • step S141 the file control unit 43 opens the HEIF file with an abnormal repair function recorded on the media 14 (generates a file pointer for accessing the HEIF file, etc.). Further, the file control unit 43 seeks from the beginning of the meta box of the opened HEIF file with a repair function by a fixed length which is the size of the meta box of the temporary data, and the process proceeds from step S141 to step S142.
  • step S142 the file control unit 43 reads the repair data from the position after seeking, that is, the position at the beginning of the repair data, and the process proceeds to step S143.
  • the field recovery_data_size indicating the size of the repair data is placed at a fixed position, for example, at the beginning of the repair data.
  • the size of the repair data can be recognized from the field recovery_data_size.
  • step S143 the file control unit 43 determines whether or not the restoration data has been successfully read.
  • step S143 If it is determined in step S143 that the read of the repair data was not successful, that is, an unexpected event occurs during the writing of the repair data, and the repair data is not written normally (completely), which is not normal.
  • the file control unit 43 detects the position of the abnormal repair data as the interruption point where the writing was interrupted, and the process is performed. , Step S147.
  • step S143 If it is determined in step S143 that the restoration data has been successfully read, the process proceeds to step S144.
  • step S144 the file control unit 43 stores the repair data (hereinafter, also referred to as the latest repair data) read in the immediately preceding step S142 in the meta memory, and the process proceeds to step S145.
  • the repair data hereinafter, also referred to as the latest repair data
  • step S145 the file control unit 43 acquires the fields recovery_data_size and image_size from the latest repair data stored in the meta memory. Further, the file control unit 43 recognizes the size of the latest repair data and the size of the image immediately after the latest repair data in the HEIF file with an abnormal repair function from the recovery_data_size and image_size. .. Then, the file control unit 43 determines the size of the latest repair data (from the beginning of the latest repair data of the HEIF file with the repair function) and the size of the image arranged immediately after the latest repair data. The process proceeds from step S145 to step S146 after seeking by the combined size.
  • step S146 the file control unit 43 determines whether or not the seek performed in the immediately preceding step S145 was successful.
  • step S146 If it is determined in step S146 that the seek was successful, that is, if the seek reaches the beginning of the repair data placed immediately after the image placed immediately after the latest repair data, the process is performed. , Return to step S142.
  • step S142 as described above, the file control unit 43 reads the repair data from the position after seeking, that is, the position at the beginning of the repair data, and the same process is repeated thereafter.
  • step S146 when it is determined that the seek has failed, that is, an unexpected event occurs during the writing of the image arranged immediately after the latest restoration data, and the writing of the image is interrupted.
  • the file control unit 43 detects the position of the image in which the writing was interrupted and the seek failed as the interruption location, and the process proceeds to step S147.
  • step S147 the file control unit 43 deletes the image of the interrupted portion and the repair data from the HEIF file with the repair function, and the process proceeds to step S148.
  • step S147 when the interrupted part is the position of the repair data, the repair data is deleted. Further, when the interruption point is the position of the image, the image and the restoration data arranged immediately before the image are deleted.
  • step S148 the file control unit 43 needs to store the repair data stored in the meta memory, that is, the repair data normally written in the HEIF file with the repair function, and the temporary data in the meta box.
  • the management metadata By using the management metadata to generate management metadata other than the definite metadata required for a normal HEIF file, and writing the management metadata and the definite metadata to the meta memory, Generate a normal meta box.
  • step S149 the file control unit 43 seeks to the position at the beginning of the meta box of the temporary data of the HEIF file with the repair function, and the process proceeds to step S150.
  • step S150 the file control unit 43 repairs the HEIF file with the repair function by overwriting the normal meta box of the meta memory from the position after seeking (generates the HEIF file with the normal repair function). ), End the repair process.
  • FIG. 20 is a diagram showing a specific example of restoration data.
  • the repair data is arranged in the fields recovery_data_size, image_size, next_image_exist, info_type, target_size_x, target_size_y, num_of_grid_x, num_of_grid_y, grid_width, grid_height, grid_list, capture_gamma, and colormetory. It is composed.
  • the field recovery_data_size represents the size (data amount) of the repair data having the field recovery_data_size in bytes.
  • the field image_size represents the size (data amount) of the image to be placed immediately after the repair data having the field recovery_data_size in bytes.
  • the field next_image_exist indicates whether or not the next image (and the repair data of the image) exists after the image placed immediately after the repair data having the field recovery_data_size. If the next image is present, the field next_image_exist is set to one of 0 and 1, for example 1, and if not, the field next_image_exist is set to 0 of the other.
  • the field info_type represents the picture type (INFO type) of the image to be placed immediately after the repair data having the field recovery_data_size.
  • the fields target_size_x and target_size_y represent the vertical and horizontal sizes (number of pixels) of the image placed immediately after the restoration data having the fields target_size_x and target_size_y, respectively.
  • the fields num_of_grid_x and num_of_grid_y are the vertical and horizontal of the grid image when the image placed immediately after the repair data having the fields num_of_grid_x and num_of_grid_y is a grid image (a tile image forming) which is a grid item. Represents the number of divisions, that is, the number of vertical and horizontal tile images constituting the grid image, respectively.
  • the fields grid_width and grid_height determine the vertical and horizontal sizes (number of pixels) of the tile images constituting the grid image when the image arranged immediately after the restoration data having the fields grid_width and grid_height is a grid image. Represent each.
  • the field grid_list represents the grid information described later regarding the image placed immediately after the repair data having the field grid_list.
  • the field capture_gamma represents the gamma information regarding the gamma of the image placed immediately after the restoration data having the field capture_gamma.
  • the field colormetory represents colorimetry information regarding the colorimetry of the image placed immediately after the restoration data having the field colormetory.
  • the field hvcc_info is the hvcc information about the image placed immediately after the repair data having the field hvcc_info, and represents the hvcc information that does not include SPS, PPS, VPS, etc.
  • FIG. 21 is a diagram showing a specific example of the field grid_list as grid information in the repair data.
  • the fields param_addr, param_size, data_addr, data_size, total_vps_size, num_vps, vps_id, total_sps_size, num_sps, sps_id, total_pps_size, num_pps, pps_id are arranged in this order. ..
  • the fields param_addr and param_size represent the address and size (data amount) of VPS, SPS, and PPS as parameters related to the image, respectively.
  • the fields data_addr and data_size represent the address and size (data amount) of the ES (Elementary Stream) related to the image, respectively.
  • the fields total_vps_size, num_vps, and vps_id represent the size (data amount), number, and ID (ID of NAL (Network Abstraction Layer) unit) of VPS, respectively.
  • the fields total_sps_size, num_sps, and sps_id represent the size (data amount), number, and ID (ID of NAL unit) of SPS, respectively.
  • the fields total_pps_size, num_pps, and pps_id represent the size (data amount), number, and ID (ID of NAL unit) of PPS, respectively.
  • VPS image item format HEIF file
  • SPS SPS
  • PPS PPS
  • FIG. 22 is a diagram showing a box in which metadata generated (repaired) using at least repair data in the repair process is stored.
  • the fact that the management metadata is generated (repaired) using the repair data (field) is also expressed as the generation (repair) of the box in which the management data is stored.
  • the boxes stored in the meta box that can be generated using the repair data include the pitt box, infe box, dimg box, thmb box, collr box, hvcc box, ipse box, idat box, and iloc box.
  • the inf box, iprp box, ipco box, and impa box are boxes in which definite metadata is stored, or can be generated from other boxes.
  • the pitt box (administrative metadata stored in) can be generated using the fields grid_width and grid_height.
  • the infe box and dimg box can be created using the fields num_of_grid_x and num_of_grid_y.
  • the thum box can be created using the fields target_size_x and target_size_y.
  • the collr box can be created using the fields capture_gamma and colormetory.
  • the hvcc box can be created using the fields grid_list and hvcc_info.
  • the ipse box can be created using the fields target_size_x and target_size_y.
  • the idat box can be created using the fields num_of_grid_x, num_of_grid_y, grid_width, grid_height, and grid_list.
  • the iloc box can be created using the field grid_list.
  • the mdat box is not a box stored in the meta box, but the data after deleting the data for repairing the interrupted part, the image of the interrupted part, and the data for repairing the image in the mdat box.
  • the size (data amount) of the deleted data can be generated using the field grid_list.
  • FIG. 23 is a diagram illustrating a method of generating (repairing) a box in which management metadata generated using at least the repair data is stored in the repair process.
  • FIG. 23 also shows a method of generating a box that constitutes a HEIF file with a repair function other than the box that is generated using the repair data in the repair process.
  • the related field represents a field of repair data used to generate a box (management metadata stored in).
  • the image-related data related to one main image the main image, the screen nail image, the thumbnail image, the EXIF, and the XMP are adopted, and the mdat box of the image-related data and the restoration data is used.
  • EXIF, thumbnail image restoration data, thumbnail image, main image restoration data, main image, screen nail image restoration data, screen nail image, and XMP will be adopted as the order of arrangement.
  • the HEIF file with repair function has an ftyp box, a meta box, and an mdat box.
  • the meta box can store a hdlr box, a pitt box, an iinf box, an iref box, an iprp box, an idat box, and an iloc box.
  • the infe box can be stored in the inf box.
  • the iref box can store a dimg box, a thum box, and a cdsc box.
  • the iprp box can store the ipco box and the ipma box.
  • the ipco box which may be stored in the iprp box, may contain a collr box, an hvcc box, an ispe box, and an irot box.
  • the ftyp box can be created using a fixed value (predetermined).
  • the meta box can be generated by obtaining the size (data amount) of each box stored in the meta box and using that size.
  • the hdlr box can be generated using a fixed value.
  • the pitt box can be generated by setting the item ID of the main item to 1 and using the item ID of the main item when the image placed immediately after the repair data is not a grid image.
  • the item ID of the main item is expressed using the repair data fields num_of_grid_x and num_of_grid_y. It can be calculated according to num_of_grid_x ⁇ num_of_grid_y + 1 and generated using the item ID of the main item.
  • the iinf box can be generated by obtaining the size (data amount) of each box stored in iprp and the number of infe boxes (total number), and using the size and number.
  • the number of items stored in the mdat box is stored in the iinf box, and the number of items is counted as follows for image-related data.
  • the number of items for one image-related data is three, that is, the main image, EXIF, and XMP. become.
  • the number of items for one image-related data is the main image.
  • the infe box uses the repair data fields num_of_grid_x and num_of_grid_y to obtain the number of tile images (number of grid components) num_of_grid_x ⁇ num_of_grid_y, and the number of tile images num_of_grid_x ⁇ num_of_grid_y.
  • the iref box can be generated by obtaining the size (data amount) of each box stored in the iref and using that size.
  • the dimg box can be generated by using the repair data fields num_of_grid_x and num_of_grid_y to find the number of tile images that make up the grid image (the number of grid components) num_of_grid_x x num_of_grid_y, and using that number num_of_grid_x x num_of_grid_y. can.
  • the repair data fields target_size_x and tait_size_y are used, and target_size_x and taet_size_y are the size (number of pixels) of the screen nail image or thumbnail image.
  • the item ID of the existing item (image) can be obtained as the item ID of the screen nail image or the thumbnail image, and can be generated using the item ID.
  • the item ID of the item (image) that is the size (number of pixels) of the thumbnail image in the image-related data is used as a reference.
  • the item IDs of EXIF and XMP can be obtained, and can be generated using the item IDs of EXIF and XMP.
  • the iprp box can be generated by finding the size of each box stored in the iprp box and using that size.
  • the ipco box can be generated by finding the size of each box stored in the ipco box and using that size.
  • the collr box can be created using the repair data fields capture_gamma and colormetory.
  • the hvcc box can be created using the repair data fields hvcc_info and grid_list.
  • the ispe box can be created using the repair data fields target_size_x and tait_size_y.
  • the irot box can be created using a fixed value.
  • the ipma box is an infe by fixing the order of the infe boxes of each item in a predetermined order so that the infe box of each item can be associated with each property in ipco. It can be generated using the box and each property in the ipco box associated with its infe box.
  • the order of the infe boxes of each item it is possible to associate the infe box with the property of the item corresponding to the infe box in ipco.
  • the order of the infe box is the main image as an item with an item ID of 1, the screen nail image as an item with an item ID of 2, the thumbnail image as an item with an item ID of 3, EXIF, and XMP (of the infe box).
  • the properties of the main image with item ID 1 are the first, second, and third properties in the ipco box.
  • the properties of the screen nail image with item ID 2 are the 1st, 4th, and 5th properties in the ipco box.
  • the properties of the thumbnail image with item ID 3 are the 1st, 6th, and 7th properties in the ipco box.
  • the infe box can be associated with the property of the item corresponding to the infe box. Then, using the infe box and the property associated with the infe box (the property of the item corresponding to the infe box), generate an ipma box that stores the index to the property of each item in the ipco box. Can be done.
  • the HEIF standard document states ⁇ The item type and ID should be listed in the infe box. -The ipco box has codec information (hvcc) and image size (ipse) information. -It is stated in the ipma box that the property associated with the ID is specified.
  • the idat box can be created using the repair data fields grid_list, grid_width, grid_height num_of_grid_x, and num_of_gird_y.
  • the iloc box can be created using the repair data field grid_list.
  • the size of the data (actually used) in the mdat box can be generated by using the field grid_list.
  • FIG. 24 is a block diagram showing a configuration example of an embodiment of a computer in which a program for executing the above-mentioned series of processes is installed.
  • the program can be recorded in advance on the hard disk 905 or ROM 903 as a recording medium built in the computer.
  • the program can be stored (recorded) in the removable recording medium 911 driven by the drive 909.
  • a removable recording medium 911 can be provided as so-called package software.
  • examples of the removable recording medium 911 include a flexible disc, a CD-ROM (Compact Disc Read Only Memory), an MO (Magneto Optical) disc, a DVD (Digital Versatile Disc), a magnetic disc, and a semiconductor memory.
  • the program can be installed on the computer from the removable recording medium 911 as described above, or can be downloaded to the computer via a communication network or a broadcasting network and installed on the built-in hard disk 905. That is, for example, the program transfers wirelessly from a download site to a computer via an artificial satellite for digital satellite broadcasting, or transfers to a computer by wire via a network such as LAN (Local Area Network) or the Internet. be able to.
  • LAN Local Area Network
  • the computer has a built-in CPU (Central Processing Unit) 902, and the input / output interface 910 is connected to the CPU 902 via the bus 901.
  • CPU Central Processing Unit
  • the CPU 902 executes the program stored in the ROM (Read Only Memory) 903 accordingly. .. Alternatively, the CPU 902 loads the program stored in the hard disk 905 into the RAM (Random Access Memory) 904 and executes it.
  • ROM Read Only Memory
  • the CPU 902 performs processing according to the above-mentioned flowchart or processing performed according to the above-mentioned block diagram configuration. Then, the CPU 902 outputs the processing result from the output unit 906, transmits it from the communication unit 908, and further records it on the hard disk 905, if necessary, via the input / output interface 910.
  • the input unit 907 is composed of a keyboard, a mouse, a microphone, and the like. Further, the output unit 906 is composed of an LCD (Liquid Crystal Display), a speaker, or the like.
  • LCD Liquid Crystal Display
  • the processing performed by the computer according to the program does not necessarily have to be performed in chronological order in the order described as the flowchart. That is, the processing performed by the computer according to the program also includes processing executed in parallel or individually (for example, parallel processing or processing by an object).
  • the program may be processed by one computer (processor) or may be distributed processed by a plurality of computers. Further, the program may be transferred to a distant computer and executed.
  • the system means a set of a plurality of components (devices, modules (parts), etc.), and it does not matter whether all the components are in the same housing. Therefore, a plurality of devices housed in separate housings and connected via a network, and a device in which a plurality of modules are housed in one housing are both systems. ..
  • this technology can have a cloud computing configuration in which one function is shared by a plurality of devices via a network and jointly processed.
  • each step described in the above flowchart can be executed by one device or shared by a plurality of devices.
  • one step includes a plurality of processes
  • the plurality of processes included in the one step can be executed by one device or shared by a plurality of devices.
  • a file processing device including a file control unit that writes restoration data for repairing the HEIF file into a HEIF (High Efficiency Image File Format) file in which a still image is stored.
  • the repair data is data for repairing management metadata for managing the image in the HEIF file.
  • the file control unit arranges the restoration data for repairing the management metadata of the image immediately before the image.
  • the restoration data includes the size of the restoration data and the size of the image arranged immediately after the restoration data.
  • the repair data is stored in the pitt box, infe box, dimg box, thmb box, collr box, hvcc box, ipse box, idat box, and iloc box stored in the meta box of the HEIF file.
  • the file processing device according to any one of ⁇ 2> to ⁇ 4>, which includes data for repairing metadata for.
  • the HEIF file stores the image and related images related to the image.
  • the file processing device according to any one of ⁇ 1> to ⁇ 5>, wherein the file control unit writes the restoration data of the image and the restoration data of the related image.
  • the related image is an image having a smaller number of pixels than the image.
  • ⁇ 8> The file processing device according to any one of ⁇ 1> to ⁇ 7>, wherein the HEIF file stores the image and the metadata of the image.
  • a file processing method including writing restoration data for repairing the HEIF file into a HEIF (High Efficiency Image File Format) file in which a still image is stored.
  • a program for operating a computer as a file control unit that writes restoration data for repairing the HEIF file into a HEIF (High Efficiency Image File Format) file that stores still image images.
  • a file processing device including a file control unit that repairs the HEIF file in which repair data for repairing a HEIF (High Efficiency Image File Format) file in which a still image is stored is written by using the repair data.
  • the repair data is data for repairing management metadata for managing the image in the HEIF file.
  • the file processing device according to ⁇ 11>, wherein the file control unit generates the management metadata using the repair data.
  • the file control unit deletes the image of the interrupted portion where writing is interrupted from the HEIF file, and stores the image written before the interrupted portion using the repair data.
  • the file processing device according to ⁇ 12> that generates a HEIF file.
  • the restoration data for repairing the management metadata of the image is placed immediately in front of the image.
  • the repair data includes the size of the repair data and the size of the image placed immediately after the repair data.
  • the file processing apparatus When the file control unit fails to seek a size that matches the size of the repair data and the size of the image arranged immediately after the repair data from the beginning of the repair data, the image The file processing apparatus according to ⁇ 13>.
  • the HEIF file stores the image and related images related to the image.
  • the file processing device according to ⁇ 13> or ⁇ 14>, wherein the file control unit deletes the image and the related image when any of the image and the related image is detected as the interruption point.
  • the file processing device According to ⁇ 15>, wherein the related image is an image having a smaller number of pixels than the image.
  • the HEIF file stores the image and the metadata of the image.
  • the file processing device according to any one of ⁇ 13> to ⁇ 16>, wherein the file control unit deletes the image and the metadata when any of the image and the metadata is detected as the interruption point. .. ⁇ 18>
  • the file control unit uses the pitt box, infe box, dimg box, thmb box, collr box, hvcc box, ipse box, idat box, and the hedate box stored in the meta box of the HEIF file.
  • the file processing device according to any one of ⁇ 12> to ⁇ 17>, which repairs the management metadata stored in the iloc box.
  • HEIF High Efficiency Image File Format
  • a file processing method including repairing the HEIF file in which repair data is written by using the repair data.
  • Repairing a HEIF (High Efficiency Image File Format) file that stores still image images Makes a computer function as a file control unit that repairs the HEIF file in which repair data is written using the repair data. Program for.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Library & Information Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本技術は、ユーザが失う画像を少なくすることができるようにするファイル処理装置、ファイル処理方法、及び、プログラムに関する。 静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、HEIFファイルを修復する修復用データが書き込まれる。HEIFファイルは、修復用データを用いて修復される。本技術は、HEIFファイルの処理に適用することができる。

Description

ファイル処理装置、ファイル処理方法、及び、プログラム
　本技術は、ファイル処理装置、ファイル処理方法、及び、プログラムに関し、特に、例えば、ユーザが失う画像を少なくすることができるようにするファイル処理装置、ファイル処理方法、及び、プログラムに関する。
　画像を、効率的に格納するファイルフォーマットとして、HEIF(High Efficiency Image File Format)がある（非特許文献１を参照）。
ISO/IEC 23008-12:2017, Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 12: Image File Format
　HEIFファイルには、例えば、連写で撮像された画像等の、複数枚の静止画の画像を格納することができる。HEIFファイルに、複数枚の画像を格納する場合、画像の枚数が多いほど、HEIFファイルの書き込み（記録）に要する書き込み時間が長くなる。書き込み時間が長い場合、HEIFファイルの書き込み中に、バッテリが抜かれることや、コンセントが抜かれることによる電源断や、メディアが抜かれること等によって、正常でないHEIFファイルが生成される可能性が高くなることが予想される。正常でないHEIFファイルとは、HEIFファイルとしてのフォーマットを有していないファイルである。
　正常でないHEIFファイルについては、再生をすることができず、ユーザは、HEIFファイルに格納されるはずの画像すべてを失うことになる。
　本技術は、このような状況に鑑みてなされたものであり、ユーザが失う画像を少なくすることができるようにするものである。
　本技術の第１のファイル処理装置、又は、プログラムは、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部を備えるファイル処理装置、又は、そのようなファイル処理装置として、コンピュータを機能させるためのプログラムである。
　本技術の第１のファイル処理方法は、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むことを含むファイル処理方法である。
　本技術の第１のファイル処理装置、ファイル処理方法、及び、プログラムにおいては、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データが書き込まれる。
　本技術の第２のファイル処理装置、又は、プログラムは、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部を備えるファイル処理装置、又は、そのようなファイル処理装置として、コンピュータを機能させるためのプログラムである。
　本技術の第２のファイル処理方法は、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復することを含むファイル処理方法である。
　本技術の第２のファイル処理装置、ファイル処理方法、及び、プログラムにおいては、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルが、前記修復用データを用いて修復される。
　なお、ファイル処理装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。
　また、プログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して提供することができる。
本技術を適用したディジタルカメラの一実施の形態の構成例を示すブロック図である。 JPEG(Joint Photographic Experts Group)に準拠したJPEGファイルのフォーマットの例を示す図である。 ISOベースメディアファイルフォーマットの例を示す図である。 HEIFに準拠したHEIFファイルのフォーマットの例を示す図である。 イメージアイテム形式のHEIFファイルのフォーマットの例を示す図である。 iprpボックスの例を示す図である。 イメージシーケンス形式のHEIFファイルのフォーマットの例を示す図である。 trakボックスの例を示す図である。 主画像及びサムネイル画像が格納されたコレクションファイルの例を示す図である。 主画像のトラック及びその主画像のサムネイル画像のトラックが格納されたシーケンスファイルの例を示す図である。 タイル画像が格納されたHEIFファイルの例を示す図である。 ファイル制御部４３により生成される修復機能付きHEIFファイルの概要を説明する図である。 修復用データを用いた正常でない（修復機能付き）HEIFファイルの修復の概要を説明する図である。 修復機能付きHEIFファイルの生成の処理の例を説明するフローチャートである。 正常でない修復機能付きHEIFファイルの例を示す図である。 中断箇所の検出後の修復処理の例を説明する図である。 中断箇所の画像、及び、その画像の修復用データの削除後の修復処理の例を説明する図である。 正常なmetaボックスの生成後の修復処理の例を説明する図である。 修復処理の例を説明するフローチャートである。 修復用データの具体例を示す図である。 修復用データのうちのグリッド情報（フィールド）grid_listの具体例を示す図である。 修復処理において、少なくとも修復用データを用いて生成（修復）されるメタデータが格納されるボックスを示す図である。 修復処理において、少なくとも修復用データを用いて生成される管理用メタデータが格納されるボックスの生成（修復）方法を説明する図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
　＜本技術を適用したディジタルカメラの一実施の形態＞
　図１は、本技術を適用したディジタルカメラの一実施の形態の構成例を示すブロック図である。
　ディジタルカメラ１０は、光学系１１、イメージセンサ１２、信号処理部１３、メディア１４、I/F(Interface)１５及び１６、ボタン／キー１７、タッチパネル１８、液晶パネル１９、ビューファインダ２０、並びに、I/F２１等を有する。
　光学系１１は、被写体からの光を、イメージセンサ１２に集光する。
　イメージセンサ１２は、光学系１１からの光を受光し、光電変換する撮像を行うことで、電気信号としての画像のデータを生成し、信号処理部１３に供給する。
　信号処理部１３は、光学系／イメージセンサ制御部４１、符号化制御部４２、ファイル制御部４３、メディア制御部４４、操作制御部４５、表示制御部４６、及び、UI制御部４７を有する。
　光学系／イメージセンサ制御部４１は、光学系１１及びイメージセンサ１２を制御し、その制御に従って行われる撮像により得られる画像（のデータ）を、符号化制御部４２に供給する。
　符号化制御部４２は、光学系／イメージセンサ制御部４１からの画像を表示制御部４６に供給するとともに、必要に応じて符号化し、ファイル制御部４３に供給する。また、符号化制御部４２は、ファイル制御部４３から供給される画像を必要に応じて復号し、表示制御部４６に供給する。
　ファイル制御部４３は、符号化制御部４２から供給される画像を格納したファイルを生成し、メディア制御部４４に供給する。また、ファイル制御部４３は、メディア制御部４４から供給されるファイルの再生、すなわち、ファイルに格納された画像等のデータの読み出し等を行う。例えば、ファイルから読み出された画像は、ファイル制御部４３から符号化制御部４２に供給される。
　メディア制御部４４は、メディア１４、並びに、I/F１５及び１６との間でのファイルのやりとりを制御する。例えば、メディア制御部４４は、ファイル制御部４３からのファイルを、メディア１４に記録させ、又は、I/F１５及び１６から送信させる。また、メディア制御部４４は、メディア１４からファイルを読み出し、又は、I/F１５及び１６にファイルを受信させ、ファイル制御部４３に供給する。
　操作制御部４５は、ユーザによるボタン／キー１７やタッチパネル１８の操作に応じて、その操作に対応する操作信号を、必要なブロックに供給する。
　表示制御部４６は、符号化制御部４２から供給される画像等を、液晶パネル１９や、ビューファインダ２０、I/F２１に供給して表示させる表示制御等を行う。
　UI制御部４７は、UI(User Interface)制御をつかさどる。
　メディア１４は、例えば、SDカード等の記憶媒体である。I/F１５は、例えば、WiFi（登録商標）やイーサネット（登録商標）等のLAN(Local Area Network)のI/Fである。I/F１６は、例えば、USB(Universal Serial Bus)のI/Fである。ボタン／キー１７及びタッチパネル１８は、ディジタルカメラ１０に指令その他の情報を入力するときに、ユーザによって操作される。タッチパネル１８は、液晶パネル１９と一体的に構成することができる。液晶パネル１９及びビューファインダ２０は、表示制御部４６から供給される画像等を表示する。I/F２１は、HDMI(High-Definition Multimedia Interface)（登録商標）やDP(Display Port)等の少なくとも画像を伝送するI/Fである。
　以上のように構成されるディジタルカメラ１０では、光学系／イメージセンサ制御部４１は、イメージセンサ１２の撮像により得られるRAWデータの画像（以下、RAW画像ともいう）から、例えば、そのRAW画像と同一の解像度（画素数）（サイズ）のYUVの画像を生成し、RAW画像とともに、符号化制御部４２に供給する。符号化制御部４２は、光学系／イメージセンサ制御部４１からのYUVの画像から、HEIFファイルの主画像(master image)等を生成する。例えば、光学系／イメージセンサ制御部４１からのYUVの画像を、そのままHEIFファイルの主画像とすることができる。
　符号化制御部４２は、YUVの主画像から、液晶パネル１９や外部のディスプレイでの表示の用途用に、主画像に基づく第１の他の画像としての、例えば、主画像よりも解像度が低いYUVの画像（以下、スクリーンネイル画像ともいう）を生成するとともに、インデクス表示（一覧表示）の用途用に、主画像に基づく第２の他の画像としての、例えば、スクリーンネイル画像よりも解像度が低いYUVの画像（以下、サムネイル画像ともいう）を生成する。符号化制御部４２は、例えば、スクリーンネイル画像を、表示制御部４６を介して、液晶パネル１９に供給し、いわゆるスルー画として表示させる。サムネイル画像としては、例えば、長辺が320ピクセル以下のサイズの画像を採用することができる。主画像と、主画像に基づく第１の他の画像としてのスクリーンネイル画像、又は、主画像に基づく第２の他の画像としてのサムネイル画像とのサイズ（ピクセル数）の比率は、例えば、200倍以下にすることができる。主画像に基づく第１の他の画像としてのスクリーンネイル画像と、主画像に基づく第２の他の画像としてのサムネイル画像とのサイズの比率も、同様に、200倍以下とすることができる。スクリーンネイル画像としては、例えば、解像度が4K以上の画像を採用することができる。また、スクリーンネイル画像としては、例えば、ユーザの選択に応じて、4K（QFHD）又はFHDの画像を採用することができる。さらに、主画像とスクリーンネイル画像としては、同一の解像度の画像を採用することができる。主画像とスクリーンネイル画像として、同一の解像度の画像を採用する場合、HEIFファイルには、主画像とスクリーンネイル画像との両方を格納することもできるし、スクリーンネイル画像を格納せずに、主画像を格納することができる。HEIFファイルに、スクリーンネイル画像を格納せずに、主画像を格納する場合には、主画像をリサイズして、スクリーンネイル画像として用いることができる。
　また、符号化制御部４２は、RAW画像に対応する主画像、スクリーンネイル画像、及び、サムネイル画像（同一のRAW画像から生成された主画像、スクリーンネイル画像、及び、サムネイル画像）を、必要に応じて符号化し、RAW画像とともに、ファイル制御部４３に供給する。
　ファイル制御部４３は、必要に応じて、RAW画像が格納されたRAWファイルや、対応する主画像、スクリーンネイル画像、及び、サムネイル画像（同一のRAW画像から生成された主画像、スクリーンネイル画像、及び、サムネイル画像）が格納されたHEIFファイル、及び／又は、JPEGファイル等を生成し、メディア制御部４４に供給する。HEIFファイルとは、HEIF(High Efficiency Image File Format)に準拠したファイルであり、JPEGファイルとは、JPEG(Joint Photographic Experts Group)に準拠したファイルである。
　メディア制御部４４は、ファイル制御部４３からのRAWファイルや、HEIFファイル、JPEGファイルを、メディア１４に記録し、あるいは、I/F１５又は１６から送信させる。
　ファイル制御部４３において生成するファイルの種類（例えば、RAWファイルや、HEIFファイル、JPEGファイル等）は、例えば、ユーザの操作（指定）に応じて選択することができる。また、HEIFファイルには、後述するように、イメージアイテム形式とイメージシーケンス形式とがあるが、イメージアイテム形式とイメージシーケンス形式とのいずれを採用するかは、例えば、ユーザの操作に応じて選択することができる。さらに、ファイル制御部４３では、ユーザの操作に応じて、HEIFファイルとJPEGファイルとの間の相互変換を行うことができる。
　また、ファイル制御部４３では、コーデックや、画像のサイズ（解像度）、カラーフォーマット、ビット深度が異なる、同一の画像内容の複数のファイルを生成することができる。
　ファイル制御部４３において、同一の画像内容の複数のファイルを生成する場合、符号化制御部４２では、光学系／イメージセンサ制御部４１からのYUVの画像から、複数のファイルそれぞれに格納される画像のストリーム（ファイルストリーム）が生成される。
　符号化制御部４２では、コーデックや、画像のサイズ（解像度）、カラーフォーマット、ビット深度が異なる画像のストリームを生成することができる。
　例えば、符号化制御部４２では、光学系／イメージセンサ制御部４１から供給されるYUVの画像から、所定のサイズ、所定のカラーフォーマット、及び、所定のビット深度の画像を生成し、その画像を、所定のコーデック（符号化方式）で符号化した第１のストリームを生成することができる。さらに、符号化制御部４２では、光学系／イメージセンサ制御部４１から供給される同一のYUVの画像から、他のサイズ、他のカラーフォーマット、及び、他のビット深度の画像を生成し、その画像を、他のコーデックで符号化した第２のストリームを生成することができる。
　そして、ファイル制御部４３では、第１のストリームを格納したファイルと、第２のストリームを格納したファイルとを生成することができる。
　＜JPEGファイル＞
　図２は、JPEG(Joint Photographic Experts Group)に準拠したJPEGファイルのフォーマットの例を示す図である。
　JPEGファイルは、例えば、Exif(EXIF)のメタデータ、サムネイル画像、XMP(Extensible Metadata Platform)（登録商標）のメタデータ、主画像及び簡易表示用画像の格納場所（位置）等を表すMPF、主画像、並びに、簡易表示用画像が格納されて構成される。簡易表示用画像としては、例えば、スクリーンネイル画像を採用することができる。
　＜ISOベースメディアファイルフォーマット＞
　図３は、ISOベースメディアファイルフォーマットの例を示す図である。
　HEIF(ISO/IEC 23008-12)は、ISOベースメディアファイルフォーマット(ISO/IEC 14496-12)に準拠したファイルフォーマットであり、したがって、HEIFファイルは、ISOベースメディアファイルフォーマットに準拠する。
　ISOベースメディアファイルフォーマットは、データを格納するコンテナとしてのボックス(box)と呼ばれる単位で構成され、ボックス構造と呼ばれる構造を有する。
　ボックスは、タイプ(box type)、及び、実データ(data)等を有する。タイプは、ボックス内の実データの種類を表す。実データとしては、画像（静止画、動画）や、オーディオ、字幕（サブタイトル）等の再生可能なメディアデータ、属性名（フィールド名）とその属性名（で表される変数）の属性値（フィールド値）、その他の各種のデータを採用することができる。
　さらに、実データとしては、ボックスを採用することができる。すなわち、ボックスは、実データとして、ボックスを持つことができ、これにより、階層構造にすることができる。
　ISOベースメディアファイルフォーマットに準拠したベースメディアファイルは、ftypボックス、moovボックス(MovieBox)、metaボックス(MetaBox)、及び、mdatボックス(MediaDataBox)等を有することができる。ftypボックスには、ファイルフォーマットを識別する識別情報が格納される。moovボックスは、trakボックス等を格納することができる。metaボックスは、iinfボックス、iprpボックス、irefボックス、ilocボックス等を格納することができる。mdatボックスは、メディアデータ（AVデータ）、その他任意のデータを格納することができる。
　HEIFは、以上のようなISOベースメディアファイルフォーマットに準拠する。
　＜HEIFファイル＞
　図４は、HEIFに準拠したHEIFファイルのフォーマットの例を示す図である。
　HEIFファイルには、大きく分けて、イメージアイテム形式と、イメージシーケンス形式とがある。さらに、イメージアイテム形式には、後述するアイテムを１つだけ有するシングルイメージ形式と、アイテムを複数有するイメージコレクション形式とがある。
　イメージアイテム形式のHEIFファイルは、ftypボックス、metaボックス、及び、mdatボックスを有する。
　イメージシーケンス形式のHEIFファイルは、ftypボックス、moovボックス、及び、mdatボックスを有する。
　なお、HEIFファイルは、metaボックス及びmoovボックスのうちの一方だけでなく、両方を有することもできる。
　ftypボックスには、ファイルフォーマットを識別する識別情報、例えば、ファイルがイメージアイテム形式又はイメージシーケンス形式のHEIFファイルであること等が格納される。
　metaボックス及びmoovボックスには、mdatボックスに格納されるメディアデータの再生や管理等に必要な、例えば、メディアデータの格納場所等のメタデータが格納される。
　mdatボックスには、メディアデータ（AVデータ）等が格納される。
　ディジタルカメラ１０において、イメージアイテム形式とイメージシーケンス形式とのHEIFファイルのうちのいずれのHEIFファイルを生成するかは、例えば、ユーザの操作に応じて選択することができる。また、HEIFファイルのmdatボックスに、画像を符号化して格納する場合には、イメージアイテム形式については、イントラ符号化のみが許され、イメージシーケンス形式については、イントラ符号化及びインター符号化が許される。したがって、例えば、HEIFファイルに格納されたデータへの高速アクセスを優先する場合には、イメージアイテム形式のHEIFファイルの生成を選択し、HEIFファイルのサイズ（データ量）を小さくすることを優先する場合には、イメージシーケンス形式のHEIFファイルの生成を選択することができる。
　図５は、イメージアイテム形式のHEIFファイルのフォーマットの例を示す図である。
　イメージアイテム形式のHEIFファイルでは、ftypボックスに、イメージアイテム形式のHEIFファイルであることを表す情報、例えば、mif1等が（属性値として）格納される。
　metaボックスには、iinfボックス、irefボックス、iprpボックス、及び、ilocボックスが格納される。
　iinfボックスには、mdatボックスに格納されたメディアデータ（AVデータ）であるアイテムの数（を表す属性名と属性値）等が格納される。アイテムとは、イメージアイテム形式のHEIFファイルのmdatボックスに格納される１つのデータであり、例えば、１枚（画面）の画像が、アイテムである。本明細書では、静止画及び動画にかかわらず、画像の１枚を、フレームともいう。１フレームは、１アイテムである。
　irefボックスには、アイテムどうしの関連を表す情報が格納される。例えば、mdatボックスには、対応する主画像、スクリーンネイル画像、及び、サムネイル画像のそれぞれをアイテムとして格納することができる。mdatボックスに、主画像としてのアイテムI1、スクリーンネイル画像としてのアイテムI2、及び、サムネイル画像としてのアイテムI3が格納される場合、irefボックスには、アイテムI2がアイテムI1としての主画像のスクリーンネイル画像であることを表す情報や、アイテムI3がアイテムI1としての主画像のサムネイル画像であることを表す情報が格納される。
　iprpボックスには、アイテムのプロパティに関する情報が格納される。
　ilocボックスには、mdatボックスに格納されたアイテムの格納場所に関する情報が格納される。
　イメージアイテム形式の（HEIFファイルの）mdatボックスには、アイテムとしての、例えば、画像のフレームが格納される。mdatボックスには、１個以上のアイテムを格納することができる。また、mdatボックスには、アイテムとしてのフレームを符号化して格納することができる。但し、イメージアイテム形式のmdatボックスに格納するアイテムとしてのフレームの符号化は、イントラ符号化に制限される。アイテムとしてのフレームを符号化する符号化方式（コーデック）としては、例えば、HEVC等を採用することができる。
　図６は、図５のiprpボックスの例を示す図である。
　iprpボックスには、アイテムのプロパティに関するipcoボックス及びipmaボックスが格納される。ipcoボックスには、mdatボックスに格納されたアイテムのプロパティ、例えば、アイテムとしての画像のコーデックに関するコーデック情報やサイズに関する画サイズ情報が格納される。ipmaボックスには、mdatボックスに格納されたアイテムの、ipcoボックスに格納されたプロパティへのインデクス（ポインタ）が格納される。
　図７は、イメージシーケンス形式のHEIFファイルのフォーマットの例を示す図である。
　イメージシーケンス形式のHEIFファイルでは、ftypボックスに、イメージシーケンス形式のHEIFファイルであることを表す情報、例えば、msf1等が格納される。
　moovボックスには、trakボックスが格納される。trakボックスには、mdatボックスに格納されるトラックに関する情報が格納される。
　トラックは、画像や音声等の１つの独立した、タイムラインに従って再生されるメディアデータで構成される。例えば、トラックは、エレメンタリストリームとなる１フレーム以上の画像で構成される。mdatボックスに格納されるトラックについては、複数のトラック、例えば、同時に記録された画像及び音声それぞれのトラックを、同時に再生することができる。
　トラックのメディアデータは、サンプルと呼ばれる単位で構成される。サンプルとは、HEIFファイル内のメディアデータにアクセスする場合の、最小の単位（アクセス単位）である。したがって、サンプルより細かい単位で、HEIFファイル内のメディアデータにアクセスすることはできない。
　画像のメディアデータについては、例えば、１フレーム等が、１サンプルとなる。また、音声のメディアデータについては、例えば、その音声のメディアデータの規格で定められた１オーディオフレーム等が、１サンプルとなる。
　イメージシーケンス形式の（HEIFファイルの）mdatボックスにおいて、トラックのメディアデータは、チャンク(chunk)と呼ばれる単位で配置される。チャンクは、論理的に連続したアドレスに配置される１以上のサンプルの集合である。
　mdatボックスに、メディアデータとしての複数のトラックが格納される場合、その複数のトラックは、チャンク単位で、インターリーブして配置される。
　以上のように、イメージシーケンス形式のmdatボックスには、画像や音声等のメディアデータで構成される１以上のトラックが格納される。
　mdatボックスには、トラックを構成する画像のフレームを符号化して格納することができる。イメージシーケンス形式のmdatボックスに格納するトラックを構成するフレームの符号化には、GOP(Group of Picture)として、long GOPを採用するとともに、イントラ符号化及びインター符号化のいずれをも採用することができる。トラックを構成するフレームを符号化するコーデックとしては、例えば、HEVC等を採用することができる。
　図８は、trakボックスの例を示す図である。
　trakボックスには、tkhdボックス及びmdiaボックスを格納することができる。tkhdボックスには、trakボックスが管理するトラックの作成日時等の、トラックのヘッダ情報が格納される。mdiaボックスには、minfボックス等が格納される。minfボックスには、stblボックスが格納される。stblボックスには、トラックのサンプル、ひいては、チャンクにアクセスするための情報が格納されるstsdボックス、stscボックス、stszボックス、及び、stcoボックスが格納される。stsdボックスには、トラックのコーデックに関するコーデック情報が格納される。stscボックスには、チャンクサイズ（1チャンクのサンプル数）が格納される。stszボックスには、サンプルサイズが格納される。stcoボックスには、チャンクオフセット、すなわち、mdatボックスに格納されたトラックの各チャンクの配置位置のオフセットが格納される。
　ここで、イメージアイテム形式のHEIFファイルを、コレクションファイルともいい、イメージシーケンス形式のHEIFファイルを、シーケンスファイルともいう。
　ディジタルカメラ１０では、主画像、さらには、必要なスクリーンネイル画像、及び、サムネイル画像のうちの一方又は両方が格納されたHEIFファイルを生成することができる。
　＜コレクションファイル＞
　図９は、主画像及びサムネイル画像が格納されたコレクションファイルの例を示す図である。
　いま、コレクションファイルのmdatボックスには、フレーム（アイテム）がHEVCで符号化されて格納されることとする。
　ftypボックスには、ファイルフォーマットを識別する識別情報として、イメージアイテム形式であることと、コーデックがHEVCであることとを表すheicが格納される。
　iinfボックスには、mdatボックスに格納されたアイテムの数（アイテム数）が格納される。図９では、アイテムID#1で特定される主画像（以下、主画像Item#1のようにも記載する）、主画像Item#2、アイテムID#101で特定されるサムネイル画像（以下、サムネイル画像Item#101のようにも記載する）、サムネイル画像Item#102の合計で４個のアイテム（フレーム）が、mdatボックスに格納されている。したがって、アイテム数は４である。なお、サムネイル画像Item#101は、主画像Item#1のサムネイル画像であり、サムネイル画像Item#102は、主画像Item#2のサムネイル画像である。
　iinfボックスには、さらに、例えば、mdatボックスに格納されたアイテムごとに、infeボックスが格納される。infeボックスには、アイテムを特定するアイテムIDと、アイテムタイプとが登録される。図９では、主画像Item#1及びItem#2、並びに、サムネイル画像Item#101及びItem#102それぞれのinfeボックスが存在する。
　irefボックスには、mdatボックスに格納されたアイテムどうしを関連付ける情報として、例えば、thmbボックスが格納される。thmbボックスは、主画像とその主画像のサムネイル画像とを関連付ける情報としての参照元と参照先とが対応付けられて格納される。thmbボックスにおいて、参照元は、主画像のアイテムIDを表し、参照先は、参照元のアイテムIDで特定される主画像のサムネイル画像のアイテムIDを表す。したがって、参照元に対応付けられている参照先によれば、参照元が表すアイテムIDで特定される主画像のサムネイル画像のアイテムIDを認識することができる。また、参照先に対応付けられている参照元によれば、参照先が表すアイテムIDで特定されるサムネイル画像の主画像のアイテムIDを認識することができる。
　iprpボックスには、図６で説明したように、ipcoボックス及びipmaボックスが格納される。ipcoボックスには、図６で説明したように、mdatボックスに格納されたアイテムとしてのフレームのプロパティ、例えば、コーデックに関するコーデック情報やサイズに関する画サイズ情報が格納される。ipmaボックスには、図６で説明したように、mdatボックスに格納されたアイテムの、ipcoボックスに格納されたプロパティへのインデクスが格納される。
　ilocボックスには、図６で説明したようにmdatボックスにおけるアイテムの格納場所に関する情報が格納される。図９では、ilocボックスには、アイテム数が４であることが格納されている。さらに、ilocボックスには、mdatボックスに格納された主画像Item#1及びItem#2、並びに、サムネイル画像Item#101及びItem#102それぞれの格納場所へのオフセット及びサイズがアイテムIDと対応付けられて格納されている。
　＜シーケンスファイル＞
　図１０は、主画像のトラック及びその主画像のサムネイル画像のトラックが格納されたシーケンスファイルの例を示す図である。
　いま、シーケンスファイルのmdatボックスには、フレームがHEVCで符号化されて格納されることとする。
　ftypボックスには、ファイルフォーマットを識別する識別情報として、イメージシーケンス形式であることと、コーデックがHEVCであることとを表すhevcが格納される。
　moovボックスには、図７で説明したように、mdatボックスに格納されるトラックそれぞれを管理するtrakボックスが格納される。図１０では、トラックID#1で特定される主画像のトラック（以下、トラック#1のようにも記載する）、及び、トラック#1の主画像のサムネイル画像のトラック#2が、mdatボックスに格納されている。したがって、moovボックスには、トラック#1を管理するtrakボックスと、トラック#2を管理するtrakボックスとが格納される。トラック#2の（先頭から）n番目のサムネイル画像（のフレーム）は、トラック#1のn番目の主画像のサムネイル画像である。
　シーケンスファイルは、例えば、ディジタルカメラ１０で連写が行われた場合に、その連写で得られる複数フレームの主画像及びサムネイル画像を、それぞれ、1トラックとして記録する場合等に有用である。
　主画像のトラック#1を管理するtrakボックスのtkhdボックスには、トラック#1を特定するトラックID#1、トラック#1を構成する主画像の画サイズ、主画像が撮像されたときのディジタルカメラ１０の向きを表す回転情報、及び、トラック#1の作成日時が格納される。サムネイル画像のトラック#2を管理するtrakボックスのtkhdボックスには、トラック#2を特定するトラックID#2、及び、トラック#2の作成日時が格納される。
　trakボックスには、図７で説明したtkhdボックス及びmdiaボックスの他に、trefボックスを格納することができる。trefボックスには、そのtrefボックスが格納されたtrakボックスが管理するトラックと関連する他のトラックを特定するトラックID、及び、トラックの内容を表す情報等が格納される。図１０では、トラック#2を管理するtrakボックスの中に、trefボックスが設けられている。そして、そのtrefボックスには、トラック#2と関連する他のトラックがトラック#1であること(track_ID=1)、及び、トラック#2を構成するデータがサムネイル画像であること（トラック#2がサムネイル画像のトラックであること）(type=thmb)を表す情報が格納されている。
　trakボックスのmdiaボックスには、図８で説明したminfボックスの他、hdlrボックスを格納することができる。hdlrボックスには、そのhdlrボックスが格納されたtrakボックスが管理するトラックを構成するデータの種別を表す情報が格納される。主画像のトラック#1を管理するtrakボックスに（格納されるmdiaボックスに）格納されるhdlrボックスには、トラック#1を構成するデータがピクチャ（フレーム）であることを表す情報(pict)が格納され、サムネイル画像のトラック#2を管理するtrakボックスに格納されるhdlrボックスには、トラック#2を構成するデータがピクチャであることを表す情報が格納される。
　minfボックスについては、図８で説明した通りである。
　＜タイル画像が格納されたHEIFファイル＞
　図１１は、タイル画像が格納されたHEIFファイルの例を示す図である。
　ここで、HEIFのアイテムタイプの１つとして、gridがある。アイテムタイプがgridの画像（アイテム）であるグリッド画像は、１以上のタイル画像をタイリングすることにより形成される。
　タイル画像としては、例えば、ディジタルカメラ１０等で撮像された画像を分割して得られる分割画像を採用することができる。
　また、タイル画像としては、ディジタルカメラ１０等で撮像された画像そのものを採用し、そのようなタイル画像の１以上から、グリッド画像を形成することができる。例えば、複数のカメラで撮像された複数の画像をタイル画像として、そのような複数のタイル画像からグリッド画像を形成することができる。
　以下では、説明を分かりやすくするため、特に断らない限り、ディジタルカメラ１０等で撮像された画像を分割して得られる分割画像を、タイル画像として採用することとする。
　アイテムタイプがgridのグリッド画像については、そのグリッド画像を形成する（１以上の）タイル画像それぞれがアイテムとして、HEIFファイルに格納される。
　なお、グリッド画像については、グリッド画像そのものがHEIFファイルに格納されるのではなく、グリッド画像を形成するタイル画像がHEIFファイルに格納される。但し、本明細書では、便宜上、タイル画像が格納されたHEIFファイルを、そのタイル画像から形成されるグリッド画像が格納されたHEIFファイルともいう。
　図１１は、グリッド画像（を形成するタイル画像）が格納されたHEIFファイルの例を示している。
　図１１のHEIFファイルでは、例えば、ディジタルカメラ１０で撮像された画像（以下、撮像画像ともいう）を３×３（横×縦）個に分割することにより得られる９個の画像をタイル画像Item#1ないしItem#9として、そのタイル画像Item#1ないしItem#9が、アイテムとして、mdatボックスに格納されている。
　図１１において、mdatボックスに格納されたアイテムは、タイル画像Item#1ないしItem#9の９個のアイテムであるが、iinfボックス及びilocボックス内のアイテム数は１０になっている。これは、タイル画像Item#1ないしItem#9の９個のアイテムの他に、そのタイル画像Item#1ないしItem#9から形成されるグリッド画像（再構成画像）をアイテムとしてカウントするためである。図１１では、グリッド画像のアイテムIDは10になっており、説明の便宜上、かかるグリッド画像を、グリッド画像Item#10とも記載する。
　グリッド画像Item#10については、メディアデータがmdatボックスに格納されず、代わりに、metaボックスに、idatボックスが格納される。idatボックスには、タイル数横、タイル数縦、output_width、及び、output_height等のグリッド画像のメタデータが格納される。
　タイル数横及びタイル数縦は、グリッド画像Item#10を構成するタイル画像#1ないし#9の横方向及び縦方向の数をそれぞれ表す。
　output_width、及び、output_heightは、グリッド画像を形成するタイル画像がタイリング（配置）される画像領域であるキャンバスの横及び縦のサイズ（画素数）を表す。タイル画像の横及び縦の画素数を、tile_width及びtile_heightとそれぞれ表すこととすると、tile_width×タイル数横は、output_width以上であり、tile_height×タイル数縦は、output_height以上である必要がある。
　さらに、グリッド画像Item#10については、ilocボックスに、そのグリッド画像Item#10の格納場所に関する情報（オフセット及びサイズ）が格納されるが、この情報は、グリッド画像Item#10のidatボックスの格納場所を表す。
　図１１のHEIFファイルは、タイル画像Item#1ないしItem#9と、そのタイル画像Item#1ないしItem#9から形成されるタイル画像Item#10との10個のアイテムが格納されていることに応じて、10個のinfeボックスを有する。図９で説明したように、infeボックスには、アイテムを特定するアイテムIDと、アイテムタイプとが格納（登録）されるが、グリッド画像Item#10のinfeボックスには、グリッド画像Item#10のアイテムタイプとして、グリッドアイテムを表すgridが格納される。アイテムタイプがgridのアイテム、ここでは、グリッド画像Item#10は、グリッドアイテムと呼ばれる。
　グリッドアイテムが格納されるHEIFファイルでは、irefボックスに、dimgボックスが格納される。dimgボックスには、グリッドアイテムと、そのグリッドアイテムを構成するタイル画像とを関連付ける情報が格納される。例えば、dimgボックスには、タイル画像のアイテムIDが参照先として格納されるとともに、そのタイル画像から形成されるグリッド画像のアイテムIDが参照元として格納される。図１１では、タイル画像Item#1ないしItem#9のアイテムID#1ないし#9が参照先として格納され、グリッド画像Item#10のアイテムID#10が参照元として格納されている。その他、dimgボックスには、グリッド画像を形成するタイル画像の数を表す参照カウンタが格納される。
　以上のようなHEIFファイルについては、ファイル制御部４３は、グリッド画像Item#10のinfeボックスに格納されたアイテムタイプgridから、グリッド画像Item#10が１以上のタイル画像から形成されるグリッドアイテム（再構成画像）であることを認識することができる。さらに、ファイル制御部４３は、dimgボックスに格納された参照元と参照先とから、タイル画像から形成されるグリッド画像Item#10のアイテムID#10と、そのグリッド画像Item#10の形成に用いられるタイル画像Item#1ないしItem#9のアイテムID#1ないし#9とを特定することができる。また、ファイル制御部４３は、idatボックスに格納されたタイル数横及びタイル数縦、並びに、output_width及びoutput_heightから、グリッド画像#10を形成するタイル画像#1ないし#9の横方向及び縦方向の数、並びに、グリッド画像#10を形成する際にタイル画像#1ないし#9を配置するキャンバスの横方向及び縦方向のサイズを特定することができる。
　ファイル制御部４３は、dimgボックスから特定されたアイテムID#1ないし#9のタイル画像Item#1ないしItem#9から、idatボックスから特定された横方向及び縦方向の数のタイル画像を、idatボックスから特定されたサイズのキャンバスに配置することで、dimgボックスから特定されたアイテムID#10のグリッド画像Item#10を形成することができる。
　＜修復機能付きHEIFファイル＞
　図１２は、ファイル制御部４３により生成される修復機能付きHEIFファイルの概要を説明する図である。
　HEIFファイルには、例えば、連写で撮像された画像等の、複数枚の静止画としての画像（主画像）を格納することができる。HEIFファイルに、複数枚の画像を格納する場合、画像の枚数が多いほど、HEIFファイルのメディア１４への書き込み（記録）に要する書き込み時間が長くなる。ここでいう複数枚の画像とは、例えば、主画像及びサムネイル画像のように、同一内容の複数枚の画像を意味するのではなく、連写で撮像された画像のように、別に撮像された複数枚の画像を意味する。
　書き込み時間が長い場合、HEIFファイルのメディア１４への書き込み中の不慮の事象の発生によって、正常でないHEIFファイル、すなわち、HEIFファイルとしてのフォーマットを有していないファイルが生成される可能性が高くなることが予想される。ここで、メディア１４への書き込み中の不慮の事象とは、例えば、ユーザによってメディア１４が取り外しされることや、バッテリが抜かれること又はコンセントが抜かれることによる電源断等である。
　正常でないHEIFファイルについては、再生をすることができず、ユーザは、HEIFファイルに格納されるはずの画像すべてを失うことになる。
　そこで、ファイル制御部４３では、正常でないHEIFファイルを、正常なHEIFファイル、すなわち、HEIFファイルとしてのフォーマットを有するファイルに修復する機能を有するHEIFファイルである修復機能付きHEIFファイルを生成することができる。
　修復機能付きHEIFファイルには、画像とともに、その画像の再生や管理等のためにmetaボックスに格納されるメタデータ（以下、管理用メタデータともいう）の生成（修復）に用いられる、HEIFファイルを修復するための修復用データが格納される。
　図１２では、３枚の画像と、各画像の修復用データ、すなわち、３枚の画像それぞれについて、画像の管理用メタデータを生成するための修復用データとが格納された修復機能付きHEIFファイルが生成されている。また、図１２の修復機能付きHEIFファイルでは、画像の修復用データは、その画像の直前に配置されている。すなわち、修復用データの直後に、その修復用データを用いて管理用メタデータが修復（生成）される画像が配置されている。
　ファイル制御部４３は、修復機能付きHEIFファイルのメディア１４への書き込み中の不慮の事象の発生によって、正常でない修復機能付きHEIFファイルが生成された場合、修復用データを用いて、正常でない修復機能付きHEIFファイルを、正常な（修復機能付き）HEIFファイルに修復する。
　すなわち、ファイル制御部４３は、正常でない修復機能付きHEIFファイルに格納された、正常な書き込みが行われた画像について、その画像に対応する修復用データを用いて、管理用メタデータを生成する。さらに、ファイル制御部４３は、その管理用メタデータがmetaボックスに格納された正常なHEIFファイルを生成する。
　したがって、修復機能付きHEIFファイルのメディア１４への書き込み中に、メディア１４が取り外しされること、又は、バッテリが抜かれること等による正常でない電源断等の不慮の事象が発生した場合に、ユーザが失う画像を少なくすることができる。
　図１３は、修復用データを用いた正常でない（修復機能付き）HEIFファイルの修復の概要を説明する図である。
　図１３は、仮データのmetaボックスが書き込まれ、その後、mdatボックスに、１枚目の画像の修復用データ、１枚目の画像、２枚目の画像の修復用データ、２枚目の画像、及び、３枚目の画像の修復用データが書き込まれてから、３枚目の画像の書き込みが行われている途中で、メディア１４が取り外しされる等の不慮の事象が発生した場合のHEIFファイルの修復の例を示している。ここで、仮データのmetaボックスとは、metaボックスの書き込みの時点で確定しているメタデータ（以下、確定メタデータともいう）が書き込まれ、かつ、確定していないメタデータについては、そのメタデータを書き込む領域が確保された固定長（固定サイズ）のmetaボックスを意味する。metaボックス以外のボックスについても同様である。
　図１３では、３枚目の画像の書き込みが行われている途中で、不慮の事象が発生している。このため、図１３の修復機能付きHEIFファイルは、１枚目の画像及び２枚目の画像、並びに、１枚目の画像及び２枚目の画像の修復用データが正常（完全）に書き込まれているが、３枚目の画像が完全には書き込まれておらず、かつ、metaボックスが仮データの状態の正常でないHEIFファイルになっている。
　以上のような正常でないHEIFファイルの修復において、ファイル制御部４３は、途中まで書き込まれた３枚目の画像を削除する（切り捨てる）。さらに、ファイル制御部４３は、正常に書き込まれた１枚目の画像及び２枚目の画像の修復用データと、仮データのmetaボックスに格納されたメタデータとを用いて、正常なHEIFファイルに必要な、確定メタデータ以外のメタデータを生成し、そのメタデータと確定メタデータとが格納された正常なmetaボックスを生成する。そして、ファイル制御部４３は、仮データのmetaボックスに代えて、正常なmetaボックスを、HEIFファイルに書き込むことで、正常なHEIFファイルの生成（正常でないHEIFファイルの修復）を行う。
　なお、本明細書では、修復機能付きHEIFファイルとして、イメージアイテム形式のHEIFファイルを採用した場合について説明するが、修復機能付きHEIFファイルとしては、イメージシーケンス形式のHEIFファイルを採用することもできる。修復機能付きHEIFファイルとして、イメージシーケンス形式のHEIFファイルを採用する場合、mdatボックスに格納されるデータのメタデータが格納されるmetaボックスは、moovボックスとなる。
　＜修復機能付きHEIFファイルの生成＞
　図１４は、修復機能付きHEIFファイルの生成の処理の例を説明するフローチャートである。
　なお、ディジタルカメラ１０は、1回の撮像に対して、主画像、スクリーンネイル画像、及び、サムネイル画像の３枚の画像を生成し、この３枚の画像（主画像、スクリーンネイル画像、及び、サムネイル画像）と、この３枚の画像の（撮像の）メタデータとしてのEXIF及びXMPを、１枚の主画像に関連する画像関連データとしてまとめて格納したHEIFファイルを生成することができる。
　但し、図１４では、説明を簡単にするため、主画像と、EXIF及びXMPとを、１枚の主画像に関連する画像関連データとしてまとめて格納したHEIFファイルを生成することとする。
　ステップＳ１１１において、ファイル制御部４３は、撮像回数を表す変数capnumを、１つの（修復機能付き）HEIFファイルに格納する主画像を撮像した撮像回数に設定する。例えば、ユーザがレリーズボタン（図示せず）を1回だけ操作して、1回の撮像が行われた場合、変数capnumは、１に設定される。また、例えば、ユーザが連写を行った場合、変数capnumは、連写による撮像が行われた回数に設定される。
　さらに、ステップＳ１１１では、ファイル制御部４３は、HEIFファイルに格納する主画像の数をカウントする変数nを、初期値としての１に設定し、処理は、ステップＳ１１２に進む。
　ステップＳ１１２では、ファイル制御部４３は、ｎ枚目の主画像（ｎ回目の撮像で生成された主画像）及び撮像情報を、図示せぬ画像用メモリに記憶させるとともに、コーデック情報を、図示せぬmeta用メモリに記憶させ、処理は、ステップＳ１１３に進む。ここで、撮像情報とは、EXIF及びXMPの生成に用いられる、主画像（の撮像）に関連する情報、例えば、主画像の撮像時のＦ値や、焦点距離、撮像日時等である。コーデック情報とは、主画像等のコーデックに関連する情報で、例えば、SPS(Sequence Parameter Set)や、PPS(Picture Parameter Set)、VPS(Video Parameter Set)の情報等である。コーデック情報は、正常なmetaボックスの生成に用いられる。
　ステップＳ１１３では、ファイル制御部４３は、符号化制御部４２に、ｎ枚目の主画像を符号化させ、処理は、ステップＳ１１４に進む。
　ステップＳ１１４では、ファイル制御部４３は、ｎ枚目の主画像の修復用データ、すなわち、ｎ枚目の主画像のメタデータ（管理用メタデータ）を修復するための修復用データを生成し、処理は、ステップＳ１１５に進む。
　ステップＳ１１５では、ファイル制御部４３は、ｎ枚目の主画像の撮像情報を用いて、ｎ枚目の主画像のEXIF及びXMPを生成し、処理は、ステップＳ１１６に進む。
　ステップＳ１１６では、ファイル制御部４３は、変数nが１であるかどうかを判定する。
　ステップＳ１１６において、変数nが１であると判定された場合、すなわち、まだ、１枚目の主画像の画像関連データがメディア１４に書き込まれる前である場合、処理は、ステップＳ１１７に進む。
　ステップＳ１１７では、ファイル制御部４３は、仮データのftypボックス及びmetaボックスを生成する。さらに、ステップＳ１１７では、ファイル制御部４３は、メディア制御部４４を制御することにより、仮データのftypボックス及びmetaボックスを、その順で、HEIFファイルの先頭から配置する形で、メディア１４に書き込み、処理は、ステップＳ１１８に進む。
　ステップＳ１１８では、ファイル制御部４３は、ｎ枚目の主画像のEXIF及びXMPを、HEIFファイルのmdatボックスに直前に書き込まれたデータの直後に配置する形で、メディア１４に書き込み、処理は、ステップＳ１１９に進む。なお、１枚目の主画像のEXIF及びXMPは、直前に書き込まれた仮データのftypボックス及びmetaボックスの直後のmdatボックスの先頭から配置する形で書き込まれる。
　ステップＳ１１９では、ファイル制御部４３は、ｎ枚目の主画像の修復用データを、HEIFファイルのmdatボックスに直前に書き込まれたｎ枚目の主画像のEXIF及びXMPの直後に配置する形で、メディア１４に書き込み、処理は、ステップＳ１２０に進む。
　ステップＳ１２０では、ファイル制御部４３は、ｎ枚目の主画像を、HEIFファイルのmdatボックスに直前に書き込まれたｎ枚目の主画像の修復用データの直後に配置する形で、メディア１４に書き込み、処理は、ステップＳ１２１に進む。
　ステップＳ１２１では、ファイル制御部４３は、変数nを１だけインクリメントして、処理は、ステップＳ１２２に進む。
　ステップＳ１２２では、ファイル制御部４３は、変数nが撮像回数（を表す変数）capnum以下であるかどうかを判定する。
　ステップＳ１２２において、変数nが撮像回数capnum以下であると判定された場合、すなわち、撮像回数capnumの撮像で撮像された主画像すべてが、まだ、メディア１４に書き込まれていない場合、処理は、ステップＳ１１２に戻る。そして、以下、同様の処理が繰り返される。
　また、ステップＳ１２２において、変数nが撮像回数capnum以下でないと判定された場合、すなわち、撮像回数capnumの撮像で撮像された主画像すべてが、メディア１４に書き込まれた場合、処理は、ステップＳ１２３に進む。
　ステップＳ１２３では、ファイル制御部４３は、meta用メモリの記憶内容を用い、メディア１４に正常に書き込まれた主画像を含む画像関連データについて、正常なftypボックスとmetaボックスとを生成し、処理は、ステップＳ１２４に進む。
　ステップＳ１２４では、ファイル制御部４３は、メディア１４に書き込まれた仮データのftypボックスとmetaボックスとを、正常なftypボックスとmetaボックスとで上書きする。これにより、ファイル制御部４３は、正常なftypボックス及びmetaボックス、並びに、正常な画像関連データ（を有するmdatボックス）が格納された修復機能付きHEIFファイルを生成して、処理を終了する。
　なお、図１４では、HEIFファイルにおいて、画像関連データとしての主画像、EXIF、及び、XMPを、EXIF、XMP、主画像の順で配置することとしたが、主画像、EXIF、及び、XMPの配置順は、これに限定されるものではない。
　また、図１４では、HEIFファイルにおいて、主画像の直前に、その主画像の修復用データを配置することとしたが（主画像の修復用データの直後に、その主画像を配置することとしたが）、主画像とその主画像の修復用データとの配置関係は、これに限定されるものではない。例えば、修復用データ、並びに、画像関連データとしての主画像、EXIF、及び、XMPについては、最初に、修復用データを配置し、その後に、画像関連データとしての主画像、EXIF、及び、XMPを、EXIF、XMP、主画像の順で配置することができる。なお、修復用データを、主画像の直前に配置する場合には、修復用データを検出することができれば、修復用データの直後に続く主画像の先頭を、容易に検出することができる。
　上述したように、ここでは、説明を簡単にするために、主画像と、EXIF及びXMPとを、１枚の主画像に関連する画像関連データとすることとした。但し、１枚の主画像に関連する画像関連データとしては、主画像、及び、主画像に関連する関連画像、すなわち、主画像と同一内容の画像で、画素数が少ないスクリーンネイル画像、及び、サムネイル画像と、主画像等のメタデータであるEXIF及びXMPとを採用することができる。この場合、修復用データは、画像ごとに生成される。すなわち、主画像、スクリーンネイル画像、及び、サムネイル画像それぞれの修復用データが生成される。
　また、この場合、画像関連データ及び修復用データの配置順としては、例えば、EXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、主画像、スクリーンネイル画像の修復用データ、スクリーンネイル画像、XMPの順を採用することができる。その他、例えば、最初に、主画像、スクリーンネイル画像、及び、サムネイル画像それぞれの修復用データをまとめて配置し、その後に、画像関連データを配置する配置順を採用することができる。
　＜修復機能付きHEIFファイルの修復＞
　図１５は、正常でない修復機能付きHEIFファイルの例を示す図である。
　なお、図１５では、説明を簡単にするため、mdatボックスには、画像及びその画像の修復用データのみが、修復用データ、画像の順で配置され、また、ftypボックについては、考慮しないこととする。後述する図１６ないし図１９でも同様である。
　図１５では、仮データのmetaボックスが書き込まれ、その後、１枚目の画像の修復用データ、１枚目の画像、２枚目の画像の修復用データ、２枚目の画像、３枚目の画像の修復用データが、その順で、mdatボックスに書き込まれている。そして、３枚目の画像の修復用データに続いて、３枚目の画像がmdatボックスに書き込まれている最中に、不慮の事象の発生、例えば、修復機能付きHEIFファイルの書き込みが行われているメディア１４がディジタルカメラ１０から取り外しされることによって、３枚目の画像の書き込みの途中で、書き込みが中断され、正常でない修復機能付きHEIFファイルが生成されている。
　このような正常でない修復機能付きHEIFファイルが記録されたメディア１４が、ディジタルカメラ１０に再び装着され、正常でない修復機能付きHEIFファイルが検出されると、ディジタルカメラ１０では、正常でない修復機能付きHEIFファイルを修復する修復処理が開始される。
　修復処理では、まず、書き込みが中断された中断箇所が検出される。
　中断箇所の検出では、ファイル制御部４３は、正常でない修復機能付きHEIFファイルのmetaボックスの先頭から、仮データのmetaボックスのサイズである固定長だけシークする（ファイルの読み書き位置を表す変数であるファイルポインタに、所望の読み書き位置を設定すること等を行う）。シーク後の位置は、１枚目の画像の修復用データの先頭の位置になるので、ファイル制御部４３は、シーク後の位置から１枚目の画像の修復用データを読み出す。
　なお、修復機能付きHEIFファイルの生成において、修復用データの前に、例えば、EXIFが配置されている場合、シークは、そのEXIFのサイズ分だけ多く行われる。この場合、EXIFのサイズは、固定長であることとする。
　また、修復機能付きHEIFファイルの生成において、修復用データの書き込み中に不慮の事象が発生し、正常な修復用データが書き込まれていないために、修復用データを読み出すことができなかった場合、mdatボックスの先頭に配置された画像から、読み出すことができなかった修復用データの直前に配置された画像まで（の管理用メタデータ）が、修復の対象となる。
　ファイル制御部４３は、１枚目の画像の修復用データ（の先頭部分）を読み出すことができた場合、その１枚目の画像の修復用データを用いて、その１枚目の画像の修復用データと、その後に続く１枚目の画像とのサイズを認識する。
　修復用データは、その修復用データのサイズを表すフィールドrecovery_data_size、及び、その修復用データに続く画像のサイズを表すフィールドimage_sizeを、その先頭部分に有する。ファイル制御部４３は、１枚目の画像の修復用データのフィールドrecovery_data_size及びimage_sizeから、１枚目の画像の修復用データのサイズ及び１枚目の画像のサイズを認識する。
　ファイル制御部４３は、１枚目の画像の修復用データのサイズ及び１枚目の画像のサイズを合わせたサイズだけシークする。シーク後の位置は、２枚目の画像の修復用データの先頭の位置になるので、ファイル制御部４３は、シーク後の位置から２枚目の画像の修復用データを読み出す。
　ファイル制御部４３は、１枚目の画像の修復用データと同様にして、２枚目の画像の修復用データを用いて、その２枚目の画像の修復用データと、その後に続く２枚目の画像とのサイズを認識する。
　ファイル制御部４３は、２枚目の画像の修復用データのサイズ及び２枚目の画像のサイズを合わせたサイズだけシークする。シーク後の位置は、３枚目の画像の修復用データの先頭の位置になるので、ファイル制御部４３は、シーク後の位置から３枚目の画像の修復用データを読み出す。
　ファイル制御部４３は、１枚目の画像の修復用データと同様にして、３枚目の画像の修復用データを用いて、その３枚目の画像の修復用データと、その後に続く３枚目の画像とのサイズを認識する。
　ファイル制御部４３は、３枚目の画像の修復用データのサイズ及び３枚目の画像のサイズを合わせたサイズだけシークする。
　シーク後の位置は、正常な修復機能付きHEIFファイルであれば、４枚目の画像の修復用データの先頭の位置（又は修復機能付きHEIFファイルの終わり）になる。しかしながら、図１５では、３枚目の画像の途中で書き込みが中断されているために、４枚目の画像の修復用データの先頭の位置にシークすることができず、シークに失敗する。
　ファイル制御部４３は、３枚目の画像の修復用データのサイズ及び３枚目の画像のサイズを合わせたサイズだけのシークの失敗により、書き込みが中断された中断箇所が、３枚目の画像（の位置）であることを検出する。
　図１６は、中断箇所の検出後の修復処理の例を説明する図である。
　ファイル制御部４３は、中断箇所を検出すると、中断箇所の画像、及び、その画像の修復用データを、修復機能付きHEIFファイルのmdatボックスから削除する。
　その結果、修復機能付きHEIFファイルのmdatボックスは、正常に書き込みが行われたデータのみが格納された状態、ここでは、中断箇所よりも先に書き込まれた１枚目及び２枚目の画像と、その１枚目及び２枚目の画像の修復用データが格納された状態になる。
　なお、中断箇所が、３枚目の画像ではなく、例えば、３枚目の画像が書き込まれる前の３枚目の画像の修復用データである場合、３枚目の画像の修復用データだけが削除される。
　また、１枚の主画像に関連する画像関連データとして、例えば、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPが採用され、その画像関連データとともに、主画像、スクリーンネイル画像、及び、サムネイル画像それぞれの修復用データが書き込まれる場合、これらの画像関連データ及び修復用データのいずれかが中断箇所として検出されたときには、中断箇所を含む画像関連データ及び修復用データのすべてを削除することができる。この場合、例えば、サムネイル画像が中断箇所として検出されたときや、EXIFが中断箇所として検出されたときには、そのサムネイル画像又はEXIFを含む画像関連データ及び修復用データがすべて削除される。
　さらに、画像関連データ及び修復用データが、例えば、EXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、主画像、スクリーンネイル画像の修復用データ、スクリーンネイル画像、XMPの順で配置される場合において、例えば、スクリーンネイル画像が中断箇所として検出されたときには、スクリーンネイル画像と、その直前に配置されたスクリーンネイル画像の修復用データだけを削除し、その前に配置されたEXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、及び、主画像は残すことができる。
　図１７は、中断箇所の画像、及び、その画像の修復用データの削除後の修復処理の例を説明する図である。
　ファイル制御部４３は、中断箇所の画像、及び、その画像の修復用データを削除すると、その削除後の修復機能付きHEIFファイルに正常に書き込まれた画像の修復用データを用いて、その画像の管理用メタデータが格納された正常なmetaボックスを生成（修復）する。
　すなわち、ファイル制御部４３は、正常に書き込まれた１枚目の画像及び２枚目の画像の修復用データと、仮データのmetaボックスに格納されたメタデータとを用いて、正常なHEIFファイルに必要な、確定メタデータ以外の管理用メタデータを生成し、その管理用メタデータと確定メタデータとを、meta用メモリに書き込むことで、正常なmetaボックスを生成する。
　図１８は、正常なmetaボックスの生成後の修復処理の例を説明する図である。
　ファイル制御部４３は、正常なmetaボックスを生成すると、修復機能付きHEIFファイルの仮データのmetaボックスの先頭の位置にシークし、シーク後の位置から、meta用メモリの正常なmetaボックスを、上書きの形で書き込む。これにより、ファイル制御部４３は、正常な（修復機能付き）HEIFファイルを生成する（正常でないHEIFファイルを修復する）。
　図１９は、修復処理の例を説明するフローチャートである。
　ファイル制御部４３は、例えば、メディア１４に記録された修復機能付きHEIFファイルの中から、正常でない修復機能付きHEIFファイルが検出されると、修復処理を開始する。HEIFファイルが、修復機能付きHEIFファイルであるかどうかは、例えば、metaボックスに、修復機能付きHEIFファイルであることを表す新規のフィールド又はボックスを設け、その新規のフィールド又はボックスに応じて判定することができる。
　修復処理では、ステップＳ１４１において、ファイル制御部４３は、メディア１４に記録された正常でない修復機能付きHEIFファイルをオープンする（HEIFファイルにアクセするためのファイルポインタの生成等を行う）。さらに、ファイル制御部４３は、オープンした正常でない修復機能付きHEIFファイルのmetaボックスの先頭から、仮データのmetaボックスのサイズである固定長だけシークし、処理は、ステップＳ１４１からステップＳ１４２に進む。
　ステップＳ１４２では、ファイル制御部４３は、シーク後の位置、すなわち、修復用データの先頭の位置から、その修復用データを読み出し、処理は、ステップＳ１４３に進む。
　ここで、修復用データでは、その修復用データのサイズを表すフィールドrecovery_data_sizeが、固定の位置、例えば、修復用データの先頭部分に配置されている。修復用データの読み出しにあたって、修復用データのサイズは、フィールドrecovery_data_sizeから認識することができる。
　ステップＳ１４３では、ファイル制御部４３は、修復用データの読み出しに成功したかどうかを判定する。
　ステップＳ１４３において、修復用データの読み出しに成功しなかったと判定された場合、すなわち、修復用データの書き込み中に不慮の事象が発生し、修復用データが正常（完全）に書き込まれずに、正常でない修復用データが書き込まれたために、修復用データを読み出すことができなかった場合、ファイル制御部４３は、その正常でない修復用データの位置を、書き込みが中断された中断箇所として検出し、処理は、ステップＳ１４７に進む。
　また、ステップＳ１４３において、修復用データの読み出しに成功したと判定された場合、処理は、ステップＳ１４４に進む。
　ステップＳ１４４では、ファイル制御部４３は、直前のステップＳ１４２で読み出した修復用データ（以下、最新の修復用データともいう）を、meta用メモリに記憶させ、処理は、ステップＳ１４５に進む。
　ステップＳ１４５では、ファイル制御部４３は、meta用メモリに記憶された最新の修復用データからフィールドrecovery_data_size及びimage_sizeを取得する。さらに、ファイル制御部４３は、recovery_data_size及びimage_sizeから、最新の修復用データのサイズ、及び、正常でない修復機能付きHEIFファイルにおいて、最新の修復用データの直後に配置されている画像のサイズを認識する。そして、ファイル制御部４３は、（修復機能付きHEIFファイルの最新の修復用データの先頭から）最新の修復用データのサイズ、及び、その最新の修復用データの直後に配置されている画像のサイズを合わせたサイズだけシークして、処理は、ステップＳ１４５からステップＳ１４６に進む。
　ステップＳ１４６では、ファイル制御部４３は、直前のステップＳ１４５で行われたシークに成功したかどうかを判定する。
　ステップＳ１４６において、シークに成功したと判定された場合、すなわち、シークによって、最新の修復用データの直後に配置されている画像の直後に配置された修復用データの先頭に到達した場合、処理は、ステップＳ１４２に戻る。ステップＳ１４２では、ファイル制御部４３は、上述したように、シーク後の位置、すなわち、修復用データの先頭の位置から、その修復用データを読み出し、以下、同様の処理が繰り返される。
　一方、ステップＳ１４６において、シークに失敗したと判定された場合、すなわち、最新の修復用データの直後に配置されている画像の書き込み中に不慮の事象が発生し、その画像の書き込みが中断された場合、ファイル制御部４３は、その書き込みが中断された、シークに失敗した画像の位置を、中断箇所として検出し、処理は、ステップＳ１４７に進む。
　ステップＳ１４７では、ファイル制御部４３は、中断箇所の画像及び修復用データを、修復機能付きHEIFファイルから削除し、処理は、ステップＳ１４８に進む。
　すなわち、ステップＳ１４７では、中断箇所が修復用データの位置である場合、その修復用データが削除される。また、中断箇所が画像の位置である場合、その画像と、その画像の直前に配置された修復用データとが削除される。
　ステップＳ１４８では、ファイル制御部４３は、meta用メモリに記憶された修復用データ、すなわち、修復機能付きHEIFファイルに正常に書き込まれた修復用データと、仮データのmetaボックスに格納された必要な管理用メタデータとを用いて、正常なHEIFファイルに必要な、確定メタデータ以外の管理用メタデータを生成し、その管理用メタデータと確定メタデータとを、meta用メモリに書き込むことで、正常なmetaボックスを生成する。
　その後、処理は、ステップＳ１４８からステップＳ１４９に進み、ファイル制御部４３は、修復機能付きHEIFファイルの仮データのmetaボックスの先頭の位置にシークし、処理は、ステップＳ１５０に進む。ステップＳ１５０では、ファイル制御部４３は、シーク後の位置から、meta用メモリの正常なmetaボックスを上書きすることで、修復機能付きHEIFファイルを修復して（正常な修復機能付きHEIFファルを生成して）、修復処理を終了する。
　＜修復用データの例＞
　図２０は、修復用データの具体例を示す図である。
　修復用データは、例えば、図２０に示すように、フィールドrecovery_data_size，image_size，next_image_exist，info_type，target_size_x，target_size_y，num_of_grid_x，num_of_grid_y，grid_width，grid_height，grid_list，capture_gamma，colormetory，hvcc_infoが、その順で配置されて構成される。
　フィールドrecovery_data_sizeは、そのフィールドrecovery_data_sizeを有する修復用データのサイズ（データ量）をバイト単位で表す。
　フィールドimage_sizeは、そのフィールドrecovery_data_sizeを有する修復用データの直後の配置される画像のサイズ（データ量）をバイト単位で表す。
　フィールドnext_image_existは、そのフィールドrecovery_data_sizeを有する修復用データの直後の配置される画像の後に、次の画像（及びその画像の修復用データ）が存在するかどうかを表す。次の画像が存在する場合、フィールドnext_image_existは、０及び１のうちの一方の、例えば、１に設定され、存在しない場合、フィールドnext_image_existは、他方の０に設定される。
　フィールドinfo_typeは、そのフィールドrecovery_data_sizeを有する修復用データの直後の配置される画像のピクチャタイプ（INFO種別）を表す。
　フィールドtarget_size_x及びtarget_size_yは、そのフィールドtarget_size_x及びtarget_size_yを有する修復用データの直後に配置された画像の縦及び横のサイズ（画素数）をそれぞれ表す。
　フィールドnum_of_grid_x及びnum_of_grid_yは、そのフィールドnum_of_grid_x及びnum_of_grid_yを有する修復用データの直後に配置された画像が、グリッドアイテムであるグリッド画像（を形成するタイル画像）である場合に、そのグリッド画像の縦及び横の分割数、すなわち、グリッド画像を構成するタイル画像の縦及び横の数をそれぞれ表す。
　フィールドgrid_width及びgrid_heightは、そのフィールドgrid_width及びgrid_heightを有する修復用データの直後に配置された画像がグリッド画像である場合に、そのグリッド画像を構成するタイル画像の縦及び横のサイズ（画素数）をそれぞれ表す。
　フィールドgrid_listは、そのフィールドgrid_listを有する修復用データの直後に配置された画像に関する後述するグリッド情報を表す。
　フィールドcapture_gammaは、そのフィールドcapture_gammaを有する修復用データの直後に配置された画像のガンマに関するガンマ情報を表す。
　フィールドcolormetoryは、そのフィールドcolormetoryを有する修復用データの直後に配置された画像のカラリメトリに関するカラリメトリ情報を表す。
　フィールドhvcc_infoは、そのフィールドhvcc_infoを有する修復用データの直後に配置された画像に関するhvcc情報であって、SPS，PPS，VPS等を含まないhvcc情報を表す。
　図２１は、修復用データのうちのグリッド情報としてのフィールドgrid_listの具体例を示す図である。
　フィールドgrid_listは、例えば、図２１に示すように、フィールドparam_addr，param_size，data_addr，data_size，total_vps_size，num_vps，vps_id，total_sps_size，num_sps，sps_id，total_pps_size，num_pps，pps_idが、その順で配置されて構成される。
　フィールドparam_addr及びparam_sizeは、画像に関するパラメータとしてのVPS，SPS，PPSのアドレス及びサイズ（データ量）をそれぞれ表す。
　フィールドdata_addr及びdata_sizeは、画像に関するES(Elementary Stream)のアドレス及びサイズ（データ量）をそれぞれ表す。
　フィールドtotal_vps_size，num_vps、及び、vps_idは、VPSのサイズ（データ量）、数、及び、ID（NAL(Network Abstraction Layer)ユニットのID）をそれぞれ表す。
　フィールドtotal_sps_size，num_sps、及び、sps_idは、SPSのサイズ（データ量）、数、及び、ID（NALユニットのID）をそれぞれ表す。
　フィールドtotal_pps_size，num_pps、及び、pps_idは、PPSのサイズ（データ量）、数、及び、ID（NALユニットのID）をそれぞれ表す。
　VPS，SPS、及び、PPSの数は、イメージアイテム形式のHEIFファイルでは１個であるが、イメージシーケンス形式のHEIFファイルでは複数である場合がある。
　図２２は、修復処理において、少なくとも修復用データを用いて生成（修復）されるメタデータが格納されるボックスを示す図である。
　ここで、修復用データ（のフィールド）を用いて管理用メタデータが生成（修復）されることを、その管理データが格納されるボックスが生成（修復）される、とも表現する。
　修復用データを用いて生成され得る、metaボックスに格納されるボックスとしては、pitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、ilocボックスがある。
　なお、metaボックスに格納されるボックスのうちのiinfボックス、iprpボックス、ipcoボックス、及び、impaボックスは、確定メタデータが格納されるボックスであるか、又は、他のボックスから生成することができる管理用メタデータが格納されるボックスであり、修復用データなしで生成することができる。
　pitmボックス（に格納される管理用メタデータ）は、フィールドgrid_width及びgrid_heightを用いて生成することができる。
　infeボックス及びdimgボックスは、フィールドnum_of_grid_x及びnum_of_grid_yを用いて生成することができる。
　thumボックスは、フィールドtarget_size_x及びtarget_size_yを用いて生成することができる。
　colrボックスは、フィールドcapture_gamma及びcolormetoryを用いて生成することができる。
　hvccボックスは、フィールドgrid_list及びhvcc_infoを用いて生成することができる。
　ipseボックスは、フィールドtarget_size_x及びtarget_size_yを用いて生成することができる。
　idatボックスは、フィールドnum_of_grid_x，num_of_grid_y，grid_width，grid_height、及び、grid_listを用いて生成することができる。
　ilocボックスは、フィールドgrid_listを用いて生成することができる。
　なお、mdatボックスは、metaボックスに格納されるボックスではないが、mdatボックス内の、中断箇所の修復用データの削除後のデータ、又は、中断箇所の画像、及び、その画像の修復用データの削除後のデータのサイズ（データ量）については、フィールドgrid_listを用いて生成することができる。
　図２３は、修復処理において、少なくとも修復用データを用いて生成される管理用メタデータが格納されるボックスの生成（修復）方法を説明する図である。
　なお、図２３では、修復処理において、修復用データを用いて生成されるボックス以外の修復機能付きHEIFファイルを構成するボックスの生成方法も示されている。
　また、図２３において、関連フィールドとは、ボックス（に格納される管理用メタデータ）を生成するのに用いられる修復用データのフィールドを表す。
　さらに、図２３では、１枚の主画像に関連する画像関連データとして、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPとを採用するとともに、画像関連データ及び修復用データのmdatボックス内の配置順として、EXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、主画像、スクリーンネイル画像の修復用データ、スクリーンネイル画像、XMPの順を採用することとする。
　修復機能付きHEIFファイルは、ftypボックス、metaボックス、及び、mdatボックスを有する。
　metaボックスには、hdlrボックス、pitmボックス、iinfボックス、irefボックス、iprpボックス、idatボックス、及び、ilocボックスが格納され得る。
　iinfボックスには、infeボックスが格納され得る。
　irefボックスには、dimgボックス、thumボックス、及び、cdscボックスが格納され得る。
　iprpボックスには、ipcoボックス、及び、ipmaボックスが格納され得る。iprpボックスに格納され得るipcoボックスには、colrボックス、hvccボックス、ispeボックス、及び、irotボックスが格納され得る。
　ftypボックスは、（あらかじめ決められた）固定の値を用いて生成することができる。
　metaボックスは、metaボックスに格納される各ボックスのサイズ（データ量）を求め、そのサイズを用いて生成することができる。
　hdlrボックスは、固定の値を用いて生成することができる。
　pitmボックスは、修復用データの直後に配置された画像がグリッド画像でない場合、主要アイテムのアイテムIDを１に設定し、その主要アイテムのアイテムIDを用いて生成することができる。また、pitmボックスは、修復用データの直後に配置された画像がグリッド画像（を構成するタイル画像）である場合、修復用データのフィールドnum_of_grid_x及びnum_of_grid_yを用いて、主要アイテムのアイテムIDを、式num_of_grid_x×num_of_grid_y + 1に従って求め、その主要アイテムのアイテムIDを用いて生成することができる。
　iinfボックスは、iprpに格納される各ボックスのサイズ（データ量）と、infeボックスの数（合計数）とを求め、そのサイズと数とを用いて生成することができる。なお、iinfボックスには、mdatボックスに格納されたアイテムの数が格納されるが、画像関連データについて、アイテムの数は、以下のようにカウントされる。１枚の主画像に関連する画像関連データとして、例えば、主画像、EXIF、及び、XMPが採用される場合、１つの画像関連データに対するアイテム数は、主画像、EXIF、及び、XMPの３個になる。また、１枚の主画像に関連する画像関連データとして、例えば、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPが採用される場合、１つの画像関連データに対するアイテム数は、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPの５個になる。例えば、１枚の主画像に関連する画像関連データとして、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPが採用され、mdatボックスに、２枚の主画像の画像関連データが格納されている場合、iinfボックスに格納されるアイテムの数は、１０（＝５×２）個となる。
　infeボックスは、修復用データのフィールドnum_of_grid_x及びnum_of_grid_yを用いて、グリッド画像を構成するタイル画像の数（gridの構成要素数）num_of_grid_x×num_of_grid_yを求め、そのタイル画像の数num_of_grid_x×num_of_grid_yに、１枚の主画像に関連する画像関連データとしての主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPのうちの、主画像以外の構成要素の数、すなわち、スクリーンネイル画像(SCN)、サムネイル画像(thumb)、EXIF、及び、XMPの数である４個を加算した加算値を用いて生成することができる。
　irefボックスは、irefに格納される各ボックスのサイズ（データ量）を求め、そのサイズを用いて生成することができる。
　dimgボックスは、修復用データのフィールドnum_of_grid_x及びnum_of_grid_yを用いて、グリッド画像を構成するタイル画像の数（gridの構成要素数）num_of_grid_x×num_of_grid_yを求め、その数num_of_grid_x×num_of_grid_yを用いて生成することができる。
　thmbボックスは、スクリーンネイル画像(SCN)及びサムネイル画像(thumb)それぞれについて、修復用データのフィールドtarget_size_x及びtaget_size_yを用いて、target_size_x及びtaget_size_yがスクリーンネイル画像又はサムネイル画像のサイズ（画素数）になっているアイテム（画像）のアイテムIDを、スクリーンネイル画像又はサムネイル画像のアイテムIDとして求め、そのアイテムIDを用いて生成することができる。
　cdscボックスは、ここでは、画像関連データ及び修復用データの配置順が決まっているので、画像関連データにおいてサムネイル画像のサイズ（画素数）になっているアイテム（画像）のアイテムIDを基準として、EXIF及びXMPのアイテムIDを求めることができ、そのEXIF及びXMPのアイテムIDを用いて生成することができる。
　iprpボックスは、iprpボックスに格納される各ボックスのサイズを求め、そのサイズを用いて生成することができる。
　ipcoボックスは、ipcoボックスに格納される各ボックスのサイズを求め、そのサイズを用いて生成することができる。
　colrボックスは、修復用データのフィールドcapture_gamma及びcolormetoryを用いて生成することができる。
　hvccボックスは、修復用データのフィールドhvcc_info及びgrid_listを用いて生成することができる。
　ispeボックスは、修復用データのフィールドtarget_size_x及びtaget_size_yを用いて生成することができる。
　irotボックスは、固定の値を用いて生成することができる。
　ipmaボックスは、各アイテムのinfeボックスと、ipco内の各プロパティとの紐づけを行うことができるように、例えば、各アイテムのinfeボックスの順番をあらかじめ決められた順番に固定することで、infeボックスとそのinfeボックスに紐づくipcoボックス内の各プロパティとを用いて生成することができる。
　ここで、各アイテムのinfeボックスの順番を固定することで、infeボックスと、ipco内の、そのinfeボックスに対応するアイテムのプロパティとを紐付けることができる。
　例えば、infeボックスの順番を、アイテムIDが1のアイテムとしての主画像、アイテムIDが2のアイテムとしてのスクリーンネイル画像、アイテムIDが3のアイテムとしてのサムネイル画像、EXIF、XMPの（infeボックスの）順に固定することとする。
　また、ipcoボックスに、プロパティとしての、主画像、スクリーンネイル画像、及び、サムネイル画像に共通の情報、主画像のコーデック情報、主画像の画サイズ情報、スクリーンネイル画像のコーデック情報、スクリーンネイル画像の画サイズ情報、サムネイル画像のコーデック情報、サムネイル画像の画サイズ情報が、その順番で格納されることとする。
　この場合、アイテムIDが1の主画像のプロパティは、ipcoボックス内の1番目、2番目、3番目のプロパティとなる。アイテムIDが2のスクリーンネイル画像のプロパティは、ipcoボックス内の1番目、4番目、5番目のプロパティとなる。アイテムIDが3のサムネイル画像のプロパティは、ipcoボックス内の1番目、6番目、7番目のプロパティとなる。
　したがって、infeボックスと、そのinfeボックスに対応するアイテムのプロパティとを紐付けることができる。
　そして、infeボックスと、そのinfeボックスに紐付けられたプロパティ（infeボックスに対応するアイテムのプロパティ）とを用いて、ipcoボックス内の各アイテムのプロパティへのインデクスを格納したipmaボックスを生成することができる。
　なお、HEIFの規格書には、
　・infeボックスにitemの種類とIDが記載されること、
　・ipcoボックスにコーデック情報(hvcc)や画サイズ(ipse)の情報があること、
　・ipmaボックスにIDに紐づくプロパティが何かが明記されること
　が記載されている。
　idatボックスは、修復用データのフィールドgrid_list，grid_width，grid_height num_of_grid_x、及び、num_of_gird_yを用いて生成することができる。
　ilocボックスは、修復用データのフィールドgrid_listを用いて生成することができる。
　なお、図２２で説明したように、mdatボックス内の（実際に使用する）データのサイズについては、フィールドgrid_listを用いて生成することができる。
　＜本技術を適用したコンピュータの説明＞
　次に、上述した一連の処理は、ハードウエアにより行うこともできるし、ソフトウエアにより行うこともできる。一連の処理をソフトウエアによって行う場合には、そのソフトウエアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
　図２４は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
　プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク９０５やROM９０３に予め記録しておくことができる。
　あるいはまた、プログラムは、ドライブ９０９によって駆動されるリムーバブル記録媒体９１１に格納（記録）しておくことができる。このようなリムーバブル記録媒体９１１は、いわゆるパッケージソフトウエアとして提供することができる。ここで、リムーバブル記録媒体９１１としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。
　なお、プログラムは、上述したようなリムーバブル記録媒体９１１からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク９０５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。
　コンピュータは、CPU(Central Processing Unit)９０２を内蔵しており、CPU９０２には、バス９０１を介して、入出力インタフェース９１０が接続されている。
　CPU９０２は、入出力インタフェース９１０を介して、ユーザによって、入力部９０７が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)９０３に格納されているプログラムを実行する。あるいは、CPU９０２は、ハードディスク９０５に格納されたプログラムを、RAM(Random Access Memory)９０４にロードして実行する。
　これにより、CPU９０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU９０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース９１０を介して、出力部９０６から出力、あるいは、通信部９０８から送信、さらには、ハードディスク９０５に記録等させる。
　なお、入力部９０７は、キーボードや、マウス、マイク等で構成される。また、出力部９０６は、LCD(Liquid Crystal Display)やスピーカ等で構成される。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
　また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
　さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
　また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
　さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
　また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
　なお、本技術は、以下の構成をとることができる。
　＜１＞
　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部を備える
　ファイル処理装置。
　＜２＞
　前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータである
　＜１＞に記載のファイル処理装置。
　＜３＞
　前記ファイル制御部は、前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置する
　＜２＞に記載のファイル処理装置。
　＜４＞
　前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含む
　＜３＞に記載のファイル処理装置。
　＜５＞
　前記修復用データは、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復するデータを含む
　＜２＞ないし＜４＞のいずれかに記載のファイル処理装置。
　＜６＞
　前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
　前記ファイル制御部は、前記画像の修復用データと、前記関連画像の修復用データとを書き込む
　＜１＞ないし＜５＞のいずれかに記載のファイル処理装置。
　＜７＞
　前記関連画像は、前記画像より画素数が少ない画像である
　＜６＞に記載のファイル処理装置。
　＜８＞
　前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納される
　＜１＞ないし＜７＞のいずれかに記載のファイル処理装置。
　＜９＞
　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むことを含む
　ファイル処理方法。
　＜１０＞
　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部
　として、コンピュータを機能させるためのプログラム。
　＜１１＞
　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部を備える
　ファイル処理装置。
　＜１２＞
　前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータであり、
　前記ファイル制御部は、前記修復用データを用いて、前記管理用メタデータを生成する
　＜１１＞に記載のファイル処理装置。
　＜１３＞
　前記ファイル制御部は、前記HEIFファイルから、書き込みが中断された中断箇所の前記画像を削除し、前記修復用データを用いて、前記中断箇所よりも先に書き込まれた前記画像が格納された前記HEIFファイルを生成する
　＜１２＞に記載のファイル処理装置。
　＜１４＞
　前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置し、
　前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含み、
　前記ファイル制御部は、前記修復用データの先頭から、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを合わせたサイズのシークに失敗した場合、前記画像を前記中断箇所として検出する
　＜１３＞に記載のファイル処理装置。
　＜１５＞
　前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
　前記ファイル制御部は、前記画像及び前記関連画像のいずれかが前記中断箇所として検出された場合、前記画像及び前記関連画像を削除する
　＜１３＞又は＜１４＞に記載のファイル処理装置。
　＜１６＞
　前記関連画像は、前記画像より画素数が少ない画像である
　＜１５＞に記載のファイル処理装置。
　＜１７＞
　前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納され、
　前記ファイル制御部は、前記画像及び前記メタデータのいずれかが前記中断箇所として検出された場合、前記画像及び前記メタデータを削除する
　＜１３＞ないし＜１６＞のいずれかに記載のファイル処理装置。
　＜１８＞
　前記ファイル制御部は、前記修復用データを用いて、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復する
　＜１２＞ないし＜１７＞のいずれかに記載のファイル処理装置。
　＜１９＞
　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復することを含む
　ファイル処理方法。
　＜２０＞
　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部
　として、コンピュータを機能させるためのプログラム。
　１０　ディジタルカメラ，　１１　光学系，　１３　信号処理部，　１４　メディア，　１５，１６　I/F，　１７　ボタン／キー，　１８　タッチパネル，　１９　液晶パネル，　２０　ビューファインダ，　２１　I/F，　４１　光学系／イメージセンサ制御部，　４２　符号化制御部，　４３　ファイル制御部，　４４　メディア制御部，　４５　操作制御部，　４６　表示制御部，　４７　UI制御部，　９０１　バス，　９０２　CPU，　９０３　ROM，　９０４　RAM，　９０５　ハードディスク，　９０６　出力部，　９０７　入力部，　９０８　通信部，　９０９　ドライブ，　９１０　入出力インタフェース，　９１１　リムーバブル記録媒体

Claims (20)

  1. 　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部を備える
    　ファイル処理装置。
  2. 　前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータである
    　請求項１に記載のファイル処理装置。
  3. 　前記ファイル制御部は、前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置する
    　請求項２に記載のファイル処理装置。
  4. 　前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含む
    　請求項３に記載のファイル処理装置。
  5. 　前記修復用データは、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復するデータを含む
    　請求項２に記載のファイル処理装置。
  6. 　前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
    　前記ファイル制御部は、前記画像の修復用データと、前記関連画像の修復用データとを書き込む
    　請求項１に記載のファイル処理装置。
  7. 　前記関連画像は、前記画像より画素数が少ない画像である
    　請求項６に記載のファイル処理装置。
  8. 　前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納される
    　請求項１に記載のファイル処理装置。
  9. 　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むことを含む
    　ファイル処理方法。
  10. 　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部
    　として、コンピュータを機能させるためのプログラム。
  11. 　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部を備える
    　ファイル処理装置。
  12. 　前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータであり、
    　前記ファイル制御部は、前記修復用データを用いて、前記管理用メタデータを生成する
    　請求項１１に記載のファイル処理装置。
  13. 　前記ファイル制御部は、前記HEIFファイルから、書き込みが中断された中断箇所の前記画像を削除し、前記修復用データを用いて、前記中断箇所よりも先に書き込まれた前記画像が格納された前記HEIFファイルを生成する
    　請求項１２に記載のファイル処理装置。
  14. 　前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置し、
    　前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含み、
    　前記ファイル制御部は、前記修復用データの先頭から、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを合わせたサイズのシークに失敗した場合、前記画像を前記中断箇所として検出する
    　請求項１３に記載のファイル処理装置。
  15. 　前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
    　前記ファイル制御部は、前記画像及び前記関連画像のいずれかが前記中断箇所として検出された場合、前記画像及び前記関連画像を削除する
    　請求項１３に記載のファイル処理装置。
  16. 　前記関連画像は、前記画像より画素数が少ない画像である
    　請求項１５に記載のファイル処理装置。
  17. 　前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納され、
    　前記ファイル制御部は、前記画像及び前記メタデータのいずれかが前記中断箇所として検出された場合、前記画像及び前記メタデータを削除する
    　請求項１３に記載のファイル処理装置。
  18. 　前記ファイル制御部は、前記修復用データを用いて、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復する
    　請求項１２に記載のファイル処理装置。
  19. 　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復することを含む
    　ファイル処理方法。
  20. 　静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部
    　として、コンピュータを機能させるためのプログラム。
PCT/JP2021/006575 2020-03-09 2021-02-22 ファイル処理装置、ファイル処理方法、及び、プログラム WO2021182090A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2022505894A JPWO2021182090A1 (ja) 2020-03-09 2021-02-22
CN202180018881.8A CN115211104A (zh) 2020-03-09 2021-02-22 文件处理设备、文件处理方法和程序
US17/797,962 US20230039708A1 (en) 2020-03-09 2021-02-22 File processing device, file processing method, and program
EP21767892.9A EP4106325A4 (en) 2020-03-09 2021-02-22 FILE PROCESSING DEVICE, FILE PROCESSING METHOD AND PROGRAM

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020039881 2020-03-09
JP2020-039881 2020-03-09

Publications (1)

Publication Number Publication Date
WO2021182090A1 true WO2021182090A1 (ja) 2021-09-16

Family

ID=77670543

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/006575 WO2021182090A1 (ja) 2020-03-09 2021-02-22 ファイル処理装置、ファイル処理方法、及び、プログラム

Country Status (5)

Country Link
US (1) US20230039708A1 (ja)
EP (1) EP4106325A4 (ja)
JP (1) JPWO2021182090A1 (ja)
CN (1) CN115211104A (ja)
WO (1) WO2021182090A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190052937A1 (en) * 2016-02-16 2019-02-14 Nokia Technologies Oy Media encapsulating and decapsulating
WO2019193097A1 (en) * 2018-04-05 2019-10-10 Canon Kabushiki Kaisha Method and apparatus for encapsulating images in a file
WO2019192870A1 (en) * 2018-04-05 2019-10-10 Canon Kabushiki Kaisha Method and apparatus for encapsulating images or sequences of images with proprietary information in a file

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005301641A (ja) * 2004-04-12 2005-10-27 Matsushita Electric Ind Co Ltd 映像撮影装置
CN104365090A (zh) * 2012-06-13 2015-02-18 富士胶片株式会社 图像处理系统、发送侧装置及接收侧装置
WO2015196394A1 (en) * 2014-06-25 2015-12-30 SZ DJI Technology Co., Ltd. Multimedia file repair methods and apparatus
JP6451102B2 (ja) * 2014-07-03 2019-01-16 大日本印刷株式会社 動画修復装置、動画修復方法、および、動画修復装置用のプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190052937A1 (en) * 2016-02-16 2019-02-14 Nokia Technologies Oy Media encapsulating and decapsulating
WO2019193097A1 (en) * 2018-04-05 2019-10-10 Canon Kabushiki Kaisha Method and apparatus for encapsulating images in a file
WO2019192870A1 (en) * 2018-04-05 2019-10-10 Canon Kabushiki Kaisha Method and apparatus for encapsulating images or sequences of images with proprietary information in a file

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"High efficiency coding and media delivery in heterogeneous environments", ISO/IEC 23008-12:2017
See also references of EP4106325A4

Also Published As

Publication number Publication date
EP4106325A4 (en) 2023-08-02
JPWO2021182090A1 (ja) 2021-09-16
US20230039708A1 (en) 2023-02-09
CN115211104A (zh) 2022-10-18
EP4106325A1 (en) 2022-12-21

Similar Documents

Publication Publication Date Title
JP2011142586A (ja) 画像処理装置、情報記録媒体、および画像処理方法、並びにプログラム
US20220269716A1 (en) File processing device, file processing method, and program
JP4779921B2 (ja) データ処理装置及びデータ処理方法、並びにコンピュータ・プログラム
CN1321526C (zh) 运动图像编辑装置及其控制方法
WO2020196006A1 (ja) ファイル生成装置、ファイル生成方法、ファイル再生装置、ファイル再生方法、及び、プログラム
US20220309035A1 (en) File processing device, file processing method, and program
WO2021182090A1 (ja) ファイル処理装置、ファイル処理方法、及び、プログラム
JP7468530B2 (ja) ファイル処理装置、ファイル処理方法、及び、プログラム
WO2021117481A1 (ja) データ処理装置、データ処理方法、及び、プログラム
US20230006818A1 (en) File processing device and file processing method
CN104469238B (zh) 运动图像数据记录设备及其控制方法
WO2021182089A1 (ja) ファイル処理装置、ファイル処理方法、及び、プログラム
US20130170814A1 (en) Image Pickup Device and Control Method Thereof
US20230124473A1 (en) Image processing device and image processing method
JP2014096194A (ja) 記録装置及び記録方法
JP2011130219A (ja) 映像記録装置および映像再生装置
JP2009224853A (ja) 映像収録装置及び素材管理方法
JP2010147901A (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: 21767892

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022505894

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021767892

Country of ref document: EP

Effective date: 20220914

NENP Non-entry into the national phase

Ref country code: DE