WO2018115847A1 - Procédés et appareil de fourniture d'image et d'accès à ladite image - Google Patents

Procédés et appareil de fourniture d'image et d'accès à ladite image Download PDF

Info

Publication number
WO2018115847A1
WO2018115847A1 PCT/GB2017/053809 GB2017053809W WO2018115847A1 WO 2018115847 A1 WO2018115847 A1 WO 2018115847A1 GB 2017053809 W GB2017053809 W GB 2017053809W WO 2018115847 A1 WO2018115847 A1 WO 2018115847A1
Authority
WO
WIPO (PCT)
Prior art keywords
image
data
viewing means
access
displayable
Prior art date
Application number
PCT/GB2017/053809
Other languages
English (en)
Inventor
Jake Leigh CLARKE
Nicholas Tony MUNSON
Original Assignee
Sony Interactive Entertainment Inc.
Sony Interactive Entertainment Europe Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Interactive Entertainment Inc., Sony Interactive Entertainment Europe Limited filed Critical Sony Interactive Entertainment Inc.
Publication of WO2018115847A1 publication Critical patent/WO2018115847A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/51—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/78—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/783—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using metadata automatically derived from the content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/58—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/58—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/583—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using metadata automatically derived from the content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/70—Information retrieval; Database structures therefor; File system structures therefor of video data
    • G06F16/78—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/44—Receiver circuitry for the reception of television signals according to analogue transmission standards
    • H04N5/445—Receiver circuitry for the reception of television signals according to analogue transmission standards for displaying additional information

Definitions

  • the present invention relates to image provisioning and access methods and corresponding apparatus.
  • Conventional images comprise a single array of black and white or colour pixels, which may be encoded in a variety of ways to form a single image file.
  • Popular conventional file formats include .jpg (joint photographic experts group), .gif (graphics interchange format) and .png (portable network graphics), although many others exist.
  • the present invention seeks to address or mitigate this need.
  • a method of image provision is provided in accordance with claim 1.
  • a method of image provision is provided in accordance with claim 8.
  • an image provision apparatus is provided in accordance with claim 12.
  • an image access apparatus is provided in accordance with claim 14.
  • Figure 1 is a schematic diagram of a system comprising image provision and access apparatuses in accordance with an embodiment of the present invention.
  • Figure 2 is a schematic diagram of an image sample scheme in accordance with an embodiment of the present invention.
  • Figure 3 is a flow diagram of a method of image provision in accordance with an embodiment of the present invention.
  • FIG. 4 is a flow diagram of a method of image provision in accordance with an embodiment of the present invention.
  • Figure 5 is a flow diagram of a method of image access in accordance with an embodiment of the present invention.
  • Figure 6 is a schematic diagram of an apparatus in accordance with an embodiment of the present invention.
  • Figure 1 illustrates a system 1 in which an image source (here a server 2 on a network 4, but equally a local source such as an optical disk) can supply image files to one or more of several types of client.
  • a first client 10A uses a conventional viewing means 50 such as a TV or monitor, and uses a conventional browser / app to access images from the source.
  • a second client 10B uses a first alternative viewing means, such as a stereoscopic TV 51, 52, and uses a browser/app in accordance with an embodiment of the present invention to access images from the source.
  • a third client IOC uses a second alternative viewing means, such as a virtual reality (VR) head mounted display (HMD) 53, and also uses a browser/app in accordance with an embodiment of the present invention to access images from the source.
  • VR virtual reality
  • HMD head mounted display
  • the clients may access the server directly (i.e. by having a direct address to the relevant content, or by accessing a website hosted by the server), or indirectly (for example by viewing a website hosted by a third party that points to an image on the server).
  • a web page on the server may include an image 'address/resource/example l.png', which the first client will download and use to view the webpage in a conventional manner.
  • the second client using a stereoscopic-aware browser, may encounter the link to 'address/resource/examplel.png' in the webpage and replace it with a request for 'address/resource/examplel.3dp', where .3dp is a notional stereoscopic image format comprising data for left and right images of a stereoscopic pair.
  • the third client using a VR-aware browser, may instead request 'address/resource/examplel.vrp', where .vrp is a notional VR image format comprising data for a spherical panoramic image.
  • this scheme is problematic; the second and third browsers will send alternative requests to a host server for any image they encounter regardless of whether an alternative format image is available, thus increasing load on the server. This potentially also delays displaying the original .png image as a fall-back option if it is necessary to wait for confirmation of the presence or absence of the alternative image from the server (e.g. in the form of either delivering the alternative image, or delivering a so-called 404 error message indicating that the requested item has not been found). In a situation where only a comparatively small number of images will be supported by alternative format substitutes in this manner, the resulting experience would be poor for users of the second and third clients.
  • the system is not flexible; if the first client decides to post the example 1. png image on another site (e.g. Facebook®, Twitter® or the like), the alternative format images will not be transferred as well. Consequently if the second or third client viewed the resulting Facebook® or Twitter® post, they could not access the stereo or VR versions of the image left behind on the original server.
  • another site e.g. Facebook®, Twitter® or the like
  • supplementary data is incorporated into a conventional image file that is either not detected by conventional browsers/apps (or 'viewing means'), or is ignored by design.
  • This supplementary data may comprise additional image data to wholly or partially allow reconstruction of an alternative image type by a compatible browser/app, and/or may comprise information pointing to additional image data to similarly wholly or partially allow reconstruction of an alternative image mode by a compatible browser/app (or 'viewing means'). Singly or in combination, these additional sources of data then enable reconstruction of at least one alternative image type.
  • the .png file format is used as an example, but the techniques described herein are not limited to this format.
  • the .png image format comprises an initial signature followed by so-called 'chunks'.
  • the signature is simply a sequence of 8 bytes shared by all .png files to identify them as such regardless of file name.
  • the chunks then comprise the image data.
  • Each chunk has a 4-byte identifier. Each byte corresponds to an upper or lower case ASCII character, and the identifier then corresponds to a mnemonic such as 'IHDR', or image header chunk, and 'ID AT', or image data chunk.
  • a browser or app equipped to display .png files is programmed to handle these known chunk types appropriately to extract the information required to display the image.
  • the .png scheme also allows for non-standard custom chunks.
  • the chunk naming scheme allows for conventional browsers and apps to ignore these if desired.
  • the four-character chunk identifier utilises whether or not the selected characters are in upper or lower case to flag specific meanings that any browser will recognise:
  • the first character case bit indicates whether a chunk is essential; consequently if a browser fails to recognise an essential chunk it will issue a warning, but failure to recognise a non-essential chunk can be ignored.
  • the second character case bit indicates whether a chunk is public or private, or more generally, standard or proprietary, if a browser fails to recognise a proprietary chunk it can be ignored.
  • the third character case bit is in principle reserved and should be upper case, but in conjunction with the other character case bits (e.g. proprietary), could be used to flag any desired change of state.
  • the fourth character case bit indicates to apps that might re-save the file (for example, image editors) whether or not to include an unknown chunk in the new version of the file.
  • a new chunk can be defined with a four character name whose letter cases indicate it is non-essential and proprietary but should be preserved when the image is copied; this will be ignored by legacy browsers/apps, but can be recognised by 3D aware browsers/apps or VR aware browsers/apps as appropriate.
  • a custom chunk may thus have the (non-limiting) example name 'thRd', for 'three-dimensional image', and comprise image data for a complementary image to that encoded in the standard ID AT image chank(s) of the .png file, such that the two images form a stereoscopic image pair that a 3D-aware browser or app can display for the second client.
  • a similar image 3D image header chunk could be provided with data defining the image dimensions and the like, or the existing IHDR data could be re-used on the assumption that both images will have identical dimensions and other properties.
  • a custom chunk may thus have the (non- limiting) example name 'vrPi', for 'virtual reality panoramic image', and comprise image data for a cylindrical-projection, box-projection or spherical-projection panoramic image that the user of an HMD can view by looking around whilst wearing the HMD.
  • the conventional .png image may comprise a representative section of the wider panorama so that users of legacy browsers/apps can still see some of the scene. It will be appreciated that both 3D and VR versions of images could be incorporated in the .png image at the same time to support the second and third clients of Figure 1 simultaneously.
  • a range of different supplementary data types to generating alternative image types may be included as appropriately named chunks.
  • Such types include the panorama or 'skybox' mentioned above, and also potentially 3D models, animation data, audio queues and data, and interaction scripts, so that interactive elements could be included in the VR presentation of the image (for example, a character standing behind you in the image may talk to you or go 'boo' if you turn to face them, with suitable animation provided either by rendering a 3D model, or having animation frames of the specific sub-region of the panoramic that move, together with audio data and rules for when the animation / audio are triggered (for example when the character is within N degrees or M pixels of the central viewpoint of the user).
  • Such chunks may also have associated header chunks or may include relevant parameter data in the chunks themselves in a format known to the 3D or VR aware browsers/apps.
  • the supplementary data for newer and alternative image formats can be encapsulated within the .png image file, so that the first client can view the original .png image in conventional fashion transparently, while whichever of the second and third clients are supported by the .png file can access their respective alternative data to display image data appropriately, or as a fall-back position display the original .png like any other image.
  • whichever of the above alternative image data is desired for inclusion in the .png file may be included in a single chunk, together with data forming an asset table identifying the type, offset and size of each date item within the chunk.
  • the asset table could be located at the start of the chunk, or again may be included as an associated header chunk.
  • EXIF is a metadata format supported by .jpg and other popular image file formats (e.g. TIFF), and allows for various descriptive information to be included about the image.
  • the EXIF data itself is limited to 64 kilobytes but is expandable using a so-called FlashPix extension.
  • a suitable field to exploit is the MakerNote field, which allows for proprietary binary data.
  • .gif files comprise a 'logical screen' which can be occupied by one or more images, thereby enabling the presentation of single or animated gif images.
  • Gifs allow for application extensions and comment extensions, but these are typically too small to be of much use for encoding image data.
  • a false animated gif could be constructed in which the second to Q* frame of the gif was treated as an equal size chunk comprising supplementary data.
  • the animation delay time for the first frame could be set to maximum (approximately 11 minutes) to create an effectively still gif image for most usage scenarios.
  • the alternative image data will at least double the size of the host image file (for example in the case of creating a stereo image pair), and may be much larger (in the case of VR image formats).
  • the supplementary data comprises a pointer to alternative image data.
  • a .png file may include a second image to form a stereo pair in the manner described previously herein, but also contain a 'liNk' chunk that contains a universal resource locator (URL) for the potentially much larger VR image data.
  • URL universal resource locator
  • the host image only contains links to alternative image data, in order to limit the impact on legacy browsers/apps.
  • the URL may be complete, as in "www.example.com/alternativesupport/uniqueid.3dp” or "www.example.com/alternativesupport/uniqueid.vrp”. This provides the most flexibility in terms of where the alternative image data is supported.
  • the URL may be partial, for example, just taking the for 'uniqueid' part, and the remainder of the URL can be included in the browser/app by default.
  • one or more mirror URLs may also be provided by default (i.e. plural sites that can be assumed to host the additional image information), and the alternative image data can be requested from each in turn (for example in an order of preference) until it is retrieved.
  • one or more different default URLs may be chosen based on the present location of the client device.
  • the current address of the host image can also be interrogated to determine if it holds the alternative image data, echoing the previously discussed approach of requesting parallel image files from a given site.
  • the 'uniqueid' can fit for example into a .png chunk, .jpg/exif metadata and .gif comment extension without subverting the normal function of these image formats.
  • the uniqueid is used to associate the host image with the or each alternative image data item.
  • the uniqueid may be constructed using any scheme that might result in a unique value sequence. This may therefore include information relating to the date/time of creation of an image, GPS coordinates (for example obtained from EXIF information), a random number 'nonce', a user account name, or any other suitable identifying value from the device used to first save the host image (such as an OS-accessible machine ID), or the like.
  • the alternative image data may then be uploaded to the server to an address corresponding to the uniqueid, for example via a web-portal that receives the data and the uniqueid, checks that the uniqueid is new, and places the data at the appropriate address corresponding to the uniqueid.
  • the address may not literally correspond to the uniqueid as in the above examples, but may take the uniqueid as an argument, used to access the data by a webserver, as in "www.example.com/alternativesupport.htm7uniqueid.3dp" or "www.example.com/alternativesupport.htm7uniqueid.vrp”.
  • the '.3dp' and '.vrp' extensions may not be used to distinguish the type of alternative image requested; for example, the type of alternative image may be disambiguated by the type of device, browser or app that is connecting to the server to make the request, or by a flag or other notifier sent as a separate part of a handshaking or communication process, and/or may be in another part of the URL path (for example, by use of separate addresses for different image types), and/or may be integrated into the uniqueid code in some other way (so that different alternative images associated with the first image have respective uniqueid codes). Alternatively or in addition to the above options for generating the uniqueid, optionally it may at least in part be derived from pixel values in the image itself.
  • a number of characters in the uniqueid might, for example, be derived from colour or greyscale values of one or more pixels in an image 110.
  • This approach has several benefits. Firstly, reduces the amount of data from the unique ID that needs to be stored as meta data in a chunk, EXIF file, text comment, or other user field of an image standard. Potentially, the entire uniqueid can be derived from such properties of the image, and is not limited to samples of individual pixels; for example, discrete cosine transform values from .jpgs could be used instead of or in addition to pixel values. However, pixel values are the most portable basis for the construction of a uniqueid as they do not depend on the underlying encoding scheme of the image format.
  • Another benefit is that whilst a browser that receives the original image is able to construct the uniqueid and consequently access the alternative image data from an appropriate server, and edited image cannot. If the image is altered, for example by re-scaling or re-sampling the image to a different size, cropping the image, de-noising the image, blurring or sharpening the image or changing the colour balance, then either the selected pixels will be the wrong ones (in the case of changing the re- sizing the image or cropping it) or will have the wrong values (in the case of de- noising the image or changing the colour balance). As a result, the correct uniqueid can no longer be constructed from the image and so any associated alternative image data cannot be identified.
  • a method of image provision comprises:
  • first step s310 providing first image data comprising a first image displayable by a conventional viewing means using a first method
  • step s320 embedding in the first image data secondary data enabling a compatible viewing means to access to a separate second image displayable by the compatible viewing means using a second method.
  • the first method may for example be a conventional display of a jpg, .gif, .tif, .png or other format of standard image, which is supported by most conventional or legacy viewing means (e.g. browser/app) that is not equipped with the means to access or display the second image
  • the second method may for example be a stereoscopic display of the first and second image, typically but not necessarily both in the same format (in particular, whether format can be lossless, for example as in the case of .tif and .png, then the use of different image formats for the left and right images of a stereoscopic pair is not significant; by contrast, where one of the images is subject to lossy compression, or both images are subject to different levels of compression, then compression artefacts causing differences between the images that are not attributable to stereoscopic parallax can become apparent and cause discomfort to the user).
  • a compatible viewing means e.g. browser/app
  • the first method may be the conventional display of a first standard format image
  • the second method may be the conventional display of a second standard format image, where that second standard is not supported by the legacy reader/viewer of the first client; a typical example would be that the second image is a VR panorama, optionally incorporating one or more regions of animation.
  • the first and second methods may relate to displaying images of the same format but in different ways e.g. (one .jpg in mono versus two jpgs in stereo), or displaying images of different formats in the same way or in different ways (e.g. a conventional flat .jpg versus a panoramic VR image).
  • the secondary data comprises a unique identifier of the second image data comprising the second image.
  • the unique identifier can be formulated using any of the techniques discussed herein.
  • the secondary data comprises the second image data comprising the second image.
  • the first image data could comprise both the second image and the unique ID for the second image, either to enable validation of the embedded image against a reference from a server, or to treat the embedded image as a cached version of the server image, that may be occasionally checked for updates, or where only part of the second image is held locally (for example a static panoramic VR image) and complementary parts are kept in the server (for example regions of animation for the panoramic VR image, as discussed previously herein).
  • the second image is arranged to form a stereoscopic pair in conjunction with the first image, as described previously herein.
  • the first image can be used as normal by legacy browsers/apps, but its functionalities augmented by a second image arranged to form a stereoscopic pair with the first image for those browsers/apps capable of stereoscopic display.
  • references to browsers/apps herein throughout also includes reference to underlying operating systems or graphics drivers that enable 3D or VR display and hence enhance the functionality of browsers/apps.
  • the second image is one selected from the list consisting of a cylindrical, a cubic, and a spherical panorama, as described previously.
  • Such panoramas are suitable for VR display.
  • the unique identifier is derived at least in part from data representing one or more elements of the first image. These elements are typically pixel data, but may for example be discrete cosine data or other data parametrically descriptive of at least part of the image content, as described previously herein.
  • the one or more elements of the first image may include an element corresponding to at least part of the visible watermark or accreditation of the first image.
  • the method may comprise the step of transmitting the separate second image and the unique identifier to a remote server.
  • the remote server may then hold the second image and unique identifier in association with each other, in order to provide the second image to a client in response to receiving a request comprising the associated unique identifier.
  • a method of image provision for a host server comprises:
  • a first step s410 storing a second image, displayable by a compatible viewing means using a second method, in association with a unique identifier
  • a second step s420 receiving from a remote compatible viewing means a unique identifier extracted from first image data comprising a first image displayable using a first method;
  • a third step s430 comparing the received unique identifier with the stored unique identifier; and if they match,
  • a given client device may either have all the data it needs within the first image data in the case where the second image data is embedded in the first image, or may need to access a remote server in the case where the unique identifier is embedded in the first image, or potentially a combination of both as discussed previously herein.
  • a method of image access comprises:
  • first step s510 obtaining first image data comprising a first image displayable by a conventional viewing means using a first method, the first image data having embedded therein secondary data enabling access to a separate second image displayable by a compatible viewing means using a second method;
  • a third step s530 accessing the separate second image using the secondary data; and in a fourth step s540, displaying the second image using the second method.
  • the first image data may for example be obtained from a website, an optical disc or other loadable medium, or be included in an app, and may be obtained as standalone image, as part of a web page, or as part of a wider set of assets for an app or game.
  • the step of accessing the separate second image comprises the sub- steps of transmitting the unique ID to a remote server; and receiving the separate second image from the remote server, as explained previously herein.
  • a conventional equivalent device may be implemented in the form of a computer program product comprising processor implementable instructions stored on a non-transitory machine-readable medium such as a floppy disk, optical disk, hard disk, PROM, RAM, flash memory or any combination of these or other storage media, or realised in hardware as an ASIC (application specific integrated circuit) or an FPGA (field programmable gate array) or other configurable circuit suitable to use in adapting the conventional equivalent device.
  • a computer program may be transmitted via data signals on a network such as an Ethernet, a wireless network, the Internet, or any combination of these or other networks.
  • the hardware apparatus is typically a server, computer or videogame console 10, comprising a general-purpose processor 20 that may perform a variety of functions in response to software based instructions as described above and may also comprise storage 30 such as RAM or a hard drive upon which to store software and image data.
  • the apparatus may also comprise a network port 40 for accessing image data from a remote server, and/or an optical disk reader 50 for accessing image data from an optical disc medium.
  • the apparatus may comprise one or more output ports 60 for display purposes. As described previously herein, such ports may be adapted to supply mono image data, stereo image data, and/or VR image data.
  • an image provision apparatus comprises data storage (30) (for example RAM, SSD, HDD, a cartridge or an optical disc) operable to store first image data comprising a first image displayable by a conventional viewing means using a first method; and an image processor (20) (e.g. general-purpose processor 20) adapted (by running suitable software) to embed in the first image data secondary data enabling a compatible viewing means to access to a separate second image displayable by the compatible viewing means using a second method.
  • data storage for example RAM, SSD, HDD, a cartridge or an optical disc
  • an image processor (20) e.g. general-purpose processor 20
  • adapted by running suitable software
  • the secondary data comprises one or more selected from the list consisting of a unique identifier of second image data comprising the second image; and second image data comprising the second image, reflecting the method described previously herein.
  • the apparatus can implement the above-described method and techniques as appropriate for second images of various types and the derivation of the unique identifier; and if it is not intended for the apparatus to host or exclusively host the second image, it can implement the above-described method for sending the necessary data to a remote host as described previously herein.
  • an image access apparatus comprises data storage (30) (for example RAM, SSD, HDD, a cartridge or an optical disc) operable to store first image data comprising a first image displayable by a conventional viewing means using a first method, the first image data having embedded therein secondary data enabling a compatible viewing means to access to a separate second image displayable by the compatible viewing means using a second method; an extraction processor adapted to extract the secondary data from the first image data (i.e. general-purpose processor 20 running under suitable software instruction); an access processor adapted to access the separate second image using the secondary data (i.e. general-purpose processor 20 running under suitable software instruction); and an image processor adapted to display the second image using the second method (i.e. general-purpose processor 20 running under suitable software instruction).
  • data storage for example RAM, SSD, HDD, a cartridge or an optical disc
  • the secondary data may comprise a uniqueid associated with the second image
  • the apparatus comprises a transmitter (e.g. processor 20 together with port 40) adapted to transmit the uniqueid to a remote server; and a receiver (e.g. processor 20 together with port 40) adapted to receive the separate second image from the remote server.
  • the above embodiments encompass a combination of methods and corresponding combination of apparatus sharing the same concepts; namely providing first image data displayable using a first method in which secondary data has been embedded this enables access to a separate second image displayable using a second method, where that secondary data may comprise the second image itself, and/or a uniqueid enabling access to the second image from a remote host; a corresponding method for that host wherein it stores the second image and the uniqueid in association with each other, and when it receives a uniqueid extracted from first image data as described above, and this matches a uniqueid held at the host, then the host returns the corresponding second image.
  • a method of image access comprises obtaining the first image data, extracting the secondary data from the first image data, accessing the separate second image using the secondary data, and displaying the second image using a second method.
  • the method may comprise transmitting that uniqueid to the remote host, and receiving the second image in return.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Library & Information Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé de fourniture d'image, comprenant la fourniture de premières données d'image comprenant une première image pouvant être affichée par un moyen de visualisation classique à l'aide d'un premier procédé, et l'incorporation dans les premières données secondaires de données d'image permettant à un moyen de visualisation compatible d'accéder à une seconde image séparée pouvant être affichée par le moyen de visualisation compatible à l'aide d'un second procédé ; en même temps, un procédé correspondant d'accès à une image consiste à obtenir des premières données d'image comprenant une première image pouvant être affichée par un moyen de visualisation classique à l'aide d'un premier procédé dans lequel les premières données d'image comprennent des données secondaires permettant à un moyen de visualisation compatible d'accéder à une seconde image séparée pouvant être affichée par le moyen de visualisation compatible à l'aide d'un second procédé, d'extraire les données secondaires des premières données d'image, d'accéder à la seconde image séparée à l'aide des données secondaires, et d'afficher la seconde image à l'aide du second procédé.
PCT/GB2017/053809 2016-12-21 2017-12-19 Procédés et appareil de fourniture d'image et d'accès à ladite image WO2018115847A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1621810.9A GB2557977A (en) 2016-12-21 2016-12-21 Image provisioning and access methods and apparatus
GB1621810.9 2016-12-21

Publications (1)

Publication Number Publication Date
WO2018115847A1 true WO2018115847A1 (fr) 2018-06-28

Family

ID=58284602

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2017/053809 WO2018115847A1 (fr) 2016-12-21 2017-12-19 Procédés et appareil de fourniture d'image et d'accès à ladite image

Country Status (2)

Country Link
GB (1) GB2557977A (fr)
WO (1) WO2018115847A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050234983A1 (en) * 2003-07-18 2005-10-20 Microsoft Corporation Associating image files with media content
US20080034280A1 (en) * 2002-11-28 2008-02-07 Carro Fernando I Method and systems for hyperlinking files

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7831992B2 (en) * 2002-09-18 2010-11-09 General Instrument Corporation Method and apparatus for forwarding television channel video image snapshots to an auxiliary display device
US20110010631A1 (en) * 2004-11-29 2011-01-13 Ariel Inventions, Llc System and method of storing and retrieving associated information with a digital image
US20100029326A1 (en) * 2008-07-30 2010-02-04 Jonathan Bergstrom Wireless data capture and sharing system, such as image capture and sharing of digital camera images via a wireless cellular network and related tagging of images
US10120947B2 (en) * 2014-10-09 2018-11-06 International Business Machines Corporation Propagation of photographic images with social networking

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080034280A1 (en) * 2002-11-28 2008-02-07 Carro Fernando I Method and systems for hyperlinking files
US20050234983A1 (en) * 2003-07-18 2005-10-20 Microsoft Corporation Associating image files with media content

Also Published As

Publication number Publication date
GB201621810D0 (en) 2017-02-01
GB2557977A (en) 2018-07-04

Similar Documents

Publication Publication Date Title
US9817954B2 (en) Multi-mode protected content wrapper
CN104092713B (zh) 一种网络资源的下载信息展示方法及装置
US8451266B2 (en) Interactive three-dimensional augmented realities from item markers for on-demand item visualization
US20020165912A1 (en) Secure certificate and system and method for issuing and using same
US20030041110A1 (en) System, Method and Structure for generating and using a compressed digital certificate
US20020199096A1 (en) System and method for secure unidirectional messaging
US20030009694A1 (en) Hardware architecture, operating system and network transport neutral system, method and computer program product for secure communications and messaging
US20020178360A1 (en) System and method for communicating a secure unidirectional response message
US20020194501A1 (en) System and method for conducting a secure interactive communication session
EP2352120A1 (fr) Accès à des données auxiliaires basé sur un réseau et des informations stéganographiques
US20020196935A1 (en) Common security protocol structure and mechanism and system and method for using
US20120287116A1 (en) Anchors For Displaying Image Sprites, Sub-Regions And 3D Images
US11985381B2 (en) Mapping architecture of immersive technologies media format (ITMF) specification with rendering engines
CN103561000B (zh) 一种进行多媒体数据认证的方法、装置和浏览器
WO2017091208A1 (fr) Procédés et appareils permettant d'intégrer et de décoder des données dans un modèle tridimensionnel
US8989432B2 (en) System and method of adding a watermark to a JPEG image file
CN111640191A (zh) 基于vr一体机的投录屏画面采集处理方法
WO2018115847A1 (fr) Procédés et appareil de fourniture d'image et d'accès à ladite image
JP6323461B2 (ja) サーバ装置、クライアント装置、情報処理方法および記録媒体
EP2423832B1 (fr) Système et procédé pour fournir une gestion de système de fichiers virtualisés pour carte mémoire dans un environnement numérique
WO2012005309A1 (fr) Système de diffusion de contenu, dispositif de diffusion de contenu et programme réalisant des opérations sur un contenu
JP7218105B2 (ja) ファイル生成装置、ファイル生成方法、処理装置、処理方法、及びプログラム
KR100960092B1 (ko) 이미지 데이터 등록 방법 및 시스템
KR20170117955A (ko) 증강현실을 이용한 이메일 서비스 제공 방법
CN116702218B (zh) 小程序中三维模型的渲染方法、装置、终端及存储介质

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: 17818244

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: 17818244

Country of ref document: EP

Kind code of ref document: A1