WO2012170111A1 - Stockage et transmission d'images comprenant de multiples trames - Google Patents

Stockage et transmission d'images comprenant de multiples trames Download PDF

Info

Publication number
WO2012170111A1
WO2012170111A1 PCT/US2012/031958 US2012031958W WO2012170111A1 WO 2012170111 A1 WO2012170111 A1 WO 2012170111A1 US 2012031958 W US2012031958 W US 2012031958W WO 2012170111 A1 WO2012170111 A1 WO 2012170111A1
Authority
WO
WIPO (PCT)
Prior art keywords
image
captured
digest
component elements
instructions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2012/031958
Other languages
English (en)
Inventor
Kurt Barton Akeley
Yi-Ren Ng
Kenneth Wayne Waters
Kayvon Fatahalian
Timothy James Knight
Yuriy Aleksandrovich Romanenko
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lytro Inc
Original Assignee
Lytro Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/155,882 external-priority patent/US8908058B2/en
Application filed by Lytro Inc filed Critical Lytro Inc
Publication of WO2012170111A1 publication Critical patent/WO2012170111A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00132Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture in a digital photofinishing system, i.e. a system where digital photographic images undergo typical photofinishing processing, e.g. printing ordering
    • H04N1/00148Storage
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00132Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture in a digital photofinishing system, i.e. a system where digital photographic images undergo typical photofinishing processing, e.g. printing ordering
    • H04N1/00167Processing or editing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00132Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture in a digital photofinishing system, i.e. a system where digital photographic images undergo typical photofinishing processing, e.g. printing ordering
    • H04N1/00185Image output
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/32101Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/70Circuitry for compensating brightness variation in the scene
    • H04N23/741Circuitry for compensating brightness variation in the scene by increasing the dynamic range of the image compared to the dynamic range of the electronic image sensors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/32Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N2201/3201Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N2201/3225Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of data relating to an image, a page or a document
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/32Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N2201/3201Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N2201/3225Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of data relating to an image, a page or a document
    • H04N2201/3233Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of data relating to an image, a page or a document of authentication information, e.g. digital signature, watermark
    • H04N2201/3236Details of authentication information generation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/32Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N2201/3201Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N2201/3225Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of data relating to an image, a page or a document
    • H04N2201/3242Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title of data relating to an image, a page or a document of processing required or performed, e.g. for reproduction or before recording
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/32Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N2201/3201Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N2201/3274Storage or retrieval of prestored additional information

Definitions

  • the present invention relates to storage, manipulation, and/ or transmission of image data and related data.
  • Light field photography captures information about the direction of light as it arrives at a sensor within a data acquisition device such as a light field camera.
  • a data acquisition device such as a light field camera.
  • Such light field data can be used, along with captured image data, to create representations of scenes that can be manipulated by a user.
  • light field processing can be used to generate images using the captured image data along with the light field data.
  • Various types of light field processing can be performed, including for example ref ocusing, aberration correction, changing the viewing perspective, and the like.
  • images may be represented as digital data that can be stored electronically.
  • image formats are known in the art, such as for example JPG, EXIF, BMP, PNG, PDF, TIFF and/ or HD Photo data formats.
  • image formats can be used for storing, manipulating, displaying, and/ or transmitting image data.
  • a system and method for storing, manipulating, and/ or transmitting image data, such as light field photographs and the like, in a unified manner that preserves relationships among constituent data elements, enforces immutability of source images, reduces bandwidth and storage requirements, and addresses privacy concerns.
  • image data such as light field photographs and the like
  • the system and method of the present invention also enable deferred combination of images captured from multiple sources and/ or at different times.
  • a container file representing a scene (referred to herein as a "picture” or “picture file”) can include or be associated with any number of component image elements
  • Frames may come from different image capture devices, enabling aggregation of image data from multiple sources.
  • Frames can include image data as well as additional data describing the scene, its particular characteristics, image capture equipment, and/ or the conditions under which the frames were captured.
  • additional data are referred to herein as metadata, which may be universal or application-specific.
  • Metadata may include, for example, tags, edit lists, and/ or any other information that may affect the way images derived from the picture look. Metadata may further include any other state information that is or may be associated with a frame or picture and is visible to an application.
  • Picture files may also include instructions for combining frames and performing other operations on frames when rendering a final image.
  • frames and pictures are implemented as data structures that can be manipulated by software running on a digital camera, computing device, or other electronic device.
  • Frames and/ or pictures can be stored on any suitable electronic storage device, using a suitable file format, and can be transmitted among electronic devices using any suitable protocol and/ or network communication scheme.
  • pictures having any number of frames can be stored, manipulated and/ or transmitted.
  • Each frame can represent an image captured by a sensor in a digital camera, along with appropriate state information.
  • Each image can be a light field image or a conventional two-dimensional image.
  • a frame having a two- dimensional image is referred to as a two-dimensional frame; a frame having a light field image is referred to as a light field frame.
  • Pictures can include two- dimensional frames, light field frames, or any combination thereof.
  • a picture can also be reduced to, or converted to, any standard image format as desired.
  • each frame includes data representing an image detected by the sensor of the camera (image data), and may also include data describing other relevant camera parameters (metadata).
  • metadata include camera settings such as zoom and exposure time, the geometry of a microlens array used in capturing a light field frame, and the like.
  • the metadata may be provided in text format, XML, and/ or in any other suitable format.
  • the image data contained in each frame may be provided in any suitable format, such as for example a raw image or a lossy compression of the raw image. If the image is a raw image, the frame is referred to as a raw frame.
  • pictures can contain any number of frames, and can also contain additional metadata, if appropriate.
  • pictures can also include data derived from the frames and metadata.
  • constituent frames of a picture may have been captured at different times and even by different data acquisition devices.
  • several cameras can be used for capturing images to be aggregated into a picture.
  • each individual camera may not possess the complete picture, as each is contributing only a subset of the frames for the picture.
  • the present invention enables deferred aggregation, wherein cameras are able to output pictures (either 2-D or light field), and their various components (such as frames), even if additional frames and/ or data is/ are expected at a later time. Additional frames and/ or data can be aggregated with such pictures at a later time, either by the camera itself or by software running at a computing device.
  • the system of the present invention provides mechanisms for ensuring that original frame data is preserved, even when users and/ or other entities make changes to pictures.
  • the system of the present invention allows editing of pictures (aggregations of frames, as well as other data), without allowing changes to the original frames themselves.
  • frames are treated as immutable, so that any editing or changes made to images are made to pictures rather than their constituent frames.
  • special effects, distortions, color effects, refocusing, and/ or other operations that can be performed on images are stored as instructions within the picture data structure, and are applied when rendering the final image, so that the original image data is not overwritten.
  • the instructions specified within a picture are mutable, even though the included frames remain immutable.
  • the immutability of frames is enforced by the use of a digest, or hash, which is a unique identifier that may be recomputed (invariantly) from the frame's contents at any time. Unauthorized changes to a frame can thus be detected by comparing the frame's digest with a previously computed digest for that frame.
  • each picture file can include a digest for each frame, even when the frame itself is included in the picture, so that any unauthorized changes to frame data can be detected by performing a new hash operation on the frame data and comparing the digest with the result of the hash operation.
  • the system of the present invention includes mechanisms for displaying a final image at an output device, based on stored picture data.
  • the picture data may include any number of frames, as well as descriptions of operations that are to be performed on the frames.
  • aggregation and other operations are performed "on the fly" when an image is to be rendered for display or transmission.
  • a picture can be reduced or converted into an image file having conventional image data format; this image file can then be displayed, rendered, or transmitted by conventional means.
  • the present invention also provides a mechanism for improving the efficiency of image sharing. For example, when changes are made to a picture whose frames are already stored at two or more locations, only the changes need be transmitted from one location to another. Each location can use its existing copy of the frame data, without the need for transmitting such frame data from one location to another. Only the changes in operations to be performed on the frame data need be transmitted. The present invention thus avoids the needless and redundant transmission of frame data. [0018] Accordingly, in various embodiments, the system of the present invention provides a mechanism by which multiple frames can be aggregated into pictures. This simplifies the process by which users can manage, view, and manipulate multiple images that have some logical relation to one another.
  • Multi-frame pictures can also be reliably aggregated, with assurances of image integrity, even long after the individual images are captured. Such aggregation can be automatic, or it can be performed in response to user input specifying particular combinations of frames to be aggregated.
  • system of the present invention provides a mechanism for allowing a picture to be modified, while enforcing the
  • the present invention also provides additional advantages, as will be made apparent in the description provided herein.
  • certain metadata elements that are not essential to rendering can be selectively removed from frames. For example, in circumstances where an originator of an image wishes to remain anonymous, metadata elements that may identify of the originator can be obscured or deleted using the techniques of the present invention.
  • the technique for storing, manipulating, and transmitting light field picture describing described herein can be applied to other scenarios and conditions, and is not limited to the specific examples discussed herein.
  • the system of the present invention is not limited to light field pictures, but can also be applied to pictures taken by conventional cameras and other imaging devices, whether or not such pictures contain light field data.
  • FIG. 1A depicts an architecture for implementing the present invention in a camera, according to one embodiment.
  • Fig. IB depicts an architecture for implementing the present invention wherein a camera collects image data from other cameras, according to one embodiment.
  • FIG. 1C depicts an architecture for implementing the present invention wherein a computing device collects image data from cameras, according to one embodiment.
  • Fig. ID depicts an architecture for implementing the present invention in a client/ server environment, according to one embodiment.
  • Fig. IE depicts an architecture for implementing the present invention in a standalone computing device, according to one embodiment.
  • Fig. 2 depicts an example of a relationship between pictures and frames, according to one embodiment.
  • FIG. 3 depicts an example of a data structure for a frame, according to one embodiment.
  • Fig. 4A depicts a conceptual representation of digest generation, according to one embodiment.
  • Fig. 4B depicts an example of a relationship between pictures, frames, and digests, according to one embodiment.
  • Fig. 5 depicts an example of generation of a final image from components of a picture, according to one embodiment.
  • Fig. 6 depicts an example of the use of derived frames in generating a final image from components of a picture, according to one embodiment.
  • Fig. 7 depicts an example of generation of a high-dynamic range final image from frames having different exposure lengths, according to one embodiment.
  • Fig. 8 depicts an example of a mechanism for BLOB storage according to one embodiment.
  • Fig. 9 is a flowchart depicting a method of generating and sharing frames and/ or digests, according to one embodiment.
  • Fig. 10 is a flowchart depicting a method of generating and storing a picture file specifying a combination of frames, according to one embodiment.
  • Fig. 11 is a flowchart depicting a method of rendering and outputting a final image based on a stored picture file, according to one embodiment.
  • Capture event the capture of a set of frames that are related.
  • Capture events on a single camera is sequential-flash relighting. Capture events can also involve multiple cameras, each capturing one or more frames.
  • Frame a data entity (stored, for example, in a file) containing a
  • This state includes the sensor image, and other relevant camera parameters, specified as metadata.
  • the sensor image may be either a raw image or a compressed representation of the raw image.
  • Digest a result of a hash function applied to a frame.
  • each digest is a 2-tuple: a first entry identifies a hash function, and a second entry provides the result of the identified hash function applied to a frame.
  • digests provide a mechanism for authenticating frames.
  • Framed picture a picture that includes frame data for all of its frames. (No frame in a framed picture is represented by its digest.)
  • Immutable in one embodiment, the term "immutable" is used herein to refer to data that is not easily changeable by an ordinary user of the device without such a change being detected. It is possible, however, that a system administrator or other authorized individual may be able to make changes to such data, under certain circumstances.
  • Light field a collection of rays. A ray's direction specifies a path taken by light, and its color specifies the radiance of light following that path.
  • Light field frame a frame whose sensor image is a light field image.
  • Light field image a two-dimensional image that spatially encodes a four-dimensional light field. The sensor image from a light field camera is a light field image.
  • Light field picture a picture with one or more light field frames. (A picture with a mix of two-dimensional and light field frames is a light field picture.)
  • Microlens a small lens.
  • Picture a data entity (stored, for example, in a file) containing one or more frames, metadata, and/ or data derived from the frames and/ or metadata. Metadata can include tags, edit lists, and/ or any other descriptive information or state associated with a picture or frame.
  • Pixel an n-tuple of intensity values, with an implied meaning for each value.
  • a typical 3-tuple pixel format is RGB, wherein the first value is red intensity, the second green intensity, and the third blue intensity. Also refers to an individual sensor element for capturing data for a pixel.
  • Raw image an image (for example in Bayer format) that has not been subjected to any lossy compression since it was captured at a sensor.
  • Raw frame a frame in which the sensor image is a raw image.
  • Sensor image any representation of a raw image.
  • Two dimensional (2-D) frames a frame whose sensor image is a two- dimensional (2-D) image.
  • Two dimensional (2-D) image (or image): a two-dimensional (2-D) array of pixels.
  • the pixels are typically arranged in a square or rectangular Cartesian pattern, but other patterns are possible.
  • Two dimensional (2-D) picture a picture that includes only 2-D
  • the term "camera” is used herein to refer to an image capture device or other data acquisition device.
  • a data acquisition device can be any device or system for acquiring, recording, measuring, estimating, determining and/ or computing data representative of a scene, including but not limited to two-dimensional image data, three- dimensional image data, and/ or light field data.
  • Such a data acquisition device may include optics, sensors, and image processing electronics for acquiring data representative of a scene, using techniques that are well known in the art.
  • One skilled in the art will recognize that many types of data acquisition devices can be used in connection with the present invention, and that the invention is not limited to cameras.
  • the use of the term "camera” herein is intended to be illustrative and exemplary, but should not be considered to limit the scope of the invention. Specifically, any use of such term herein should be considered to refer to any suitable data acquisition device.
  • Camera 100A includes optics 111 (such as one or more lenses) for receiving and focusing an image; image sensor(s) 112, located in the optical image path for capturing the image as electronic data; and image processing circuitry 113 for processing the image data to generate data file(s) representing picture(s) 201 and/ or frame(s) 202.
  • optics 111 such as one or more lenses
  • image sensor(s) 112 located in the optical image path for capturing the image as electronic data
  • image processing circuitry 113 for processing the image data to generate data file(s) representing picture(s) 201 and/ or frame(s) 202.
  • picture(s) 201 and/ or frame(s) 202 are stored in local data storage 101 at camera 100A; however, in other embodiments, such data can be transmitted, output, and/ or stored elsewhere.
  • Data storage 101 may be implemented as any magnetic, optical, and/ or electrical storage device for storage of data in digital form, such as flash memory, magnetic hard drive, CD-ROM, and/ or the like.
  • optics 111, image sensor(s) 112, and/ or image processing circuitry 113 operate as described in related U.S. Utility Application Serial No. 12/703,367 for "Light Field Camera Image, File and Configuration Data, and Method of Using, Storing and Communicating Same.”
  • Input device 108 receives input from user 110; such input may include commands for editing, deleting, transmitting, combining, and/ or otherwise manipulating pictures (s) 201 and/ or frame(s) 202. As described in more detail below, in one embodiment the system of the present invention does not permit user 110 to modify individual frames 202, but does allow user 110 to modify pictures 201, so as to allow image editing while preserving the
  • input device 108 can receive input provided via physical buttons, touchscreen, rocker switch, dial, knob, graphical user interface, or any other suitable mechanism, or any combination thereof.
  • user 110 operations on pictures 201 are stored as instructions, as described in more detail.
  • Image renderer 502 renders final image(s) 107 from picture(s) 201 and/ or frame(s) 202, using instructions based on user input. Such rendering can be immediate or deferred.
  • Output device 106 present final image(s) 107 to user 110.
  • Output device 106 may be an integrated display screen on camera 100A, a separate display screen (not shown), and/ or any other suitable device.
  • Final image(s) 107 may include a representation of picture(s) 201.
  • camera 100 A combines any number of frames 202 to generate one or more picture(s) 201, according to the techniques described herein. In one embodiment, such combination is performed by generating instructions specifying various types of operations to be performed on frames 202, including for example combining frames 202 with one another.
  • both frames 202 and pictures 201 are identical to both frames 202 and pictures 201 .
  • Frames 202 may represent image data and metadata captured by camera 100A and/ or by other data acquisition devices. Frames 202 may represent image data captured during a single capture event, or they may represent image data captured at different capture events. In this manner, the system of the present invention provides a mechanism for taking data
  • camera 100 A may include components (not shown) for transmitting picture(s) 201, frame(s) 202, and/or final image(s) 107 in any suitable data format and according to any suitable data transmission protocol.
  • data can be transmitted via the Internet, or via a wired or wireless communications network, personal area network such as BlueTooth, cellular telephone network, pager network, or the like.
  • personal area network such as BlueTooth, cellular telephone network, pager network, or the like.
  • hash module 120 may transform frame(s) 202 into digest(s) 402 by applying a hash function, according to techniques described herein. Such transformation can save storage space and bandwidth in
  • Hash module 120 may be used for authenticating previously generated digest(s) 402 by comparing hash results with previously stored digest(s) 402.
  • hash module 120 may be implemented as software running on a processor, or as a part of image Tenderer 502, or as a separate component, or in any other suitable fashion. In other embodiments, hash module 120 may be omitted.
  • Fig. IB there is shown an alternative architecture in which camera 100 A collects image data from other cameras 100B, lOOC, according to one embodiment.
  • camera 100B is shown as a two-dimensional camera, while cameras 100 A, lOOC are shown as light field cameras; however, any combination of two-dimensional and/ or light field cameras can be used.
  • many components of cameras 100B, lOOC are omitted from Fig. IB.
  • Each camera 100B, lOOC contains local data storage 101, which may include image data 301 and/ or metadata 302 for images captured at that camera 100B, lOOC.
  • cameras 100B, lOOC transfer their image data 301 and/ or metadata 302 to camera 100 A, which collects and stores such data as frame(s) 202 in local data storage 101. Transfer for data from cameras 100B, lOOC to camera 100 A can take place according to any suitable method.
  • cameras 100B, lOOC, and/or 100A can be connected to one another via USB cable or other wired connection; in another embodiment such communication can take place via BlueTooth or another personal area network; in yet another embodiment, such communication can take place via any other wired or wireless communications network.
  • camera 100 A performs operations on data from frame(s) 202, including combining data from frame(s) 202 into one or more picture(s) 201, as described above and as set forth in more detail herein. As discussed above, such combination can take place in response to commands provided by user 110 via input device 108.
  • Image renderer 502 renders final image(s) 107; final image(s) can be presented via output device 106, or otherwise transmitted, stored, and/ or manipulated.
  • Other components of camera 100 A may operate in the same manner as described above in connection with Fig. 1A.
  • optional hash module 120 is also shown, for generating digest(s) 402 from frame(s) 202, and for authenticating previously generated digest(s) 402.
  • FIG. 1C there is shown an alternative architecture in which image data 301 and/ or metadata 302 are collected by computing device 105.
  • User 110 interacts with computing device 105 via input device 108, which may include a mouse, trackpad, trackball, keyboard, and/ or any of the other input components mentioned above.
  • Computing device 105 may be any electronic device, including for example and without limitation, a desktop computer, laptop computer, personal digital assistant (PDA), cellular telephone, smartphone, music player, handheld computer, tablet computer, kiosk, game system, enterprise computing system, server computer, or the like.
  • computing device 105 runs an operating system such as for example: Linux; Microsoft Windows, available from Microsoft Corporation of Redmond, Washington; Mac OS X, available from Apple Inc. of Cupertino, California; iOS, available from Apple Inc. of Cupertino, California; and/ or any other operating system that is adapted for use on such devices.
  • Computing device 105 stores picture(s) 201 and/or frame(s) 202 in data storage 104, which may be located locally or remotely with respect to computing device 105.
  • Data storage 104 may be implemented as any magnetic, optical, and/ or electrical storage device for storage of data in digital form, such as flash memory, magnetic hard drive, CD-ROM, and/ or the like.
  • Data storage 104 can also be implemented remotely, for example at a server (not shown in Fig. 1C).
  • hash module 120 is shown as part of computing device 105; however, hash module 120 can instead be implemented in one or more of cameras 100 or in any other suitable component.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well known to those skilled in the art.
  • computing device 105 includes a number of hardware components as are well
  • processors 111 which can be a conventional microprocessor for performing operations on data under the direction of software, according to well-known techniques
  • memory 112 such as random-access memory having a structure and architecture as are known in the art, for use by the one or more processors in the course of running software.
  • processors 111 which can be a conventional microprocessor for performing operations on data under the direction of software, according to well-known techniques
  • memory 112 such as random-access memory having a structure and architecture as are known in the art, for use by the one or more processors in the course of running software.
  • Such components are well known in the art of computing architecture.
  • Image data 301 and/ or metadata 302 are collected by server 109.
  • Image data 301 and/ or metadata 302 may be transmitted to server 109 via any suitable mechanism; one example is communications network 103 such as the Internet.
  • image data 301 and/ or metadata 302 can be transmitted using HTTP and/ or any other suitable data transfer protocol.
  • Client computing device 105 is communicatively coupled with server 109 via communications network 103.
  • User 110 interacts with computing device 105 via input device 108, which may include a mouse, trackpad, trackball, keyboard, and/ or any of the other input components mentioned above.
  • input device 108 may include a mouse, trackpad, trackball, keyboard, and/ or any of the other input components mentioned above.
  • computing device 105 transmits corresponding request to cause data to be transmitted, received, and/ or manipulated by server 109.
  • server 109 can receive image data 301 and/ or metadata 302 from cameras 100 A, 100B, and store such data as frame(s) 202 in centralized data storage 104.
  • server 109 can perform operations on data, including combining frames 202 to generate picture(s) 201; such picture(s) 201 can then be transmitted to client computing device 105 for viewing on output device 106 as final image(s) 107.
  • client computing device 105 can also store, transmit, or otherwise manipulate final image(s) 107.
  • client computing device 105 may be any electronic device, including for example and without limitation, a desktop computer, laptop computer, personal digital assistant (PDA), cellular telephone, smartphone, music player, handheld computer, tablet computer, kiosk, game system, enterprise computing system, server computer, or the like.
  • computing device 105 runs an operating system such as for example: Linux; Microsoft Windows, available from Microsoft Corporation of Redmond, Washington; Mac OS X, available from Apple Inc. of Cupertino, California; iOS, available from Apple Inc. of Cupertino, California; and/ or any other operating system that is adapted for use on such devices.
  • Linux Microsoft Windows, available from Microsoft Corporation of Redmond, Washington
  • Mac OS X available from Apple Inc. of Cupertino, California
  • iOS available from Apple Inc. of Cupertino, California
  • any other operating system that is adapted for use on such devices.
  • client computing device 105 includes a network interface (not shown) for enabling communication via network 103, and may also include browser software (not shown) for transmitting requests to server 109 and receiving responses therefrom. In this manner, user 110 can edit, delete, modify, manage, and otherwise manipulate data stored at server 109.
  • Centralized data storage 104 is shown as being located at server
  • Providing centralized data storage 104 at server 109 allows pictures(s) 201 and frame(s) 202 to be accessed by a number of computing devices 105 in different locations, using a client/ server architecture. However, such architecture is not necessary to practice the present invention. In one
  • computing device 105 communicates with serve 109 via
  • each of a number of cameras 100 generates digests 402 for its frames 202, and immediately shares these digests 402 with other cameras 100 participating in the capture event.
  • each camera 100 has a "complete" version of a picture 201 representing the capture event, in the sense that each frame 202 for the capture event is represented either by its digest 402 or by the actual frame data 202.
  • each camera 100 transfers actual frame data 202 to central data server 109.
  • Frame data 202 can then be retrieved from server 109 when any of the pictures 201 are to be viewed.
  • frame data 202 can be retrieved ahead of time, so as to improve response time in viewing a picture 201.
  • FIG. IE there is shown an alternative architecture for implementing the present invention in a standalone computing device 105, according to one embodiment.
  • picture(s) 201 and frame(s) 202 may represent images previously collected from camera(s) and/ or other data acquisition devices, and stored at data storage 104 of computing device 105.
  • Fig. IE illustrates that the techniques of the present invention can be practiced on image data without requiring the source of the image data to be present.
  • user 110 can manipulate frame(s) 202 to generate picture(s) 201 by interacting with computing device 105 via input device 108, causing processor 111 to perform operations on frame(s) 202 and generate picture(s) 201.
  • individual frame(s) 202 can be taken from different cameras and/ or at different times.
  • computing device 105 includes the same components as described above in connection with Fig. 1C.
  • Frames 202 can be generated by cameras 100 and/ or other visual data acquisition devices; each frame 202 includes data related to an individual image element such as an image captured by a camera 100 or other visual data acquisition device. Any number of frames 202 can be combined to form a picture 201.
  • a picture 201 may include frames 202 captured by different cameras 100 either simultaneously or in succession, and/ or may include frames 202 captured by a single camera 100 in succession.
  • Frames 202 may be captured as part of a single capture event or as part of multiple capture events.
  • Pictures 201 may include any type of frames 202, in any combination including for example two-dimensional frames 202, light field frames 202, and the like.
  • a picture 201 with one or more light field frames 202 is referred to as a light field picture.
  • each frame 202 includes data representing an image detected by the sensor of the camera (image data), and may also include data describing other relevant camera parameters (metadata), such as for example, camera settings such as zoom and exposure time, the geometry of a microlens array used in capturing a light field frame, and the like.
  • the image data contained in each frame 202 may be provided in any suitable format, such as for example a raw image or a lossy compression of the raw image, such as for example, a file in JPG, EXIF, BMP, PNG, PDF, TIFF and/ or HD Photo format.
  • the metadata may be provided in text format, XML, or in any other suitable format.
  • pictures 201 are related to their constituent frame(s) 202 by virtue of pointers in database records.
  • any particular frame 202 can be a constituent of any number of pictures 201, depending on how many pictures 201 contain a pointer to that frame 202.
  • any particular picture 201 can contain any number of frames 202, depending on how many frames 202 are identified as its constituents in its database record.
  • picture 201 may be a container file that actually contains frame(s) 202.
  • references herein to a picture 201 "containing" one or more frames 202 mean that those frames 202 are associated with picture 201.
  • Pointers are stored to establish relationships between the frame 202 and the various pictures 201 it corresponds to.
  • frame 202 can be represented by its corresponding digest 402, as described herein.
  • the system of the present invention provides a mechanism for storing and manipulating pictures 201 having an arbitrary number of frames 202.
  • a collection of frames 202 may be designated as constituents of a particular picture 201 based on any appropriate criteria.
  • the mode of the capture event may define the relationship between a set of frames 202 and thus cause such frames 202 to be constituents of a common picture 201.
  • a photographer may capture a series of images using exposure bracketing.
  • a set of images having different lighting characteristics can be captured, so that a final image can be generated from the captured images using interpolation or some other form of combination; such a process is referred to as "relighting".
  • an indication that bracketing or relighting is being used may cause the frames 202 captured in a sequence to be associated with a common picture 201. Such an indication may be provided, for example, in metadata for frame(s) 202.
  • any assignment of frames to pictures is allowed, whether specified automatically or manually, and that such assignment can be taken at the time of image capture (i.e., immediately after a capture event) or at any subsequent time.
  • the system of the present invention allows pictures 201 having arbitrary sets of frames 202 to be created.
  • post-capture editing tools such as image manipulation software, can be used for manually specifying such relationships between pictures 201 and frames 202.
  • frame 202 includes image data 301 and/ or metadata 302, although some frames 202 may omit one or the other.
  • frames 202 can include image data 301 for two-dimensional and/ or light field sensor images.
  • other types of image data 301 can be included in frames 202, such as three-dimensional image data and the like.
  • a depth map of the scene is extracted from the light field, so that three-dimensional scene data can be obtained and used.
  • a camera can capture a two- dimensional image, and use a range finder to capture a depth map; such captured information can be stored as frame data, so that the two-dimensional image and the depth map together form a three-dimensional image.
  • metadata 302 includes fields for various parameters associated with image data 301, such as for example camera settings such as zoom and exposure time, the geometry of a microlens array used in capturing a light field frame, and the like.
  • frames 202 are stored in frame files.
  • Frame files may contain additional data, for example to enable operating systems and/ or applications to work with frames 202.
  • additional data include: a file format identifier, to allow applications to recognize frame files; and thumbnail image, in a format that allows an operating system to display a thumbnail as a representation of the file.
  • thumbnail image in a format that allows an operating system to display a thumbnail as a representation of the file.
  • metadata 302 may include identifying data, such as a serial number of the camera or other device used to capture the image, an identifier of the individual photographer operating the camera, the location where the image was captured, and/ or the like. In some situations, user 110 or some other individual may not want such information to be readily available to anyone interacting with frame 202. As described below, in one embodiment, such identifying data, as well as any other data that is not critical to the
  • interpretation of image data 301 may be provided in a removable section of metadata 302.
  • user 110 or an administrator or other individual, can specify that such data be removed or suppressed, so as to preserve privacy.
  • Metadata 302 can be provided in any appropriate format, such as for example a human-readable text file including name-value pairs.
  • metadata 302 is represented using name-value pairs in JavaScript Object Notation (JSON).
  • JSON JavaScript Object Notation
  • metadata 302 is editable by user 110 or any other individual having access to frame 202.
  • metadata 302 is provided in XML or text format, so that any text editor can be used for such editing.
  • frames 202 can be represented as digests 402.
  • a hash function 401 is defined, for generating a unique digest 402 for each frame 202.
  • Hash function 401 can be any mathematical function that operates on the digital data that represents frame 202, to generate output that is unique for that frame 202, or output that is extremely unlikely to be identical for any two frames 202.
  • digests 402 are small relative to their corresponding frames 202, so that transmission, storage, and manipulation of such digests 402 is faster and more efficient than such operations would be on the frames 202 themselves.
  • each digest is 256 bytes in length, although one skilled in the art will recognize that they may be of any length.
  • a digest can also be referred to as a "hash".
  • Digests 402 are substantially unique with respect to one another, so that any attempt to modify data of a frame 202 can be detected by performing hash function 401 on frame 202 data, since the resulting digest 402 would fail to match any previously stored digest 402 for that frame 202. In this manner, the system of the present invention is able to enforce immutability of digests 402 in an efficient manner. Computation of digests 402 by hash function 401 can be performed at camera 100 or any data acquisition device, or at computing device 105, or at server 109. Computation of digests 402 can take place at the time of image capture or at any subsequent time. Verification of image integrity can be performed at any suitable time by recalculating digest 402 from frame 202 data and comparing the result with a previously stored version of digest 402; any difference indicates that the underlying frame 202 has been altered.
  • hash module 120 performs hash function 401 on frame 202 including image data and metadata 302.
  • Hash module 120 may be implemented in software on camera 100, computing device 105, and/ or server 109, and may be part of image renderer 502 or any other component, or may be a separate component.
  • hash function 501 on image data and metadata 302
  • the system of the present invention ensures that changes to either image data and/ or metadata 302 can be detected. In this manner, hash function 401 is used to enforce immutability of both image data and metadata 302.
  • hash function 401 is designed so that nonsubstantive changes to metadata 302 do not cause changes to the resultant digest 402. For example, addition or deletion of whitespace, addition or deletion of comments, reordering of parameters, and the like, do not affect the value of digest 402. In this manner, frame immutability is enforced without hindering the ability to make non-substantive changes that may improve readability but do not change the operation of metadata 302. In one embodiment, hash function 401 ignores any removable sections that are not critical to image rendering, so that such sections can be removed or included without affecting digest 402.
  • FIG. 4B there is shown an example of a
  • pictures 201, frames 202, and digests 402 are represented by the frame data itself, while two other frames are represented by digests 402. Any combination of frames 202 and/ or digests 402 can be included in any particular picture 201.
  • a picture 201 that includes frames 202 but no digests 402 is referred to as a framed picture.
  • Hash module 120 can be used to generate digests 402, as well as to authenticate digests 402.
  • data acquisition devices such as cameras 100 can share digests 402 rather than frames 202, while retaining their own frames 202 locally, so as to save bandwidth and/ or storage space.
  • digests 402 for a picture 201 are shared among cameras 100, each camera 100 has a complete version of picture 201; specifically, each frame 202 in picture 201 is represented either by frame data itself (as captured on that camera 100) or as a digest 402 of the frame 202 (which was computed, for example, by the camera 100 that captured that frame 202).
  • digests 402 help to ensure the integrity of frame 202 data. Since digests 402 can be recomputed from frames 202 at any time, corrupted and/ or modified frames 202 can easily be detected.
  • user 110 can manipulate pictures 201 by interacting with computing device 105 and/ or camera 100.
  • Input device(s) 108 may be provided for receiving input from user 110.
  • a user interface can be provided to enable user 110 to manipulate pictures 201 in various ways.
  • user 110 can specify various operations to be performed on constituent frames 202 of pictures 201, including brightening, darkening, scaling, cropping, rotating, blurring, changing color balance, and the like.
  • Users 110 can also specify that frames 202 are to be combined various ways, and specify relationships between individual frames 202.
  • such manipulations are not stored as changed frame 202 data itself. Rather, they are stored as representations of operations to be performed on frames 202, so that the operations can be re- executed whenever picture 201 is to be rendered.
  • the system of the present invention stores a representation of the operation itself. Underlying frames 202 can thus be left untouched.
  • Such operations are stored within the picture file 201 itself.
  • Pictures 201 thus have the ability to store a recipe (instructions) for creating a particular final image, the ingredients (frames 202) for the recipe are maintained in their original form.
  • Such an approach preserves the integrity of the original captured images and associated metadata (within frames 202), since such original frames 202 can always be retrieved no matter what operations are specified to be performed on such frames 202 in connection with a particular picture 201.
  • FIG. 5 there is shown a block diagram depicting generation of a final image 107 from components of a picture 201, according to one embodiment.
  • Frame 202 represents image data.
  • Digests 402 are generated from frames 202, such as frames 202 captured at other cameras 100.
  • Instructions 501 are representations of modifications and other operations user 110 has performed on frames 202 of picture 201.
  • Image renderer 502 (which may be implemented on computing device 105, camera 100, or any other component), generates final image 107 for display on output device 106, or for storage or transmission.
  • renderer 502 uses data stored in picture 201, including frames 202 and instructions 501. Specifically, renderer 502 performs operations on frames 202 based on instructions 501.
  • original frame(s) 202 can be obtained for any stored digest(s) 402, and the authenticity of such frame(s) 202 can be confirmed by applying hash function 401 and comparing the result to stored digest(s) 402.
  • image renderer 502 is implemented as a software application.
  • final image 107 does not contain information describing the frames 202 and instructions 501 that were used in its creation. Rather, final image 107 is generated in any conventional image format, including for example RAW, TIFF, JPG, GIF, or the like. In other embodiments, however, some or all of the data describing frames 202 and instructions 501 may be included as metadata or in another format.
  • instructions 501 may include a list of user-specified edits to displayed images, such as cropping, rotating, changing contrast, refocusing, and the like. Instructions 501 may indicate operations on a single frame 202 or on any combination of frames 202. In some cases, a series of instructions 501 may be applied in a specified order, so that the result of one instruction 501 is passed to the next instruction 501. In the example of Fig. 5, instructions 501A, 501B, 501C are performed on various frames 202, and then instructions 501D operate to combine the respective results of instructions 501 A, 501B, 501C.
  • renderer 502 When generating image 107, renderer 502 applies such instructions 501 to image data stored in frame 202, in the specified order, to generate final image(s) 107. In one embodiment, such steps are performed each time the image is to be displayed or rendered. In one embodiment, such operations include post-processing as described in related U.S. Utility Application Serial No.
  • a user interface can be provided, so that user
  • a slider can be provided for controlling refocusing operations.
  • rendering performance is improved by including acceleration structures within pictures.
  • acceleration structures may include metadata that can be applied to frames 202.
  • metadata can be derived from frames 202 and/ or user-supplied metadata.
  • the system can store frames that are derived from application of specified operations.
  • Derived frames 601 can be generated by applying instructions 501 to frames 202 and storing the result or a digest 402 of the result. Storage of derived frames 601 can improve efficiency, since image renderer 502 need not regenerate the frame each time final image 107 is to be rendered.
  • derived frames 601 from a previous rendering operation can be retrieved.
  • Derived frames 601 can thus be used as an intermediate storage mechanism so as to avoid redundant recalculation.
  • derived frames 601 are generated by image renderer 502 and stored as components of picture 201.
  • Digests 402 of derived frames 601 can be generated, stored, shared, and/ or transmitted in a manner similar to that described above for digests 402 of frames 202.
  • derived frames 601 and/ or their digests 402 can be stored in a cache (not shown) for rapid access.
  • derived frames 601 can be regenerated when instructions 501 change, so that set of available derived frames 601 is kept current.
  • generation of derived frames 601 is triggered manually in response to user 110 commands.
  • the system of the present invention automatically generates derived frames 601 when certain defined circumstances arise; for example, when it is determined that generation of a derived frame 601 is likely to be useful and storage space is available. A determination that generation of a derived frame 601 is likely to be useful may depend, for example, on detection that certain instructions 501 are being repeatedly applied to the same frame(s) 202.
  • a user 110 or other entity can specify whether or not acceleration structures such as derived frames 601 should be used for a particular picture 201 or frame 202.
  • the specification as to whether an acceleration structure should be used may depend on the characteristics of the destination renderer 502; for example, a renderer 502 with superior processing power may not need an acceleration structure, whereas one which has inferior processing power (and/ or is burdened by other concurrent tasks) may use acceleration structures.
  • the available of cache storage space may determine whether acceleration structures such as derived frames 601 should be used.
  • derived frames 601 are shown, for illustrative purposes.
  • Derived frame 601B is generated from frame 202A and is stored within picture 201.
  • Derived frame 601 A was generated based on some instructions not part of picture 201; for example, derived frame 601A may have been provided by some other device.
  • picture 201 includes digest 402A of derived frame rather than derived frame 601A itself.
  • the system of the present invention retrieves derived frame 601 A and checks it against digest 402A. Then, image renderer 502 applies instructions as indicated: instructions 501B are applied to derived frame 601A and instructions 501C are applied to digest 402B. Instructions 501 A need not be performed, since derived frame 601B is already available and contains the results of application of instructions 501 A to frame 202A. Instructions 501D are applied to the results of instructions 501B and 501 C in combination with derived frame 601B, to generate final image 107 for output. [0096] Note that the example of Fig. 6 illustrates the application of instructions 502 to frames 202 as well as derived frames 601. In general, any number of instructions can be applied in succession to one or more frame(s) 502, derived frame(s) 601, and/ or combination(s) thereof.
  • Derived frames 601 may include metadata, if appropriate, in the same manner as frames 602.
  • each derived frame 601 includes a pointer 602 or other identifier indicating the frame 202 from which it was derived. This allows a mechanism by which the original frame 202 to be retrieved.
  • This pointer 602 can be provided as metadata within derived frame 601.
  • the system of the present invention can refer to pointer 602 within derived frame 601 to locate and retrieve the corresponding original frame 202 so that it can be edited, modified, and more manipulated as appropriate.
  • Additional forms of acceleration structures can be used. For example, if the frame data are light field images, a stack of output images can be computed, each with a different focus distance. These images can be stored, so that a picture 201 can later be "refocused" by selecting one of the pre-computed images. If user 110 selects an apparent focal distance for which no image was pre-computed, such as a distance between two stored distances, interpolation and/ or extrapolation can be used to generate an appropriate resultant image in an efficient manner.
  • digests improves the efficiency with which frames 202 can be aggregated into pictures 201, particularly when such aggregation is deferred (i.e., takes place substantially later than image capture). For example, in situations where frames 202 from different cameras 100 or other data acquisition devices are to be aggregated with one another, embodiments of the present invention make such transfer of information describing such frames 202 more efficient.
  • Digests 402 can be shared among the various devices, so that actual image data need not be repeatedly transferred.
  • a device can refer to frame 202 data by its corresponding digest 402, with the assurance that when actual frame 202 data arrives, it is authentic. The authenticity of frame 202 data can be assured by recomputing digest 402 from frame 202 data, and comparing the result with stored digest 402. Any discrepancy indicates that frame 202 has been modified or corrupted.
  • a picture 201 is defined as having a single frame 202.
  • each "blobref” includes a hash type (i.e., an identification of the hash function) and hash data, forming the digest 402.
  • a blobref might be "SHAl-2fd4elc67a2d28fced849eelbb76e7391b93ebl2"; "shal” indicates the hash type, and the remainder of the data is the hash data itself.
  • the hash data can be of any suitable length, such as for example 40 hexadecimal digits.
  • the blobref refers to a binary large object (BLOB), according to well known techniques; this reference can be de-referenced by a blob server
  • frame 201 separates private metadata from other metadata. For example, metadata that might identify the photographer, location, and/ or equipment can be omitted by deleting the privateMetadata blobref from frame 202.
  • the user interface for enabling user 110 to manipulate pictures 201 allows various operations to be performed on pictures 201; however, such operations do not change the underlying frame 202 data itself.
  • the user interface does not provide a way for user 110 to delete frames 202; in another embodiment, such an operation is possible but only for certain authenticated users 110 and/ or only under special conditions. Even if a picture 201 is deleted, in one embodiment its component frames 202 remain stored.
  • the system of the present invention encourages persistence of underlying data and thereby provides support for archival functions.
  • the techniques of using digests 402, as described above ensure authenticity of frames 202, by providing a way for modifications or corruption of frames 202 to be detected. Such assurances of authenticity also help to support archival functions.
  • High-dynamic range (HDR) imaging is a technique that combines two or more images having different exposure lengths so as to generate an image having a higher dynamic range than do the source images. HDR imaging thus provides a way to overcome the limited dynamic range available in some image sensors.
  • Fig. 7 the techniques of the present invention are applied to generate an HDR final image 107.
  • Optics 111, image sensor(s) 112, and image processing circuitry 113 of camera 110 generate two or more frames 202 having different exposure lengths.
  • two frames 202 are shown: short- exposure frame 202B and long-exposure frame 202C.
  • Frames 202B, 202C are shown as being captured by a single camera 100; alternatively, they may come from different cameras or other data acquisition devices.
  • frames 202B [0109] According to the techniques of the present invention, frames 202B,
  • 202C are represented in picture 201. Metadata (not shown) may also be included in frames 202B, 202C, for example to identify the exposure lengths and other information about the images represented therein. Instructions 501A specify how frames 202B, 202C are to be combined to generate HDR final image 107, for example using HDR processing techniques to extract various portions of images depending on contrast levels.
  • HDR final image 107 is generated by image renderer 502 running at computing device 105.
  • image renderer 502 could be located at camera 100 or at any other location.
  • renderer 502 combines frames 202B, 202C based on instructions 501 A.
  • a user interface can be presented to allow the user to specify parameters for the rendering operation; for example a slider control (not shown) can be presented to allow user 110 to specify the overall contrast level of HDR final image 107.
  • the representations of frames 202B, 202C within picture 201 may be replaced by digests (not shown in Fig. 7) according to the techniques described above.
  • JSON JavaScript Object Notation
  • Metadata for the present invention is stored using a JavaScript Object Notation (JSON) format, which provides a standardized text notation for objects.
  • JSON JavaScript Object Notation
  • JSON is sufficiently robust to provide representations according to the techniques described herein, including objects, arrays, and hierarchies. JSON further provides a mechanism which is easy for humans to read, write, and understand.
  • object : ⁇ ⁇ I ⁇ members ⁇
  • pair string : value
  • the JSON representation can be used to store frame metadata in a key-value pair structure.
  • frame metadata may contain information describing the camera that captured an image.
  • An example of a portion of such a representation in JSON is as follows:
  • Data stored in the JSON representation may include integers, floating point values, strings, Boolean values, and any other suitable forms of data, and/ or any combination thereof.
  • a software application can access data in a frame 202 by performing a key lookup, and/ or by traversing or iterating over the data structure, using known techniques. In this manner, image renderer 502 can use the data found within frames 202 and pictures 201 when generating final image(s) 107 and/ or when combining frames 202 into pictures 201.
  • the JSON representation may also include structures; for example a value may itself contain a list of values, forming a hierarchy of nested key-value pair mappings. For example:
  • binary data is stored in the JSON structure via a base64-encoding scheme.
  • Identifying data, as well as any other data that is not critical to the interpretation of image data, may be provided in a removable section of metadata, for example in a separate section of the JSON representation. This section can be deleted without affecting image rendering operations, since the data contained therein is not used for such operations.
  • An example of such a section is as follows:
  • Data to be used in rendering images may be included in any number of separate sections. These may include any or all of the following:
  • Description section can contain any information generally describing the equipment used to capture the image.
  • Image section contains image data.
  • Image section can contain color-related fields for converting raw images to RGB format.
  • Image section can contain a "format” value indicating whether the format of the image is "raw” or "rgb".
  • various other fields can be provided to indicate what corrections and/ or other operations were performed on the captured image.
  • timeStamp "2009:07:04 03:00:46 GMT"
  • Devices section specifies camera hardware and/ or settings; for example, lens manufacturer and model, exposure settings, and the like. In one embodiment, this section is used to break out information for component parts of the camera that may be considered to be individual devices. An example is as follows:
  • Light field section provides data relating to light fields, image refocusing, and the like. Such data is relevant if the image is a light field image.
  • An example is as follows:
  • pegDataStream " / 9 / 4AAQSkZJRgABAQAAAQABAAD/DBAQE mJFZ//Z” ⁇
  • the "defects" key refers to a set of (x,y) tuples indicating defective pixels. Such information can be useful in generating images, as defective pixels can be ignored, recomputed from adjacent pixels, down- weighted, or otherwise processed. One skilled in the art will recognize that various techniques for dealing with such defects can be used. If a concern exists that the specific locations of defects can uniquely identify a camera, raising privacy issues, the "defects" values can be omitted or can be kept hidden so that they are not exposed to unauthorized users.
  • Frame digests are supported by the JSON data structure. As described above, a digest can be stored as both a hash type and hash data. The following is an example of a digest within the removable section of a JSON data structure:
  • Metadata can be included in a file separate from the image itself.
  • one file contains the image data (for example, img_0021.jpg, img_0021.dng, img_0021.raw, or the like), and another file in the same directory contains the JSON metadata (for example, img_0021.txt).
  • the files can be related to one another by a common filename (other than the extension) and/ or by being located in the same directory.
  • the image data and the metadata can be stored in a single file.
  • the JSON data structure can be included in an ancillary tag according to the exchangeable image file format (EXIF), or it can be appended to the end of the image file.
  • EXIF exchangeable image file format
  • a file format can be defined to include both image data and metadata.
  • provisionalDate STRING, // to be included only if the JSON is formatted to a provisional version
  • ⁇ , 'thumbnailArray [ THUMBNAIL_OBJ / / may be empty .
  • frameArray [ FRAME_OBJ ], // may be empty .
  • viewArray [ VIEW_OBJ ] , / / may be empty .
  • imageRef BLOBREF, // the ef, the http, or the inline image must be present
  • ARRAY_IMAGE_PIXEL :: NUMBER
  • Metadata FRAME_METADATA_OBJ, // optional, but blobref must be specified in either case.
  • PRIVATE_FRAME_METADATA_OBJ // optional, but cannot be present if blobref is not present.
  • mosaic // describes the pattern of pixels in the raw image
  • top INT, // number of rows of pixels removed from the top of the sensor image
  • bitsPerPixel BIT // bits per pixel in the raw stream. Greater than or equal to sensor
  • bitsPerPixel bitsPerPixel .
  • pixelFormat // how to interpret the value of an individual pixel (after it is unpacked from the raw data)
  • black INT, // post- shift black value (values below this are negative values, due to noise)
  • sampleArray [ ACCELEROMETER_SAMPLE_OBJ ] // must not be empty.
  • FlashArray [ FLASH_OBJ ], // may be empty .
  • infinityLambda LAMBDA, // distance ahead of the MLA that is in focus at infinity (along optical axis )
  • zoomStep INT, // optional, zoom stepper-motor position
  • focusStep INT, // optional, focus stepper-motor position
  • exitFNumber NUMBER, // ratio of focal length to the diameter of the exit pupil
  • Rotation : RADIAN, // positive values indicate CW rotation, viewed from the optical axis in front of the camera
  • tile SENSOR_TILE_ENUM, // name of tile pattern
  • bitsPerPixel : BIT
  • imageRef BLOBREF, // must be present .
  • Vendor-Content VE D0R_FRAME_PARAMETER_0BJ
  • any number of extensions can be made to the JSON specification for picture files; these may be provided, for example, for certain types of equipment or vendors according to one embodiment.
  • BLOB Binary Large Object
  • frame and/ or picture data is stored as binary large objects (BLOBs).
  • BLOBs binary large objects
  • “Blobrefs” can be used as wrappers for such BLOBs; each blobref holds or refers to a BLOB.
  • blobrefs can contain hash type and hash data, so as to facilitate authentication of data stored in BLOBs.
  • Front end 802 receives commands 801 such as put (blobref, blob) and get(blobref) (which returns a BLOB).
  • Front end 802 may be an application programming interface (API), for example, for receiving commands 801 from a browser, input device, or other source.
  • API application programming interface
  • front end 802 may pass a search request to search server 803, which obtains index data from index storage 804 so as to identify the location of the requested BLOB.
  • Front end 802 makes requests of the appropriate blob server(s) 505, based on the index data, to obtain the requested BLOB.
  • Blob servers 805 retrieve requested BLOBs from blob storage 806.
  • Blob servers 805 communicate with one another to keep their data in sync, so as to avoid discrepancies in stored BLOBs.
  • search server 803 may periodically communicate with one or more Blob servers 805 in order to update its index 804.
  • FIG. 9 there is shown a flowchart depicting a method of generating and sharing frames 202 and/ or digests 402, according to one embodiment.
  • Camera 100 or other data acquisition device captures 901 images and generates 902 frames 202 from the captured images.
  • frames 202 can contain metadata describing the equipment used in capturing the image, as well as removable identifying information and the like.
  • Digests 402 are generated 903 by applying a hash function to frame data, as described above.
  • Frames 202 are stored 903, either at camera 100 or at some central location such as server 109, another camera 100, computing device 105, or the like.
  • Digests 402 and/ or frames 202 are shared 905 among devices, if appropriate, to allow images captured in step 901 to be combined with images captured at other devices. As described above, in some embodiments digests 402 are shared so as to conserve bandwidth. Sharing 905 of frames 202 and/ or digests 402 can include transmission over a computing network, as described above.
  • FIG. 10 there is shown a flowchart depicting a method of generating and storing a picture 201 file specifying a combination of frames 202, according to one embodiment.
  • an operation is performed in response to receiving input 1001, for example a command entered via input device 108, to combine images.
  • Such an operation can be performed automatically in response to a determination that two or more images are related (for example if it is determined that they are of the same subject at approximately the same time).
  • Picture 201 file is generated 1002, which can include any combination of frames 202 and/ or digests 402.
  • picture 201 may include instructions for combining frames 202.
  • Picture 201 file is stored 1003, for example in data storage 104 at a camera 100, computing device 105, server 109, or any other suitable location.
  • 107 can be generated from picture 201, using the image data and instructions contained therein. Such rendering can happen at any time, even long after picture 201 file has been generated.
  • FIG. 11 there is shown a flowchart depicting a method of rendering and outputting a final image based on a stored picture 201 file, according to one embodiment.
  • such an operation is performed in response to receiving 1101 input, for example via input device 108, to render a final image 107.
  • the steps of Fig. 10 are performed by image Tenderer 502 in response to such input.
  • Picture file 1102 is retrieved. If picture 201 includes frames 202, the frames are retrieved for rendering. If picture 201 includes digests 402, the corresponding frames 202 are retrieved 1103, and can be authenticated by independent application 1104 of the hash function to frame 202 data, as described above. The hash result from such independent application is compared 1105 against stored digest 402 for authentication. If the retrieved frames 202 are authenticated, final image 107 is rendered 1106 based on data in picture file 201, including image data and/ or instructions. Once final image 107 has been rendered, it is output 1104, for example on output device 106 such as a display screen.
  • user input is received for controlling the rendering operation 1106.
  • user 110 may be able to control various parameters of the image combination, such as size, contrast, distortion, and the like. Any type of suitable user interface may be provided for enabling such user control.
  • component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.
  • the present invention can be implemented as a system or a method for performing the above-described techniques, either singly or in any combination.
  • the present invention can be implemented as a computer program product comprising a nontransitory computer-readable storage medium and computer program code, encoded on the medium, for causing a processor in a computing device or other electronic device to perform the above-described techniques.
  • Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention can be embodied in software, firmware and/ or hardware, and when embodied in software, can be downloaded to reside on and be operated from different platforms used by a variety of operating systems.
  • the present invention also relates to an apparatus for performing the operations herein.
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computing device.
  • a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, readonly memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, flash memory, solid state drives, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • the computing devices referred to herein may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
  • the present invention can be implemented as software, hardware, and/ or other elements for controlling a computer system, computing device, or other electronic device, or any combination thereof.
  • Such an electronic device can include, for example, a processor, an input device (such as a keyboard, mouse, touchpad, trackpad, joystick, trackball, microphone, and/ or any combination thereof), an output device (such as a screen, speaker, and/or the like), memory, long-term storage (such as magnetic storage, optical storage, and/ or the like), and/ or network connectivity, according to techniques that are well known in the art.
  • a processor such as a keyboard, mouse, touchpad, trackpad, joystick, trackball, microphone, and/ or any combination thereof
  • an output device such as a screen, speaker, and/or the like
  • memory such as a screen, speaker, and/or the like
  • long-term storage such as magnetic storage, optical storage, and/ or the like
  • network connectivity such as magnetic storage, optical storage, and/ or the like
  • Examples of electronic devices that may be used for implementing the invention include: a mobile phone, personal digital assistant, smartphone, kiosk, server computer, enterprise computing device, desktop computer, laptop computer, tablet computer, consumer electronic
  • An electronic device for implementing the present invention may use any operating system such as, for example: Linux; Microsoft Windows, available from Microsoft Corporation of Redmond, Washington; Mac OS X, available from Apple Inc. of Cupertino, California; iOS, available from Apple Inc. of Cupertino, California; and/ or any other operating system that is adapted for use on the device.
  • Linux any operating system
  • Microsoft Windows available from Microsoft Corporation of Redmond, Washington
  • Mac OS X available from Apple Inc. of Cupertino, California
  • iOS available from Apple Inc. of Cupertino, California
  • any other operating system that is adapted for use on the device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Studio Devices (AREA)

Abstract

Conformément à différents modes de réalisation, de multiples trames, ayant chacune des données et des métadonnées d'image, peuvent être agrégées dans des images. Les trames peuvent provenir de différents dispositifs de capture d'image, permettant une agrégation de données d'image provenant de multiples sources. L'agrégation peut être automatique, ou elle peut être réalisée en réponse à une entrée d'utilisateur spécifiant des combinaisons particulières de trames à agréger. Dans différents modes de réalisation, des images sont mutables, alors que l'immutabilité des trames cohérentes est exécutée. Dans différents modes de réalisation, certains éléments de métadonnées qui ne sont pas essentiels pour la restitution peuvent être retirés de manière sélective de trames, de façon à traiter les problèmes de confidentialité. Dans différents modes de réalisation, des trames peuvent être authentifiées par l'utilisation de condensés générés par une fonction de hachage.
PCT/US2012/031958 2011-06-08 2012-04-03 Stockage et transmission d'images comprenant de multiples trames Ceased WO2012170111A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/155,882 US8908058B2 (en) 2009-04-18 2011-06-08 Storage and transmission of pictures including multiple frames
US13/155,882 2011-06-08

Publications (1)

Publication Number Publication Date
WO2012170111A1 true WO2012170111A1 (fr) 2012-12-13

Family

ID=47296354

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/031958 Ceased WO2012170111A1 (fr) 2011-06-08 2012-04-03 Stockage et transmission d'images comprenant de multiples trames

Country Status (1)

Country Link
WO (1) WO2012170111A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2750391A1 (fr) * 2012-12-31 2014-07-02 Nokia Corporation Procédé, appareil et produit de programme informatique pour le traitement d'images
WO2016061011A3 (fr) * 2014-10-15 2016-06-09 Microsoft Technology Licensing, Llc Recommandation de capture d'appareil photo pour des applications
WO2016202926A1 (fr) * 2015-06-18 2016-12-22 Dxo Labs Procédé et dispositif de production d'une image numérique
US9641500B2 (en) 2013-04-17 2017-05-02 P2S Media Group Oy Method and apparatus for determining multimedia data authenticity level
WO2017172234A1 (fr) * 2016-04-01 2017-10-05 Intel Corporation Technologies de gestion de données immuables sur un dispositif de banque de données

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060130017A1 (en) * 2002-06-17 2006-06-15 Microsoft Corporation Combined image views and methods of creating images
KR20090016453A (ko) * 2006-04-04 2009-02-13 어도비시스템즈인코오포레이티드 개선된 플레놉틱 카메라
KR20110059247A (ko) * 2009-11-27 2011-06-02 삼성전자주식회사 광 필드 데이터를 이용한 영상 처리 장치 및 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060130017A1 (en) * 2002-06-17 2006-06-15 Microsoft Corporation Combined image views and methods of creating images
KR20090016453A (ko) * 2006-04-04 2009-02-13 어도비시스템즈인코오포레이티드 개선된 플레놉틱 카메라
KR20110059247A (ko) * 2009-11-27 2011-06-02 삼성전자주식회사 광 필드 데이터를 이용한 영상 처리 장치 및 방법

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2750391A1 (fr) * 2012-12-31 2014-07-02 Nokia Corporation Procédé, appareil et produit de programme informatique pour le traitement d'images
US9202266B2 (en) 2012-12-31 2015-12-01 Nokia Technologies Oy Method, apparatus and computer program product for processing of images
US9641500B2 (en) 2013-04-17 2017-05-02 P2S Media Group Oy Method and apparatus for determining multimedia data authenticity level
WO2016061011A3 (fr) * 2014-10-15 2016-06-09 Microsoft Technology Licensing, Llc Recommandation de capture d'appareil photo pour des applications
US9723200B2 (en) 2014-10-15 2017-08-01 Microsoft Technology Licensing, Llc Camera capture recommendation for applications
WO2016202926A1 (fr) * 2015-06-18 2016-12-22 Dxo Labs Procédé et dispositif de production d'une image numérique
FR3037756A1 (fr) * 2015-06-18 2016-12-23 Dxo Labs Procede et dispositif de production d'une image numerique
US10600170B2 (en) 2015-06-18 2020-03-24 Dxo Labs Method and device for producing a digital image
WO2017172234A1 (fr) * 2016-04-01 2017-10-05 Intel Corporation Technologies de gestion de données immuables sur un dispositif de banque de données

Similar Documents

Publication Publication Date Title
US8908058B2 (en) Storage and transmission of pictures including multiple frames
US12002264B2 (en) Use of camera metadata for recommendations
US20120249550A1 (en) Selective Transmission of Image Data Based on Device Attributes
CN111989932B (zh) 用于将图像封装在文件中的方法和装置
TWI222316B (en) Apparatus, method and computer program product configured to provide output image adjustment of an image file
US7626614B1 (en) Transfer function and high dynamic range images
CN114930811B (zh) 用于深白平衡编辑的方法和装置
US8982223B2 (en) Image sending apparatus, image recording apparatus and image recording method using identification information relating reduced image data with original image data
US20090102946A1 (en) Methods, apparatuses, systems, and computer program products for real-time high dynamic range imaging
US10114838B2 (en) Reference card for scene referred metadata capture
JP6108755B2 (ja) 撮影機器、撮影画像送信方法及び撮影画像送信プログラム
WO2012170111A1 (fr) Stockage et transmission d'images comprenant de multiples trames
US9781293B2 (en) Apparatus and method for managing image files by displaying backup information
US10600170B2 (en) Method and device for producing a digital image
WO2024163777A1 (fr) Systèmes et procédés d'imagerie avec une première caméra pour simuler une seconde caméra
CN116320714B (zh) 图像采集方法、装置、设备、存储介质和程序产品
WO2022079989A1 (fr) Système, dispositif, procédé et programme de traitement d'informations, dispositif d'imagerie et procédé de commande et programme de commande pour dispositif d'imagerie
WO2024251049A1 (fr) Procédé et appareil de traitement de données de médias, dispositif électronique et support d'informations lisible
CN115456894A (zh) 一种视频制作色彩校正方法、装置、设备及存储介质
Perez The color management handbook for visual effects artists: digital color principles, color management fundamentals & aces workflows
WO2024122396A1 (fr) Dispositif et procédé de traitement d'image
CN120529169A (zh) 数据处理方法、装置、电子设备及存储介质
CN118018859A (zh) 训练数据的生成方法、装置、电子设备和存储介质
Horsmanheimo Camera Architecture
JP2006279459A (ja) 画像撮影装置、画像撮影方法、画像撮影プログラムおよび記録媒体

Legal Events

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

Ref document number: 12796005

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12796005

Country of ref document: EP

Kind code of ref document: A1