Extension persistence mechanism for a digital image format5983229Abstract An image file structure that supports and selectively maintains extensions is disclosed incorporating, a header, image data, non-image data and extension portions. Each extension portion includes extension data and an extension persistence value that is selected to indicate if extension data is to be maintained as part of the image file when modifications have been made to the image data portions of the image file or not. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1.
______________________________________
The meaning of The Extension Persistence Property 22
Value Meaning
______________________________________
0 .times. 0
Extension is valid and remains in the file independent of
modifications to the core elements of the file.
0 .times. 1
Extension is invalid upon any modification to the core
elements of the file, and must be removed from the file
when core elements are edited.
0 .times. 2
Extension is potentially invalid upon modification to the
core elements of the file, and must remain in the file until
an application that understands the extension can
determine if the extension is valid (remains in the file) or
invalid (removed from the file).
______________________________________
The persistence property 22 is set based upon the requirements for the extension. For example, an application desires to store audio annotations with the image. The audio extension might have a persistence value of 0.times.0, which means that the audio annotation is always saved with the image independent of any core element modifications. Another application might store a histogram of the image in addition to the core image data. This type of extension might have a persistence value of 0.times.1, which means that if an application edits the file, the histogram extension is no longer valid and must be deleted upon saving the file. The histogram extension might be assigned a value of 0.times.2 (potentially invalid) instead of 0.times.1 In this case, an application that doesn't understand the histogram extension must maintain the extension in the file independent of core element edits. On the other hand, an application that does understand the histogram extension is required to determine the validity of the data prior to using it. If the extension data is invalid it must be removed from the file. FIG. 2 depicts the steps an application must take to add extension data to the hypothetical image file. The application starts at 30 and steps to reading the number of extensions field 16 from the image file 10 at step 32 and increments this value at step 34. If per decision block 36 the incremented value is 1, the extension about to be added is the first extension to be added to the image file 10. The application must determine the location in the file where the extension data will be written (the extension #1 offset) per step 38 and then write the incremented number of extensions, the extension #1 offset and the extension #1 data to the file per step 40. If the incremented value of the number of extensions field is not one, then there are already extensions in this file. The application can read the extension data 26 for the extensions already in the file into a buffer in memory per step 42. The application can then determine the new offsets for both the existing extensions and the new extensions, taking into account the space required to store the extension offset for the new extension per step 44. The new extension data is then added to the buffer in memory per step 46. Finally, the incremented value of the number of extensions field, the buffer of extension data and the extensions offsets are written to the file per step 48. Referring to FIG. 3 which depicts the steps an application takes when reading the image file, modifying the core elements of the file, and checking the persistence of the extensions in the file. The application, starts at step 60 and in the course of operation, reads the image file per step 62. At some point the application may modify one or more core elements in the file (either image data or non-image data) per step 64. At that point, the application must determine if any of the extensions in the file have been rendered invalid and thus must be deleted. The application reads the extension data for each extension, noting the value of the extension persistence field in particular for each extension per step 66. For each extension in the file, if the persistence field is 0.times.01 per step 68, the application must delete that extension. The application can do this by reading all of the extension data that is still valid into memory. The application can then determine the new offsets for each extension that is still valid, taking into account the deleted extension data per steps 72, 74, and 76. The application then writes the updated extension offsets and the buffer of extension data back to the file per step 78. The application also decrements the number of extensions field by the number of deleted extensions and writes that new value back to the file. If the persistence field 0.times.1 is not present the file is saved per step 70. FIG. 4 depicts the steps an application takes when validating extension data in the file. The application starts step 80 by reading the image file step 82. In particular, the application must read the extension persistence field from the data for each extension per step 84. If no extension has a persistence equal to 0.times.2, all extensions are valid per block 104. For each extension that has a persistence value of 0.times.2, the application must determine if it understands that extension per steps 86 and 88, which can be accomplished by determining if the value in the extension type field for that extension is a known value. If the application does not understand that extension, it must assume that the extension is still valid per step 92 and leave the data for that extension untouched. If the application does understand that extension, it must determine if the data for that extension is still valid per steps 90 and 94. The method to perform this test will be determined by the definition of each particular extension. If the application determines that the extension is not valid per step 96, it must delete that extension per step 98. For each invalid extension, the application must decrement the number of extensions field by one and then write the final value back to the file. The application can then read all of the extension data into a buffer in memory while removing the data for the invalid extensions. The application can then update the values of the extension offsets, taking into account the deleted extensions. Once the new offsets have been determined per step 100 the application can then write the new extension offsets and the buffer of extension data back to the file per step 102. FIG. 5 illustrates a computer 110 of the PC type wherein the present invention is practiced. The computer 110 includes a display 112, central processor 114, and a keyboard 116 for data entry. Accessories such as a mouse, supplementary memory, (not shown) may be added to facilitate image and data processing. The image file structure may be contained in the software, loaded in the computer, or on transportable storage media such as a floppy disk, tape, or write/erasable CD. Other variants of the hardware for executing the image file structure are well within the skills of practitioners in this art. The invention has been described with reference to a preferred embodiment; However, it will be appreciated that variations and modifications can be effected by a person of ordinary skill in the art without departing from the scope of the invention. PARTS LIST 10 image file 11 file header 12 extensions 13 baseline image data 14 extension properties 15 baseline non-image data 16 number of extensions field 18 recording fields 20 extension type field 22 extension persistence property 24 extension data size 26 extension data 30 start step 32 read number of extensions 34 increments number of extensions 36 decision block 38 determine extension offset 40 write to file 42 read extensions into buffer/memory 44 determine new offsets for extension, 1-n 46 add new extensions to buffer/memory 48 write to file 60 start step 62 read image file 64 modify core image elements 66 check extensions persistence 68 decision block 70 save file 72 decrement number of extensions by the number of 0.times.1 extensions 74 remove all 0.times.1 extensions 76 determine new offsets 78 write to file 80 start step 82 read image file 84 check extensions persistence 86 decision block 88 decision block 90 validate extensions 92 extensions assumed valid 94 valid 96 decrement number of extensions 98 delete extension 100 determine new offsets 102 write to file 104 all extensions are valid 110 computer 112 display 114 central processor 116 keyboard
|
Same subclass Same class Consider this |
||||||||||