Document processing apparatus, document processing method, and program product
By writing repair data in the HEIF file to repair abnormal files, the image loss problem caused by power interruption or media removal during HEIF file writing is solved, and the effect of reducing the number of images lost by users is achieved.
Patent Information
- Application Number
- CN202180018881.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-03-09
- Filing Date
- 2021-02-22
- Publication Date
- 2025-06-10
- Estimated Expiration
- 2041-02-22
AI Technical Summary
During the writing process, abnormal files are generated due to power interruption or media removal, resulting in the user losing all images stored in the HEIF file.
Design a file processing device and method to reduce the number of images lost by users by writing repair data into a HEIF file.
By using repair data to repair HEIF files, it can effectively reduce image loss caused by power interruption or media removal, ensuring the integrity of HEIF files and the security of user data.
Smart Images

Figure CN115211104B_ABST
Abstract
Description
Technical Field
[0001] The present technology relates to a document processing device, a document processing method, and a program, and more particularly to a document processing device, a document processing method, and a program that can reduce the number of images lost by a user, for example. Background Art
[0002] As a file format for efficiently storing images, there is an High Efficiency Image File Format (HEIF) (see Non-Patent Document 1).
[0003] Citation List
[0004] Non-Patent Document
[0005] Non-Patent Document 1: ISO / IEC 23008-12:2017, Information technology - Efficient coding and media delivery in heterogeneous environments - Part 12: Image file format Summary of the Invention
[0006] Problems to be Solved by the Invention
[0007] For example, an HEIF file can store images of multiple still images, such as images captured by continuous shooting. When an HEIF file stores multiple images, the writing time required to write (record) the HEIF file increases as the number of images increases. In the case of a long writing time, during the writing of the HEIF file, due to power interruption caused by removing the battery or unplugging the plug, removing the medium, etc., there is a high possibility of generating an abnormal HEIF file. An abnormal HEIF file is a file that does not have the format of an HEIF file.
[0008] The abnormal HEIF file cannot be reproduced, and the user loses all the images stored in the HEIF file.
[0009] The present technology has been made in view of such a situation, and aims to reduce the number of images lost by the user.
[0010] Solutions to the Problems
[0011] The first document processing device or the first program of the present technology is: a document processing device including: a file control unit that writes repair data for repairing the HEIF file into an High Efficiency Image File Format (HEIF) file that stores still images; or a program for causing a computer to function as such a document processing device.
[0012] The first file processing method of the present technology is: A file processing method, including: writing repair data into a High Efficiency Image File Format (HEIF) file that stores still images, where the repair data is used to repair the HEIF file.
[0013] In the first file processing device, the first file processing method, and the first program of the present technology, repair data is written into a High Efficiency Image File Format (HEIF) file that stores still images, and the repair data is used to repair the HEIF file.
[0014] The second file processing device or the second program of the present technology is: A file processing device, including: a file control unit, where the file control unit uses repair data to repair a High Efficiency Image File Format (HEIF) file that stores still images, the repair data is used to repair the HEIF file, and the repair data is written into the HEIF file; or a program that causes a computer to function as such a file processing device.
[0015] The second file processing method of the present technology is: A file processing method, including: using repair data to repair a High Efficiency Image File Format (HEIF) file that stores still images, the repair data is used to repair the HEIF file, and the repair data is written into the HEIF file.
[0016] In the second file processing device, the second file processing method, and the second program of the present technology, repair data is used to repair a High Efficiency Image File Format (HEIF) file that stores still images, the repair data is used to repair the HEIF file, and the repair data is written into the HEIF file.
[0017] Note that the file processing device can be an independent device or can be an internal block included in a device.
[0018] In addition, the program can be provided by being transmitted through a transmission medium or recorded on a recording medium. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] Figure 1 is a block diagram showing a configuration example of an embodiment of a digital camera to which the present technology is applied.
[0020] Figure 2 is a diagram showing an example of the format of a JPEG file conforming to the Joint Photographic Experts Group (JPEG).
[0021] Figure 3 is a diagram showing an example of the ISO Base Media File Format.
[0022] Figure 4 is a diagram showing an example of the format of a HEIF file conforming to HEIF.
[0023] Figure 5 A diagram showing an example of the format of a HEIF file that shows the image item format.
[0024] Figure 6 A diagram showing an example of an iprp box.
[0025] Figure 7 A diagram showing an example of the format of a HEIF file that shows the image sequence format.
[0026] Figure 8 A diagram showing an example of a trak box.
[0027] Figure 9 A diagram showing an example of a collection file that stores a set of a main image and a thumbnail image.
[0028] Figure 10 A diagram showing an example of a sequence file that stores a track of a main image and a track of a thumbnail image of the main image.
[0029] Figure 11 A diagram showing an example of a HEIF file that stores a tile image.
[0030] Figure 12 A diagram showing an overview of a HEIF file with a repair function generated by a file control unit 43.
[0031] Figure 13 A diagram showing an overview of using repair data to repair an abnormal HEIF file (with a repair function).
[0032] Figure 14 A flowchart showing an example of a process for generating a HEIF file with a repair function.
[0033] Figure 15 A diagram showing an example of an abnormal HEIF file with a repair function.
[0034] Figure 16 A diagram showing an example of a repair process after detecting an interrupted part.
[0035] Figure 17 A diagram showing an example of a repair process after deleting an image of an interrupted part and repair data of the image.
[0036] Figure 18 A diagram showing an example of a repair process after generating a normal meta box.
[0037] Figure 19Is a flowchart showing an example of a repair process.
[0038] Figure 20 Is a diagram showing a specific example of repair data.
[0039] Figure 21 Is a diagram showing a specific example of grid information (field) grid_list (grid list) in repair data.
[0040] Figure 22 Is a diagram showing a box for storing metadata generated (repaired) at least using repair data in a repair process.
[0041] Figure 23 Is a diagram showing a method for generating (repairing) a management metadata stored at least using repair data in a repair process.
[0042] Figure 24 Is a block diagram showing a configuration example of an embodiment of a computer to which this technology is applied. Detailed implementation
[0043] <An embodiment of a digital camera to which this technology is applied>
[0044] Figure 1 Is a block diagram showing a configuration example of an embodiment of a digital camera to which this technology is applied.
[0045] The digital camera 10 includes an optical system 11, an image sensor 12, a signal processing unit 13, a medium 14, interfaces (I / F) 15 and 16, buttons / keys 17, a touch panel 18, a liquid crystal panel 19, a viewfinder 20, an I / F 21, etc.
[0046] The optical system 11 condenses the light from the subject on the image sensor 12.
[0047] The image sensor 12 receives the light from the optical system 11, performs imaging through photoelectric conversion, generates image data as an electrical signal, and provides the image data to the signal processing unit 13.
[0048] The signal processing unit 13 includes an optical system / image sensor control unit 41, an encoding control unit 42, a file control unit 43, a medium control unit 44, an operation control unit 45, a display control unit 46, and a UI control unit 47.
[0049] The optical system / image sensor control unit 41 controls the optical system 11 and the image sensor 12, and provides the (data) of the image obtained through imaging performed according to this control to the encoding control unit 42.
[0050] The encoding control unit 42 provides the image from the optical system / image sensor control unit 41 to the display control unit 46, encodes the image as needed, and provides the image to the file control unit 43. In addition, the encoding control unit 42 decodes the image provided from the file control unit 43 as needed, and provides the image to the display control unit 46.
[0051] The file control unit 43 generates a file storing the image provided from the encoding control unit 42, and provides the file to the medium control unit 44. In addition, the file control unit 43 reproduces the file provided from the medium control unit 44, that is, reads data such as the image stored in the file. For example, the image read from the file is provided from the file control unit 43 to the encoding control unit 42.
[0052] The medium control unit 44 controls the file exchange with the medium 14 and the I / Fs 15 and 16. For example, the medium control unit 44 causes the file from the file control unit 43 to be recorded on the medium 14 or to be sent from the I / Fs 15 and 16. In addition, the medium control unit 44 reads a file from the medium 14, or causes the I / Fs 15 and 16 to receive the file and provides the file to the file control unit 43.
[0053] The operation control unit 45 provides an operation signal corresponding to the operation to the necessary blocks according to the operation of the buttons / keys 17 or the touch panel 18 by the user.
[0054] The display control unit 46 performs display control and the like to provide the image etc. provided from the encoding control unit 42 to the liquid crystal panel 19, the viewfinder 20, and the I / F 21 for display.
[0055] The UI control unit 47 manages the user interface (UI) control.
[0056] For example, the medium 14 is a storage medium such as an SD card. For example, the I / F 15 is an I / F of a local area network (LAN) such as Wi-Fi (registered trademark) or Ethernet (registered trademark). For example, the I / F 16 is a universal serial bus (USB) I / F. When a command or other information is input to the digital camera 10, the buttons / keys 17 and the touch panel 18 are operated by the user. The touch panel 18 may be integrally formed with the liquid crystal panel 19. The liquid crystal panel 19 and the viewfinder 20 display the image etc. provided from the display control unit 46. The I / F 21 is an I / F that transmits at least an image, such as a high-definition multimedia interface (HDMI) (registered trademark) or a display port (DP).
[0057] In the digital camera 10 configured as described above, the optical system / image sensor control unit 41 generates, for example, a YUV image having the same resolution (number of pixels) (size) as the resolution (number of pixels) (size) of the original image based on the image of the original data obtained by imaging with the image sensor 12, and provides this image together with the original image to the encoding control unit 42. The encoding control unit 42 generates the main image of the HEIF file, etc. based on the YUV image from the optical system / image sensor control unit 41. For example, the YUV image from the optical system / image sensor control unit 41 can be directly used as the main image of the HEIF file.
[0058] The encoding control unit 42 generates, as a first other image based on the main image, a YUV image (hereinafter also referred to as a screennail image) having a resolution lower than that of the main image, for example, for display on the liquid crystal panel 19 or an external display; and generates, as a second other image based on the main image, a YUV image (hereinafter also referred to as a thumbnail image) having a resolution lower than that of the screennail image, for example, for index display (list display). For example, the encoding control unit 42 provides the screennail image to the liquid crystal panel 19 via the display control unit 46 to display the screennail image as a so-called through-the-lens image. For example, as the thumbnail image, an image having a size of 320 pixels or less on the long side can be adopted. The ratio of the size (number of pixels) between the main image and the screennail 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 can be, for example, 200 times or less. The ratio of the size between the screennail 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 also be 200 times or less. For example, as the screennail image, an image having a resolution of 4K or higher can be adopted. In addition, for example, as the screennail image, a 4K (QFHD) or FHD image can be adopted according to the user's selection. In addition, images having the same resolution can be adopted as the main image and the screennail image. In the case where images having the same resolution are adopted as the main image and the screennail image, both the main image and the screennail image can be stored in the HEIF file, or the main image can be stored without storing the screennail image. In the case where the main image is stored in the HEIF file without storing the screennail image, the size of the main image can be adjusted and used as the screennail image.
[0059] In addition, the encoding control unit 42 encodes the main image, the screenshot image, and the thumbnail image corresponding to the original image (the main image, the screenshot image, and the thumbnail image generated from the same original image) as needed, and provides them to the file control unit 43 together with the original image.
[0060] For example, the file control unit 43 generates a raw file storing the original image, a HEIF file and / or a JPEG file storing the corresponding main image, screenshot image, and thumbnail image (the main image, the screenshot image, and the thumbnail image generated from the same original image) as needed, and provides the generated files to the medium control unit 44. The HEIF file is a file conforming to the High Efficiency Image File Format (HEIF), and the JPEG file is a file conforming to the Joint Photographic Experts Group (JPEG).
[0061] The medium control unit 44 records the raw file, the HEIF file, or the JPEG file from the file control unit 43 on the medium 14, or sends the raw file, the HEIF file, or the JPEG file from the I / F 15 or 16.
[0062] For example, the type of file to be generated by the file control unit 43 (e.g., raw file, HEIF file, JPEG file, etc.) can be selected according to the user's operation (specification). In addition, as described later, the HEIF file includes an image item format and an image sequence format. For example, which of the image item format and the image sequence format to adopt can be selected according to the user's operation. In addition, the file control unit 43 can perform mutual conversion between the HEIF file and the JPEG file according to the user's operation.
[0063] In addition, the file control unit 43 can generate multiple files having the same image content but different codecs, image sizes (resolutions), color formats, and bit depths.
[0064] When the file control unit 43 generates multiple files having the same image content, the encoding control unit 42 generates an image stream (file stream) to be stored in each of the multiple files from the YUV image from the optical system / image sensor control unit 41.
[0065] The encoding control unit 42 can generate image streams having different codecs, image sizes (resolutions), color formats, and bit depths.
[0066] For example, the encoding control unit 42 can generate an image of a predetermined size, a predetermined color format, and a predetermined bit depth from the YUV image provided by the optical system / image sensor control unit 41, and generate a first stream obtained by encoding the image using a predetermined codec (encoding method). In addition, the encoding control unit 42 can generate an image having another size, another color format, and another bit depth from the same YUV image provided by the optical system / image sensor control unit 41, and generate a second stream obtained by encoding the image using another codec.
[0067] Then, the file control unit 43 can generate a file storing the first stream and a file storing the second stream.
[0068] <JPEG file>
[0069] Figure 2 is a diagram showing an example of the format of a JPEG file conforming to the Joint Photographic Experts Group (JPEG).
[0070] A JPEG file is configured to store, for example, Exif (EXIF) metadata, a thumbnail image, Extensible Metadata Platform (XMP) (registered trademark) metadata, an MPF indicating the storage locations (positions) of the main image and the simplified display image, the main image, and the simplified display image. For example, a screenshot image can be adopted as the simplified display image.
[0071] <ISO Base Media File Format>
[0072] Figure 3 is a diagram showing an example of the ISO Base Media File Format.
[0073] HEIF (ISO / IEC 23008-12) is a file format conforming to the ISO Base Media File Format (ISO / IEC 14496-12), so a HEIF file conforms to the ISO Base Media File Format.
[0074] The ISO Base Media File Format includes units called boxes as containers for storing data and has a structure called a box structure.
[0075] A box includes a type (box type), actual data (data), etc. The type indicates the type of the actual data in the box. As the actual data, reproducible media data (such as images (still images, moving images), audio, and subtitles), attribute names (field names), and attribute values (field values) of attribute names (variables represented by the attribute names), and various other data can be adopted.
[0076] In addition, a box can be used as actual data. That is to say, a box can have a box as actual data, so a hierarchical structure can be formed.
[0077] A base media file conforming to the ISO base media file format may include an ftyp box, a moov box (MovieBox), a meta box (MetaBox), an mdat box (MediaDataBox), etc. The ftyp box stores identification information for identifying the file format. The Moov box can store trak boxes, etc. The meta box can store iinf boxes, iprp boxes, iref boxes, iloc boxes, etc. The mdat box can store media data (AV data) and any other data.
[0078] HEIF conforms to the above ISO base media file format.
[0079] <HEIF file>
[0080] Figure 4 is a diagram showing an example of the format of a HEIF file conforming to HEIF.
[0081] HEIF files are roughly divided into an image item format and an image sequence format. In addition, the image item format includes a single image format having only one item and an image set format having multiple items, which will be described later.
[0082] A HEIF file in the image item format includes an ftyp box, a meta box, and an mdat box.
[0083] A HEIF file in the image sequence format includes an ftyp box, a moov box, and an mdat box.
[0084] Note that a HEIF file can include not only one of the meta box and the moov box, but also both the meta box and the moov box.
[0085] The ftyp box stores identification information for identifying the file format, such as whether the file is a HEIF file in the image item format or a HEIF file in the image sequence format.
[0086] The meta box and the moov box store metadata required for the reproduction, management, etc. of the media data stored in the mdat box, such as metadata about the storage location of the media data.
[0087] The mdat box stores media data (AV data), etc.
[0088] In digital camera 10, for example, it is possible to select, according to a user operation, which one of a HEIF file in an image item format and a HEIF file in an image sequence format is to be generated. Further, in a case where an image is encoded and stored in the mdat box of a HEIF file, only intra-frame encoding is allowed for the image item format, and both intra-frame encoding and inter-frame encoding are allowed for the image sequence format. Thus, for example, in a case where high-speed access to data stored in a HEIF file is prioritized, a HEIF file in the image item format can be selected, and in a case where reduction of the size (data amount) of a HEIF file is prioritized, a HEIF file in the image sequence format can be selected.
[0089] Figure 5 is a diagram showing an example of the format of a HEIF file in the image item format.
[0090] In a HEIF file in the image item format, for example, the ftyp box stores information (such as mif1) (as an attribute value) indicating that the HEIF file is in the image item format.
[0091] The moov box stores the iinf box, the iref box, the iprp box, and the iloc box.
[0092] The iinf box stores (indicates) the number (the attribute name and the attribute value) of items (which are media data (AV data) stored in the mdat box), etc. An item is one piece of data stored in the mdat box of a HEIF file in the image item format, and for example, one image (frame) is an item. In the present specification, one image is also referred to as a frame regardless of whether it is a still image or a moving image. One frame is one item.
[0093] The iref box stores information indicating the association between the respective items. For example, the mdat box can store each of a corresponding main image, a screenshot image, and a thumbnail image as an item. In a case where the mdat box stores item I1 as the main image, item I2 as the screenshot image, and item I3 as the thumbnail image, the iref box stores information indicating that item I2 is a screenshot image of the main image of item I1 and information indicating that item I3 is a thumbnail image of the main image of item I1.
[0094] The iprp box stores information about the attributes of the items.
[0095] The iloc box stores information about the storage locations of the items stored in the mdat box.
[0096] For example, the mdat box in the image item format (of the HEIF file) stores the frames of an image as items. The mdat box can store one or more items. In addition, the mdat box can encode the frames and store them as items. However, note that encoding the frames as items stored in the mdat box in the image item format is limited to intra-frame encoding. For example, as an encoding method (codec) for encoding the frames as items, HEVC or the like can be adopted.
[0097] Figure 6 is a diagram showing Figure 5 an example of the iprp box in
[0098] The iprp box stores the ipco box and the ipma box related to the attributes of the item. The ipco box stores the attributes of the items stored in the mdat box, such as codec information about the codec of the image as an item and image size information about the size of the image as an item. The ipma box stores the index (pointer) of the items stored in the mdat box to the attributes stored in the ipco box.
[0099] Figure 7 is a diagram showing an example of the format of the HEIF file in the image sequence format.
[0100] In the HEIF file in the image sequence format, for example, the ftyp box stores information indicating that the HEIF file is in the image sequence format, such as msf1.
[0101] The moov box stores the trak box. The trak box stores information about the track stored in the mdat box.
[0102] A track includes a segment of independent media data reproduced according to a timeline, such as an image or sound. For example, a track includes one or more image frames forming an elementary stream. For the tracks stored in the mdat box, multiple tracks can be reproduced simultaneously, such as tracks of an image and sound recorded simultaneously.
[0103] The media data of a track is composed of units called samples. A sample is the smallest unit (access unit) in the case of accessing the media data in the HEIF file. Therefore, the media data in the HEIF file cannot be accessed in units smaller than a sample.
[0104] For example, for image media data, one frame or the like is a sample. In addition, for example, for sound media data, one audio frame or the like defined in the standard of the sound media data is a sample.
[0105] In the mdat box in the image sequence format (of the HEIF file), 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 consecutive addresses.
[0106] When storing multiple tracks as media data in the mdat box, the multiple tracks are interleaved and arranged in units of blocks.
[0107] As described above, the mdat box in the image sequence format stores one or more tracks of media data including images, sounds, etc.
[0108] The mdat box can encode and store image frames included in the track. When encoding the frames included in the track stored in the mdat box in the image sequence format, a long group of pictures (GOP) can be used as the GOP, and both intra-frame encoding and inter-frame encoding can be employed. As a codec for encoding the frames included in the track, for example, HEVC, etc. can be used.
[0109] Figure 8 It is a diagram showing an example of the trak box.
[0110] The trak box can store the tkhd box and the mdia box. The tkhd box stores the header information of the track, such as the creation date and time of the track managed by the trak box. The mdia box stores the minf box, etc. The minf box stores the stbl box. The stbl box stores the stsd box, the stsc box, the stsz box, and the stco box, and these stsd box, stsc box, stsz box, and stco box store the samples of the track and thus store the information for accessing the blocks. The stsd box stores the codec information about the codec of the track. The stsc box stores the block size (the number of samples per block). The stsz box stores the sample size. The stco box stores the block offset, that is, the offset of the arrangement position of each block of the track stored in the mdat box.
[0111] Here, the HEIF file in the image item format is also called a collection file, and the HEIF file in the image sequence format is also called a sequence file.
[0112] In the digital camera 10, a HEIF file can be generated, which stores the main image and one or both of the required screenshot images and thumbnail images.
[0113] <Collection file>
[0114] Figure 9 It is a diagram showing an example of the collection file storing the main image and the thumbnail image.
[0115] Here, it is assumed that the frame (item) is encoded by HEVC and stored in the mdat box of the collection file.
[0116] The ftyp box stores the heic as identification information for identifying the file format, where the heic indicates that the format is an image item format and the codec is HEVC.
[0117] The iinf box stores the number of items stored in the mdat box. In Figure 9 , the mdat box stores a total of four items (frames), including the main image identified by item ID #1 (hereinafter also described as main image item #1), main image item #2, the thumbnail image identified by item ID #101 (hereinafter also described as thumbnail image item #101), and thumbnail image item #102. Therefore, the number of items is four. Note that thumbnail image item #101 is a thumbnail image of main image item #1, and thumbnail image item #102 is a thumbnail image of main image item #2.
[0118] For example, the iinf box also stores the infe box for each item stored in the mdat box. In the infe box, the item ID and item type for identifying the item are registered. In Figure 9 , there are infe boxes for main image item #1, main image item #2, thumbnail image item #101, and thumbnail image item #102.
[0119] For example, the iref box stores the thmb box as information for associating the items stored in the mdat box. The thmb box stores the referrer and the reference destination in association with each other as information for associating the main image with the thumbnail image of the main image. In the thmb box, the reference source represents the item ID of the main image, and the reference destination represents the item ID of the thumbnail image of the main image identified by the item ID of the reference source. Therefore, based on the reference destination associated with the reference source, the item ID of the thumbnail image of the main image identified by the item ID represented by the reference source can be identified. In addition, based on 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 identified.
[0120] As Figure 6 described, the iprp box stores the ipco box and the ipma box. As Figure 6 described, the ipco box stores the attributes of the frames that are the items stored in the mdat box, such as codec information about the codec and image size information about the size. As Figure 6 described, the ipma box stores the index of the items stored in the mdat box to the attributes stored in the ipco box.
[0121] As Figure 6 described, the iloc box stores information about the storage location of the items in the mdat box. In Figure 9Among them, the number of items stored in the iloc box is 4. In addition, the iloc box stores the offset and size of the storage location of each of the main image item #1 and main image item #2 and thumbnail image item #101 and thumbnail image item #102 stored in the mdat box in association with the item ID.
[0122] <Sequence file>
[0123] Figure 10 is a diagram showing an example of a sequence file of the track storing the main image and the track of the thumbnail image of the main image.
[0124] Here, it is assumed that the frames are encoded by HEVC and stored in the mdat box of the sequence file.
[0125] The ftyp box stores hevc as identification information for identifying the file format, and this hevc indicates that the format is an image sequence format and the codec is HEVC.
[0126] As Figure 7 described, the moov box stores trak boxes, and each trak box manages the tracks stored in the mdat box. In Figure 10 , the mdat box stores the track of the main image identified by the track ID #1 (hereinafter also described as track #1) and track #2 of the thumbnail image of the main image of track #1. Therefore, the moov box stores the trak box that manages track #1 and the trak box that manages track #2. The nth (frame) thumbnail image of track #2 is the thumbnail image of the nth main image of track #1.
[0127] For example, when continuous shooting is performed by the digital camera 10 and the main images and thumbnail images of a plurality of frames obtained by continuous shooting are recorded as one track, the sequence file is useful.
[0128] The tkhd box of the trak box that manages track #1 of the main image stores the track ID #1 that identifies track #1, the image size of the main image included in track #1, the rotation information indicating the direction of the digital camera 10 when the main image is captured, and the creation date and time of track #1. The tkhd box of the trak box that manages track #2 of the thumbnail image stores the track ID #2 that identifies track #2 and the creation date and time of track #2.
[0129] In addition to Figure 7 the tkhd box and mdia box described in Figure 10In this case, the tref box is set within the trak box of the management track #2. Thus, the tref box stores information indicating that the other track related to track #2 is track #1 (track ID = 1) and that the data included in track #2 is a thumbnail image (track #2 is the track of the thumbnail image) (type = thmb).
[0130] In addition to Figure 8 the minf box described in
[0131] Figure 8 Figure 8 the mdia box of the trak box may also store an hdlr box. The hdlr box stores information indicating the type of data included in the track managed by the trak box that stores the hdlr box. The hdlr box stored in the trak box of track 1 that manages the main image (in the stored mdia box) stores information indicating that the data included in track 1 is a picture (frame) (pict), and the hdlr box stored in the trak box of track 2 that manages the thumbnail image stores information indicating that the data included in track 2 is a picture.
[0132] <HEIF file storing a tiled image>
[0133] Figure 11 is a diagram showing an example of a HEIF file storing a tiled image.
[0134] Here, one item type of HEIF is a grid. A grid image with an item type of grid image is formed by tiling one or more tiled images.
[0135] As the tiled image, for example, a segmented image obtained by segmenting an image captured by a digital camera 10 or the like can be adopted.
[0136] In addition, the image itself captured by a digital camera 10 or the like can be adopted as the tiled image, and the grid image can include one or more such tiled images. For example, a plurality of images captured by a plurality of cameras can be used as the tiled image, and the grid image can include such a plurality of tiled images.
[0137] Hereinafter, for simplicity of description, unless otherwise specified, a segmented image obtained by segmenting an image captured by a digital camera 10 or the like is adopted as the tiled image.
[0138] For a grid image with an item type of "grid", each of the (one or more) tiled images forming the grid image is stored as an item in the HEIF file.
[0139] Note that for a grid image, the grid image itself is not stored in the HEIF file, but the tile images that form the grid image are stored in the HEIF file. However, note that in this specification, for convenience, the HEIF file storing the tile images is also referred to as the HEIF file storing the grid image including the tile images.
[0140] Figure 11 An example of a HEIF file storing a grid image (tile images forming the grid image) is shown.
[0141] In Figure 11 the HEIF file, for example, nine images obtained by dividing the image captured by the digital camera 10 (hereinafter also referred to as the captured image) into 3×3 (horizontal × vertical) images are stored as tile image items 1 to 9, and the tile image items 1 to 9 are stored as items in the mdat box.
[0142] In Figure 11 although the items stored in the mdat box are the nine items of tile image items 1 to 9, the number of items in the iinf box and the iloc box is 10. This is because in addition to the nine items of tile image items #1 to #9, the grid image (reconstructed image) including tile image items #1 to #9 is counted as an item. In Figure 11 the item ID of the grid image is 10, and for ease of description, the grid image is also referred to as grid image item #10.
[0143] For grid image item #10, instead of storing the media data in the mdat box, an idat box is stored in the meta box. The idat box stores metadata of the grid image, such as the number of tiles in the horizontal direction, the number of tiles in the vertical direction, output_width (output width), and output_height (output height).
[0144] The number of tiles in the horizontal direction and the number of tiles in the vertical direction respectively represent the number of tile images #1 to #9 included in grid image item #10 in the horizontal and vertical directions.
[0145] Here, output_width and output_height represent the horizontal and vertical sizes (number of pixels) of the canvas, which is the image area where the tiled images forming the grid image are tiled (arranged). Assuming that the number of pixels in the horizontal and vertical directions of the tiled image is represented as tile_width and tile_height, tile_width × the number of tiles in the horizontal direction needs to be equal to or greater than output_width, and tile_height × the number of tiles in the vertical direction needs to be equal to or greater than output_height.
[0146] In addition, for the grid image item #10, the iloc box stores information (offset and size) about the storage location of the grid image item #10, and this information represents the storage location of the idat box of the grid image item #10.
[0147] Corresponding to the storage of the 10 items, namely tiled image items #1 to #9 and tiled image item #10, Figure 11 the HEIF file includes 10 infe boxes, and the tiled image item #10 includes the tiled image items #1 to #9. As described in the reference Figure 9 The infe box stores (registers) the item ID that identifies the item and the item type. The infe box of the grid image item #10 represents the grid of grid items as the item type of the grid image item #10. An item with an item type of grid (grid image item #10 in this example) is called a grid item.
[0148] In the HEIF file storing the grid item, the iref box stores the dimg box. The dimg box stores information that associates the grid item with the tiled images included in the grid item. For example, the dimg box stores the item ID of the tiled image as the reference destination, and stores the item ID of the grid image including the tiled image as the reference source. In Figure 11 the item IDs #1 to #9 of the tiled image items #1 to #9 are stored as the reference destinations, and the item ID #10 of the grid image item #10 is stored as the reference source. In addition, the dimg box stores a reference counter that represents the number of tiled images included in the grid image.
[0149] For the HEIF file described above, the file control unit 43 can identify that the grid image item #10 is a grid item (reconstructed image) including one or more tiled images according to the item type grid stored in the infe box of the grid image item #10. In addition, the file control unit 43 can identify the item ID #10 of the grid image item #10 including the tiled images and the item IDs #1 to #9 of the tiled image items #1 to #9 used to form the grid image item #10 according to the reference source and reference destination stored in the dimg box. In addition, the file control unit 43 can identify the number of the tiled image items #1 to #9 in the horizontal and vertical directions included in the grid image #10, and the sizes in the horizontal and vertical directions of the canvas on which the tiled image items #1 to #9 are arranged when forming the grid image #10, according to the number of tiled images in the horizontal direction and the number of tiled images in the vertical direction, and the output_width (output width) and output_height (output height) stored in the idat box.
[0150] By arranging the tiled images in the number in the horizontal and vertical directions identified from the idat box on the canvas with the size identified from the idat box, according to the tiled image items #1 to #9 of the item IDs #1 to #9 identified from the dimg box, the file control unit 43 can form the grid image item #10 of the item ID #10 identified from the dimg box.
[0151] <HEIF File with Repair Function>
[0152] Figure 12 is a diagram showing an overview of the HEIF file with a repair function generated by the file control unit 43.
[0153] For example, the HEIF file can store an image (main image) as a plurality of still images (such as images captured by continuous shooting). In the case where the HEIF file stores a plurality of images, the writing time required to write (record) the HEIF file to the medium 14 increases as the number of images increases. For example, the plurality of images mentioned here do not refer to a plurality of images with the same content (such as a main image and a thumbnail image), but refer to a plurality of images captured separately (such as images captured by continuous shooting).
[0154] In the case where the writing time is long, due to an unexpected event occurring during the writing of the HEIF file to the medium 14, the possibility of generating an abnormal HEIF file, that is, a file that does not have the format of a HEIF file, is very high. Here, for example, the unexpected event during the writing to the medium 14 is caused by the user removing the medium 14, a power interruption caused by removing the battery or removing the plug, etc.
[0155] The abnormal HEIF file cannot be reproduced, and the user loses all the images stored in the HEIF file.
[0156] In this context, 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 (i.e., a file having the format of a HEIF file).
[0157] The HEIF file with a repair function stores the repair data for repairing the HEIF file together with the images, and this repair data is used to generate (repair) the metadata (hereinafter also referred to as management metadata) stored in the meta box for image reproduction, management, etc.
[0158] In Figure 12 a HEIF file with a repair function is generated, which stores three images and the repair data for each image, that is, the repair data for generating the image management metadata for each of the three images. In addition, in Figure 12 the HEIF file with a repair function in, the image repair data is arranged immediately before the image. That is, immediately after the repair data, the image for which the management metadata is repaired (generated) using the repair data is arranged.
[0159] In the case where an abnormal HEIF file with a repair function is generated due to an unexpected event during writing the HEIF file with a repair function to the medium 14, the file control unit 43 uses the repair data to repair the abnormal HEIF file with a repair function into a (normal) HEIF file with a repair function.
[0160] That is, the file control unit 43 uses the repair data corresponding to the normal written image stored in the abnormal HEIF file with a repair function to generate the management metadata. In addition, the file control unit 43 generates a normal HEIF file storing the management metadata in the meta box.
[0161] Therefore, in the process of writing the HEIF file with a repair function to the medium 14, in the case of an unexpected event such as removing the medium 14 or an abnormal power interruption caused by removing the battery, etc., the number of images lost by the user can be reduced.
[0162] Figure 13 is a diagram showing an overview of repairing an abnormal HEIF file with a repair function using the repair data.
[0163] Figure 13An example of repairing a HEIF file is shown where, after writing a temporary metadata box, repair data for a first image, the first image, repair data for a second image, the second image, and repair data for a third image are written in an mdat box, and an unexpected event such as removal of the medium 14 occurs during the writing of the third image. Here, the temporary metadata box refers to a metadata box of a fixed length (fixed size) in which metadata confirmed at the time of writing the metadata box (hereinafter also referred to as confirmed metadata) is written, and an area for writing metadata is ensured for unconfirmed metadata. This also applies to boxes other than the metadata box.
[0164] In Figure 13 an unexpected event occurs during the writing of the third image. Therefore, Figure 13 the HEIF file with a repair function in
[0165] is an abnormal HEIF file in which the first image and the second image and the repair data of the first image and the second image are written normally (completely), while the third image is not written completely, and the metadata box is temporary data.
[0166] Note that although this specification describes the case where a HEIF file in the image item format is used as a HEIF file with a repair function, a HEIF file in the image sequence format may also be used as a HEIF file with a repair function. When a HEIF file in the image sequence format is used as a HEIF file with a repair function, the metadata box storing the metadata of the data stored in the mdat box is the moov box.
[0167] <Generating a HEIF file with a repair function>
[0168] Figure 14 is a flowchart showing an example of a process for generating a HEIF file with a repair function.
[0169] Note that the digital camera 10 can generate three images, namely, a main image, a screenshot image, and a thumbnail image, for a single imaging, and generate a HEIF file that stores these three images (the main image, the screenshot image, and the thumbnail image) and EXIF and XMP, which are (imaging) metadata of these three images, as image-related data associated with one main image together.
[0170] However, note that in Figure 14 for simplicity of description, a HEIF file is generated that stores the main image and EXIF and XMP as image-related data associated with one main image together.
[0171] In step S111, the file control unit 43 sets a variable capnum representing the number of imaging times to the number of times of capturing the main image to be stored in one (HEIF file with a repair function). For example, when the user operates a release button (not shown) only once to perform a single imaging, the variable capnum is set to 1. In addition, for example, when the user performs continuous shooting, the variable capnum is set to the number of imaging times performed by continuous shooting.
[0172] In addition, in step S111, the file control unit 43 sets a variable n for counting the number of main images to be stored in the HEIF file to 1 as an initial value, and the process proceeds to step S112.
[0173] In step S112, the file control unit 43 stores the n-th main image (the main image generated by the n-th imaging) and imaging information in an image memory (not shown), and stores codec information in a meta memory (not shown), and the process proceeds to step S113. Here, the imaging information is information related to the imaging of the main image for generating EXIF and XMP, such as the F value, focal length, imaging date and time, etc. when capturing the main image. The codec information is information related to the codec of the main image, etc., and is, for example, information such as a sequence parameter set (SPS), a picture parameter set (PPS), or a video parameter set (VPS). The codec information is used to generate a normal meta box.
[0174] In step S113, the file control unit 43 causes the encoding control unit 42 to encode the n-th main image, and the process proceeds to step S114.
[0175] In step S114, the file control unit 43 generates repair data for the n-th main image, that is, repair data for the metadata (management metadata) for repairing the n-th main image, and the process proceeds to step S115.
[0176] In step S115, the file control unit 43 generates the EXIF and XMP of the n-th main image by using the imaging information of the n-th main image, and the process proceeds to step S116.
[0177] In step S116, the file control unit 43 determines whether the variable n is 1.
[0178] If it is determined in step S116 that the variable n is 1, that is, if it is before the image-related data of the first main image is written to the medium 14, the process proceeds to step S117.
[0179] In step S117, the file control unit 43 generates a temporary data ftyp box and a meta box. Further, in step S117, the file control unit 43 controls the medium control unit 44 to write the temporary data ftyp box and the meta box to the medium 14 in such a manner that the ftyp box and the meta box are arranged in sequence starting from the beginning of the HEIF file, and the process proceeds to step S118.
[0180] In step S118, the file control unit 43 writes the EXIF and XMP of the n-th main image to the medium 14 in such a manner that the EXIF and XMP are arranged after the data written to the mdat box of the HEIF file immediately before, and the process proceeds to step S119. Note that the EXIF and XMP of the first main image are written in such a manner that the EXIF and XMP are arranged starting from the beginning of the mdat box after the temporary data ftyp box and the meta box written immediately before.
[0181] In step S119, the file control unit 43 writes the repair data of the n-th main image to the medium 14 in such a manner that the repair data is arranged after the EXIF and XMP of the n-th main image written to the mdat box of the HEIF file immediately before, and the process proceeds to step S120.
[0182] In step S120, the file control unit 43 writes the n-th main image to the medium 14 in such a manner that the main image is arranged after the repair data of the n-th main image written to the mdat box of the HEIF file immediately before, and the process proceeds to step S121.
[0183] In step S121, the file control unit 43 increments the variable n by 1, and the process proceeds to step S122.
[0184] In step S122, the file control unit 43 determines whether the variable n is less than or equal to (the variable) capnum representing the number of imaging times.
[0185] If it is determined in step S122 that the variable n is less than or equal to the imaging number capnum, that is, if not all of the main images captured by performing imaging up to the imaging number capnum have been written to the medium 14, the process returns to step S112. Thereafter, similar processing is repeated.
[0186] In addition, if it is determined in step S122 that the variable n is not less than or equal to the imaging number capnum, that is, if all of the main images captured by performing imaging up to the imaging number capnum have been written to the medium 14, the process proceeds to step S123.
[0187] In step S123, the file control unit 43 generates a normal ftyp box and a meta box for the image-related data including the main images normally written to the medium 14 by using the stored content of the meta memory, and the process proceeds to step S124.
[0188] In step S124, the file control unit 43 overwrites the temporary data ftyp box and meta box written to the medium 14 by using the normal ftyp box and the meta box. As a result, the file control unit 43 generates a HEIF file with a repair function that stores (includes) the normal ftyp box, the meta box, and the normal image-related data (the mdat box), and ends the process.
[0189] Note that although Figure 14 the HEIF file in has the main image, EXIF, and XMP as image-related data arranged in the order of EXIF, XMP, and the main image, the arrangement order of the main image, EXIF, and XMP is not limited to this.
[0190] In addition, although Figure 14 the HEIF file in has the repair data of the main image (the main image arranged immediately after the repair data of the main image) arranged immediately before the main image, the arrangement relationship between the main image and the repair data of the main image is not limited to this. For example, for the repair data and the main image, EXIF, and XMP as image-related data, the repair data may be arranged first, and then the main image, EXIF, and XMP as image-related data may be arranged in the order of EXIF, XMP, and the main image. Note that when the repair data is arranged immediately before the main image, if the repair data can be detected, the start of the main image immediately after the repair data can be easily detected.
[0191] As described above, here, for simplicity of description, the main image, as well as EXIF and XMP, are set as image-related data associated with one main image. However, note that as image-related data associated with one main image, the main image and related images associated with the main image, that is, screenshot images and thumbnail images having the same content as the main image and having a smaller number of pixels, and EXIF and XMP, etc., which are metadata of the main image, can be adopted. In this case, repair data is generated for each image. That is, repair data for each of the main image, the screenshot image, and the thumbnail image is generated.
[0192] Furthermore, in this case, for example, as the arrangement order of the image-related data and the repair data, the order of EXIF, the repair data of the thumbnail image, the thumbnail image, the repair data of the main image, the main image, the repair data of the screenshot image, the screenshot image, and XMP can be adopted. Additionally, for example, an arrangement order can be adopted in which the repair data for each of the main image, the screenshot image, and the thumbnail image is arranged together first, and then the image-related data is arranged.
[0193] <Repair HEIF file with repair function>
[0194] Figure 15 is a diagram showing an example of an abnormal HEIF file having a repair function.
[0195] Note that in Figure 15 , for simplicity of description, only the image and the repair data of the image are arranged in the mdat box in the order of the repair data and the image, without considering the ftyp box. This also applies to Figures 16 to 19 described later.
[0196] In Figure 15 , a temporary data meta box is written, and thereafter, the repair data of the first image, the first image, the repair data of the second image, the second image, and the repair data of the third image are sequentially written into the mdat box. Then, after the repair data of the third image, during the process of writing the third image into the mdat box, an unexpected event occurs, such as removing the medium 14 in which the HEIF file with the repair function is written from the digital camera 10, so that the writing is interrupted during the writing of the third image, and an abnormal HEIF file with the repair function is generated.
[0197] When the medium 14 in which the abnormal HEIF file with the repair function is recorded is reinstalled into the digital camera 10 and the abnormal HEIF file with the repair function is detected, the digital camera 10 starts the repair process for repairing the abnormal HEIF file with the repair function.
[0198] In the repair process, first, the interrupted part where the writing was interrupted is detected.
[0199] When detecting the interrupted part, the file control unit 43 searches from the beginning of the meta box of the abnormal HEIF file with the repair function for a fixed length that is the size of the temporary data meta box (for example, setting the desired read / write position as a file pointer which is a variable representing the read / write position of the file). Since the searched position is the start position of the repair data of the first image, the file control unit 43 reads the repair data of the first image from the searched position.
[0200] Note that when generating a HEIF file with the repair function, for example, in the case where EXIF is arranged before the repair data, an additional search is performed according to the size of EXIF. In this case, the size of EXIF is assumed to be a fixed length.
[0201] Furthermore, when generating a HEIF file with the repair function, in the case where the repair data cannot be read because an unexpected event occurred during the writing of the repair data and normal repair data was not written, the repair target is from the image arranged at the beginning of the mdat box to the image (the management metadata) arranged immediately before the unreadable repair data.
[0202] In the case where the beginning part of the repair data of the first image can be read, the file control unit 43 uses the repair data of the first image to identify the size of the repair data of the first image and the size of the subsequent first image.
[0203] The repair data has a recovery_data_size (recovery data size) field representing the size of the repair data and an image_size (image size) field representing the size of the image after the repair data at its beginning part. The file control unit 43 identifies the size of the repair data of the first image and the size of the first image from the recovery_data_size (recovery data size) field and the image_size (image size) field of the repair data of the first image.
[0204] The file control unit 43 performs a search according to the size obtained by combining the size of the repair data of the first image and the size of the first image. Since the searched position is the start position of the repair data of the second image, the file control unit 43 reads the repair data of the second image from the searched position.
[0205] Similar to the repair data of the first image, the file control unit 43 uses the repair data of the second image to identify the size of the repair data of the second image and the size of the subsequent second image.
[0206] The file control unit 43 performs a search based on the size obtained by combining the size of the restoration data of the second image and the size of the second image. Since the searched position is the start position of the restoration data of the third image, the file control unit 43 reads the restoration data of the third image from the located position.
[0207] Similar to the restoration data of the first image, the file control unit 43 uses the restoration data of the third image to identify the size of the restoration data of the third image and the size of the subsequent third image.
[0208] The file control unit 43 performs a search based on the size obtained by combining the size of the restoration data of the third image and the size of the third image.
[0209] In the case of a HEIF file with a normal restoration function, the searched position is the start position of the restoration data of the fourth image (or the end of the HEIF file with a restoration function). However, in Figure 15 since the writing was interrupted in the middle of the third image, it is impossible to search for the start position of the restoration data of the fourth image, and the search fails.
[0210] The file control unit 43 detects that since the search based on the size obtained by combining the size of the restoration data of the third image and the size of the third image fails, the third image (position) is the interrupted part where the writing was interrupted.
[0211] Figure 16 is a diagram showing an example of the restoration process after detecting the interrupted part.
[0212] When detecting the interrupted part, the file control unit 43 deletes the image of the interrupted part and the restoration data of that image from the mdat box of the HEIF file with a restoration function.
[0213] As a result, the mdat box of the HEIF file with a restoration function is in a state where only the normally written data is stored. In this example, this state is the state of storing the first image and the second image written before the interrupted part and the restoration data of the first image and the second image.
[0214] Note that in the case where the interrupted part is not the third image but, for example, the restoration data of the third image before writing the third image, only the restoration data of the third image is deleted.
[0215] In addition, for example, in a case where a main image, a screenshot image, a thumbnail image, EXIF, and XMP are used as image-related data associated with a single main image, and repair data for each of the main image, the screenshot image, and the thumbnail image is written together with the image-related data, when any one of the image-related data and the repair data is detected as a broken part, all of the image-related data and the repair data including the broken part can be deleted. In such a case, for example, when the thumbnail image is detected as a broken part or EXIF is detected as a broken part, all of the image-related data and the repair data including the thumbnail image or EXIF are deleted.
[0216] In addition, in a case where the image-related data and the repair data are arranged in the order of, for example, EXIF, repair data of the thumbnail image, the thumbnail image, repair data of the main image, the main image, repair data of the screenshot image, the screenshot image, and XMP, for example, when the screenshot image is detected as a broken part, only the screenshot image and the repair data of the screenshot image arranged immediately before the screenshot image are deleted, and EXIF, the repair data of the thumbnail image, the thumbnail image, the repair data of the main image, and the main image arranged before the repair data of the screenshot image can be retained as they are.
[0217] Figure 17 is a diagram showing an example of the repair process after deleting the image of the broken part and the repair data of that image.
[0218] When deleting the image of the broken part and the repair data of that image, the file control unit 43 generates (repairs) a normal meta box of the management metadata of the stored image using the repair data of the images that are normally written in the HEIF file with the repair function after deletion.
[0219] That is, the file control unit 43 generates management metadata other than the confirmed metadata required for a normal HEIF file by using the repair data of the first image and the second image that have been normally written and the metadata stored in the temporary data meta box, and generates a normal meta box by writing the management metadata and the confirmed metadata into the meta memory.
[0220] Figure 18 is a diagram showing an example of the repair process after generating a normal meta box.
[0221] When generating a normal meta box, the file control unit 43 searches for the start position of the temporary data meta box of the HEIF file with a repair function, and rewrites from the searched position using the normal meta box of the meta memory. As a result, the file control unit 43 generates a normal HEIF file (repairing the abnormal HEIF file) with a repair function.
[0222] Figure 19 is a flowchart showing an example of the repair process.
[0223] For example, when an abnormal HEIF file with a repair function is detected from the HEIF file with a repair function recorded in the medium 14, the file control unit 43 starts the repair process. For example, it can be determined whether the HEIF file is a HEIF file with a repair function by setting a new field or box indicating that the HEIF file is a HEIF file with a repair function in the meta box, and this determination can be made based on the new field or box.
[0224] During the repair process, in step S141, the file control unit 43 opens the abnormal HEIF file with a repair function recorded in the medium 14 (for example, generates a file pointer for accessing the HEIF file). In addition, the file control unit 43 searches for a fixed length that is the size of the temporary data meta box from the start of the meta box of the opened abnormal HEIF file with a repair function, and the process proceeds from step S141 to step S142.
[0225] In step S142, the file control unit 43 reads the repair data from the searched position, that is, the start position of the repair data, and the process proceeds to step S143.
[0226] Here, in the repair data, the recovery_data_size (recovery data size) field indicating the size of the repair data is arranged at a fixed position, for example, at the beginning part of the repair data. When reading the repair data, the size of the repair data can be identified from the recovery_data_size (recovery data size) field.
[0227] In step S143, the file control unit 43 determines whether the repair data has been successfully read.
[0228] If it is determined in step S143 that the reading of the repair data is not successful, that is, if the repair data cannot be read because an unexpected event occurred during the writing of the repair data, the repair data was not written normally (completely), and abnormal repair data was written, the file control unit 43 detects the position of the abnormal repair data as the interrupted part where the writing was interrupted, and the process proceeds to step S147.
[0229] In addition, if it is determined in step S143 that the reading of the repair data is successful, the process proceeds to step S144.
[0230] In step S144, the file control unit 43 stores the repair data (hereinafter also referred to as the latest repair data) read in the just previous step S142 in the meta memory, and the process proceeds to step S145.
[0231] In step S145, the file control unit 43 obtains the recovery_data_size (recovery data size) field and the image_size (image size) field from the latest repair data stored in the meta memory. In addition, the file control unit 43 identifies the size of the latest repair data in the abnormal HEIF file with a repair function and the size of the image arranged immediately after the latest repair data based on the recovery_data_size (recovery data size) and the image_size (image size). Then, the file control unit 43 searches (starting from the beginning of the latest repair data of the HEIF file with a repair function) for the size obtained by combining the size of the latest repair data and the size of the image arranged immediately after the latest repair data, and the process proceeds from step S145 to step S146.
[0232] In step S146, the file control unit 43 determines whether the search performed in the just previous step S145 is successful.
[0233] If it is determined in step S146 that the search is successful, that is, if the search reaches the beginning of the repair data arranged immediately after the image arranged immediately after the latest repair data, the process returns to step S142. In step S142, as described above, the file control unit 43 reads the repair data from the searched position, that is, the beginning position of the repair data, and thereafter, similar processing is repeated.
[0234] On the other hand, if it is determined in step S146 that the search fails, that is, if an unexpected event occurs during the writing of the image arranged immediately after the latest repair data and the writing of the image is interrupted, the file control unit 43 detects the position of the image whose writing is interrupted and fails in the search as the interrupted part, and the process proceeds to step S147.
[0235] In step S147, the file control unit 43 deletes the image and the repair data of the interrupted part from the HEIF file with a repair function, and the process proceeds to step S148.
[0236] That is, in step S147, if the interrupted part is the position of the repair data, the repair data is deleted. Further, if the interrupted part is the position of an image, the image and the repair data arranged immediately before the image are deleted.
[0237] In step S148, the file control unit 43 generates management metadata other than the confirmed metadata required for a normal HEIF file by using the repair data stored in the meta memory, that is, the repair data normally written to the HEIF file having a repair function, and the required management metadata stored in the temporary data meta box, and generates a normal meta box by writing the management metadata and the confirmed metadata to the meta memory.
[0238] Thereafter, the process proceeds from step S148 to step S149, the file control unit 43 searches for the start position of the temporary data meta box of the HEIF file having a repair function, and the process proceeds to step S150. In step S150, the file control unit 43 repairs the HEIF file having a repair function (generates a HEIF file having a normal repair function) by rewriting the normal meta box in the meta memory from the searched position, and ends the repair process.
[0239] <Example of repair data>
[0240] Figure 20 is a diagram showing a specific example of the repair data.
[0241] For example, as Figure 20 shown, the repair data is configured by arranging the fields recovery_data_size (recovery data size), image_size (image size), next_image_exist (existence of the next image), info_type (information type), target_size_x (target size x), target_size_y (target size y), num_of_grid_x (number of grids x), num_of_grid_y (number of grids y), grid_width (grid width), grid_height (grid height), grid_list (grid list), capture_gamma (capture gamma), colormetory (chromaticity), and hvcc_info (hvcc information) in sequence.
[0242] The recovery_data_size (recovery data size) field represents the size (data amount) of the repair data having the recovery_data_size (recovery data size) field in bytes.
[0243] The image_size (image size) field represents the size (amount of data) of the image arranged immediately after the repair data having the recovery_data_size (recovery data size) field, in bytes.
[0244] The next_image_exist (existence of next image) field indicates whether there is a next image (and its repair data) after the image arranged immediately after the repair data having the recovery_data_size (recovery data size) field. In the case where there is a next image, the next_image_exist field is set to one of 0 and 1, for example, 1; and in the case where there is no next image, the next_image_exist field is set to the other, that is, 0.
[0245] The info_type (information type) field represents the picture type (information type) of the image arranged immediately after the repair data having the recovery_data_size (recovery data size) field.
[0246] The target_size_x (target size x) field and the target_size_y (target size y) field respectively represent the vertical and horizontal sizes (number of pixels) of the image arranged immediately after the repair data having the target_size_x (target size x) field and the target_size_y (target size y) field.
[0247] In the case where the image arranged immediately after the repair data having the num_grid_x (number of grids x) field and the num_grid_y (number of grids y) field is (formed as) a tiled image of a grid image (which is a grid item), the num_grid_x (number of grids x) field and the num_grid_y (number of grids y) field respectively represent the number of divisions in the vertical and horizontal directions of the grid image, that is, the number of tiled images in the vertical and horizontal directions included in the grid image.
[0248] In the case where the image arranged immediately after the repair data having the grid_width (grid width) field and the grid_height (grid height) field is a grid image, the grid_width (grid width) field and the grid_height (grid height) field respectively represent the vertical and horizontal sizes (number of pixels) of the tiled images included in the grid image.
[0249] The grid_list field represents grid information about an image arranged immediately after the repair data with the grid_list field, which will be described later.
[0250] The capture_gamma field represents gamma information about the gamma of an image arranged immediately after the repair data with the capture_gamma field.
[0251] The chrominance field represents chrominance information about the chrominance of an image arranged immediately after the repair data with the chrominance field.
[0252] The hvcc_info field is hvcc information about an image arranged immediately after the repair data with the hvcc_info field, and represents hvcc information excluding SPS, PPS, VPS, etc.
[0253] Figure 21 It is a diagram showing a specific example of the grid_list field as grid information in the repair data.
[0254] For example, as Figure 21 shown, the grid_list field is configured by arranging 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, and pps_id in sequence.
[0255] The param_addr field and the param_size field respectively represent the addresses and sizes (data volumes) of VPS, SPS, and PPS as parameters regarding the image.
[0256] The data_addr field and the data_size field respectively represent the addresses and sizes (data volumes) of the Elementary Stream (ES) related to the image.
[0257] The total_vps_size (total VPS size) field, num_vps (number of VPSs) field, and vps_id field respectively represent the size (data volume), number, and ID (ID of the network abstraction layer (NAL) unit) of the VPS.
[0258] The total_sps_size (total SPS size) field, num_sps (number of SPSs) field, and sps_id field respectively represent the size (data volume), number, and ID (ID of the NAL unit) of the SPS.
[0259] The total_pps_size field, num_pps field, and pps_id field respectively represent the size (data volume), number, and ID (ID of the NAL unit) of the PPS.
[0260] Although the number of VPSs, SPSs, and PPSs is one in a HEIF file in image item format, the number of VPSs, SPSs, and PPSs can be multiple in a HEIF file in image sequence format.
[0261] Figure 22 It is a diagram showing a box that stores metadata generated (repaired) at least using repair data in the repair process.
[0262] Here, generating (repairing) management metadata using the (fields of) repair data is also represented as a box for generating (repairing) storage management data.
[0263] Examples of boxes that can be stored in the meta box generated using repair data include the pitm box, infe box, dimg box, thmb box, colr box, hvcc box, ipse box, idat box, and iloc box.
[0264] Note that among the boxes stored in the meta box, the iinf box, iprp box, ipco box, and impa box are boxes that store confirmed metadata or boxes that store management metadata that can be generated based on other boxes, and can be generated without repair data.
[0265] The grid_width (grid width) field and grid_height (grid height) field can be used to generate (store the) management metadata (in the pitm box).
[0266] The num_of_grid_x (number of grids x) field and num_of_grid_y (number of grids y) field can be used to generate the infe box and dimg box.
[0267] The target_size_x (target size x) field and the target_size_y (target size y) field can be used to generate a thum box.
[0268] The capture_gamma (capture gamma) field and the colometory (chromaticity) field can be used to generate a colr box.
[0269] The grid_list (grid list) field and the hvcc_info (hvcc information) field can be used to generate an hvcc box.
[0270] The target_size_x (target size x) field and the target_size_y (target size y) field can be used to generate an ipse box.
[0271] The num_of_grid_x (number of grids x) field, the num_of_grid_y (number of grids y) field, the grid_width (grid width) field, the grid_height (grid height) field, and the grid_list (grid list) field can be used to generate an idat box.
[0272] The grid_list (grid list) field can be used to generate an iloc box.
[0273] Note that although the mdat box is not a box stored in the meta box, the grid_list (grid list) field can be used to generate the size (amount of data) of the data after deleting the interrupted part in the mdat box, or the size (amount of data) of the data after deleting the interrupted part of the image and the repair data of the image.
[0274] Figure 23 It is a diagram showing a method of generating (repairing) a box for storing management metadata generated at least using repair data in a repair process.
[0275] Note that Figure 23 It also shows a method of generating, in a repair process, boxes other than those generated using repair data and included in a HEIF file having a repair function.
[0276] In addition, in Figure 23 the relevant fields represent the fields of repair data used to generate (store in) the boxes (management metadata in the boxes).
[0277] In addition, in Figure 23Among them, the main image, screenshot image, thumbnail image, EXIF, and XMP are used as image-related data associated with a main image, and the order of EXIF, restoration data of the thumbnail image, thumbnail image, restoration data of the main image, main image, restoration data of the screenshot image, screenshot image, and XMP is used as the arrangement order of the image-related data and restoration data in the mdat box.
[0278] The HEIF file with a restoration function has an ftyp box, a meta box, and an mdat box.
[0279] The meta box can store the hdlr box, pitm box, iinf box, iref box, iprp box, idat box, and iloc box.
[0280] The iinf box can store the infe box.
[0281] The iref box can store the dimg box, thum box, and cdsc box.
[0282] The iprp box can store the ipco box and ipma box. The ipco box that can be stored in the iprp box can store the colr box, hvcc box, ispe box, and irot box.
[0283] A (predetermined) fixed value can be used to generate the ftyp box.
[0284] The meta box can be generated by obtaining the size (data volume) of each box stored in the meta box and using this size.
[0285] A fixed value can be used to generate the hdlr box.
[0286] In the case where the image arranged immediately after the restoration data is not a grid image, the pitm box can be generated by setting the item ID of the main item to 1 and using the item ID of the main item. In addition, in the case where the image arranged immediately after the restoration data is a grid image (the tiled image included in the grid image), the pitm box can be generated as follows: using the num_grid_x (number of grids x) field and num_grid_y (number of grids y) field of the restoration data, obtaining the item ID of the main item according to the expression num_of_grid_x × num_of_grid_y + 1, and using the item ID of the main item.
[0287] The iinf box can be generated in the following way: Obtain the size (data volume) of each box stored in iprp and the number of infe boxes (total number), and use the size and the number. Note that the iinf box stores the number of items stored in the mdat box, and for image-related data, the number of items is calculated as follows. For example, in the case where the main image, EXIF, and XMP are used as the image-related data associated with one main image, the number of items of one image-related data is three, namely the main image, EXIF, and XMP. In addition, for example, in the case where the main image, screenshot image, thumbnail image, EXIF, and XMP are used as the image-related data associated with one main image, the number of items of one image-related data is five, namely the main image, screenshot image, thumbnail image, EXIF, and XMP. For example, in the case where the main image, screenshot image, thumbnail image, EXIF, and XMP are used as the image-related data associated with one main image, and the mdat box stores the image-related data of two main images, the number of items stored in the iinf box is 10 (= 5 × 2).
[0288] The infe box can be generated in the following way: Use the num_of_grid_x (number of grids x) field and the num_of_grid_y (number of grids y) field of the repair data to obtain the number of tiled images (number of grid components) included in the grid image, which is num_of_grid_x × num_of_grid_y, and use the addition value obtained by adding the following number to the number of tiled images num_of_x × num_of_grid_y: the number of components other than the main image among the main image, screenshot image, thumbnail image, EXIF, and XMP, which are used as the image-related data associated with one main image, that is, four, which represents the number of the screenshot image (SCN), thumbnail image (thumb), EXIF, and XMP.
[0289] The iref box can be generated by obtaining the size (data volume) of each box stored in iref and using the size.
[0290] The dimg box can be generated in the following way: Use the num_of_grid_x (number of grids x) field and the num_of_grid_y (number of grids y) field of the repair data to obtain the number of tiled images (number of grid components) included in the grid image, which is num_of_grid_x × num_of_grid_y, and use the number num_of_grid_x × num_of_grid_y.
[0291] The thmb box can be generated in the following way: for each of the screenshot image (SCN) and the thumbnail image (thumb), use the target_size_x (target size x) field and the taget_size_y (target size y) field of the repair data to obtain the item ID of the item (image) where target_size_x (target size x) and taget_size_y (target size y) are the sizes (number of pixels) of the screenshot image or the thumbnail image as the item ID of the screenshot image or the thumbnail image, and use this item ID.
[0292] Here, since the arrangement order of the image-related data and the repair data is determined, the cdsc box can be generated in the following way: obtain the item IDs of EXIF and XMP based on the item ID of the item (image) with the size (number of pixels) of the thumbnail image in the image-related data, and use the item IDs of EXIF and XMP.
[0293] The iprp box can be generated by obtaining the size of each box stored in the iprp box and using this size.
[0294] The ipco box can be generated by obtaining the size of each box stored in the ipco box and using this size.
[0295] The colr box can be generated using the capture_gamma (capture gamma) field and the colormetory (chromaticity) field of the repair data.
[0296] The hvcc box can be generated using the hvcc_info (hvcc information) field and the grid_list (grid list) field of the repair data.
[0297] The ispe box can be generated using the target_size_x (target size x) field and the taget_size_y (target size y) field of the repair data.
[0298] The irot box can be generated using fixed values.
[0299] The ipma box can be generated in the following way: for example, fix 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 attribute in the ipco, and use each attribute in the infe box and the ipco box associated with the infe box.
[0300] Here, by fixing the order of the infe boxes of each item, the infe box can be associated with the attribute of the item in the ipco corresponding to the infe box.
[0301] For example, assume that the order of the infe box is fixed in the order of the main image of the item with item ID 1, the screenshot image of the item with item ID 2, the thumbnail image of the item with item ID 3, EXIF, and XMP (the infe box).
[0302] In addition, assume that the ipco box stores the information common to the main image, the screenshot image, and the thumbnail image, the codec information of the main image, the image size information of the main image, the codec information of the screenshot image, the image size information of the screenshot image, the codec information of the thumbnail image, and the image size information of the thumbnail image as attributes in sequence.
[0303] In this case, the attributes of the main image with item ID 1 are the first, second, and third attributes in the ipco box. The attributes of the screenshot image with item ID 2 are the first, fourth, and fifth attributes in the ipco box. The attributes of the thumbnail image with item ID 3 are the first, sixth, and seventh attributes in the ipco box.
[0304] Therefore, the infe box can be associated with the attributes of the item corresponding to the infe box.
[0305] Then, the infe box and the attributes associated with the infe box (the attributes of the item corresponding to the infe box) can be used to generate an ipma box that stores an index to each item's attribute in the ipco box.
[0306] Note that the HEIF standard specification describes that
[0307] · The type and ID of the item are described in the infe box,
[0308] · The codec information (hvcc) and the image size (ipse) information are located in the ipco box, and
[0309] · The attributes associated with the ID are specified in the ipma box.
[0310] The idat box can be generated using the grid_list (grid list) field, the grid_width (grid width) field, the grid_height (grid height) field, the num_of_grid_x (number of grids x) field, and the num_of_grid_y (number of grids y) field of the repair data.
[0311] The iloc box can be generated using the grid_list (grid list) field of the repair data.
[0312] Note that as Figure 22As described above, the grid_list (grid list) field can be used to generate the size of the data in the mdat box (for actual use).
[0313] <Description of a computer applying the prior art>
[0314] Next, the above series of processes can be executed by hardware or software. In the case of executing a series of processes by software, the program included in the software is installed on a general-purpose computer or the like.
[0315] Figure 24 FIG. is a block diagram showing a configuration example of an embodiment of a computer on which a program for executing the above series of processes is installed.
[0316] The program can be pre-recorded in the hard disk 905 or ROM 903 which is a recording medium built in the computer.
[0317] Alternatively, the program can be stored (recorded) in the removable recording medium 911 driven by the drive 909. Such a removable recording medium 911 can be provided as so-called package software. Here, examples of the removable recording medium 911 include a floppy disk, a compact disc read-only memory (CD-ROM), a magneto-optical (MO) disk, a digital versatile disc (DVD), a magnetic disk, a semiconductor memory, and the like.
[0318] Note that the program can be installed on the computer from the removable recording medium 911 as described above, or can be downloaded to the computer through a communication network or a broadcast network and installed in the built-in hard disk 905. That is, for example, the program can be wirelessly transmitted from a download site to the computer via an artificial satellite for digital satellite broadcasting, or can be transmitted to the computer in a wired manner through a network such as a local area network (LAN) or the Internet.
[0319] The computer includes a central processing unit (CPU) 902, and an input / output interface 910 is connected to the CPU 902 via a bus 901.
[0320] When a command is input by a user operating the input unit 907 or the like through the input / output interface 910, the CPU 902 executes the program stored in the read-only memory (ROM) 903 according to the command. Alternatively, the CPU 902 loads the program stored in the hard disk 905 into the random access memory (RAM) 904 and executes the program.
[0321] As a result, the CPU 902 executes the processing according to the above flowchart or the processing executed by the configuration of the above block diagram. Then, the CPU 902 executes control as needed to output the processing result from the output unit 906 or send the processing result from the communication unit 908 through the input / output interface 910, or record the processing result in the hard disk 905, for example.
[0322] Note that the input unit 907 includes a keyboard, a mouse, a microphone, etc. In addition, the output unit 906 includes a liquid crystal display (LCD), a speaker, etc.
[0323] Here, in this specification, the processing executed by a computer according to a program does not necessarily need to be executed in time series in the order described in the flowchart. That is, the processing executed by a computer according to a program also includes processing executed in parallel or individually (e.g., parallel processing or object-by-object processing).
[0324] In addition, the program can be processed by one computer (processor), or can be processed by multiple computers in a distributed manner. In addition, the program can be transmitted to a remote computer for execution.
[0325] In addition, in this specification, a system refers to a collection of multiple components (devices, modules (parts), etc.), and it is not important whether all components are in the same housing. Therefore, multiple devices housed in separate housings and connected by a network, and one device housing multiple modules in one housing are both systems.
[0326] Note that the embodiments of the present technology are not limited to the above embodiments, and various modifications can be made without departing from the scope of the present technology.
[0327] For example, the present technology can have a cloud computing configuration in which one function is shared and processed by multiple devices through a network.
[0328] In addition, each step described in the above flowchart can be executed by one device, or can be executed by multiple devices in a shared manner.
[0329] In addition, in the case where multiple processes are included in one step, the multiple processes included in one step can be executed by one device, or can be executed by multiple devices in a shared manner.
[0330] In addition, the effects described in this specification are merely illustrative and not restrictive. Therefore, other effects can be obtained.
[0331] Note that the present technology can also be configured in the following manner.
[0332] <1>
[0333] A file processing device, comprising:
[0334] A file control unit that writes repair data for repairing the HEIF file storing still images into the HEIF file.
[0335] <2>
[0336] The file processing device according to <1>, wherein
[0337] The repair data includes data for repairing management metadata for managing images in the HEIF file.
[0338] <3>
[0339] The file processing device according to <2>, wherein
[0340] The file control unit arranges the repair data for repairing the management metadata of the image immediately before the image.
[0341] <4>
[0342] The file processing device according to <3>, wherein
[0343] The repair data includes the size of the repair data and the size of the image arranged immediately after the repair data.
[0344] <5>
[0345] The file processing device according to any one of <2> to <4>, wherein
[0346] The repair data includes data for repairing management metadata stored in pitm boxes, infe boxes, dimg boxes, thmb boxes, colr boxes, hvcc boxes, ipse boxes, idat boxes, and iloc boxes stored in the meta box of the HEIF file.
[0347] <6>
[0348] The file processing device according to any one of <1> to <5>, wherein
[0349] The HEIF file stores an image and associated images related to the image, and
[0350] The file control unit writes the repair data of the image and the repair data of the associated images.
[0351] <7>
[0352] The file processing device according to <6>, wherein
[0353] The related image includes an image having a number of pixels less than the number of pixels of the said image.
[0354] <8>
[0355] The document processing device according to any one of <1> to <7>, wherein
[0356] The HEIF file stores an image and metadata of the image.
[0357] <9>
[0358] A document processing method includes:
[0359] Writing repair data into a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being used to repair the HEIF file.
[0360] <10>
[0361] A program for causing a computer to function as:
[0362] A file control unit that writes repair data into a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being used to repair the HEIF file.
[0363] <11>
[0364] A document processing device includes:
[0365] A file control unit that uses repair data to repair a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being used to repair the HEIF file and being written into the HEIF file.
[0366] <12>
[0367] The document processing device according to <11>, wherein
[0368] The repair data includes data for repairing management metadata for managing an image in the HEIF file, and
[0369] The file control unit generates management metadata by using the repair data.
[0370] <13>
[0371] The document processing device according to <12>, wherein
[0372] The file control unit deletes the image of the interrupted part where the writing was interrupted from the HEIF file, and uses the repair data to generate a HEIF file of the image written before the interrupted part.
[0373] <14>
[0374] The file processing device according to <13>, wherein
[0375] The repair data for repairing the management metadata of the image is arranged immediately before the image,
[0376] The repair data includes the size of the repair data and the size of the image arranged immediately after the repair data, and
[0377] In the case where the search for the size obtained by combining the size of the repair data and the size of the image arranged immediately after the repair data fails starting from the beginning of the repair data, the file control unit detects the image as the interrupted part.
[0378] <15>
[0379] The file processing device according to <13> or <14>, wherein
[0380] The HEIF file stores an image and associated images related to the image, and
[0381] In the case where any one of the image and the associated images is detected as the interrupted part, the file control unit deletes the image and the associated images.
[0382] <16>
[0383] The file processing device according to <15>, wherein
[0384] The associated images include images having fewer pixels than the number of pixels of the image.
[0385] <17>
[0386] The file processing device according to any one of <13> to <16>, wherein
[0387] The HEIF file stores an image and the metadata of the image, and
[0388] In the case where any one of the image and the metadata is detected as the interrupted part, the file control unit deletes the image and the metadata.
[0389] <18>
[0390] The file processing device according to any one of <12> to <17>, wherein
[0391] The file control unit uses the repair data to repair the management metadata stored in the pitm box, infe box, dimg box, thmb box, colr box, hvcc box, ipse box, idat box, and iloc box stored in the metadata box of the HEIF file.
[0392] <19>
[0393] A file processing method includes:
[0394] Using repair data to repair a High Efficiency Image File Format (HEIF) file that stores a still image, the repair data being for repairing the HEIF file and being written into the HEIF file.
[0395] <20>
[0396] A program that causes a computer to function as:
[0397] A file control unit that uses repair data to repair a High Efficiency Image File Format (HEIF) file that stores a still image, the repair data being for repairing the HEIF file and being written into the HEIF file.
[0398] Reference mark list
[0399] 10 Digital camera
[0400] 11 Optical system
[0401] 13 Signal processing unit
[0402] 14 Medium
[0403] 15, 16 I / F
[0404] 17 Button / key
[0405] 18 Touch panel
[0406] 19 Liquid crystal panel
[0407] 20 Viewfinder
[0408] 21 I / F
[0409] 41 Optical system / image sensor control unit
[0410] 42 Encoding control unit
[0411] 43 File control unit
[0412] 44 Medium control unit
[0413] 45 Operation control unit
[0414] 46 Display control unit
[0415] 47 UI control unit
[0416] 901 Bus
[0417] 902 CPU
[0418] 903 ROM
[0419] 904 RAM
[0420] 905 Hard disk
[0421] 906 Output unit
[0422] 907 Input unit
[0423] 908 Communication unit
[0424] 909 Driver
[0425] 910 Input / output interface
[0426] 911 Removable recording medium
Claims
1. A file processing device, comprising: a file control unit that writes repair data into a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being used to repair the HEIF file, wherein, the repair data includes data for repairing management metadata stored in a metadata box in the HEIF file for managing the image.
2. The file processing device according to claim 1, wherein, the file control unit arranges the repair data for repairing the management metadata of the image immediately before the image.
3. The file processing device according to claim 2, wherein, the repair data includes the size of the repair data and the size of the image arranged immediately after the repair data.
4. The file processing device according to claim 1, wherein, the repair data includes data for repairing management metadata stored in a pitm box, an infe box, a dimg box, a thmb box, a colr box, a hvcc box, an ipse box, an idat box, and an iloc box stored in the metadata box of the HEIF file.
5. The file processing device according to claim 1, wherein, the HEIF file stores an image and associated images related to the image, and the file control unit writes the repair data of the image and the repair data of the associated images.
6. The file processing device according to claim 5, wherein, the associated images include images having a smaller number of pixels than the number of pixels of the image.
7. The file processing device according to claim 1, wherein, the HEIF file stores an image and metadata of the image.
8. A file processing method, comprising: writing repair data into a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being used to repair the HEIF file, wherein, the repair data includes data for repairing management metadata stored in a metadata box in the HEIF file for managing the image.
9. A program product for causing a computer to function as: a file control unit that writes repair data into a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being used to repair the HEIF file, wherein, the repair data includes data for repairing management metadata stored in a metadata box in the HEIF file for managing the image.
10. A file processing device, comprising: a file control unit that uses repair data to repair a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being used to repair the HEIF file, the repair data being written into the HEIF file, wherein, the repair data includes data for repairing management metadata stored in a metadata box in the HEIF file for managing the image, and the file control unit generates management metadata by using the repair data.
11. The file processing device according to claim 10, wherein, The file control unit deletes the image of the interrupted part where writing was interrupted from the HEIF file, and uses the repair data to generate a HEIF file of the image written before the interrupted part.
12. The file processing device according to claim 11, wherein, repair data for repairing management metadata of an image is arranged immediately before the image, the repair data includes the size of the repair data and the size of the image arranged immediately after the repair data, and in a case where a search starting from the beginning of the repair data for a size obtained by combining the size of the repair data and the size of the image arranged immediately after the repair data fails, the file control unit detects the image as the interrupted part.
13. The file processing device according to claim 11, wherein, the HEIF file stores an image and associated images related to the image, and in a case where any one of the image and the associated images is detected as the interrupted part, the file control unit deletes the image and the associated images.
14. The file processing device according to claim 13, wherein, the associated images include images having a smaller number of pixels than the number of pixels of the image.
15. The file processing device according to claim 11, wherein, the HEIF file stores an image and metadata of the image, and in a case where any one of the image and the metadata is detected as the interrupted part, the file control unit deletes the image and the metadata.
16. The file processing device according to claim 10, wherein, the file control unit uses the repair data to repair the management metadata stored in the pitm box, infe box, dimg box, thmb box, colr box, hvcc box, ipse box, idat box, and iloc box stored in the meta box of the HEIF file.
17. A file processing method, comprising: using repair data to repair a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being for repairing the HEIF file and being written into the HEIF file, wherein, the repair data includes data for repairing management metadata stored in a meta box for managing an image in the HEIF file, and generating management metadata by using the repair data.
18. A program product that causes a computer to function as: a file control unit that uses repair data to repair a High Efficiency Image File Format (HEIF) file storing a still image, the repair data being for repairing the HEIF file and being written into the HEIF file, wherein, the repair data includes data for repairing management metadata stored in a meta box for managing an image in the HEIF file, and the file control unit generates management metadata by using the repair data.
Citation Information
Patent Citations
Video recording processing method and device, computer device and storage medium
CN108322808A
Video photographing device
JP2005301641A