Image and texture rendering system for artificial intelligence

Abstract

A system for encoding and compressing images and textures to a bitstream as an executable program of computer instructions operable on pixel space, permitting the Encoder to arbitrarily determine the order, location and method used for reconstructing the components of an image at the decoder. The bitstream is typically further compressed by an Adaptive Entropy Compressor. Bitstream execution reconstructs the image directly to pixel space. Memory management and parallel processing controls may be embedded in the bitstream. The system is optimised for AI processing of images with a universally interpretable construction format that enables machines and humans to understand precisely how the image was created and can be reconstructed. Dual bitstreams may be combined at the decoder for securely embedding customised content (e.g., advertising) at the edge.

Description

[0001] TITLE:

[0002] Image and Texture Rendering System for Artificial Intelligence

[0003] INTRODUCTION

[0004] This specification discloses an Al-Compatible Image & Texture Rendering System, hereinafter referenced as THWITRS (Thort Werx Image & Texture Rendering System). Unlike conventional codecs that primarily rely on fixed encoding strategies and view images as static pixel arrays, THWITRS fundamentally transforms image data into executable programs comprising computer instructions (typically 32-bit fixed length) that operate directly on pixel space. These instructions are delivered as one or more bitstreams, termed Active Entangled Streams (AES), to an Engine for execution to reconstruct the image. Encoding may be lossy or lossless.

[0005] A key innovation of THWITRS is its distinct separation of compression and entropy coding into two channels, a departure from prior art codecs that often mix these processes. The AES typically entangles image data, control information, memory management, parallel processing controls, and the decoding method within the same bitstream, and may include entropy encoded and / or encrypted information. This "compute space" representation is uniquelyamenable to processing by Artificial Intelligence (Al) and other machine processes, allowing Al to interact with images with an underlying knowledge of their structure and construction, rather than merely as pixel arrangements.

[0006] THWITRS is designed to accommodate expected advances in Al, Convolutional Neural Networks (CNN), Machine Learning, computational power, and memory technology. It facilitates a shift from merely transferring a compressed image to synthesising the image at the destination in response to models, textures, or other information. This enables embodiments compatible with the evolution of movies, where actors or scenery are computer-generated on a host computer from a stream of models and textures. The system can reconstruct textures for 3D Engines to apply to polygons, or it can configure the Engine as a Host Pixel Generator, passing textures and other data to generate frames that can be collapsed with other layers reconstructed in the Worksheet. Furthermore, the encoder is typically unrestricted in its encoding strategies, with access to a comprehensive library of primitive functions. It may competitively test strategies against itself or other compression systems to determine the optimal approach for an image, frame, or part thereof. THWITRS also supports lossless transmission of information.

[0007] THWITRS introduces a ramp-on method to replace the traditional Group Of Pictures (GOP) method commonly used in video codecs, providing a more flexible approach to managing image updates.

[0008] While existing technologies may apply varying levels of compression or adapt parameters within a single encoding method, THWITRS represents a significant departure by incorporating multiple, fundamentally different encoding schemes within the same image. This flexibility enables the system to utilise entirely different encoding methods, tailored to the specific characteristics or requirements of individual image parts. This approach promises enhanced image quality, improved efficiency, and expanded functionality beyond the capabilities of single-method adaptive encoding systems, particularly through the integration of Al and CNN into the encoding decision process for automated optimisation and application-specific strategies.

[0009] THWITRS can dynamically blend scene information from one bitstream with a second, separate stream of advertising or other content, customising and integrating these two streams directly at the decoder. This provides unparalleled flexibility in content and ad delivery that is highly efficient, precisely targeted, and inherently resistant to traditional ad-blocking methods, as the ads may be dynamically wrapped onto objects within the scene itself. Various other applications of the system are also disclosed herein.

[0010] PRIORITY DOCUMENTS

[0011] In the provisional application AU 2024902167 Artificial Intelligence Biased Multifunction Codec that this specification derives priority from, the disclosed system was referenced as MIPS (Multifunctional Image Processing System); THWITRS (Thort Werx Image &Texture Rendering System) replaces all prior references to MIPS to avoid confusion with the well-known MIPS processor architecture. Also, in the priority document, the terms Virtual Machine and Virtual Processor were sometimes interchanged, to avoid confusion, in this specification the term Virtual Machine (VM) comprises a Virtual Processor (VP) and the memory the VP is operable on, said memory referenced as a Worksheet. SYNTAX AND INTERPRETATION

[0012] Singular / Plural: "a," "an," and "the" include both singular and plural referents unless context clearly indicates otherwise. "A processor" encompasses one or more processors.

[0013] "May," "Can," "Might": Indicate optional features or permissive language, not requirements.

[0014] "Will," "Shall": Indicate mandatory features or definitive outcomes.

[0015] "Or": Always inclusive, meaning "one or more of the listed items" unless explicitly stated as exclusive. "A or B or C" and "A, B, or C" both mean any of: A alone, B alone, C alone, A+B, A+C, B+C, or A+B+C. When exclusive selection is intended, explicit language will be used: "exactly one of," "only one of," or "exclusively A or B."

[0016] "And": In claim language, "and" indicates that all listed elements are required (conjunctive). However, in the specification's descriptive text, "and" may be used in a non-limiting manner to simply connect related concepts without requiring all elements to be present simultaneously. When mandatory inclusion of all elements is intended in the specification, explicit language such as "requires both A and B" or "includes all of A, B, and C" will be used.

[0017] Simple Comma Lists: "A, B, C" (without "and" or "or") means one or more of the listed items unless modified by transitional phrases or context clearly indicates all are required.

[0018] “Image”: Unless context indicates otherwise, a digital representation of visual information, which may include singular images, multiple images, portions of images, layers of images, or combinations thereof.

[0019] "Frame": Unless context indicates otherwise, encompasses complete frames, partial frames, or multiple frames.

[0020] "Patch": Unless context indicates otherwise, refers to a selected region or set of regions of pixels within an Image, Frame, or Worksheet, typically used for localised analysis or processing. A patch may be as small as a single pixel, or it may comprise a single contiguous area of multiple pixels, or it may be composed of multiple discrete and non-contiguous pixel regions. References to "a patch" include individual patches, collections of patches, or sub-regions of patches.

[0021] Lists preceded by the transitional phrase "comprising" or "including" require ALL listed elements (when connected by commas or "and") but permit additional unlisted elements. Lists with explicit "or" maintain their inclusive meaning regardless of transitional phrase. Lists preceded by "such as" are exemplary (one or more listed items). Lists with "consisting of" or "limited to" are exhaustive (no additional items). Lists with "selected from" indicate one or more from the specified group. Transitional phrases override default comma list interpretation. When ambiguity exists, explicit qualifying language such as "at least one of," "all of," or "each of" will be used. List Interpretation: Open-ended lists (with "comprising," "including," "such as"): exemplary, additional items permitted. Closed lists (with "consisting of," "limited to"): exhaustive, no additional items. Selection lists ("selected from," "chosen from"): one or more from specified group.

[0022] QualifyingTerms: "At least," "no more than," "exactly," "only," "exclusively," "all," "each," "any," "some" modify scope as their plain meaning indicates. Ranges: "Between X and Y" and "from X to Y" include endpoints unless stated otherwise. "About," "approximately," "substantially" indicate reasonable engineering tolerances. Technical Terms: Defined per ordinary meaning in relevant art at filing date unless explicitly defined herein.

[0023] TERMINOLOGY

[0024] Arbitrary: Any selection or determination of values, methods, locations, sequences, or parameters using any suitable selection method (for example, optimal, random, sequential, algorithmic, preferential, or any other basis for choice). Component: Hardware, firmware, software or combination thereof. Stencilling (Collapse / Compositing): Copying a first set of pixels onto a second set, averaging pixel attributes based on alpha values with priority typically for the top set.

[0025] Image Component: Any discrete part of an image, natural or synthetic. "Synthetic Image Components" are digitally created; "Real Image Components" are digital representations of images captured photographically. First / Second Definition: "First" refers to a particular item selected from a plurality; "Second" refers to a different item from the same plurality.

[0026] Image: Broadly includes static images, sequences, videos, stereoscopic imagery, 3DoF / 6DoF experiences, Plenoptic data, point clouds, and multisensory elements. May be 2D or 3D, including virtual and tangible outputs. Frames are numbered sequentially starting with 'frame 1 '. Resolution: Number of pixels in display area (X by Y). Coordinates (x,y) reference pixel position with origin (0,0) at top left.

[0027] "Output": As pertaining to a reconstructed image, means transfer to a display device, storage medium, printer, 3D printer, or processing pipeline for further operations including windowing, blending, or amalgamation with other imagery. Output format may require additional processing by display managers or other components prior to final use.

[0028] Colour Model: Pixel attributes (e.g., RGB, YCrCb). Colour Depth: Number of bits per pixel attribute (e.g., 24- bit RGB = 8 bits each for red, green, blue).

[0029] Pixel Space: Coordinate-based framework for 2D / 3D digital content processing. Composed of pixels (2D) or voxels (3D) with attributes including color, intensity, depth, or transparency. May includes sub-pixel precision for enhanced quality.

[0030] Patch: Arbitrarily selected pixels within Pixel Space, may be contiguous or non-contiguous, at any location. May be one pixel or any geometric shape.

[0031] Colour Space: Defines how digital colour appears on devices. Transparent / Transparency: Pixel may be fully or partially transparent as set by alpha attribute (0.0 = fully transparent, 1.0 = opaque). Reconstructing an Image: Reconstructing to a degree of fidelity. Lossless encoding provides perfect replica; lossy compression involves acceptable quality loss. Scene: Main image content in a frame. Computer: Any processing device including desktop, laptop, tablet, smartphone, microcontroller. May include interconnected systems and Al components. Contains processor, memory, and input / output components. Frame Attribute: for example, an instruction in an AES (or Meta Data passed to a video player) causing a) a haptic response (e.g., vibration of a viewer seat with display of a frame), b) fragrance release, c) lighting changes (e.g., stroboscope), and or d) activation of a fog machine.

[0032] "Source Computer": Computer or plurality of networked computers that generates, processes, or stores an AES, including encoding components configured to process input data for AES generation and typically decoder components for encoding validation. May be distributed across LAN, WAN, or cloud infrastructure.

[0033] Destination Computer: Computer that executes an AES, including any networked computers providing resources (e.g., legacy codecs, SVG libraries, text engines, 3D modelling libraries). Resources may be local or remote.

[0034] "Source / Destination Relationship": A computer may function as both source and destination when coresident encoder and decoder components are present. AES may be generated on one computer, stored on intermediate computers, and distributed for execution elsewhere.

[0035] Host Resource: Component coupled to the Destination computer external to THWITRS Encoder / Decoder. System Codec: Codec available to computer but not integral to THWITRS. Prior Art Codec: For example, JPEG, MPEG, H.264, H.265, AV1 , WebP, or PNG. Entropy Coding: For example, Huffman Coding, Arithmetic coding, ANS, or Golomb Coding.

[0036] DESCRIPTION:

[0037] THWITRS (pronounced "thwitters") is a system for image creation, editing, compression, or image-related intellectual property (IP) protection. It includes an Image Representation Language that provides a standardised format for transferring images to a user’s device, said format tuned for Al image construction or compression. The system includes an extensive set of drawing primitives and may use established and / or novel compression techniques. THWITRS may be integrated with a 2D / 3D engine to provide textures for games (especially streaming games) or movies, particularly where imagery is at least partially built by a 2D / 3D Engine at the destination computer.

[0038] The system includes a method and apparatus for encoding an image to facilitate its reconstruction at a decoder through arbitrary spatial addressing, which encompasses executable instructions that direct placement of pixel attributes in a memory at the decoder, specifically at encoder-determined pixel coordinates within that memory, herein referenced as a Worksheet1. The encoded image is represented as a sequence of computer instructions operable on pixel space, said sequence referenced as an Active Entangled Stream (AES). An AES typically comprises entangled image data, control information, and decoding method(s), and may further include memory management and / or parallel processing controls. The AES also manages the complexity of supporting multiple encoding methods within a single framework, handling transitions between differently encoded regions, and can direct the placement of pixel attributes by arbitrarily locating a pointer to any location within the Worksheet to perform one or more processes at or relative to said location. The invention further comprises a corresponding method and apparatus for decoding the image. The decoder apparatus comprises a) processor (typically a Virtual Processor (VP)), configured to execute these computer instructions operable on pixel space, b) Worksheet and usually c) a Render Image. Execution of the AES by the VP reconstructs the image in the Worksheet. THWITRS offers a platform that enables images to be processed and formatted consistently, particularly in Al-driven applications. It provides a framework that allows Al systems to input their determinations of image structure and compression into a unified format. Within THWITRS, diverse encoding methods can be mixed within a single frame, according to the Encoder's determinations for that specific frame. This capability enables THWITRS to integrate and adapt combinations of established or novel techniques, addressing diverse imaging requirements. Additionally, encoding may also include novel micro-strategies for incremental bit reduction that, while currently demanding on encoders, may become more feasible with ongoing advancements in processing power. An Encoder may selectively apply prior art compression techniques and the disclosed methods on a frame-by-frame or patch-by-patch basis.

[0039] Representing an image as computer instructions can inherently lead to very efficient compression for certain image elements (e.g., a large gradient-filled rectangle for a sky), while offering high flexibility in image regeneration at the decoder. However, encoding the movement of blocks for motion prediction directly using computer instructions is often uncompetitive compared to the highly efficient motion vectors of the prior art. To address this and distinguish its approach from prior art where entropy coding is often an integral, monolithic part of the primary compression algorithm, THWITRS employs a distinct two-stage compression pipeline:

[0040] Instruction-Based Compression (First Stage): The initial image data is transformed into a stream of executable instructions (THWITRS Computer Instruction Set - TCIS). This conversion itself inherently provides a first level of compression, where high-level primitives can effectively represent large numbers of pixels. Importantly and distinct to other codecs, after allowing for adjacency of related instructions (e.g., pos (x,y) followed by draw_circle_565_line (r,g,b, radius)), the instructions are position independent and the first stage of the encoded image may be rearranged by the encoder to optimise subsequent entropy encoding.

[0041] Adaptive Entropy Compression (Second Stage): Following the generation of the instruction stream, the instructions are further processed by an Adaptive Entropy Compressor (AEC) component. The AEC typically disassembles or analyses the instruction stream, extracting its constituent information (e.g., drawing primitives, parameters, coordinate data) and re-packaging this information into alternative, specialised data formats. These alternative formats are specifically designed for efficient compression through standard, context-adaptive entropy processes. Although the AES is described as entangled instructions and data, the opcodes and data fields may be separated for at least part of the process. The data field may be further separated (e.g., colour data to one stream (that may be further split into separate colour streams, e.g., red, green, blue, alpha), location information to another) amongst other methods of disassemblingthe AES to optimise entropy encoding. This is described further with reference to the Entropy Pipe and the Adaptive Entropy Compressor (AEC).

[0042] The second stage may be bypassed for applications that do not require enhanced compression, e.g., a microcontroller in an industrial application generating a graphics display on a coupled LCD.

[0043] At the decoder, an Adaptive Entropy Decompressor (AED) reverses this second stage, restoring the received compressed data to the original executable instructions. These instructions are then executed by the THWITRS Engine (usually by a Virtual Processor) to regenerate the image, thereby providing a highly flexible and efficient method for overall image compression. The Engine typically has one or more Special Purpose Engines (SPE) to provide functionality additional to the Virtual Processor. Data may also be pushed to a resource on the Host referenced as a Host Pixel Generator (HPG).

[0044] Compression Flexibility and Algorithm Selection:

[0045] While compression of an image is typically an inherent part of the encoding process, it is not necessarily an essential requirement, and aspects of the invention may have application with or without compression. Moreover, the preferred fixed length instruction set operating in a Virtual Machine is, subject to basic criteria, position independent, permitting the Encoder to rearrange the order of instructions to facilitate subsequent entropy encoding. The Encoder may also tag the program with hints (that are removed prior to execution of the program) for the Entropy compressor. THWITRS may be adapted to incorporate a diversity of Algorithms. For example, Entropy encoding may use Huffman Coding, Arithmetic Coding, Run Length Encoding, Asymmetric Numeral Systems (tANS, rANS), Lempel-Ziv-Welch, Golomb-Rice, Exponential Golomb Coding, Shannon-Fano coding, Burrows-Wheeler Transform, Context Adaptive Binary Arithmetic Coding (CABAC), Context Adaptive Variable Length Coding (CAVLC), or another method. An Entropy encoding method may be associated with one or more tables, e.g., Colour table, Probability table, Symbol table. A table may be a predetermined default at the encoder, sent to the decoder in a bitstream, or dynamically generated by the decoder in response to incoming data.

[0046] Central to the system are an Encoder component, the THWITRS Computer Instruction Set (TCIS), NonTransient Computer-Readable Media for storing the instructions, and a Decoder including an Engine, said Engine including a Worksheet and a Processor component.

[0047] Encoder

[0048] The Encoder serves as the core component for transforming images into executable programs for reconstruction. The system provides significant flexibility in how the encoder may direct regeneration to any part of the memory (Worksheet) at the decoder for reconstruction. It can revisit areas and choose whatever encoding tools it requires. It is capable of selecting an arbitrary patch anywhere in the video, placing it anywhere in the Worksheet it deems suitable, and maintaining it there as long as determined. The decoder usually contain pre-stored information to assist in reconstructing a new frame, however, THWITRS is essentially an Additive Synthesis system with the encoder typically assuming a blank canvas for the frame at the decoder, using primitive rendering operations to direct the building of the final image. Later operations can overlay previous ones, providing a powerful and flexible method of image construction.

[0049] The unique nature of THWITRS, wherein the Encoder precisely controls and foresees the sequence of all processes at the decoder as dictated by the Active Entangled Stream (AES), provides significant optimisation opportunities. This unparalleled control allows the Encoder to leverage knowledge about the state and future modification of individual pixels or pixel regions. For instance, if the Encoder knows that a pixel's attributes will be fixed or significantly altered by a subsequent process (e.g., a transform followed by a specific line drawing that overwrites parts of it), it can strategically omit redundant information from earlier processes related to that pixel. To further optimise this process, a pixel map is maintained at the decoder. This map dynamically tracks pixels (for little or no bit cost) that have been fixed or partially fixed by an earlier process, wherein said information may be useful in improving compression. For example, there is no need to send a residual for a pixel that is known to have been definitively fixed earlier and protected by the Pixel Map from alteration by a block transform. This process is described further under “Pixel Map” hereunder.

[0050] The Encoder may vary widely in complexity depending on the application, from basic implementations in security cameras to networks of powerful computers for applications such as optimising compression of a movie for mass distribution. It converts an image to a sequence of instructions selected from the TCIS; may entropy compress said instructions and / or encrypt said instructions. The Encoder may also embed parallel processing control and / or memory management directives for the decoding process in the instruction stream. The AES is executed by a Processor at the Decoder to reconstruct the image in the Worksheet.

[0051] Specifically, the Encoder includes an AES Synthesiser Component responsible for encoding an image as a sequence of computer instructions.

[0052] A typical THWITRS encoder is configured to synthesise an Active Entangled Stream (,d32 AES) using an AES Synthesiser Component, which includes: a) Analyser Component (Analyser): Analyses an image to determine one or more strategies for encoding a patch of a frame. The analysis may include examining the input image to segment it into distinct layers, detect objects, and estimate depth (further detailed in another section of this specification). b) Compiler Component (Compiler): Compiles each determined strategy into distinct executable bitstreams. The compiler may use distinct strategies for each of a plurality of image patches and competitively test an optimum strategy for one or more of said patches. c) Engine Component (Engine): Executes the compiled patches to reconstruct the encoded patch. d) Encoding Decision Component (EDC): Compares the reconstructed patches to select the optimum strategy for a given patch to include in the output AES. The EDC typically processes information from the Design Criteria Component (DCC) or another component, such as an Adaptive Entropy Compressor (AEC), in determining the optimum strategy. For instance, a compiled strategy that seems optimal when executed by the Engine may be superseded by an alternative when considering the final bit size after entropy encoding.

[0053] The AES Synthesiser also provides essential functions such as: Encryption of the ,d32 AES to a d32s file, determining the number of threads for parallel frame processing and inserting required instructions, determining breakpoints for inserting in the frame to permit reconstruction to lesser resolution or color (e.g., due to reduced bandwidth), dividing the frame into a plurality of sections to structure the ordered delivery of the frame to a decoder.

[0054] A Design Criteria Component (DCC) operatively coupled to the encoder, the provides parameters affecting the image encoding. It may receive feedback from the encoder, suggest encoding strategies, or other information. The DCC can provide a human interface (e.g., a GUI) or be machine-controlled (e.g., an Al system directing compression).

[0055] The sequence produced by the AES Synthesiser is referenced as Active Entangled Stream (AES) that in its native state as a sequence of instructions is referenced as a ,d32 bitstream. This ,d32 bitstream represents a compressed image that is uniquely editable in its compressed format without first requiring decoding. Although a ,d32 bitstream may be provided directly to a decoder (for example, for programming into a microcontroller that executes the AES as part of a dedicated application), an AES typically undergoes further Secondary Compression to produce a ,d32c file. Secondary compression is usually lossless entropy encoding. While existing methods (e.g., 7z) may be used for secondary compression, the preference is an Adaptive Entropy Compressor (AEC) component. The AEC may be configured to act interactively with the AES Synthesiser and may also be configured with a specific entropy method. Notably, the AEC may disassemble or rearrange the instructions into alternative formats for more efficient entropy encoding. It should be understood that while image data conversion into instructions and subsequent entropy encoding are functionally distinct processes, their application may be intermixed or iteratively applied throughout the encoding of the bitstream, rather than being strictly sequential over the entire stream. This allows for dynamic optimisation based on the characteristics of different parts of the image.

[0056] This separation of compression logic from entropy coding allows Al and other systems to work extensively on devising rich instruction sets, offloading the responsibility for entropy compression to a dedicated, separate process. The ,d32c or ,d32cs bitstreams may then be further packaged with information to facilitate input to a video player or other component for managing a received AES.

[0057] The THWITRS Encoder is equipped with access to a comprehensive and extensive repository of encoding methodologies, typically comprising the drawing primitives, other instructions, other image processing functions disclosed in this specification. These are stored on Non-Transient Computer Readable Media (NTCRM), which may be located locally or remotely accessible to the Encoder. This provides the Encoder with a broad range of alternative methods to employ when encoding an image. This rich toolkit enables the Encoder to dynamically select and apply various strategies on a per-image, per-frame, or even per-pixel basis. This extensive library encompasses diverse types of instructions and methodologies. For instance, it includes instructions for precise pixel manipulation (such as those utilising the pixel map for intelligent tracking and avoidance of redundant data), as well as commands for controlling parallel processing within the decoder's Engine. Furthermore, it incorporates other specialised methodologies, such as adaptive switching between different compression schemes, sophisticated memory management protocols embedded directly within the bitstream, and methods to insert breakpoints.

[0058] The Encoder also leverages image fingerprints as a data resource. These fingerprints, which are property vectors characterising blocks of pixels, are extracted and stored (again, potentially locally or remotely). These stored fingerprints provide valuable metadata about image regions, assisting the Encoder's decision-making process in applying efficient, flexible, and adaptive image reconstruction programs.

[0059] Additionally, the Encoder may have access to pre-encoded, position-independent sequences of ,d32 instructions, referred to as Strands or Snippets, which can be dynamically integrated into the bitstream. The availability and strategic selection from this diverse set of stored methods and data resources enable the Encoder to devise such programs, forming the basis of our claimed encoding methodology.

[0060] A frame output from a display may also be a compilation of a plurality of Active Entangled Streams, with a first AES encoded by a first Encoder and the second AES by a second Encoder. This is described further under the section on compositing advertising or other content with a first AES (e.g., the main scene).

[0061] 3D, Multi-Dimensional, and Immersive Content Encoding In addition to accommodating a diverse range of traditional and novel input formats, the THWITRS system is specifically designed to embrace the complexities of encoding for virtual, multidimensional, and immersive displays, such as 3D stereoscopic movies, surround displays, virtual reality (VR), augmented reality (AR), and even more expansive 6D content. The fundamental principle enabling THWITRS's adaptability to these diverse display environments is its inherent ability to target pixel regions and parallelise encoding and decoding, much like its application for large-scale "Big Screen" displays. For 3D stereoscopic content, the system efficiently handles two distinct image streams (e.g., left and right eye views). These streams can be robustly processed by two separate THWITRS Engines at the decoder, which may share relevant timing parameters to ensure synchronised rendering. This includes the ability to encode depth information, textures, and other spatial data essential for rendering lifelike three-dimensional visuals.

[0062] Extending this principle, THWITRS is well-suited for surround displays and panoramic / 360-degree virtual environments. In such configurations, the overall immersive view can be logically divided into a plurality of individual display "tiles" or viewports. Each tile, which may be a physical screen or a distinct rendering region within a larger virtual space, can be conceptually coupled to its own dedicated THWITRS Decoder and Engine. The Encoder cluster can operate similarly to how it handles a "Big Screen" setup. It can initially generate instruction lists for the entire vast, multi-dimensional scene. These comprehensive instruction sets are then distributed to individual decoder nodes (or virtual viewports), which effectively act as dedicated "tile" decoders. Each such decoder then edits and culls the global instruction stream, retaining only the relevant instructions for its specific pixel region or view. For example, a global instruction to fill an entire 360-degree scene might be edited by a tile decoder to only apply to its specific angular segment. Instructions for drawing objects or lines are similarly adjusted for relocation or culled if they fall outside the tile's view. This distributed and parallelised approach offers significant benefits:

[0063] Scalability: It scales indefinitely, allowing for the creation and processing of extremely large and complex immersive environments.

[0064] Parallel Processing: Encoding and rendering are inherently parallelised across multiple decoders / engines. Low Complexity at the Edge: Each decoding "tile" or viewport can remain relatively low complexity (e.g., implemented in a cheap microprocessor like a Raspberry Pi for physical screens), reducing requirements for super-fast data links or high-end image processing chips at each individual display point.

[0065] The system extends further into the realm of 6D space, which encompasses not only 3D spatial coordinates but also incorporates orientation, time, and other dimensions, facilitating dynamic and interactive virtual environments. For all such multidimensional and immersive applications, THWITRS can employ sophisticated algorithms and machine learning techniques, possibly utilising advanced computational models like Generative Adversarial Networks (GANs) or enhanced Convolutional Neural Networks (CNNs), to analyse and encode this complex data. THWITRS may leverage a dual strategy encoding approach that combines predetermined design criteria, set by users or designers, with sophisticated automated analysis algorithms, particularly through Artificial Intelligence (Al) and CNNs. This allows for intelligent decisions on encoding methods in different parts of an image or scene, dynamically adapting to content characteristics. This strategy harnesses the power of machine learning to analyse the content and determine the most appropriate encoding technique for each segment, thereby optimising for both quality and efficiency across various display modalities.

[0066] Encoder's Analyser and Image Content Processing

[0067] The Encoder includes an Analyser component designed to examine an image to determine effective encoding strategies. This process typically begins by partitioning a frame into a plurality of patches or segments. For each segment, the Analyser determines an effective encoding strategy. This usually entails competitive compiling, wherein several strategies for a patch are compiled to determine the amount of compression. The system typically interacts with the Adaptive Entropy Compressor (AEG) to assess if a chosen strategy still yields a benefit after entropy encoding. Said compilation is then executed by an Engine to determine the fidelity of the reconstructed patch with the original, and an effective strategy is chosen that provides a suitable trade-off between compression and fidelity. Notably, the encoder can rearrange the sequencing of instructions to further improve entropy encoding, a capability not found in other codecs. Determining the amount of compression is a straightforward calculation for the Encoder.

[0068] The Analyser typically commences the process by creating an Analog model in 24RGB or 32RGB of each frame in the image. This Analog model represents a lossless reference of the frame based on information available to the Analyser. The objective is to reconstruct this Analog frame model at the decoder in a timely manner and to a degree of fidelity determined by predetermined criteria, bandwidth constraints, and destination computer capability. While the Analyser's primary function is to analyse an image and provide the Competitive Compiler with information to assist it in determining the optimal strategy for encoding a patch, frame, or other set of pixels into a sequence of THWITRS instructions, the process is typically a cooperative iterative process between the Analyser and Compiler that may utilise the resources of each other and feedback information to one another or with another component. For example, the Analyser may use the Analog model to determine the effectiveness of a presumptive strategy for compiling a patch or a frame of an image. Depending on the image input, an Analog copy may not always be required; for example, the input may be one or more lines of THWITRS source code instructions prepared by a text editor that only requires compilation and no analysis.

[0069] The encoder typically compresses an image using the highest resolution, number of colour channels, and colour depth provided in the initial image and may provide alternative encodings to suit target systems with less capability. For an image with a greater colour depth (e.g., 48 bit), the encoder may be configured to initiate a plurality of distinct final encodings, e.g., one that converts the image to 24 bits and a second that uses 48 bit colour or arrange the bitstream to accommodate multiple resolutions and colour depths. The Analyser may also determine that a patch is better encoded in YUV or another colour space rather than RGB. For example, feedback from an Adaptive Entropy Compressor (AEG) may indicate that compressing a particular patch in YUV provides a more optimal outcome at the entropy pipe.

[0070] The Analyser's examination process leverages various techniques for Image Segmentation and Object Detection, which involve partitioning an image into meaningful regions or segments (often corresponding to different objects or parts of objects) and then identifying and localising these objects. Each segment may be classified according to characteristics that influence the choice of encoding method. Examples include: Vectorizable elements like text or logos, Detailed photographic regions or areas requiring high fidelity, Regions amenable to representation using disclosed THWITRS drawing or painting instructions, Areas that may be replaced with a synthesised object (e.g., a similar sky with clouds from a library accessible to the encoder, a decision which may be automated or involve human interaction).

[0071] The Analyser may employ any combination of established computer vision (GV) or deep learning techniques, and may perform these tasks in conjunction with Artificial Intelligence (Al) systems, Convolutional Neural Networks (CNNs), or other machine learning processes. These Al-assisted processes maybe integral to the encoder hardware / software, implemented as part of the encoding system, or accessed remotely through cloud-based services or external processing units. The integration of Al capabilities allows for enhanced accuracy in object detection and segmentation whilst providing adaptive learning from processed image data to improve analysis performance over time.

[0072] For an existing image requiring encoding, the image is typically processed by the Analyser component of the Encoder to determine what, if any, components or objects may be separated for different encoding methods (e.g., separating a moving ball from the background, or identifying distinct human figures). This task may be facilitated by metadata pertaining to the image or by the provision of the image in plural layers, for example.

[0073] The Analyser is further capable of sophisticated image analysis, for example:

[0074] For a current frame of a source image that is multi-frame (e.g., a video or slideshow), in addition to the current frame, the Analyser may analyse any one or more prior or subsequent frames (or every prior or subsequent frame) relative to the current frame. This analysis seeks a patch with pixel attributes identical to the current frame or within acceptable criteria (which may or may not require repair, such as encoding residual values in the AES). Said seeking may include determining a patch of pixels that may have been altered in the current frame by motion within the scene or by the camera (said motion may be sub-pixel motion) or by lighting changes or another factor. Such altered pixels may be cost-effectively (bitwise) altered to acceptable criteria by reversing said alteration in part at least. This may include moving said patch on sub-pixel boundaries, or more economically and with improved accuracy (e.g., 256-bit sub-pixel accuracy), by the use of novel Asymmetric Quads. The Analyser's flexibility extends to utilising any suitable geometric shape for prediction purposes; for instance, a shape_move instruction can efficiently outline any patch of pixels using a combination of lines and Bezier curves, and apply transformations such as shifting, rotating, tilting, or scaling. For the current frame, the analysis of prior frames may flag the Compiler to keep said patch in the Worksheet for use by the current frame. For future frames, the Compiler may be flagged to keep the patch of the current frame. It is to be noted that, in contrast to the prior art, THWITRS has no requirement to store an entire frame at the decoder; the Encoder can decide to keep any patch of pixels in the Worksheet for as long as required (within device limitations). As part of its sophisticated analysis, the Encoder may examine a pixel or patch of pixels and determine their anticipated behaviour across one or more subsequent frames. Based on this predictive analysis, the The Encoder may elect to initially encode these pixels or patches with a particular fidelity if deemed acceptable and unlikely to negatively impact the user experience. Conversely, if the analysis indicates that these pixels or patches will become more visually important over time, or if a gradual adjustment improves the efficiency or quality of a future encoding or reconstruction process, the Encoder may strategically plan to incrementally refine or 'fix' their representation across subsequent frames.

[0075] Locating a patch that has been magnified, rotated, or tilted (e.g., by zooming or camera movement) and determining that it is economical to send the transformed version to an earlier frame and progressively adjust it (e.g., shrinking and expanding) as subsequent frames play.

[0076] Identifying regions suitable for replacing with a 3D model, or particle physics SPE’s are disclosed fir each). Analysing backgrounds or similar regions for replacement with a set of polygons. This may involve extracting the background and applying textures that can be adjusted frame to frame, or it may involve purely synthetic polygon mesh construction. This can include:

[0077] Polygon Mesh Construction and Motion Adjustment: In this approach, a patch of pixels from the source image, such as a background region or a complex foreground object, may be analysed and converted into a corresponding set of polygons. This process is akin to known methods used in 3D rendering engines for mesh generation. Once the polygonal representation is derived, the Encoder then encodes instructions that describe this mesh. For handlingthe potentially large number of vertices, texture coordinates, normal vectors, and other associated properties for a polygon mesh, the Encoder directs these instructions and parameters to a Special Purpose Engine (SPE) via Integrated Push Extended (IPE) instructions. These IPEs pre-load the necessary data onto the SPE's dedicated stack, allowing for efficient, potentially asynchronous processing of complex graphics operations. A key advantage within THWITRS is the ability to efficiently encode intra-frame motion by only transmitting updates to the vertices of these polygons from a first frame to subsequent frames. The Encoder, with its foresight of decoder operations, can precisely track the movement, deformation, or transformation of these polygonal elements and send minimal updates, rather than re-transmitting entire pixel blocks. This method is particularly effective for large, textured areas or objects with predictable motion.

[0078] Synthetic Polygon Mesh Construction and Motion Adjustment: Similar to the above, this method applies when the polygon mesh is entirely computer synthesised rather than being derived from an existing image patch. This is particularly useful in scenarios such as movie production for creating virtual sets, dynamic backgrounds, or complex special effects. The Analyser, in conjunction with design criteria or Al systems, can define a purely geometric background or object (e.g., a landscape, a building, or a character model) as a polygon mesh. The instructions to generate and render this synthetic mesh are then transmitted. As with derived meshes, the Encoder can precisely control and update the positions and properties (e.g., colour, texture mapping, lighting parameters) of the mesh vertices and faces over time and across frames. The parameters for defining and manipulating these synthetic polygons are likewise transmitted efficiently by directing them to a Special Purpose Engine (SPE) via IPE instructions. This allows for highly efficient encoding of synthetic scenes where only the transformational parameters or texture adjustments need to be transmitted, with the underlying geometry being reconstructed and manipulated by the decoder's Engine or a specialised SPE. This approach provides immense flexibility for dynamic scenes, allowing textures to be adjusted frame-to-frame, light sources to move, or camera perspectives to change with minimal bitstream overhead.

[0079] Attempting to break the source image into a plurality of Internal Layers for transfer to the Compiler, which may then determine an effective compiling strategy for each layer. The Analyser may fingerprint one or more patches of one or more layers and provide the Compiler with one or more potential compiling strategies for each said patch. Examining the image to determine the presence of a geometric shape, an object (which may include determining if an object may be 2D or 3D modelled or accessing a resource to perform said modelling), an image fingerprint, a computer model of an object, a colour pattern, an internal or external camera parameter, or another relevant feature.

[0080] Performing homographic processing of an image, separating a layer from a plurality of layers (e.g., background, midground, foreground, or individual objects), or performing another image processing operation.

[0081] Analysing inter-frame luminosity variation: The Analyser may examine successive frames, or parts thereof, for changes in general luminosity. This is distinct from the luminance (L) value of individual pixels. Based on this analysis, a compact backlight layer may be created and encoded. This backlight layer can then be applied to adjust pixels of a previous frame or a portion thereof during reconstruction, potentially reducing errors or improving visual coherence before inter-frame motion changes are applied.

[0082] Specific Analysis Methodologies available to the Analyser include:

[0083] Image Segmentation and Object Detection Methods:

[0084] Traditional Computer Vision Techniques: These include edge detection algorithms (e.g., Canny edge detection, Sobel filtering) to identify boundaries; thresholding techniques to separate foreground / background; region growing methods to expand regions based on similarity; clustering algorithms (e.g., k-means) to group pixels; contour detection for object outlines; template matching for specific patterns; shape-based segmentation (e.g., Hough transform); colour-based segmentation using hue, saturation, and value properties; and texture-based segmentation analysing patterns via Gabor filters or local binary patterns.

[0085] Deep Learning-Based Methods: The Analyser can utilise CNN-based architectures such as U-Net and Mask R-CNN for semantic segmentation (classifying each pixel into object categories), and Object Detection Frameworks like YOLO (You Only Look Once) and SSD (Single Shot MultiBox Detector) for efficient object detection with bounding box localisation.

[0086] Depth Estimation Methods:

[0087] Monocular Depth Estimation: Deep learning models estimate depth from single 2D images using visual cues like occlusion, perspective, and relative size.

[0088] Stereo Vision: Analyses disparity between corresponding points in images from multiple cameras to estimate depth using triangulation.

[0089] Structured Light: Projects known patterns onto scenes and analyses deformation in captured images to calculate depth.

[0090] Volumetric Analysis: Processes volumetric data such as point clouds or depth maps from LiDAR or Time- of-Flight (ToF) sensors that directly provide depth information.

[0091] Geometric Transformation Methods:

[0092] Homography: Estimation of homography matrices enables identification of planar surfaces, image rectification for improved object detection, stereo vision calculations, and motion compensation for interframe prediction.

[0093] Camera Parameter Utilisation: Analysis of internal parameters (focal length, principal point, distortion coefficients) and external parameters (rotation, translation, camera movement) enhances object detection accuracy and enables identification of static versus moving elements.

[0094] Fingerprint Method for Image Characterisation:

[0095] The Analyser may utilise the Fingerprint method. This involves taking a block of pixels and extracting a normalised set of parameters, or a "property vector," to characterise that block. These extracted properties form a vector in feature space, which can suggest encoding methods for that block. The fingerprint data is normalised (e.g., for pixel count and variance) to enable comparisons across varying block sizes. The parameters that characterise said block include:

[0096] Colour Variance: The normalised vector sum of the variation of all pixels from the average colour of the block. This value provides an indication of the amount of "detail" present within the block. A solid color block will typically yield a colour variance of zero, while a block of pure noise will yield a high variance, and a block with alternating black and white pixels will yield a maximum variance.

[0097] Luminance, Chrominance Variance: A metric that specifically reveals the amount of detail in the luminance (brightness) and chrominance (colour) components of the block. For example, monochromatic images will exhibit a chrominance variance of zero.

[0098] Most Common Pixel Colours (N values): A list of up to 'N ' most frequently occurring colours within the block, each accompanied by its count. Using the block size, each of these counts can be expressed as a percentage of the total pixels in the block. This feature is particularly useful for identifying image regions that are composed of sets of geometric shapes, such as those found in cartoon animations.

[0099] The Analyser may recursively subdivide blocks down to a minimum size (e.g., 4x4 pixels) to search for regular patterns. For example, if the 4 child vectors of a block are a bit different from the self-vector, but 3 are matching and the 4th is different, this would be consistent with the self-vector sitting on the boundary of a homogenous region. Furthermore, the hierarchical nature of blocks, where each block has a parent and child blocks, allows for a comprehensive set of fingerprints, such as fp(self), fp(parent), fp(siblingl ), fp(sibling2), fp(sibling3), fp(childl), f p(child2), fp(child3), f p(child4), to inform analysis, which can assist in identifying boundaries of homogenous regions. The fingerprint data is readily obtained by the encoder as a simple function, facilitating its use in search to identify shaped regions, and is amenable to Al techniques. The software analysing the source image for fingerprints may consolidate adjacent blocks with matching features into a larger block, or a set of adjacent or touching blocks. The software will recursively subdivide blocks down to a minimum of 4x4 pixels to search for regular patterns. As an example, a large circle in the image will resolve to a large central square block, with smaller tessellated blocks filling out to the circumference. The analysing software may use ML or adaptive techniques to suggest that a set of blocks is a geometric feature. This analysis may be passed to the Compiler as metadata (e.g., that there is a circle of radius and position and colour), enabling the Compiler to code for this and evaluate the error reduction effected by this code.

[0100] These feature vector sets for pixel blocks can form an input to an ML algorithm that can identify regions and types in a source image. Within a set of related images (e.g., a movie), an large ML algorithm could finetune its analysis about the image content. Rather than coding these multiple times, the Compiler could be instructed to build a set of cut-and-paste fragments at the decoder for reuse. The ML could associate various fingerprint ranges with content that allows greater compression or more detail. An example would be human faces. If the fingerprint software draws a box around a human face and produces a fingerprint, this is likely to be constant even at different scales. This method can assist in deconstructing a source image into higher-level structures. The THWITRS method for a face may be optimised over time, and it may be that a generic "face" for an actor is kept on the Worksheet and reconstructed by paste and fix-up as opposed to redrawing it.

[0101] When an image source is a computer-generated volumetric screen, the Analyser can leverage the predictable patterns and precise calibration of virtual productions. This allows for dynamic adjustment of screen content based on camera position, ensuring seamless alignment with the real camera's perspective, precise synchronisation, and dynamic lighting / reflection adjustments.

[0102] The Analyser component may utilise any appropriate combination of the aforementioned established techniques and the proprietary Fingerprint method to achieve the required image segmentation and object identification. The selection of specific methods depends on factors including image characteristics, computational resources, accuracy requirements, and the presence of additional data such as camera parameters or depth information. The resulting segmented layers enable the encoder to apply tailored encoding strategies to different image regions, allowing for more efficient compression of background elements whilst preserving detail in foreground objects of interest.

[0103] The Encoder may be encoding an existing image or be a participant in the creation of a new image, for example, in an interactive computer paint process or movie editing / creation suite, typically in conjunction with Al or another system. It may access its own resources or shared resources to facilitate this process, and can also create Strands and Snippets for subsequent use or for sharing with other systems or users, contributing to a library of such assets or a fingerprint database.

[0104] Competitive Compiler and Encoder's Internal Engine

[0105] The Encoder system usually includes an internal Engine, similar in function to the decoder's Engine but typically not as extensive in its full rendering capabilities. This Encoder-side Engine usually possesses its own Worksheet, which functions as an analog of the decoder's Worksheet, allowing the Encoder to test out its generated instruction sequences and confirm their progressive build-up and fidelity as the compilation process proceeds. This provides real-time feedback during optimisation.

[0106] The Competitive Compiler plays a central role in translating the Analyser's findings into an efficient instruction sequence. A way to think about how the compile process works is to view each instruction as an operation that reduces the total error distance between the source image and the destination (reconstructed) image. The efficiency of an instruction is defined as the ratio of how many pixels it sets correctly (or contributes to setting correctly) to its instruction size (in bytes). For instance: A Block Draw instruction that sets a region of 16 x 16 pixels potentially has an efficiency of 256 pixels per instruction. A single Pixel Draw instruction only sets 1 pixel, resulting in an efficiency of 1 pixel per instruction. This efficiency concept also applies to groups of instructions. To set an 8x12 rectangle at an arbitrary position might require three instructions (e.g., RECT_SIZE(8,12), POS(x,y), RECT_888(r,g,b)). If these three instructions together set 96 pixels (8 * 12), and assuming a combined size of 3 instructions, the average efficiency would be 96 / 3, or 32 pixels per instruction. The basic compiler strategy is to simply encode an image as a sequence of draw pixel instructions. This approach would use one instruction per pixel, leading to an encoded instruction sequence approximately 4 bytes per pixel, which is close to the raw image size. However, better compiler strategies, characteristic of THWITRS's design, actively seek to replace sections of that basic sequence with instructions or groups of instructions that exhibit a higher pixel-per-instruction ratio. The overarching goal of the Compiler is twofold:

[0107] Reduce the length of the final instruction sequence (i.e., minimise the total encoded size).

[0108] Maximise the average pixel-per-instruction ratio across the entire encoded image.

[0109] This Encoder, therefore, functions as an optimising compiler, fundamentally different from systems that rely purely on mathematical transforms of image data. It intelligently selects and combines drawing instructions to achieve efficient representation.

[0110] Encoding Pipeline: Layering, Object Extraction, and Differential Processing

[0111] Following the comprehensive analysis performed by the Analyser component, THWITRS proceeds with an advanced encoding pipeline designed to achieve optimal compression and fidelity. This pipeline typically involves:

[0112] Initial Layering and Object Extraction: The system first breaks the source image, or part thereof, into a plurality of layers. Concurrently, distinct objects are identified and extracted from these layers. This may involve separating foreground from background elements, or isolating multiple individual objects within a scene.

[0113] Multi-Method Encoding for Extracted Components: Each of these extracted objects or segmented layers may then be encoded using a plurality of methods, as determined by the Analyser's competitive compiling process. This includes, but is not limited to:

[0114] Encoding using THWITRS's native drawing and painting instructions.

[0115] Encoding by converting to a 3D model.

[0116] Encoding by conversion to polygon meshes, as detailed above.

[0117] Encoding for representation by particle physics or other specialized rendering techniques, potentially offloaded to a Special Purpose Engine.

[0118] Encoding that adjusts for lighting changes.

[0119] Differential Processing and Inter-frame Adjustments: Before applying inter-frame motion changes, the system may perform additional differential processing. For instance, the previously identified backlight layer, derived from inter-frame luminosity analysis, can be applied to adjust pixels of a previous frame or part thereof to minimise error or improve visual quality for subsequent reconstruction steps. These processed layers and objects are then prepared for motion-compensated encoding, which will be described in detail subsequently. This structured approach allows THWITRS to apply highly optimised and content-adaptive encoding strategies to different parts of the image, significantly enhancing compression efficiency and reconstructed image quality.

[0120] Breakpoints for AES Reconstruction

[0121] Beyond the core encoding pipeline, the Encoder also implements a sophisticated mechanism for Breakpoints, enabling adaptive reconstruction at the decoder. This involves the Encoder strategically processing and embedding breakpoint information, along with associated metadata, within the bitstream, some of which may reside outside the primary instruction stream for player consumption.

[0122] A method for encoding a frame is to structure it so that a single bitstream may be used to handle a plurality of colour depths or resolutions at a target decoder, minimising the number of different files that a content provider needs to store. It may also permit the decoder to dynamically adapt to unexpected variations in bandwidth. Furthermore, the Reference Data Update Ramp disclosed herein may enable the decoder to recover at periodic intervals (e.g., each second) to restore fidelity without program disruption. The usual process is to reconstruct a frame to a first colour depth or resolution and progressively add to one or both. Central to this adaptive reconstruction are reconstruction breakpoints embedded within the encoded bitstream. Each breakpoint is strategically placed and associated with a distinct intermediate fidelity level of the image frame. This means that at a given breakpoint, the image can be considered 'complete' and viewable at a specific, predefined fidelity (e.g., a specific resolution or colour depth), even if further data for higher fidelity is available. This intermediate fidelity level is achieved upon reconstruction of a subset of the total plurality of data sections comprising the image frame.

[0123] The Encoder knows the expected resources at the decoder it has encoded the bitstream for, and the maximum allowable time for the Engine to be provided a section in a timely manner for frame reconstruction. The unknown parameter is typically bandwidth. To facilitate adaptive reconstruction, the encoder may encode metadata into one or more sections. This metadata is associated with specific reconstruction breakpoints and is configured to enable a decoder to determine the feasibility of timely reconstruction to a subsequent, higher fidelity level. This metadata is crucial for the decoder's decisionmaking process, allowing it to assess whether it has the available bandwidth and time to retrieve and process further data sections required for achieving the next fidelity stage. For example, this metadata may include a byte count required for the subsequent fidelity level reconstruction (i.e., how many bytes need to be loaded to reach that next stage) and an estimated time required for that subsequent fidelity level reconstruction (i.e., how long it will take to process those bytes to achieve the next stage).

[0124] The decoder's Player component is configured to constantly monitor its current available bandwidth and its internal processing rate. By comparing the currently available bandwidth and processing rate against the byte count required and estimated time required for the subsequent fidelity level (as provided in the metadata), and in consideration of the overall frame time or remaining time for timely delivery, the Player determines its capacity to proceed. If the Player determines it lacks the capacity to timely retrieve and process the remaining data for the next fidelity level, it signals an inadequacy of available bandwidth.

[0125] The system is configured such that, upon a determination by the decoder of an inadequacy of available bandwidth for timely reconstruction to said subsequent fidelity level based on said metadata, the decoder is enabled to finalise and output the image reconstructed up to the fidelity level associated with an active breakpoint. This process adaptively terminates further processing of data sections for that specific image frame, preventing delays or stalls due to insufficient resources.

[0126] A Breakpoint may be encoded by using conditional instructions such as publish_if(), overlay_if(n), and flush_render_if() instructions that are NOPs if the player has not signalled early termination and executed if signalled, although the number of [flush_render_if] instructions executed is counted to facilitate timing with the termination signal. Subsequent instructions for the current frame may be executed as NOPs until a new_frame() instruction is executed. The Video Player terminates retrieval of further sections for the frame after signalling early termination. For example, a Frame may consist of 10 sections and be arranged for transfer to the Display Manager at four distinct stages of a frame’s reconstruction, e.g., sometime during section 3, section 5, section 8 and the end of section 10. Sections 3, 5, and 8 include a publish_if() instruction. Presumably, the bandwidth is sufficient to allow stage 1 reconstruction using sections 1 , 2 and part at least of 3. Metadata at the start of section 3 tells the Player how many bytes must be loaded for stage 2 reconstruction and how much time is required post loadingthe sections fortimely reconstruction to stage 2. The video player knows the current bandwidth and may determine if it can timely retrieve the data for Stage 2. If not, early termination at stage 1 is signalled and the first flush_render(n) and preceding _if instructions are executed by the Engine. Otherwise, Stage 2 is retrieved. Sections 5 and 8 have equivalent metadata and are processed similarly to determine early termination of stage 2 or Stage 3 respectively. Other arrangements are obvious, e.g., having all the information at the start of a frame and using previous frame bandwidth in the calculations. After signalling early termination, the video player typically skips remaining sections for the current frame, moving to the next frame. It typically terminates reconstruction early at the same stage for subsequent frames until reaching an l-Frame or a RampJDn location, where it may re-evaluate current bandwidth to determine restoration to maximum colour depth / resolution or another course of action (e.g., continuing with lesser resolution / colour depth).

[0127] Real-time Decoder Feedback and Adaptive Playback

[0128] Beyond simply responding to initial breakpoint metadata, the THWITRS system further enhances adaptive playback through a sophisticated real-time feedback mechanism between the Decoder's Engine and its Player component. This allows for a more fine-tuned and dynamic adjustment of the reconstruction process, departing from a purely prescriptive execution model.

[0129] While the Engine almost always executes instructions as commanded by the Encoder, it may continuously feedback information to the Player, including its processing status, completed data sections, or immediate requirements for subsequent data. This constant communication enables the Player to maintain a precise, real-time understanding of the Engine's state and anticipated needs. The Encoder prepares the bitstream to facilitate this feedback by providing necessary hooks and metadata. This metadata, which may reside outside the primary instruction stream, informs the Player about the structure of the data and the expected processing workload, allowing the Player to make highly informed decisions about pre-fetching, pausing, or adapting the display resolution / colour depth on the fly, optimizing the user experience even under fluctuating network conditions. Active Entangled Stream (AES) Wrapper and Bitstream Structure

[0130] The encoder typically organizes the output into an Active Entropy Stream (AES), which is provided to the decoder as a sequence of distinct sections. These sections are streamed from a server or retrieved from a mass storage component operatively coupled to the destination computer by a video player or another appropriate image player.

[0131] Each section usually includes a set_section instruction typically located near its beginning. When executed by the Engine, this instruction outputs a signal to the destination computer's video player, indicating that a particular section is currently being processed and providing its distinct section ID. The Player is preinformed with details such as the number of sections required for a particular frame and the Section IDs for each section. The execution of the set_section instruction significantly facilitates the Player in receiving and providing timely sections to the decoder, and it also aids in the precise coordination of sound, subtitles, or other associated data with a particular frame. This precise signal from the Engine, indicating its exact status and location within the frame's reconstruction, is particularly useful for the Player to synchronize external elements like sound cues and subtitles with the exact moment a visual event or frame segment is being rendered. For audio, this presents a significant advantage, especially enabling the seamless insertion of audio at the network edge for specific applications, directly synchronised with the visual output. For subtitles, this granular timing capability from the Engine equally facilitates highly accurate synchronization, whether they are delivered as a separate Active Entangled Stream (AES) or through other established methods commonly employed for broader platform compatibility.

[0132] A section within the AES is flexible and may encode information for part of a first frame, part of a second frame, and potentially parts of one or more subsequent (nth) frames, including data relevant to the current frame being reconstructed. This means that sections of the bitstream can strategically overlap frames. The Encoder maintains full control over the information included in a particular section. At any stage of the encoding process, the Encoder may select information from anywhere in the image for inclusion in a particular section and may instruct the decoder to retain this information on its Worksheet for as long as it chooses (within device limitations). The essential requirement governing this sectioning is the timely provision of necessary sections to the Decoder that are required to reconstruct a particular frame.

[0133] The bitstream further includes a flush_render instruction to transfer a reconstructed frame (referred to as a Render Image) for output to the display or for compilation with a layer of the frame produced by a host resource. Execution of the flush_render instruction outputs the specific frame number being flushed to both the Video Player and the Display Manager. This vital signal facilitates the Player in coordinating auxiliary data like sound and subtitles with the exact frame being displayed. Simultaneously, it enables the Display Manager to clear the Render Image for a new frame and coordinate the compilation of layers from other sources with the frame reconstructed by the Engine.

[0134] Each section typically includes Meta Data at its start, which may contain information such as the Frame number, Section ID, and the position of this section in the frame (e.g., "section one of seven sections for the frame"). This particular metadata is usually removed prior to the section's provision to the decoder's Engine, as it pertains more to stream management than direct rendering instructions.

[0135] For navigational purposes, if the player receives a command to move back or forth in a movie, it typically advises the server of the requested new position. The server then directs the player to the next appropriate frame, which, unlike traditional codecs relying on a GOP arrangement and l-frames, would be a THWITRS- specific Ramp On location (as described in the following section).

[0136] Encoder-Assisted Recovery and Continuous State Synchronization (Ramp On)

[0137] Ramp-On is a novel alternative Group of Pictures (GOP) model that is usually reserved for applications (e.g., a through the air broadcast) that do not have network connectivity. Instead, THWITRS implements a sophisticated "Ramp On" mechanism, with the necessary data accessible while network connected (e.g., over the internet or similar network-based delivery) rather than for over-the-air broadcast.

[0138] For pre-recorded content such as movies, the Encoder prepares periodic packets of data specifically designed to update the decoder's Worksheet, generating this 'Ramp On' data for each second of the content and making it available on a server or storage component. For live feeds (e.g., through the internet), these packets are typically generated continuously and made available. Their primary purpose is to quickly resynchronize the decoder for users who have disrupted the natural playback sequence (e.g., by pausing, seeking, or experiencing a connection interruption). For such users, the data in their decoder's Worksheet may have become invalid or out of sync. In this scenario, the player advises the server of the exact frame or timecode sought. The server then sends the relevant Ramp On data to precisely bring the decoder's Worksheet up to date with all the information that would have been present at the end of the frame immediately preceding the requested playback point. Upon acknowledgement of this update by the player, the decoder can then seamlessly commence receiving and reconstructing frame data from the new, desired position, allowing for efficient and fluid resumption of playback.

[0139] For other users who have not altered the play order during that period, there is no requirement to discard or 'dump' their Worksheet data, unlike traditional codecs which often force a full refresh via l-frames every 8 frames or so. This eliminates the need to transmit redundant full-frame data to a vast majority of users, resulting in massive bandwidth savings for the content provider and significantly increasing the overall compression effectiveness of the THWITRS system. When a user who has disrupted playback retrieves a Ramp On update, the THWITRS system efficiently re-establishes the decoder's Worksheet to the precise state it would have been in at the requested point in time. This eliminates the need for the decoder to reconstruct the entire preceding sequence of frames from the stream's origin or a distant l-frame, allowing for seamless and rapid resumption of playback or transition to the new state without a full re-initialization of the image reconstruction process.

[0140] This approach offers significant advantages:

[0141] Reduced Latency and Improved User Experience: Fast recovery from disruptions, as the decoder's state can be brought current almost instantaneously.

[0142] Bandwidth Efficiency: While there is an approximate 3% overhead on the file size stored at the server to accommodate these periodic update packets, this data is only sent to a user who disrupts playback. For continuous streaming, this overhead is not incurred in the transmitted bandwidth. This targeted delivery mechanism saves substantial overall bandwidth compared to frequently sending large l-frames that may contain much redundant information.

[0143] Data Preservation: For continuous playback, valuable reconstructed data on the decoder's Worksheet is not unnecessarily discarded. For disrupted playback, the Ramp On mechanism provides a quick, synchronized baseline, avoiding the need to rebuild the entire image history.

[0144] This "Ramp On" mechanism is a fundamental function of the Encoder, working in concert with the AES structure to ensure robust and highly adaptive media delivery.

[0145] THWITRS's programmable nature and ability to define and manipulate distinct image layers makes it highly feasible to embed interactive elements, such as buttons, directly within the video stream itself. These elements can be encoded as specific graphical objects or layers using THWITRS instructions. The clientside Player can then be configured to detect user input, such as mouse pointer movements and clicks, on these interactive elements. This input can then be relayed back to the content server or a relevant application server, enabling real-time user interaction and dynamic responses within the streamed media, such as navigating menus, making selections, or controlling aspects of the content.

[0146] Compatibility with Evolving Media: Movies, Games, and Host Pixel Generation

[0147] A significant embodiment of THWITRS is its compatibility with the evolving landscape of digital media, particularly in film production and interactive entertainment where actors, scenery, or entire environments are increasingly computer-generated. This advanced integration allows THWITRS to play a pivotal role in reconstructing highly complex visual content.

[0148] In such an embodiment, THWITRS can be configured to reconstruct textures that a 3D Engine then applies to a set of polygons. These polygons, along with crucial data such as lighting parameters, camera positions, motion vectors, and other necessary information for generating movie frames, are typically transmitted to the 3D Engine via a separate channel. This allows for a highly flexible and efficient workflow, where THWITRS handles the detailed texture data while the 3D Engine manages the geometric rendering.

[0149] Alternatively, the THWITRS Engine itself can be configured as a Host Pixel Generator. In this scenario, textures, polygon information, lighting and camera angles are passed to the 3D Engine using Integrated Push Extended (IPE) instructions. The 3D Engine then generates the frame and passes it back to the Worksheet. Here, this newly generated frame can be seamlessly combined or "collapsed" with one or more layers of the frame that have been reconstructed in the Worksheet by another method. THWITRS may also be used to reconstruct textures for transfer to a Games Engine. The textures for a movie or game may include advertising information.

[0150] Decoder Components for Bitstream Reconstruction

[0151] A ,d32c bitstream is typically restored to a ,d32 file by a Bitstream Reconstruction Component (BRC) at a decoder. The BRC acts as a decompressor for the secondary compression layer, preparing the AES for execution. In most preferred embodiments, the BRC functionally comprises or is closely integrated with an Adaptive Entropy Decompressor (AED), which is configured for reassembling the AES into an executable sequence of instructions, particularly when the AEC (Adaptive Entropy Compressor) is used during encoding. However, the BRC may also configured to reverse alternative prior art secondary compression processes (e.g., if a 7z compression was used, it is reversed by a matching 7z decompressor component within the BRC). A BRC may not be required for embodiments that do not process ,d32c or ,d32cs bitstreams. A BRC may operate in a secure memory (for example as described for an Engine hereunder).

[0152] The Virtual Machine and Processor (VP)

[0153] The reconstructed AES (,d32 file) is then executed by a Processor, preferably a Virtual Processor (VP). The VP may be configured as a plurality of virtual processors operating in parallel to enhance performance. The Virtual Processor, together with a Worksheet (a large texture manipulated by the Virtual Machine), and usually a Render Image, comprise a Virtual Machine. Given the established knowledge and designs of virtual machines, individuals skilled in the field can adapt existing architectures to accommodate the requirements of a virtual machine operable for use with the disclosed instruction set and system. A preferred implementation of the VP utilises a plurality of GPU cores. It should be noted that a preferred embodiment of the THWITRS Engine is designed to operate directly within a GPU. This not only provides enhanced processing capability but facilitates an image to be reconstructed directly in graphics memory. This direct reconstruction is particularly useful for applications such as games and 3D modelling, where textures may be rendered straight into GPU memory, thereby avoiding prior art bottlenecks associated with transferring textures from CPU-rendered to GPU space. Moreover, the system's ability to retain selected image components (e.g., textures) in memory for encoder-determined durations further facilitates this process, optimising performance and resource management.

[0154] THWITRS may direct control over various operational aspects via instructions embedded within the bitstream itself, rather than relying solely on the Destination Computer's Operating System: a) Pixel Manipulation

[0155] A subset of the instructions operate directly on pixel space, allowing them to be directed to a particular pixel or group of pixels to elicit a change in their attributes. An arbitrary pixel or group of pixels may be targeted for modification. The specific locations and the sequence in which multiple pixels (or groups of pixels) are modified, as well as the nature of these modifications, are determined by the Encoder based on encoding requirements and available methods, rather than being constrained by a fixed protocol. Furthermore, THWITRS is not limited to processing patches of pixels in conventional rectangular or square formats. It can process patches in any arbitrary geometric arrangement — be it rectangles, squares, circles, ellipses, triangles, or polygons — consistent with the requirements of the selected process. b) Memory Management: Memory management is typically controlled by encoded instructions in the bitstream, rather than by the Destination Computer's Operating System. The AES typically contains encoded memory management instructions that dynamically allocate and manage memory resources in the memory space operatively coupled to the processor. The Encoder possesses knowledge of the Worksheet's content at any point during execution based on its predefined structuring of the bitstream. This design ensures that memory space allocation or reuse is conducted as required by the Encoder and is implemented via instructions encoded within the bitstream. This approach differs from conventional codecs by eliminating the need for system-level memory management intervention or the requirement for the application program to actively track memory resources. Buffers, scratchpad, and multiple frame stacks are all regions of the large texture memory controlled by the encoder via instructions encoded in the bitstream. Typically, the only transient memory used by the VP is the push stack, which is self-managing as data falls off the end after use. Embedding memory management in the bitstream, after managing it at the encoder, effectively solves memory allocation issues with GPU cores, as they are not suited to traditional memory management like malloc and Garbage Collection in other languages. In a GPU-based VP implementation, the GPU cores need to execute the THWITRS instructions and have access to the texture in VRAM - for which they are designed. c) Parallel Processing Control: Control of the parallel processing (for a plurality of virtual processors) may be by an instruction in the bitstream, rather than by the Destination Computer's Operating System. The embedding of semaphores (see hereunder) in the bitstream also hands control of parallel processing in a multiprocessing implementation of the Engine to the Encoder. Parallel processing in a THWITRS environment is further described hereunder. Embedded semaphores and Memory Management may be effective with web-GPU technologies. d) The encoder may also organise image reconstruction at the decoder in progressive chunks of increased resolution or color depth to accommodate different system capabilities or adapt to unexpected bandwidth changes by encoding breakpoints and related metadata into the AES. Each progressive level can be copied to the render image to produce an acceptable frame, allowing one AES to cater to a plurality of distinct bandwidth or processing capabilities at the decoder.

[0156] Integrated Push Extended Instruction and Special Purpose Engines / Host Pixel Generators

[0157] In addition to drawing instructions that are directly operable on pixel attributes in the Worksheet (including the list of disclosed example instructions hereunder), an Integrated Push Extended (IPE) instruction may be used. An IPE instruction pushes an arbitrary number of operands onto an Engine stack along with an instruction directing a component that augments the functions of the Engine Processor to use said operands to reconstruct a patch of pixels and place them at a location in the Worksheet determined by the Encoder. Said augmenting component may be a Special Purpose Engine (SPE) that is a part of the Decoder ora Host Pixel Generator (HPG) (for example, a System Codec, Text Library, SVG Library, 3D Graphics Engine such as Unreal). An HPG may be instructed to place a reconstructed image to the Worksheet or to a Host Resource for output to a display. An image reconstructed by an HPG and output to a host resource, rather than the worksheet, may be composited with an image output from the Worksheet, said compositing typically under the control of the Host Display Manager.

[0158] Examples of an SPE may include an Inverse Transform SPE, Text Generator, Fractal Decoding SPE, 2D or 3D Model Generator, Vector Generator (typically additional to the native vector instructions of the THWITRS ISA), Intra Frame Prediction Module, Particle Generator, Secure Processing component, Miscellaneous SPE (e.g., to provide a function outside the scope of the Engine Processor), or another type of SPE. An SPE is usually a resource at the Decoder determined for use by an Encoder to reconstruct a patch of pixels because it is an optimal strategy for said patch. The same may apply to an HPG; however, it may also be that THWITRS is instructed to send an image encoded with a prior art codec. For example, a user may be using a THWITRS compliant Editor and drop a JPG image into part of a frame, wherein, the Encoder wraps all the image data into a sequence of push instructions and an IPE Instruction to send it to a Host JPG codec for reconstruction. A movie clip may be similarly inserted if encoded for an available codec. THWITRS may be used to insert user-targeted ads at the Edge into a movie or computer game, and said ad may be provided to the THWITRS Engine, for example, as a JPG or MPEG texture. The Vulkan API has recently provided a set of extensions called Vulkan Video that allow for hardware-accelerated video compression and decompression, including H.264 and H.265, to be integrated seamlessly into Vulkan applications. A similar process may be implemented for other prior art codecs or for an SPE. An outline of Vulkan video with H.264 and interaction with THWITRS is further described hereunder.

[0159] Arbitrary Switching Between Compression Methods

[0160] THWITRS is operable to take advantage of its plurality of prior art and novel compression methods by arbitrarily switching between processes as determined by the encoder. This function is facilitated by a Hierarchical Adaptive Switch String (HAS String), which may include switching parameters in the string or utilise information in a pixel to facilitate a switch. The HAS String is typically implemented in the Adaptive Entropy Compressor / Decompressor or in a Special Purpose Engine. This is further described hereunder.

[0161] Decoder Configuration and Multi-Engine Support

[0162] The decoder may be configured with a plurality of Engines and may be configured to operably couple a BRC exclusivelyto a distinct Engine er share a BRC with multiple Engines. The processor is preferably configured to process a single bitstream at a time, in which case, a second image encoded into another bitstream pending processing must either wait until the first bitstream is fully processed, or it must be processed by an alternative THWITRS Engine or configured for a different type of codec.

[0163] THWITRS Computer Instruction Set

[0164] The instructions, stored on Non Transient Computer Readable Media are integral components of a) an Active Entangled Stream (AES), b) the encoder (for example, to reference during encoding), c) the decoder (for referencing against the instructions in an AES), and may be of use by related system components. The preferred instructions are four-byte fixed length instructions that are compatible with current GPU cores and beneficial to a Virtual Machine (typically the combination of Virtual Processor, Worksheet, and for some embodiments a Render Image) implemented in said core. The length of instructions, and fixed or otherwise, is not intended as limiting factors.

[0165] The Decoder

[0166] The Decoder comprises at least one Engine, said Engine comprising a Processor component a Worksheet, typically a Render Image and usually other support components. An entropy decoder component and / or a decryption component are typically part of the Decoder — as components of the Engine and / or distinct. The preferred Processor comprises at least one Virtual Processor (VP) and embodiments with multiple VPs typically operate in parallel. Parallel processing is typically determined by encoder and controlled by instructions in the AES. Allowance is made for a virtual processor to be replaced by a silicon (or other hardware embodiment). The system may include multiple Engines that may share a common Worksheet or operate with distinct Worksheets. The Processor executes an AES to reconstruct the image in the Worksheet. During execution, the AES instructions facilitate direct manipulation of pixel attributes at specified locations in the pixel space, allowing for addressing methods such as absolute coordinates, relative positioning, or drawing operations that directly write pixel attribute values to targeted locations. Part of the reconstruction may use other memory or compilation with an Image component rendered to other memory of the destination computer (e.g., under control of the video player or graphics manager), or other memory. The Processor may be configured to operate as a secure, preferably tamperproof Processor operable in secure memory. The secure memory may include Worksheet memory. The Decoder may comprise multiple Engines, however, each Engine is typically restricted to processing one AES at a time, although information may be transferred between Engines.

[0167] The Worksheet

[0168] The Worksheet comprises computer memory organised in Processor Addressable Pixel Space, enabling the Engine Processor to reconstruct an Image in the Worksheet by addressing pixels through their x,y (z) coordinates rather than actual computer memory addresses and processing data as pixel attributes. The preferred arrangement stores pixel attributes as 32RGBA — 8 bits for each component. For instructions that operate on reduced color depth (e.g., 4 bits of color) the unused less significant bits are set to zero.

[0169] The Worksheet size is flexible, typically dictated by the application and available resources. In the described example embodiments, a worksheet may be as large as 64K pixels in width (x direction) and 64K pixels in height (y direction). For 2D images, the Worksheet typically comprises a 2D array of pixels, X pixels wide and Y pixels high. The default origin is usually the top left corner of the Worksheet (0,0), though other origins may be used. A reference origin may be dynamically modified as required in response to computer instructions.

[0170] The method for encoding a pixel's coordinates is not fixed. For the aforementioned Worksheet size (up to 64K x 64K), each of the X and Y coordinates is stored as a 24- b it number, comprising 16 bits for the integer part of the coordinate, corresponding to 64K, and 8 bits for the fractional or subpixel part, equating to 256 levels. This aligns with the preferred configuration for 2D images, which also stores each of the x and y locations as a 24- b it number, with integer values in the most significant 16 bits and sub-pixel values in the lower 8 bits. Instructions that operate on integer values only usually set the subpixel value to zero. Various alternative configurations for storing coordinate information are contemplated within the scope of this invention.

[0171] Setting a Reference Origin for the Worksheet may use two instructions for a four-byte fixed ISA, one for the X coordinate and another for the Y coordinate. An alternative might be to increase the bit size of the instruction. For significantly smaller worksheets, a single instruction might suffice, potentially using fewer than three operand bytes and filling any unused bytes (or bits) with zeros. For worksheets exceeding 64K by 64K pixels, an additional four-byte instruction may be required, or mechanisms, such as a compound push instruction or increasing the bit count in an instruction, may be employed to extend operand capacity.

[0172] Pixel operations typically set a drawing pointer (or cursor) to a target pixel location and perform operations on that pixel or nearby pixels (e.g., using relative addressing). This pointer-based approach enables efficient sequential operations and arbitrary pixel access patterns throughout the Worksheet. For example, the set_origin and / or the pos (x,y) instruction enables the encoder to arbitrarily position the pointer to an arbitrary location in the Worksheet for subsequent instructions to perform an operation on pixel attributes of an arbitrary patch at or relative to said pointer. The coordinate system and instruction set may be readily adaptable to include a z-axis if required by an embodiment (such as for 3D printing or another 3D output). For 3D images, the Worksheet typically comprises a 3D array of voxels, X voxels wide, Y voxels high and Z voxels deep. The default origin may be the top left front corner (0, 0, 0), though other configurations are possible. A 3D Worksheet may be useful for applications including, but not limited to, 3D printing, CT, MRI, VR, AR, or in the construction of a 3D movie where depth parameters may be required. An encoded 3D movie may be reconstructed to a 2D pixel space at a decoder with the left and right frames reconstructed in distinct regions of the worksheet.

[0173] The pixel attributes may be placed on an integer x,y boundary wherein the full attribute value is allocated to that pixel, or alternatively on a sub-pixel boundary where the attribute value is distributed proportionally between adjacent pixels based on the sub-pixel coordinates.

[0174] While multiple layers in a 2D image might be represented using a number of alternatives (e.g., as different z values in a 3D configuration of the Worksheet), the preference is for the layers to be configured in a 2D Worksheet, with each layer represented by different regions of the Worksheet. For example, the foreground in one region and the background in another. These layers are composited on top of each other to reconstruct the image, with alpha values used to control transparency. The depth of a particular layer is typically not represented by a z-value but determined by the instruction order sent by the encoder for copying one layer on top of another. The compositing may occur in the Worksheet, in which case it may be destructive to a layer (unless composited to a region of the worksheet distinct to the layers) or compositing may occur at the Render Image (see hereunder) in which case it is non-destructive to the layers stored in the Worksheet. The bottommost layer often does not require an alpha value, typically serving as the background, while the subsequent layers employ alpha blending for accurate overlay and visual coherence, thus maintaining the correct z-order.

[0175] Each pixel represented in the Worksheet has a number of attributes. For example, if only working in the RGB space, there are typically three attributes: the amount of red color, the amount of green, and the amount of blue. For 24-bit color, 8 bits are required to store the value for each of these attributes. The addition of alpha results in four attributes. A monochrome pixel may only require one attribute. Additional attributes may include Luma (L) and two Chroma (U,V, or Cr, Cb). THWITRS typically stores the values for LUV virtually, as an operation that uses incoming LUV information for a pixel, is typically converted to RGB values (and if necessary, mathematically combined with an existing RGB attribute for said pixel). If LUV is required from a pixel, it is typically dynamically generated as required. For print operations, a pixel may include the four attributes for CMYK (Cyan, Magenta, Yellow, Black). Another attribute may be Depth information from various imaging techniques, such as time-of-flight, structured light, or plenoptic cameras, although depth information is typically more useful to the THWITRS encoder that may use it to facilitate placement of various objects in a frame to different layers of said frame. Multidimensional information that caters to specialised visual experiences like stereoscopic 3D viewing or 3DoF / 6DoF video parameters may also be an attribute, but like depth, is typically more useful to the THWITRS Encoder.

[0176] The Worksheet is typically larger than the final rendered image, and the encoder is free to use the Worksheet in anyway it finds advantageous. Examples would be drawing frequently used image fragments for pasting into the final image (compositing) or building a larger image to allow panning or scrolling and using spare bandwidth to prerender future frames. At the beginning of a decode session, the worksheet is assumed to be of an unknown state - each pixel is in an indeterminate value. A single instruction may be used to initialise the whole worksheet to a known arbitrary value. Normally the encoder would select a value that optimises its subsequent strategy. Specific regions are set by instructions, the main one being the Viewports which control the part of the Worksheet translated to the final rendered image. If there is no previously decoded information in the Worksheet that is of use in reconstructing a Current frame, the Encoder will have to send all of the information required to enable said reconstruction. If there is information stored in the Worksheet that is for use in said reconstruction, the Encoder will need to send less information. A session may only require the reconstruction of a single frame in the case of a static image or many frames in the case of a video. Reconstruction of a static image may use many of the same processes as for a multi-frame, except the latter typically has access to additional processes, for example, the Engine may use information from frames that it has already decoded and retained in memory to reconstruct a new frame. The Encoder may retain in the Worksheet one or more patches of pixels previously decoded, one or more previously decoded frames, or any other information sent to the decoder since the start of video playback. This may be retained until the Engine is instructed to remove (or otherwise invalidate (that may include overwriting)) one or more bytes of the retained information. The Encoder may send patches from a future frame in a video for use in reconstructing a current frame or more contemporaneous frame than said future frame. The encoder may instruct the Engine to reconstruct multiple frames concurrently with that of a Current Frame. The Encoder may analyse any frame to which it has access, seeking a suitable Patch for use in reconstructing a Frame. Although there may be applications requiring a Group Of Pictures structure as used by the prior art (e.g., for through the air transmission without network support for an update ramp), the encoder may, for many applications, be free to keep whatever it determines appropriate in decoder memory. Such arbitrarily addressed locations within the Worksheet may include information for a current frame, a previously decoded and displayed frame, a future frame (stored for output or under construction), part of any frame that the encoder has access to and has transferred to the encoder, a layer, or another purpose.

[0177] Random access to pixels in a Worksheet has advantages over current codecs, including the ability of the compiler to decide if it is more efficient to leave errors in pixel data sent to the Engine for more efficient entropy encoding, and subsequently fix the data if required. Some instructions are efficient, e.g., a rectangle drawn with the fill instruction, wherein correcting a wrong pixel is a trivial overhead. The THWITRS instruction stream can encapsulate arbitrary blobs of bitstream, so any pixel encoding method may be potentially included and be operable for encoding an image.

[0178] Worksheet Memory and Configuration

[0179] The Worksheet memory may be Graphics and / or Computer Memory of arbitrary size, typically limited by destination computer memory resources. For embodiments outputting images on small LCDs / OLEDs (say sub 800x600 px) used in industrial and consumer products, the Processor (Engine) is typically implemented within the display control electronics, often using one or more microprocessors integral to said electronics. The associated Worksheet memory is then CPU accessible and typically integrated directly with the display's control circuitry. This configuration allows an Engineer to simply couple a microprocessor to the display and send an AES to the display to integrate it into their design, as the decoding engine and Worksheet form an integral unit with the display's internal electronics, potentially even within a chip-on-glass circuit. For embodiments where the Engine replaces or augments existing codecs in desktops, laptops, tablets, and phones, the memory is typically GPU memory, which has the additional benefit that textures may be rendered directly in GPU RAM without CPU-to-GPU transfer bottlenecks. The Worksheet may be configured as secure, tamper-resistant memory protected from Host Resource access. The described Worksheet may be adjusted for increased or reduced color depth, other attributes or worksheet size by modifying the reference instructions to accommodate alternate parameters. The instruction set may be configured for other integer or sub-pixel resolutions.

[0180] Decoder Component. The Engine, within limitations of the device, may be implemented in a microcontroller. Computers increasingly include a multicore CPU and GPU together with extensive amounts of memory as standard components, enabling the processing of a highly optimized Active Entangled Stream. The Virtual Processor may be written in GPU shader code, e.g. using Open GL or WebGPU. Processing capability is expected to continually improve, and the Engine may smoothly expand to take advantage. Increased memory at a destination computer enables the Encoder to retain a greater number of patches at the decoder for future use, and improved processing power (and increased memory) provides improved opportunity to transfer computer models and textures to an Engine to reconstruct an image component. The decoder is broadly operable within the resources of a modern smartphone. The decoder is designed to reconstruct images from instructions encoded within a received bitstream. Ancillary information, possibly appended to the bitstream (for example, included in a MessagePack format), might be removed by an application (e.g., Video Player) controlled by the destination computer’s operating system or another entity before being fed into the decoder. The THWITRS system accommodates the potential for such preprocessing to be conducted by a component within the decoder, if necessary. The decoder typically includes:

[0181] Non-Transient Computer Readable Media (NTCRM) for storing a sequence of computer instructions provided in a bitstream in i) an executable format (for example a ,d32 ) or ii) for processing (for example, a ,d32c) to produce an executable format, or iii) for decryption (for example, a ,d32s or ,d32cs) to facilitate input to a processor component in an executable format, or iv) other processing (for example, removal of message pack wrapper or equivalent) to facilitate input to a processor in an executable format. Said media may be configured for storing the instruction set for the Virtual Machine.

[0182] Render Image Component: is typically a separate pixel space to the Worksheet with a resolution usually corresponding to the actual display device coupled to the destination computer, for example, a user display like a video monitor. The resolution for the Render Image is provided to the Engine by a host resource, typically the Video Player. The resolution for the Render Image may or may not be the same as the resolution encoded into an AES for reconstruction of the encoded image. The Render Image is basically the last step in the reconstruction of an Encoded Frame prior to transfer to a host resource (e.g., Display Manager or Compositor) forfurther processing. The Engine reconstructs a frame for output in its Worksheet as one or more Viewports that are essentially 32RGBA Overlays typically the resolution of the encoded Frame, however, we disclose example effects from changing the VP resolution. These are copied to the Render Image sequentially in an order predetermined by the Encoder to build up the Render Image, typically in 32RGBA pixel space. Viewports are copied with Alpha to blend with any previous Viewport (VP) for the Frame already copied. The copy may use a bilinear transform ( or equivalent) to resize, if necessary, the Viewport to the resolution of the Render Image.

[0183] Note: The reconstruction of an image in the Worksheet may copy a patch from a first to second location within the Worksheet that may include a bilinear (or other) transformation, however, in these instances it is the encoder that usually determines the resize parameters; a distinction from the present instance for a Viewport, wherein the Engine receives these parameters from a host resource (e.g., Video Player).

[0184] Note should be made of Viewport (0) that we have used as a default for a Backlight overlay. The backlight VP may be used to lighten or darken parts of any composited Viewports for a frame already at the Render Image when the Backlight VP is copied. Rather than an (or in addition to) alpha blend, it adjust the attribute of each pixel using the following (or equivalent) formula: R_render (adjusted value for red pixel in render image) = R_render (red attribute prior to backlight)* R_backlight (value of red attribute in backlight V P) / 128 and similar for Green and Blue. The backlight may be low resolution and quite blurry, so the Backlight Viewport might only be 16 pixels wide , and at the time of update this would scale up to the render image size. If the Backlight Viewport was 16 x 16, that would effectively mean the render image has 256 "cells" of lighting effect. This is an effect obtained by making the backlight viewport smaller than the AES Frame resolution. For a first and second frame of an image where the differences are mainly lighting, this, may be an efficient method of interframe encoding or for adding special effects. The backlight Viewport might also be neutral for one or more colours e.g., for Red and Blue, and accentuate Green. This would immediately give the rendered image a green tinge. The backlight VP is copied to the render Image with an update() instruction. The Distort_Copy_Shadow instruction may be used to convert an image component to a shadow for use with the backlight layer. Viewports ) is usually the main Viewport in a Worksheet for building a frame and is copied to the Render Image using the publish() instruction. The overlay(n) copies all other Viewports. The main advantage of Publish and Update is that they do not require an operand, potentially improving entropy encoding. They may be replaced by overlay(n), for n=0 or 1 ; freeing up two opcodes for another use. The 'flush_render' instruction signals a Display Manager (or equivalent) to transfer the render image to an Application Target for subsequent processing as required and output to a display device (e.g., electronic display, printed material, 3D printing), storage, combination with other images, or other applications, freeing the render image for the next frame. Scaled transfer to a Render Image accommodates displays of different resolution for the same AES. Another use may be to minimise bandwidth for an image by reconstructing it on the worksheet at a smaller resolution then shrinking the Viewport to Match so that when the image is upscaled at the render Image it is effectively at a reduced resolution. Another application may be to reconstruct an image greater than a frame and adjust the Viewport to pan or zoom. The Overlay of Worksheet components of an image in the Render Image is nondestructive for the components in the Worksheet.

[0185] It should be noted that the use of a Render Image as described is a typical process for use of THWITRS in a typical Windows, Linux, Mac, or a similar type of computer. THWITRS is not limited to this embodiment. A microcontroller, for example, may be configured to send the render image (or bypass this and send the viewport) directly to a display (e.g., an LCD or OLED display). As disclosed elsewhere, an embodiment may be configured to ensure the decoded information stays within an environment where the decoded image cannot be accessed by an unauthorised party. In another embodiment, the worksheet may be in tamper resistant memory (typically) and blend its output with the destination computer graphics, preferably independently of any control by the destination’s operating system. Another embodiment may switch image output from the system to THWITRS as required.

[0186] For a TV, the Render Image data typically provides frame pixel attributes for each pixel on the TV Screen. For a computer, while the data sent to the Render Image may describe pixel attributes for all pixels on a display, the output from the Render Image may be directed to a window that may be variably positioned and sized by means independent of the Decoder, as such, the image displayed in a window on the display component may be compressed, expanded, or cropped.

[0187] The Render Image may serve as a layer in the Application Target allowing for composite integration with other render images from a THWITRS Decoder or alternative sources. The preferred methods of compositing a first render image from a first render image component with a second render image from a second render image component may include:

[0188] • Meta information in both bitstreams

[0189] • Information in the operand of the 'Flush_Render' instruction advising that this is one of a plurality of Render images for compositing by a Display Manager or equivalent, including the z value of the image,

[0190] Use of a portal between two Bitstream Processors for a second Processor to Overlay a Viewport to the render image of a first processor. This is further detailed elsewhere.

[0191] Strands and Snippets: Modular Image Components

[0192] In THWITRS, image components are not merely static pixel data but dynamic, executable sequences of pixel space instructions known as Strands and Snippets. These are fundamental to how THWITRS regenerates images at the decoder, offering unparalleled flexibility and efficiency.

[0193] A Strand is typically a short, relocatable sequence of THWITRS Computer Instruction Set (TCIS) instructions. The consistent positioning of opcodes at the same byte boundary within these fixed-width instructions enhances their location flexibility. This design means that a Strand, once compiled, can often be executed from virtually any position within the decoder's Worksheet, embodying the characteristics of position-independent code. Typically, a Strand begins with an instruction that sets the position of the drawing cursor (e.g., a pos (x,y) instruction) for the instructions that follow. While relocating a Strand, care must be taken to ensure its reference origin remains correct; if the context's reference origin has changed, an instruction to reset it may be included at the Strand's beginning. Redundant instructions (like unnecessary origin resets) can be efficiently removed later by the Encoder's compiler. This modularity facilitates the Encoder's competitive compilation process, allowing it to insert, delete, rearrange, or modify instructions to optimize image reconstruction and entropy encoding.

[0194] A Snippet is a specialized type of Strand, characterized as a relocatable sequence of instructions designed to regenerate specific components or "parts" of an image. Snippets are particularly significant for Al input into image encoding or de novo image construction. They represent self-contained visual elements — for example, "a wig of long blond hair blowing in the wind" — that can be easily identified, manipulated, and inserted. Both Strands and Snippets are usually relocated prior to any parallel processing configuration or secondary compression of a compiled Active Entangled Stream (AES) by the Encoder.

[0195] Position Independence and Dynamic Integration

[0196] The position-independent nature of Strands and Snippets is a cornerstone of their utility. It means that an Al or a user can simply "pop" them onto an AES or directly onto the Worksheet, and when executed by the THWITRS Engine, they will correctly build or modify an image regardless of their placement. This allows for fluid, dynamic image composition in ways traditional pixel-based systems can't match. For example, a user or an Al can effortlessly drag and drop a Snippet into a paint program or movie development application, move it around, expand it, or shrink it, whether it's a single-frame element or a multi-frame animation.

[0197] IP Protection and Monetization through Strands and Snippets

[0198] Strands and Snippets are not just building blocks; they are also powerful units for Intellectual Property (IP) protection and monetization. They can be tagged with metadata such as ownership information, cost-to- run parameters, and other proprietary data. This metadata is securely protected, often by being encrypted or by residing in secure memory at the decoder.

[0199] We envision a vast library of these items, categorizing them as either public domain (typically unprotected) or proprietary. When an Al or a human user wishes to utilize a proprietary Snippet or Strand, they can easily load it into their creative environment. The critical innovation here is that when these Snippets are executed by the THWITRS system, they can track usage. This usage tracking forms a novel method of billing for IP utilization, allowing creators to monetize their work based on actual execution or display within the THWITRS ecosystem.

[0200] For the compilation of a complete image or movie, the user or another authorized entity would send the content to a trusted party (e.g., our system or another designated compiler). This entity handles the final compilation, potentially integrating various Strands and Snippets while enforcing their associated usage rights.

[0201] Secure Execution and Digital Rights Management (DRM)

[0202] An AES or a distinct Strand / Snippet within it may be encrypted for subsequent decryption and execution, optionally within a secure environment. This allows for a mix of encrypted and clear code Strands within a single AES, facilitating applications such as:

[0203] Digital Rights Management (DRM): Clear code parts can execute in system memory, while encrypted Strands are processed within a secure DRM environment. This provides granular control over content access and usage.

[0204] Secure Content Insertion / Editing: For human or machine-driven de novo image construction or editing of an existing image, an encrypted Strand can be inserted or removed from an AES. This Strand is secured against unauthorized analysis but remains fully operable to reconstruct a specific patch of an image. In conjunction with other encrypted meta-information embedded within the Strand, information assisting in IP ownership, validity, or other pertinent details can be securely determined and enforced.

[0205] This tiered approach to security ensures that creators can distribute their IP while maintaining control over its usage and protecting it against unauthorized replication or analysis, even when the content is actively being used to build new images or experiences. Adaptive Entropy Compressor (AEC)

[0206] The instruction based architecture of the system provides a highly flexible system, however, the instructions can also be expensive for some processes. The objective of the AEC is to mitigate the overhead.

[0207] The AEC typically may be configured with any available entropy compressor and the encoder may select the most competitive process for any particular patch of pixels. It may also switch between processes. It may even switch process part way through processing a block of pixels, for example when predicting a block intraframe.

[0208] The Encoder may create macro instructions to consolidate multiple instructions under one opcode. This conversion typically happens at the AEC but may be by an earlier component at the Encoder. The ADC at the Decoder remove the Macro and the Virtual Processor usually only sees its executable instructions. We also disclose an Entropy Pipe and Enhanced Entropy Pipe that split various components of an instruction into different channels to improve Entropy encoding. Once again, the ADC at the Decoder typically restores the instructions back to an executable state.

[0209] The AEC ( or another Encoder component) may go one step further and actually disassemble the instructions. For example, motion vectors of the prior are very efficient and much more efficient than sending down stream of instructions. The challenge here was to maintain the flexibility in a way that remained competitive. In this instance the encoder converts the instructions to a set of coordinates, typically on offset relative to one another or a similar process and entropy compresses these or applies a transform. An advantage is that we can home in on a single pixel if it is problematic. The instructions are restored at the Decoder usually by the ADC for VP execution.

[0210] The Special Purpose Engines combined with a series of Push instructions can expeditiously move packets of data to these additional resources.

[0211] Sequences of the same opcodes may be compressed to negligible bit count, especially the frequently used Push where we just send a count of how many and let the ADC restore them.

[0212] The Pixel Map also can be used to improve compression by not wasting time on a pixel already fixed by an earlier process. This trends to be more effective as the frame fills up.

[0213] We can also use the attributes of pixel to signal a change in a process (e.g., skip over if LSB = 0 turn right if =D

[0214] We can use standardised sets of colour tables, quantisation and other prior art tools. The system may be configured to auto generate tables of Huffman values , colour and other reference material by tracking frequency at the Decoder and building tables there (i=usually in the ADC that can track everything coming through,

[0215] Transform, residuals and other parameters may be converted to a 3d array to improve the flow of values when entropy encoded. For example, for a plane of coefficients in a 3d array a particular z level may be rotated or be moved to a different z value. A HAS string may control tis and signal the decoder what to do. An encoder that knows every step and can make assess the value of changing course at any stage is a powerful tool for Al driven imaging systems.

[0216] 1)Entropy Pipe. By separating the four bytes of an instruction into a plurality of distinct streams, the AEC may improve entropy encoding. Extended sequence of the same opcode or groups of opcodes may be compressed towards zero bits by a combination of a) separating opcodes, b) rearrangement of the separated opcodes, c) macro instructions for groups of opcodes that are recurrent in the AES, and d) rearrangement of instructions by the compiler, or e) another method. The compiler rearrangement is facilitated by the capability of the encoder to make a sequence of instructions position independent as described elsewhere. The Entropy Pipe is a mechanism for sending a list of the THWITRS instructions from the encoder to the decoder, typically to improve the efficiency of entropy encoding. The instructions are typically 4-byte instructions (quads).This mechanism collapses the sequence of quads (for example) to a bitstream to improve optimisation of lossless encoding. As the information content of the sequence of quads decreases, the size of the "pipe" shrinks as well so that a sequence of NOPs will collapse towards zero. THWITRS instructions with sparse data may shrink and repeat instructions may deflate the opcode byte to a couple of bytes. The pipe is a two-stage process at both ends, the AEC and the AED: reorder the list into 4 blocks of sequential data, each block being one of the 4 bytes in the quad. lossless compression algorithm, (e.g., using LZ, Huffman, ASL, dictionary, or arithmetic compressed bitstream format, ANS) decompression to reverse (2.) reorder blocks to reverse (1 .) Reorderingthe sequence into blocks of byte position naturally groups fields of instructions into sequences. For repeat instructions this allows sparse data to be used efficiently. The pipe may be implemented using the push stack mechanism. For example, this may use a single instruction:

[0217] Opcode: pipel , Operand 0: Channel Number, Operands 1&2: Block Length. Hex 43 01 00 80 - sends 128 bytes (pushed onto the stack) via channel 0143 is opcode, 01 is channel number, 00 is hi byte of block length, 80 is low byte of block length. For example, to send a block of zero data comprising 8 push opcodes and 24 zeroes (the data may be any value or mix of values), one arrangement may be: pipel (1 ,0, 20): 43 01 00 20; push(0,0,0) : 27 00 00 00; push(0,0,0) : 27 00 00 00; push(0,0,0) : 27 00 00 00; push(0,0,0) : 27 00 00 00; push(0,0,0) : 27 00 00 00; push(0,0,0) : 27 00 00 00; push(0,0,0): 27 00 00 00; push(0,0,0) : 27 00 00 00. When reordered (for example, by the AEG), that instruction list would look like - 43 01 00 20; 2727272727272727, 0000 00 00 00 00 00 00, 00 00 00 00 00 00 00 00, 00 0000

[0218] 00 00 00 00 00. This may compress towards almost nothing. When received by the THWITRS decoder, the AED removes the pipe instruction from the stream and reassembles the data to the original 8 push instructions that are then passed to the decoder.

[0219] We also disclose an Enhanced Entropy Pipe (e.g., Pipe2, Opcode 44) that further allows for the extraction of bytes into sub-streams. This may be especially useful when there are a mix of colour instructions and other instructions ( e.g., move cursor) where there may be coherence between colour data bytes that may benefit from isolation from other data bytes. For example, assume we have a sequence of instructions that include opcode XX, YY and ZZ. The three data bytes associate with XX are $16, $25, $31 for all the XX opcodes in this example. The data bytes for all the YY opcodes are $20, $21 , $22, and those for ZZ are $80, $80, $97. For example: if initial bit stream sequence is:

[0220] XX $16, $25, $31 ; XX $16, $25, $31 ; YY $20, $21 , $22; ZZ, $80, $80, $97; XX $16, $25, $31 ; XX $16, $25, $31 ; YY $20, $21 , $22; ZZ, $80, $80, $97; XX $16, $25, $31 ; XX $16, $25, $31 ; YY $20, $21 , $22; ZZ, $80, $80, $97; XX $16, $25, $31 ; XX $16, $25, $31 ; YY $20, $21 , $22; ZZ, $80, $80, $97; the AEG may append the instruction: $44 (opcode), $01 (channel), $00 (high order number of bytes), $40 (low order number of bytes) to the front of a rearranged sequence to produce: $44, $01 , $00, $40; XX,XX,YY,ZZ, XX,XX,YY,ZZ, XX,XX,YY,ZZ, XX,XX,YY,ZZ; $16, $16, $16, $16, $16, $16, $16, $16; $25,

[0221] $25, $25, $25, $25, $25, $25, $25; $31 , $31 , $31 , $31 , $31 , $31 , $31 , $31 ; $20, $20, $20, $20; $21 , $21 , $21 , $21 ; $22, $22, $22, $22; $80, $80, $80, $80; $80, $80, $80, $80; $97, $97, $97, $97.

[0222] When received by the decoder, the AED recognises the enhanced pipe opcode and removes this instruction, it determines that there are a total of 8 XX opcodes in the sequence and that the first opcode in the sequence is also XX, therefore, the first 8 bytes ($16’s) after the sequence of opcodes [XX,XX,YY,ZZ, XX,XX,YY,ZZ, XX,XX,YY,ZZ, XX,XX,YY,ZZ] are the respective initial data byte of each XX Opcode, the next 8 bytes the second data bytes, the next 8 bytes the third data bytes. As the first YY opcode is positioned before the first ZZ opcode, the next 4 bytes are the first bytes for each YY opcode, the next 4 for the second bytes, the next 4 for the 3rd data bytes, and ZZ being the last opcode to appear in the opcode sequence is filled similarly with the remaining bytes. This method may be adapted for instructions of different length (that for opcodes greater than a byte may also be split into sub-sequences) or for a different number of data bytes. Furthermore, an opcode may be created to change the order of data bytes (e.g., the first and second byte for each opcode might be grouped together, e.g., for the preceding example, the data bytes may be arranged as $16, $25, $16, $25, $16, $25, $16, $25, $16, $25, $16, $25, $16, $25, $16, $25; $31 ,

[0223] $31 , $31 , $31 , $31 , $31 , $31 , $31 ; etc. It may be that just the opcodes and data sequences are separated (e.g., $16, $25, $31 , $16, $25, $31 , etc.). Those experienced in the art should be able to conceive a plurality of combinations to split and rearrange the bytes in an instruction stream to optimise the information for entropy encoding.

[0224] Hierarchical Adaptive Switch String (HAS String)

[0225] The disclosed Hierarchical Adaptive String can be thought of as a n instruction set of two values in its base form 0 or 1 . It may be used internally by the ASEC / ADC and by some SPE (it may be delivered to them in a push on to their stack) It may be used to change direction of any process if the encoder decides it is worthwhile. For example, a simple example may set the ADC or an SPE to check every 10 coefficients if there should be a change in process, for example a lookup table, a direction, a entropy method). The process check the HAS every 10 steps- if a zero, no change keep going drop the zero and go again. If a 1 signal to seek guidance. The”1 ” may just be default behaviour and the process then continue. A “1 ” may mean examine the next 2 bits which encodes 4 option. Thie may extend as many levels as required (and efficient for the outcome). A combination or=f the pixel map, the use of bit values in fixed pixels and the HSAS in combination with a flexible Encoder provides a powerful ecosystem. An image encoded into a bitstream may include a plurality of bits arranged to represent a plurality of targets, wherein a target may comprise an arbitrary number of bits determined by the Encoder, for example, a target may be a block of data (e.g., 8x8 transform block), a particular number of bytes or bits, or another arrangement of digitally stored information. The decoder is configured or may be configured by the bitstream to apply one or more processes or parameters to a target to facilitate reconstruction of a patch in the Worksheet. The decoder needs to be able to associate each target with the one or more things required to process said target. Furthermore, information extracted from a first target may be required to extract information from a second target, and therefore, the sequence that targets are processed may be important.

[0226] We disclose a method for dynamically optimising the processing of a set of targets, comprising the steps of: a) Generating a sequence of instructions to establish an initial arrangement of targets at a destination, and for each target in the arrangement: i. Determining one or more processing elements or parameters from a set of processing elements or parameters for use with the target; ii. Determining whether it is more advantageous to explicitly specify the determined processing elements or parameters or to leave their selection to a default or previously used configuration. b) Performing at least one of the following: i. Modifying the sequence in which the target is to be processed relative to other targets in the arrangement. ii. Maintainingthe sequence in which the target is to be processed. c) Generating a signal indicating an optimised processing configuration based on the determinations made for each target, or any modifications to the sequence in which the targets are to be processed.

[0227] We further disclose a method for processing a set of targets, comprising the steps of: a) Receiving a signal from a source indicating an optimised processing configuration. b) Determining the optimised processing configuration based on the received signal; and c) Applying the optimised processing configuration to the targets, wherein the optimised processing configuration comprises the adjusted sequence, parameters, processing element selection, or instructions for applying defaults or a previously used configuration.

[0228] We further disclose a method and system for dynamically optimising the processing of a set of initially sequenced targets at a Decoder, comprising the steps of:

[0229] • Generating instructions at an Encoder to establish an initial sequence of targets at a decoder; e.g., wherein the initial sequence is generated by a first instruction to define a first region in destination memory wherein the first region may comprise a geometric shape, such as a rectangle; and a second instruction to define a plurality of sub-regions within the first region, wherein the sub-regions may comprise geometric shapes within the first region, such as sub-rectangles contained within the first fregion.be a rectangle, said regions within said first rectangle may comprise a plurality of sub-rectangles

[0230] • Determining one or more processing elements or parameters from a set of processing elements or parameters for use with a target of said set; For example, a first mode used for the previous rectangle may provide a first result and a second mode an improved result, however, the cost of the switch may outweigh the switch.

[0231] • Determining whether it is more efficient to explicitly specify the determined processing elements or parameters or to leave their selection to a default or previously used configuration;

[0232] • Generating an optimised processing configuration based on the determinations made for each target;

[0233] • Receiving the optimised processing configuration at a decoder; and

[0234] • Applying the optimised processing configuration to the targets, wherein the optimised processing configuration comprises a first bitstring for controlling a change in a process or parameter applied to a target of said set. Said bitstring, wherein a first bit is for controlling a first target and a second bit is for controlling a second target, wherein said control is indicated by the state of the controlling bit. A second bitstring for use by the decoder for determining if one or more targets are immune to change. The second bitstring wherein said determination of immunity causes the decoderto transfer association of a bit in said first bitstream from an immune target to a non-immune target. A third bitstream for controlling a change in the behaviour of said second bitstream. Determination of a change considers before and after entropy encoding.

[0235] Macro instructions The Compiler may create a Macro that is converted by the AED back to a sequence of executable THWITRS instructions. Macro Instructions are created by the compiler with the Tie_Knot instruction that is an instruction for use by the AEC and AED and in the preferred embodiment not for use by the Engine and removed by the AED. The Macro Opcode is not seen by the Engine but converted by the AED to the sequence of engine executable instructions represented by the Macro. The macro may include any engine executable instruction (e.g., normal or extended instructions). When the Tie_Knot command is input to an AEC, the AEC typically stores the Opcode allocated by the Compiler to represent the Macro and the sequence of THWITRS instructions that the macro represents. The AEC may use this information to rearrange the operands for a Macro Instruction for improved entropy encoding (e.g., for the entropy pipe). The Tie_Knot and coupled data is transferred to the AED that also stores the Macro information enabling it to reverse entropy encoding applied by an AEC and to reconstruct the instructions represented by the Macro. The Tie_Knot may not be restricted to the disclosed four-byte format. An example embodiment may be: [Tie_Knot Opcode (one byte), Opcode for Macro (two bytes if this is an Extended Opcode), Opcode Count (one byte storing the number (n) of opcodes to include in the macro, said opcodes listed next in sequence), First Opcode in Macro (one or two bytes), Second Opcode in Macro (one or two bytes) nth Opcode in Macro. For example, a Macro to draw a Polygon may be produced by: [Tie_Knot, $EA01 (opcode for the polygon macro, allocated by the compiler), $06 (number of primary instruction opcodes in Macro), Polygon, Push, Push, Push, Push, Push], The AED will subsequently associate the sequence of opcodes with the macro- opcode $EA01 . The Polygon Macro Instruction comprises: [$EA01 (opcode), r,g,b,5 (3 bytes), x0,y0 (4 bytes), x1 ,y1 (4 bytes), x2,y2 (four bytes), x3,y3 (four bytes), x4,y4 (four bytes)].The AEC may entropy pipe this data for improved compression. The AED has access to the THWITRS ISA and can be programmed to associate the incoming operands of the Macro Opcode with the correct instructions to produce output to the engine and to reverse the entropy pipe, i.e., push_param(x0,y0), push_param(x1 ,y1 ), push_param(x2,y2), push_param(x3,y3), push_param(x4,y4), polygon(r,g,b, 5). The example Macro Polygon draw as depicted is not particularly improved over a sequence of primary instructions to obtain the same outcome, however, the creation of a macro may be made more flexible. For an instruction that includes a potentially variable number of parameters such as polygon (r,g,b,5), instead of creating a different macro for each polygon of a different number of sides, [Tie_Knot, $EA02 (opcode for the polygon macro, allocated by the compiler), Polygon Opcode, NOP Opcode], may create a macro that is adaptable to a polygon of a variable number of sides. The resultant macro instruction might be: [$EA02 (opcode), r,g,b,n (3 bytes, n = number of sides), x0,y0 (4 bytes), xn, yn (4 bytes)]. The

[0236] AED outputs the appropriate sequence of primary push instructions and a polygon draw instruction for transfer to the Engine. The primary polygon draw instruction used in the aforementioned examples uses an absolute x and y value within a layer. An alternative polygon draw instruction (say, Polygon_T) may provide co-ordinates relative to the first polygon location using signed values. Another example, Polygon_S may use co-ordinates relative to the previous coordinate (e.g., delta xO and delta yO may be stored in a single byte). A macro may comprise multiple drawing operations (e.g., a triangle drawn into a circle or rectangle). The Polygon instructions disclosed use 12-bit rgb. For a larger colour depth or to permit the drawing of a particular plane of a layer, Polygon_R may draw to a red plane, Polygon_G to a green plane, Polygon_B to a blue plane or Polygon_Alpha to an alpha plane. For example, [Polygon_R (1 byte), (red (2 bytes), n (number of sides, 1 byte)]. A Macro may be killed with the Kill_Macro instruction: [Kill_Macro, Macro Opcode (e.g., $EA02)]. All macros are typically killed when the Engine processes a new Primary Stream, however, any default state may be set to do this (in part at least). It will be appreciated that the exemplary methods disclosed above may be readily adapted by those experienced in the art to adapt other disclosed primary instructions or to provide variations on the creation of macros.

[0237] Ephemeral Active Encoded Stream (EAES) and Security:

[0238] For many streaming applications, the inherent ephemeral nature of the data stream means that content is processed and immediately consumed. For scenarios involving protected or encrypted content within an AES, a flag may be incorporated to signal that the stream, or a specific region within it, is encrypted. This encryption flag, potentially nested or supplemented by additional flags within encrypted segments, can serve as a directive to the decoder. If the decoding environment is not deemed secure, the decoder may be instructed to halt processing of the encrypted content. Furthermore, for decoded content intended solely for immediate playback (e.g., streaming video), specific flags can be set to prohibit any storage of the unencrypted data, thereby maintaining content integrity and control. This mechanism is particularly relevant when considering the provision of encrypted snippets of code for building images from scratch, ensuring sensitive IP remains protected from unauthorised retention or exposure in unsecure environments.

[0239] System Instruction Set and Processes

[0240] The instruction set is a core component of the system, stored on non-transient computer-readable media. These instructions might, for example, constitute an AES, reference information (for a decoder or encoder), or be implemented as part of a processor.

[0241] This specification details a preferred instruction set with a fixed length of four bytes. While this length suits the use of current GPUs in decoder implementations, it's is not intended to be limiting. Typically, the Opcode is one byte, with the remaining three bytes allocated for the operand. A specific opcode can signal that it extends into one or more bytes of the operand, effectively expanding the potential instruction set beyond 256. Instructions aren't limited to 32 bits or fixed-length formats; they can incorporate variablelength instructions or other configurations, offering design and execution flexibility. The system can also be configured to use instructions where both opcode and operand information reside within a single byte.

[0242] The Reference Instruction Set provides an example of instructions for encoding an image into a bitstream. When executed by a Processor, this set reconstructs an image within the Worksheet. The reference set offers templates for adapting existing instructions or designing new ones for the system.

[0243] Instructions operate on attributes of pixels or patches of pixels in the Worksheet. These pixels or patches are typically defined by their location relative to a current reference origin of the Worksheet. By default, this origin is (0, 0) at the top-left corner of a 2D Pixel Space in the disclosed example embodiments. Multiple reference origins can exist; for instance, when copyinga rectangle, the source might use the main reference origin while the destination refers to a Destination Reference Origin.

[0244] Cursor and Origin Management

[0245] Typically, unless an instruction (usually an IPE) includes position information within its parameters, the instruction will commence operation at the current position of the drawing cursor. The system allows for positioning the cursor anywhere in the Worksheet using one or more commands. Colour associated with a particular instruction is typically set by the instruction and only applies for the instruction. An origin can be altered by an instruction. While a pixel or patch's location relative to an origin might be included in an instruction for altering a pixel attribute at or relative to that origin, an instruction to alter an attribute usually references pixels at, or relative to, the current location of a drawing cursor at an x,y coordinate in the pixel space. The cursor location is typically set by a specific instruction (e.g., pos (x,y)) or automatically incremented (or otherwise set) by a previous instruction. The x and y values are generally offsets from the current Worksheet Reference Origin.

[0246] We also describe instructions to set the origin to a new location using a single offset instruction, which increments or decrements the current origin value by a specified offset. These offset values can be either integer or signed and may require less than 24 bits of operand for smaller adjustments. Similarly, during image reconstruction, many operations may occur in close proximity. Relocating a drawing cursor using 24-bit X and Y coordinates, or even 16-bit integer values, might be inefficient. Although typically stored internally as a 24-bit value, a lesser number of bits in instructions can suffice.

[0247] Some instructions reference the origin using 'little x' and Tittle y' as offsets from the reference origin to locate a patch for a process. In this embodiment, "x" and "y" are 12-bit integers. Similar to setting a reference origin, a larger range can be coded by creating two instructions: one for "x" and another for "y." Alternatively, the bit size of the instruction could be increased. Additionally, 'x' or 'y' can be a signed value that, for a smaller range, may be represented by less than three bytes of operands.

[0248] We include instructions that can define the size of an object (e.g., a rectangle) by a Tittle x' or 'y' dimension. To accommodate a larger range, splitting an instruction into two (x and y) or increasing the number of bits in an instruction can be implemented. A similar method applies to instructions changing a pixel's attribute. Example instructions for reduced color depth are disclosed. For increased color depth, an instruction can be split into multiple instructions (e.g., a) one for each of red, green, and blue, or b) one for red and half the green, and another for the remaining half of green plus blue). Fixed-Length Instructions and Extended Opcodes

[0249] The preferred 32-bit fixed-length instructions also offer an efficient structure for the Adaptive Entropy Compressor (AEG) (or another entropy encoder) to further compress an image previously compressed into an AES. The instruction set includes instructions with one byte for the opcode and three bytes for operands: [OPCODE, BYTE, BYTE, BYTE], This allows for a stream of instructions on consistent 32-bit boundaries, with the opcode in a consistent byte location. The Opcode is preferably located in the Most Significant Byte (MSB) of the 32-bit word (i.e., the two most significant bits of the long word address = 11), with the Operands running right to left.

[0250] A fixed one-byte opcode would limit the Instruction Set Architecture (ISA) to 256 instructions. However, the opcode can extend into one or more bits of one or more operands to expand the number of instructions. These are referred to as Extended Instructions. A particular value in the first 8 bits (base opcode) indicates an Extended Instruction, accountingfor one of the 256 available opcodes in the ISA. One or more additional base codes can be used to form Extended Instructions, with at least (typically) the second byte further defining the Opcode. The remaining 16 bits in an instruction allow for 0, 8, or 16 bits of Operands, depending on the number of bytes used for additional Opcodes. Allowance is also made for a byte to include some of its bits for an Opcode and the remainder for an Operand.

[0251] Simple Push and Integrated Push Extended (IPE) Instructions

[0252] The preferred ISA format of 4 bytes inherently limits the amount of data that can be supplied as an operand for an instruction's opcode. Nominally, this is 3 bytes (and even less for an extended instruction). To circumvent this restriction while maintaining the 4-byte instruction format, a Simple Push method is disclosed, wherein an arbitrary number of operands may be pushed onto a stack, followed by an instruction that directs processing of the stacked information. The last pushed data is nominally at the top of the stack (LIFO). When the VP encounters an instruction that uses the pushed data, execution of that instruction pulls the data from the stack.

[0253] The polygon instruction is an example of a Simple Push instruction that illustrates how to fill an arbitrary region of the worksheet with a color, significantly reducing the bandwidth required to adjust the pixels in that region to an acceptable state. An irregular polygon may enclose a region containing many thousands of pixels while only consuming a handful of instructions. To draw an arbitrary polygon of 6 sides and an RGB color, the sequence would be: push_param(x4, y4), push_param(x3, y3), push_param(x2, y2), push_param(x1 , y1), push_param(xO, yO), polygon(r, g, b, 5)

[0254] The current position of the drawing cursor is the starting location of the polygon. When polygon(r, g, b, 5) is executed, it pulls the parameters previously stacked and commences drawing a line in the specified RGB color, starting at the cursor and proceeding through each stacked coordinate in order. It then fills the resulting polygon. In embodiments with a plurality of VPs configured for parallel processing, each VP preferably has its own stack.

[0255] More complex drawing functions — such as Bezier curves, transforms, fonts, 2D / 3D modelling, particle effects, spatial and transform prediction, complex motion prediction, and pass-through operations (e.g., H.264 on the Host computer) are usually directed to a Special Purpose Engine (SPE) that is a decoder component, or to a Host Pixel Generator (HPE) that is a host-managed resource. Each SPE typically has its own stack.

[0256] An Integrated Push Extended (IPE) instruction is operable on a particular SPE. When encountered by a VP, the instruction is transferred to the SPE designated to process it. IPEs are usually extended instructions that utilise one or more operand fields in the four-byte instruction architecture as part of the opcode. They expect the stack associated with the target SPE to be preloaded with all required data — which may include operands or additional opcodes. Execution begins by pulling data from the top of the stack and continues downward through the stack as needed to complete the processing of the instruction and any additional data or instructions embedded therein.

[0257] The encoder is responsible for ordering and delivering the data to the SPE stack in a timely and coherent manner. This is achieved by sending the data as a sequence of push instructions in the AES, each of which is directed to the appropriate SPE stack. To distinguish between a push directed to the local VP stack and a push directed to a particular SPE stack, the push is preceded by a push_stack pointer instruction. This pointer specifies the target stack (SPE or Host) and the number of subsequent push instructions that are to be redirected.

[0258] In some embodiments, an IPE instruction operable at an SPE may include a mode flag or control bit that instructs the SPE to retain the associated parameters or data structure for potential reuse. This stored data may be tagged with an identifier (ID) assigned by the encoder and optionally structured according to known conventions expected by the SPE. The encoder may subsequently issue a drawing instruction referencing the tag ID, thereby reusing the previously supplied parameters without retransmission. This reuse may be partial or complete and may include delta updates to specific fields by additional push instructions. The SPE may retain such structures for as long as resources permit, optionally discarding older entries under encoder direction or by internal policy. This mechanism is entirely under encoder control and does not alter the standard instruction execution flow.

[0259] Extending Color and Resolution with IPEs:

[0260] Example methods for implementing increased color depth, resolution, or other parameters (in particular, depth) in the instruction set can leverage an Integrated Push Extended Instruction, which can accommodate many parameters. For instance, to extend the color to 16 bits per channel (48 bits instead of 24), an alternate extended opcode could be used. This opcode would include the high 8 bits of R, G, and B, and be preceded by a push(RL,GL,BL) instruction which places the lower 8 bits of each channel onto the stack. The new 48-bit color extended instruction would then retrieve these low bytes from the push stack. This provides a flexible alternative to increasing the fixed size of the four-byte instructions.

[0261] Stack Arrangements and Encoder-Controlled Data Flow

[0262] The system employs a data stack, typically residingwithin the GPU's high-speed VRAM, to store parameters for processing. The Virtual Machine (VP) and Special Purpose Engines (SPEs) are preferably implemented within the GPU, utilising its shader pipeline and dedicated hardware units. In an example embodiment, the VP has its own dedicated stack, and each SPE also has its own dedicated stack. Each stack manages its own internal push and pull pointers as data is placed onto or retrieved from it. The VP consistently pulls data from its own dedicated stack when executing an instruction that requires stack parameters. The stack itself can be configured in two primary arrangements:

[0263] 4-Byte Aligned: Data is stored and accessed in fixed 4-byte boundaries, aligning with GPU memory architectures for efficient hardware access.

[0264] Byte-Stream: The stack operates as a continuous stream of bytes for maximum data density, which may involve more complex byte-level extraction

[0265] The encoder is the central controller of this system, directing a fundamentally "stateless" decoder. The encoder typically issues a command (e.g., a Set_Stack instruction) that tells the VP which stack to push data. This dictates whether subsequent push operations will place their data onto the VP's own stack or direct it to the dedicated stack of a specific SPE, continuing until a new Set_Stack command is encountered.

[0266] THWITRS Reference Instruction Set

[0267] 1) Clr (r,g,b) - Clears the whole Worksheet to the colour rgb.

[0268] 2) set_tick (n) - Sets the "tick" counter to a 24-bit value. The "player" may read this and use it as an index into a dictionary or instruction sections.

[0269] 3) set_frame (n) - Sets the "frame" counter. This may force a jump in play sequence.

[0270] 4) set_noise (d) - Sets the noise threshold to determine the probability of noise being present.

[0271] 5) set_markov (n) - Sets the probability of a markov jump to branch via "tick" count.

[0272] 6) jmp_markov (index) - Sets the "tick" counter to index if a random number is < the markov value.

[0273] 7) qual_reset () - Sets the reliability of rendering to default that can set the reliability of rendering to simulate equipment performance (game technology).

[0274] 8) rgb_lo (r,g,b) - Sets the low limit of r g b channels for noise effects (e.g., colour snow).

[0275] 9) rgb_hi (r,g,b) - Sets the high limit of r g b channels for noise effects.

[0276] 10) lum_hilo (hi,lo) - Sets the luminance high-low limits for noise effects (e.g., mono snow).

[0277] 11 ) rgb_ti nt (r,g,b) - Sets the rgb scalars for tinting mono colour draw. 12) Publish () - Copies ViewPort(1) to Render Image and resizes the image if necessary to fit the render image size with Alpha. ViewPort (1) is usually the main VP for a frame and may have had patches or layers collapsed within the Worksheet. The main advantage is it does not use any operands, unlike using overlay(1 ). The publishjf () is a conditional version dependent on a signal from the player.

[0278] 13) update() - Copies Viewport(O) with bilinear scaling to render image, however, it adjusts the brightness: R_render (adjusted value for red pixel in render image) = R_render (red attribute prior to backlight)* R_backlight (value of red attribute in backlight VP) / 128 and similar for Green and Blue.

[0279] 14) flush_render () - This signals the display manager (or equivalent) to copy the render image to an Application Target, said signal includes the frame number of the render image (for example, for collapse with another with Render Image with the same frame number at the Application Target). The display manager may signal the Engine the Render Image is cleared for a new frame. Flush_render_if (n) is a conditional version dependent on a signal from the player.

[0280] 15) push (x,y) push (w,h) extend_overlay_init (n) - Integrated Push Extended (IPE). Pushes the offsets for the top left corner of the ViewPort (VP) to locate top left corner of viewport to X+x, Y+y. Then pushes width and height of VP, then an extended instruction to setup the VP and identify it by the value of "n". This defines a rectangular patch of pixels defining a viewport.

[0281] 16) Pushl (w,h) - Virtual VP size.

[0282] 17) Push2 (x,y) - Rect Patch TLC in WS.

[0283] 18) Push3 (w,h) - Patch Size.

[0284] 19) Push4 (x,y) - TLC Patch offset TLC Virt. VP.

[0285] 20) extend_overlay1_init(n) - IPE Instruction. Whereas extend_overlay_init expects that the ViewPort to be copied is represented in the worksheet as a patch of pixels, many of which may be transparent if the contained object is small, this instruction creates a virtual VP of the size defined by the first push, and copies this to the render image by placing the actual object in the Worksheet defined by the second and third push and located relative to the top left corner of the Virtual VP as defined by the 4th push. This may save using a large area of the Worksheet to render a relatively smaller patch.

[0286] 21) Overlay (n) - Copies Viewport(n) to Render Image with alpha mix and bilinear scaling. Note VP (0) sent to the render image by overlay(O) is a backlight layer, that is scaled, but blended differently to other VP's as described in the specification. Overlayjf (n) is a conditional version dependent on a signalfrom the player.

[0287] 22) vp_pos (x,y ) - set the top left corner of the viewports ) to X+x, Y+y, where x and y are positive integers. VP(1) is usually the main VP and may be the only VP, requiring two instead of three instructions to define.

[0288] 23) vp_size (x,y) - set the VP(1 ) W,H to x,y.

[0289] 24) vp_clr (r,g,b, alpha) - 16 bit colour with alpha applied to VP(1 ) rectangle.

[0290] 25) rect_565a (r,g,b, alpha) - 16 bit colour fill of rectangle in Worksheet with 8 bit alpha specified. Used for stencil, blend and cut and paste typically set as 0,0, 0,0 and then draw inside it to make a stencil. The 0000 pixels will not be copied over destination.

[0291] 26) rnd_blk_mono (x,y) - draws random mono pixels in thex,y rect at current cursor position, with probability of a draw set by set_noise(d) level this gives a "snow" effect or image static or corruption effect.

[0292] 27) rnd_blk_col (x,y) - draws random colour pixels in the x,y rect at current cursor position - otherwise same as previous instruction.

[0293] 28) qual_set (d) - sets the "quality" of the decoder so a variable amount of noise can be simulated in the rendered image example - apply this to a block copy so each pixel is only copied if rand()<quality (game technology applications).

[0294] 29) rnd_min_XY (x,y) - sets the top-left of a region that random drawing or noise can operate on.

[0295] 30) rnd_max_XY (x,y) - sets the bottom-right of a region that random drawing or noise can operate on.

[0296] 31) rnd_grain_XY (x,y) - sets the step size of random effect in x and y directions (mainly used for random block fills on aligned boundaries).

[0297] 32) block_copy (alpha) - block copy from src rect to dst rect with alpha specified, alpha is normally 1 , but a fractional alpha can do a blend.

[0298] 33) pos (x,y) - Places the main drawing cursor at a pixel location (X+x, Y+y), where X and Y are the coordinates of the current reference origin. Parameters x and y are positive integers. An embodiment may use x and y as signed numbers (e.g., [pos_signed]. Another embodiment may only use the first operand (e.g., [pos_tiny] with MS nibble of the second byte of the instruction as signed x and the least significant nibble, signed y. The unused bytes are compressed to zero in subsequent compression of the bitstream. There are several obvious variations for this (e.g. unsigned tiny parameters, or two bytes of operands for 8 bit parameters (signed or positive). 34) dst (x,y) - Precedes line draw commands, setting the location for the end of the line (X+x, Y+y). This does not use the destination reference origin (but an instruction may be configured that does). It also auto updates the pos x,y, by copying the x,y parameters of the dst instruction to pos (x,y), facilitating chained lines.

[0299] 35) set_X (Xpos, frac) - Moving regions of image in subsequent frames may requires the destination to be not located an integer number of pixels. This allows smooth scrolling, as the eye can detect a pixel move. The VP we use internally specifies position on the Worksheet as a 24 bit number for both X and Y. This instruction is for use with a Worksheet (or other) pixel array of up to 64k pixels wide and 64k pixels high with a default origin of 0,0 (x=0, y=0) at the top left corner of the array. For the present example embodiments, a frame represented in a worksheet may be represented as a region of pixels within the worksheet. A layer is also represented as a region of pixels in a worksheet. As such, the same instructions may work on pixels for a frame, pixels for a layer or pixels outside these domains. Each pixel location is stored as a 24 bit value for the x co-ordinate and a 24 bit value for the y coordinate. The most significant (MS) 16 bits are an integer value for the pixel location in the array and the least significant 8 bits represent up to 256 subpixel location values. Instructions that do not require a subpixel value may default to zero. For the set_X instruction, the two most significant bytes (Xpos) of the operands provide a 16 bit integer value for the X position and the third byte (frac) the sub pixel value. The value of x in an instruction will reference as a positive offset to the [Xpos, frac] value unless it is a relative instruction that will reference as a signed number. If the value of x is an integer and the frac value is non-zero, said instruction will reference a subpixel value. Example solutions for a larger worksheet may include two instructions to set an X value and two to set a Y value or increase the number of bytes in an instruction.

[0300] 36) set_Y (Ypos,frac) - This is the mating instruction for the set_X instruction that sets the Y value for an origin in the Worksheet.

[0301] 37) set_d_X (Xpos, frac) - A plurality of instructions use an x,y coordinate that is a reference from a current set origin (e.g., if the origin is set to )10,10), a pos x,y, where x= 5, y =5 would place the drawing cursor at 15,15 relative to the origin of the worksheet (0,0). However, for some instructions (e.g. copy a source rectangle to a destination rectangle) in a large worksheet, the destination may not be able to reference the set origin with values within the x,y range (4096 for each) concurrently with the source referencing the set origin. [set_d_X] sets an origin as described for set_X except that it is an origin that may be used by instructions referencing a destination in the worksheet.

[0302] 38) set_d_Y (Ypos,frac) - Similar to set_d_X for Y coordinate destination origin.

[0303] 39) set_special_X (Xpos, frac) - Similar to set_d_X except that it provides a reference origin for Specialist Processors (e.g., DCTTransform) to place a result.

[0304] 40) set_special_Y (Ypos,frac) - Similar to set_d_Y except that it provides a reference origin for Specialist Processors (e.g., DCT Transform) to place a result. By reducing the bits for the X,Y parameters for the set instructions, the additional bits may be used to create an Extended Instruction, freeing up 8 bit opcodes.

[0305] 41) set_origin (x,y ) - Sets a new reference origin, wherein the x and y values are positive offsets from the present reference origin (e.g., as set by set_X and set_Y default), that sets the reference origin to a new value. For example, if the current origin is (12087, 5063), set_origin with X=15 and y=20 changes the reference origin to (13002, 5083). Recursive use of this instruction may be used to locate a reference origin at any location in a worksheet of any size.

[0306] 42) set_d_origin ( x,y) - An alternative (or addition) may be the use of signed numbers for x and y parameters adjust_origin(x,y) resets the origin + / - 128 in x and or y. The 3rd operand is zero.

[0307] 43) set_special_origin (x,y) - For a worksheet of 4096 x4096 or less, this instruction may replace the set_X and set_Y instructions for changing the reference origin of a worksheet. A similar instruction set_d_origin (absolute or signed) may be used to modify the destination origin or a set_special_origin for the Specialist Processor reference origin. When [Activate_Special), an extended instruction to activate a specialist processor, the targeted special processor is instructed to place the top left hand corner of a block of results in the worksheet at the special origin reference location at the time the instruction is executed.

[0308] 44) src_pos (x,y) - source rectangle position - used for block copies, top left corner of rectangle is located at X+x, Y+y, where x and y are positive integers. Although x and y are 12 bit integers, they are each stored in the system as 24 bit numbers, 16 bit integer, 8 bits fractional. Alternate instructions may include, for example, signed parameters.

[0309] 45) src_posX - Stores 24 bit X value to the src_pos (x, y) register.

[0310] 46) src_posY - Stores 24 bit Y value to the src_pos (x, y) register. 47) src_size (x,y) - source rectangle size.

[0311] 48) dst_pos (x,y) - destination rectangle position - used for block copies, top left corner of rectangle is located at Xd+x, Yd+y, where x and y are positive integers referencing the destination reference origin. Although x and y are 12 bit integers, they are each stored in the system as 24 bit numbers, 16 bit integer, 8 bits fractional. Alternate instructions may include, for example, signed parameters. Execution of the draw line instruction may be configured to auto update the src_pos with the current dst_pos, allowing chaining of lines.

[0312] 49) dst_posX - Stores 24 bit X value to the dst_pos (x, y) register.

[0313] 50) dst_posY - Stores 24 bit Y value to the dst_pos (x, y) register.

[0314] 51) dst_size (x,y) - destination rectangle size. 52) rect_XY (x,y) - set default rectangle size.

[0315] 53) block_X (x) - set block (square) size. It should be noted that instructions that skip or run typically auto increment to the next available location. Usually, the x coordinate for horizontal operations and the y for vertical operations. This is flexible and obvious alternatives may be constructed. E.g., colour space of LSB may be sacrificed, spare bits used, a new instruction created. Other instructions may also auto increment, or an alternative instruction that does.

[0316] 54) circle_R (r) - set radius size for circle draw.

[0317] 55) pix_888 (r,g,b) - 24 bit pixel at current drawing cursor position (pos x,y) position (autoincrement cursor to adjacent pixel). Maybe auto increment x or y. Alternatively create two instructions.

[0318] 56) pix_565 (r,g,b, alpha) - 16 bit pixel (16 bit reduced colour space) plus alpha.

[0319] 57) pix_run (r,g,b,run) - 16 bit pixels with a run length up to 255 (horizontal line). Auto increment x parameter of pos x,y by run, or create another instruction.

[0320] 58) pix_run_v (r,g,b, run) - 16 bit pixels with a run length up to 255 (vertical line).

[0321] 59) pix_skip (r,g,b,skip) - 16 bit pixel drawn after skipping <255 pixels - skip over pixels that are correct colour (horizontal).

[0322] 60) pix_skip_v (r,g,b,skip) - 16 bit pixel drawn after skipping <255 pixels - skip over pixels that are correct colour (vertical).

[0323] 61) pix_mask (r,g,b,mask) - 16 bit pixel in up to 8 positions set by mask byte(horizontal).

[0324] 62) pix_mask_v (r,g,b,mask) - 16 bit pixel in up to 8 positions set by mask byte (vertical).

[0325] 63) pix_skip_run (r,g,b, skip, run) - 16 bit pixel after skip <16 pixels, then <16 fill (horizontal).

[0326] 64) pix_skip_run_v (r,g,b, skip, run) - 16 bit pixel after skip <16 pixels, then <16 fill (vertical).

[0327] 65) pix_skip_delta_h (dr ,dg, db, skip) - Skip up to 512 horizontal pxs, then change pixel + / -16 levels for r, g ,b.

[0328] 66) pix_skip_delta_v (dr ,dg, db, skip) - Skip up to 512 vertical pixels, then change pixel + / - 16 levels for r, g ,b.

[0329] 67) set_pixel_Jump16 (dx, dy, r, g, b) - Jump and set for a 16 x 16 grid. Dx and dy are 4-bit values in the range + / -8, enabling scattered pixel adjustments, facilitating corrections to sporadically occurring "bad" pixels without repeatedly sending repositioning instructions. The erroneous pixels, typically scattered randomly, may be navigated using short jumps within a 16 x 16 region from the current location.

[0330] 68) set_lumjump256 (dx, dy, lum) - Luminance based jump and set for a 256 x 256 grid, dx and dy are 8-bit values in the range = / - 128, facilitating scattered luminance corrections.

[0331] 69) rect_line_888 (r,g,b) - 24 bit colour rectangle outline.

[0332] 70) rect_line_565 (r,g,b, thick) - 16 bit colour rectangle outline with line thickness.

[0333] 71 ) block_888 (r,g,b) - 24 bit colour default size square block (filled).

[0334] 72) block_var (r,g,b,x) - 16 bit colour <256 size square block (filled).

[0335] 73) rect_888 (r,g,b) - 24 bit colour rectangle (filled). 74) line_888 (r,g,b) - 24 bit colour line.

[0336] 75) line_565 (r,g,b, width) - 16 bit colour line variable width. 76) circle_888 (r,g,b) - 24 bit colour circle (filled).

[0337] 77) circle_565 (r,g,b, radius) - 16 bit colour circle (filled) radius <256.

[0338] 78) circle_565_line (r,g,b, radius) - 16 bit colour circle (outline) radius <256.

[0339] 79) circle_888_line (r,g,b) - 24 bit colour circle (outline).

[0340] 80) block_dbl_444 (r1 ,g1 ,b1 ,r2,g2,b2) - 12 bit colour space pair draws 2 blocks side by side - used to increase compression at the expense of reduced colour space.

[0341] 81 ) pix_dbl_444 (r1 ,g1 ,b1 ,r2,g2,b2) - 12 bit colour space pair draws 2 pixels side by side.

[0342] 82) pix_triple_luminence (10,11 ,12) - set the luminance of the next three pixels L0,L1 ,L2 without altering u,v. Auto increment the y parameter of the drawing cursor.

[0343] 83) pix_triple_UV (uv,uv,uv) - set the UV 4,4 of the next three pixels and auto increments the y parameter of the drawing cursor. Each U and V value is a delta sent as a signed 4 bit integer (i.e., the value is added to the present u,v value of the pixel).

[0344] 84) delta Y (dy,dx,d0,d1 ,d2,d3) - This instruction modifies the luminance value of four sequential horizontal pixels ( dO, d1 , d2, d3) using a 4 bit signed integer for each pixel. By ignoring the LSB of the luminance value, the instruction may change luminance + / - 16. dy and dx are also 4 bit signed integers and after each instruction, the y value of pos x,y is auto incremented by one plus the value of dy (i.e., if dy =0, the next instruction would apply to the next row of pixel immediately underneath, whereas x does not auto increment and dx is added to the current x parameter of pos x,y. This instruction is versatile, in that it can process vertical columns of pixels (4 pixels wide) or it may skip and jump to do random fixes. For example, to correct a vertical strip of 16 rows (4 bits wide), dx and dy are left at zero in 16 sequential instructions. To change a row of pixels, dy= -1 and dx=4. By changing dy, dx values, the path of operation may be made arbitrary. If more than + / - 16 is required, set dy=-1 and dx=0 and repeat instruction with new values for dO, d1 , d2, d3 as required. This instruction is also amenable to efficient secondary compression (e.g., by the THWITRS Adaptive Entropy Compressor). Another similar instruction is readily constructed (e.g., Delta X, an auto incrementing (by 4) 'x' value. Another instruction may change the value of four pixels of r or g or b. There are many variations.

[0345] 85) blend_line_565_h (run, r,g,b) - from current pixel interpolate over next (run) pixels to new colour of r,g,b.

[0346] 86) blend_line_565_v (run, r,g,b) - same but in vertical axis.

[0347] 87) blend_line_delta_h (run, dr,dg,db) - from current pixel interpolate over next <512(run) pixels to new colour of r+dr,g+dg,b+db.

[0348] 88) blend_line_delta_v (run, dr,dg,db) - same but in vertical axis delta colours are + / - 16 levels.

[0349] 89) push_colour (r,g,b) - push colour (rgb) onto colour stack for subsequent draw operations.

[0350] 90) blend_line_888_h (run) - from current pixel interpolate over next (run) pixels to previously stored colour of r,g,b.

[0351] 91) blend_line_888_v (run) - same but in vertical axis.

[0352] 92) Bokeh (x,y) - Using the default rectangle size, its top left corner at X+x, Y+y, it performs a bilinear blend of four colours (one for each corner) previously pushed onto the colour stack.

[0353] 93) push_param (a,b,c) - push 3 bytes of parameters on parameter stack for subsequent draw operations.

[0354] 94) draw_dct ( x,y) - at x,y using default block size, reconstruct a pixel block using parameters (may have variations for pixel attributes, transform coefficients, residual) pushed onto stack.

[0355] 95) polygon (r,g,b, n) - n (x,y) points are previously pushed on the param stack and a filled polygon rgb is drawn.

[0356] 96) Push (x1 ,y1) Push (w1 ,h1) Push (x2,y2) Push w2, h2) Push (Alpha, RotateX, Rotate Y, Rotate Z) Distort_Copy OR Distort_Copy_Shadow - An IPE Instruction. For an object composited on a transparent rectangle, the object may be scaled and or rotated along any of the three axes with alpha applied using the distort_copy instruction. The distort_copy_shadow is similar; however, it makes the objects pixels black with alpha. The reference object rectangle TLC (top left corner) is at x1 ,y1 with a size defined by w1 , hl . This is copies with scaling to a target transparent rectangle with TLC at x2, y2, with a size w2, h2. The target rectangle is rotated along the three axes by the amount in Rotate X, Rotate Y, and Rotate Z. Alpha is applied to the object.

[0357] 97) Push (rgb).1 through Push (rgb).n, Push (x, y), Push (w,h), Push (number of pixels, skip x, skip y), Block_copy_internal_skip (Rs, Gs, Bs, Ro, Go, Bo) - This instruction and variations explicit or obvious to those of ordinary skill in the art, transfer a block of arbitrary size (within the limits of the instruction) to an arbitrary location in the Worksheet (that may require a prior instruction to set the reference origin). The (x,y) is the offset from the reference origin for the top left pixel of the block, (w,h) width and height of the block. The attribute bits for the pixels in the rectangle defined by instructions c) and d) are usually cleared to zeroes (although other values may be applied) before this instruction. They may also be made transparent. This may vary depending on whether or not all R,G,B values are to be altered. This instruction may be invoked multiple times with different parameters and the dr to zero instruction is usually only executed once (before the use of the instruction). The instruction may be configured to skip pixels in the x or y direction and or fill particular sequences of bits in each pixel attribute with data. The instruction sequentially alters pixels in the x direction, skipping the (skip x) value between pixels until the next pixel would be outside the defined rectangle. If x=0 no pixels are skipped in the row. It then resets x and shifts down the number of rows in (skip y) repeating the process . If y=0, no rows are skipped. This may be considered a perforated rectangle (unless fully populated). The (number of pixels), is the number of push (rgb) on the stack, the combination of all the pushed operands forms one long synthetic bitstring, with the colour attribute and depth for the pixels defined by the operands of instruction f). Instruction f) will sequentially pull bits from the synthetic string and place them in pixel attributes as determined by the Rs, Gs, Bs, Ro, Go, Bo. As the colour value bitstring is processed, Rs is the number of red bits to remove (00= 4 bits, 01=8 bits, 10= 12 bits 11=16 bits) and place in the next red pixel attribute. For smaller colour depths of the final image, these values may be changed (e.g., 00= 2, 01= 4, 10=6, 11 =8). The same process is applied for Gs and Bs. Ro is the offset from the most significant red bit in a red pixel attribute to place the value removed from the colour value bitstring (for example, 00= no offset, 01 = 4 bits, 10= 8 bits, 11 =12 bits). The remaining least significant bits in a colour attribute are set to zero. As a non-zero value is applied to a pixel it may be made opaque if transparent. A perforated rectangle with truncated pixel attributes is referenced as an incomplete perforated rectangle. Although described for a rectangle, a similar process may be applied to other geometric shapes. This instruction provides a flexible means of progressively building up a pixel value and or resolution by repeating the instruction with different parameters to expand pixel attribute or fill previously skipped pixels. One use of this may be to encode a single AES that may be made to accommodate a plurality of destinations of a diverse capability. For a reduced bandwidth, the decoder downloads within imposed limitations and outputs a picture accordingly. A device with a lower resolution takes the amount of information that it requires. Should bandwidth vary, the system can reestablish a better picture at the next GOP or Ramp On.

[0358] 98) Push (x,y), Push (w,h), Block_lnternal_lnterpolate (algo) - If required, the Block_lnternal_lnterpolate (algorithm) IPE will use the algorithm specified in (algo) to interpolate empty pixels with values from surrounding pixels within the rectangle defined by x,y, w,h.

[0359] 99) Push (x0,y0) Push (wO, hO) Push (x1 , y1) Push (w1 , hi) Push (skip x, skip y) Build_Perf_Rect (Rs ,Gs, Bs, Ro, Go ,Bo) - A patch that may have been reconstructed by any THWITRS method (including a Transform) may be encompassed by a source rectangle with TLC of x0,y0 and size wO, hO . For example, to expand the image and leave vacant locations for population by another method. The pixel attribute values of the patch may be used to populate a perforated rectangle (target) with TLC x1 , y1 and size w1 , hi , Build_Perf_Rect (Rs ,Gs, Bs, Ro, Go ,Bo) The push sequence is usually preceded by an instruction to set the target rectangle (TLC at x1 ,y1 bits offset from the MSB) to black + / - transparent). The instruction takes Rs ( e.g., 00= 4 bits, 01=8 bits, 10= 12 bits 11=16 bits) bits from the most significant bits for the red attribute of the first pixel in the first row of the source rectangle, and copies these to the red attribute of the first pixel in the first row of the target an offset from the most significant bit of this attribute by the number Ro (e.g., e.g., 00= 4 bits, 01=8 bits, 10= 12 bits 11 =16 bits) bits. For Ro=-0, the bits are placed in the most significant 4 bits. Trailing bits are usually set to zero. Likewise for green and blue. The same again for the next pixel in the first row of the source copied to the next pixel in the row at the target after allowing for skip x until the target row is filed. The process is repeated for the next row in the source that is targeted to the next row after allowing for skip y. Skipped pixels may be filled from another source image or using Block_copy_internal_skip (Rs, Gs, Bs, Ro, Go, Bo), or another THWITRS instruction, or left at default colour). Block_lnternal_lnterpolate (algorithm) may be used to interpolate residual pixels.

[0360] 100) make_mask(flg,x1 ,y1) - IPE Mask Instruction. This may be used to fill a bounded shape in the worksheet. It may be multilobed (e.g., figure of 8 shape). The outline of the shape is drawn to create a mask. The first step is to draw a rectangle in the WS big enough to accommodate the shape, the rectangle (including outline) is populated with black pixels set to transparent. This is referenced by TLC (x0,y0) and size (w0,h0). An outline of the shape is drawn onto this rectangle. It may be any colour other than black ($000000) and may have transparency subject to alpha > $00. The make_mask(flag1 , x1 ,y1) instruction converts all pixels in the area shared with the pixel at (x1 ,y1 ) that are bounded by a colour > $000000 and alpha >$00 to opaque black (i.e. the alpha value is converted to $FF). flag1= one bit, if zero the outline is left untouched, if=1 the outline is black opaque. X1 =11 bits, y1 =12 bits. If there are plural defined regions, the make_mask(flag1 , x1 ,y1) is executed for each area, with a value for x1 ,y1 that lies inside the region. Flagl is usually only set for the last use of make_mask and only if the outline is to blend into the enclosed pixels. This creates the mask. A rectangle the size of the mask rectangle may be selected at any location in the worksheet and the RGB values copied to the mask rectangle. The alpha pixels in the mask remain transparent with the black pixels changed to the corresponding value in the source rectangle. A larger or smaller rectangle may be used with a bilinear copy. This does not permit alpha to be copied from the source however, an alternative copy may copy RGBA from the source and only apply it to pixels that are black and alpha $FF.

[0361] Parallel Processing Control Instructions

[0362] 101 ) blockJD (ID Number) Opcode=Two Byte Extended - An extended instruction, identified as a Block ID by the first two bytes, with 16 bits to store the actual ID. An example of a method to provide additional bits for the ID Number may include using some of the bits of the second byte.

[0363] 102) wait_semaphore (Stack Size) Opcode=IPE - An Integrated Push Extended instruction. Pushes Block ID of other Blocks that must be processed before processing a current block. For a wait for a single block, wait_semaphore_1 may be used that encodes the ID for the Block that must be waited for in 16 bits of operand (+ / - some bits of byte 2).

[0364] 103) completion_semaphore (ID Number) Opcode=Two Bytes Extended - Block has completed processing. May be a default based on the block it is located. Alternatively, may explicitly include Block ID in Operand.

[0365] 104) power_semaphore (Priority Code) Opcode=Two Bytes Extended - Request for enhanced processing power. This instruction may be used to request a particular type of processing core.

[0366] 105) nop() - Any unrecognised instruction returns a nop.

[0367] Complex Curves and Shapes with IPE Instructions

[0368] Additional drawing instructions, such as various curves, are preferably implemented using an Integrated Push Extended (IPE) instruction. While general instructions handle basic shapes like rectangles, circles, ellipses, and straight lines, complex curves benefit significantly from the IPE mechanism due to its ability to handle a variable number of parameters and different data precisions.

[0369] For complex curve IPE instructions, the operation often commences at the current position of the drawing cursor. The drawing cursor's position is established by a pos(x,y) instruction, which specifies an offset relative to the current Worksheet Reference Origin. For example, if the Reference Origin is set to (0,0) and a pos(5,6) instruction is executed, subsequent instructions using the drawing cursor's current location will reference from absolute coordinates (5,6). If the Reference Origin is (10,10) and pos(5,6) is executed, those instructions will reference from absolute coordinates (15,16). It is often preferable for the cursor's starting location to be set by a dedicated pos(x,y) instruction immediately preceding the IPE, rather than being embedded within the IPE's parameters.

[0370] This group of IPE instructions, for execution by the Engine, may also include the absolute starting location (X,Y) relative to (0,0) in the Worksheet within their pushed parameters. When destined for processing by a Special Purpose Engine (SPE), these curves preferably include this absolute starting location. This allows the SPE to operate independently of the main drawing cursor's current state, enabling the rest of the system to proceed and change drawing cursor locations, origins, etc., simultaneously or subsequently. This approach further benefits parallel processing, as different processes can independently return data to distinct, explicitly defined locations within the worksheet without conflict. The Adaptive Entropy Compressor (AEC), described elsewhere in this specification, can efficiently compress absolute coordinate data to suit the current state of worksheet settings, reducing bandwidth requirements. A variety of alternative configurations for coordinate referencing would be obvious to those experienced in the art.

[0371] If an extended instruction's opcode intrinsically implies a fixed and recognised number of parameters (e.g., a Cubic Bezier always takes four points), then there is no need to explicitly include the parameter count within the instruction or its pushed data. Otherwise, the count may be specified.

[0372] The system allows for various data precision levels within the pushed parameters. For example, two versions of these extended drawing instructions may exist: one utilising standard integer resolution, and another employing 16-bit integer coordinates with 8-bit subpixel precision. If a curve concludes at its beginning point, it implicitly defines a closed shape. Color information is also provided via pushed parameters; different examples will demonstrate the variability of this process. When graphics are ultimately processed by the system, all color data is internally converted to 32-bit (RGBA, with unsupplied lower bits set to zero), and resolution is normalised to 16-bit integer with 8-bit subpixel precision.

[0373] The following example IPE instructions depict the sequence of push instructions in the AES required to push operand data onto a a stack accessible to the SPE in advance of it receiving and executing the related IPE instruction at the end of each example. The actual IPE instruction is passed to the IPE by the VP, that typically executes the instruction, a process that causes the VP to pass the four byte instruction to the IPE.

[0374] 1 . Quadratic Bezier: Preset Location (Drawing Cursor), RGB Colour

[0375] The initial starting point (P0) is implicitly defined by the drawing cursor's current position. The two control points (P1 , P2) are provided as 24-bit signed offsets (relative to their preceding point). Colour is a 24-bit RGB value. Parameters are pushed to ensure colour is popped first, followed by the geometric points. Example IPE Sequence (Final Corrected Stack Order for Single Curves): [Push_Opcode_8bit | y.P2_signed_offset_16int_8sub_24bit] [Push_Opcode_8bit | x.P2_signed_offset_16int_8sub_24bit]

[0376] [Push_Opcode_8bit | y.P1_signed_offset_16int_8sub_24bit]

[0377] [Push_Opcode_8bit | x.P1_signed_offset_16int_8sub_24bit]

[0378] [Push_Opcode_8bit | r g b 24bit1

[0379] [Quad_Bez_lnt_Opcode_8bit | line_width_24bit] / Extended instruction with line_width operand /

[0380] 2. Quadratic Bezier: Absolute Subpixel Resolution Start, Extended RGBA (16-bit per channel) Colour With 16-bit integer, 8-bit subpixel coordinates, and extended 16-bit per channel RGBA colour.

[0381] [Push_Opcode_8bit | y.P2_signed_offset_16int_8sub_24bit]

[0382] [Push_Opcode_8bit | x.P2_signed_offset_16int_8sub_24bit]

[0383] [Push_Opcode_8bit | y.P1_signed_offset_16int_8sub_24bit]

[0384] [Push_Opcode_8bit | x.P1_signed_offset_16int_8sub_24bit]

[0385] [Push_Opcode_8bit | Start_Y_Abs_16int_8sub_24bit]

[0386] [Push_Opcode_8bit | Start_X_Abs_16int_8sub_24bit]

[0387] [Push_Opcode_8bit | r 16bit parti 8bit r 16bit part2 8bit g 16bit parti Sbitl

[0388] [Push_Opcode_8bit | g_16bit_part2_8bit_b_16bit_part1_8bit_b_16bit_part2_8bit]

[0389] [Push_Opcode_8bit | alpha_16bit_part1_8bit_alpha_16bit_part2_8bit_padding_8bit] [Quad_Bez_ExtendedColor_Subpixel_Opcode_8bit | line_width_24bit]

[0390] Cubic Bezier Curves (Absolute Subpixel Start, RGB Colour)

[0391] Cubic Bezier curves require four control points (PO, P1 , P2, P3). Here, the absolute starting point PO is explicitly provided. Subsequent control points P1 , P2, and P3 are defined as 24-bit signed offsets relative to their preceding point in the curve's sequence. All coordinates (X and Y) are 16-bit integer with 8-bit subpixel precision (24 bits total), and colour is 24-bit RGB. Parameters are pushed to ensure colour is popped first, then the starting point, then the rest of the geometry.

[0392] Elliptical Curves, Arcs, Splines may be similarly configured.

[0393] Multiple Curve Example: Composite Outline Instruction forming Closed Shape

[0394] The next IPE example shows additional instructions included within the pushed data and executed in sequence under the control of the main IPE instruction. Segment 1 : A Cubic Bezier curve, starting at an absolute point. Segment 2: A Quadratic Bezier curve, starting implicitly from the end of Segment 1 (relative offsets). Segment 3: A Straight Line, starting implicitly from the end of Segment 2 (relative offsets).

[0395] The IPE instruction includes a flag to automatically close the shape and will also carry the global line width within its own 24-bit operand:

[0396] [Push_Opcode_8bit | End_Y_signed_offset_16int_8sub_24bit]

[0397] [Push_Opcode_8bit | End_X_signed_offset_16int_8sub_24bit]

[0398] [Push_Opcode_8bit | Segment_Type_StraightLine_ID_24bit]

[0399] [Push_Opcode_8bit | y.P2_signed_offset_16int_8sub_24bit]

[0400] [Push_Opcode_8bit | x.P2_signed_offset_16int_8sub_24bit]

[0401] [Push_Opcode_8bit | y.P1_signed_offset_16int_8sub_24bit]

[0402] [Push_Opcode_8bit | x.P1_signed_offset_16int_8sub_24bit]

[0403] [Push_Opcode_8bit | Segment_Type_QuadraticBezier_ID_24bit]

[0404] [Push_Opcode_8bit | y.P3_signed_offset_16int_8sub_24bit]

[0405] [Push_Opcode_8bit | x.P3_signed_offset_16int_8sub_24bit]

[0406] [Push_Opcode_8bit | y.P2_signed_offset_16int_8sub_24bit]

[0407] [Push_Opcode_8bit | x.P2_signed_offset_16int_8sub_24bit] [Push_Opcode_8bit | y.P1_signed_offset_16int_8sub_24bit]

[0408] [Push_Opcode_8bit | x.P1_signed_offset_16int_8sub_24bit]

[0409] [Push_Opcode_8bit | Start_Y_Abs_16int_8sub_24bit]

[0410] [Push_Opcode_8bit | Start_X_Abs_16int_8sub_24bit]

[0411] [Push_Opcode_8bit | Segment_Type_CubicBezier_ID_24bit]

[0412] [Push_Opcode_8bit | R_G_B_Global_24bit]

[0413] [Push_Opcode_8bit | Alpha_Global_8bit_padding_16bit]

[0414] Extended Functionality and Flexibility

[0415] The adaptability of the Integrated Push Extended (IPE) instruction is further exemplified by its capacity to incorporate advanced rendering features through variations in its opcode or the inclusion of additional pushed parameters. For instance, color information isn't limited to a single static value; a curve's color could dynamically change along its path by including coordinate-based color data. This also facilitates complex gradient fills, whether defined simply between two specific points or by specifying color values at multiple locations along a curve ( or within a shape), allowing for sophisticated visual effects. Furthermore, for closed shapes, the versatility extends to rendering options: a single IPE instruction could specify colouring only the curve's outline, only its enclosed contents, or both, offering precise control over drawing behaviour. These examples merely hint at the broad flexibility available through the IPE mechanism.

[0416] The Shape_Copy IPE Instruction

[0417] The Shape_Copy instruction is an Integrated Push Extended (IPE) instruction designed to transform and move an arbitrary two-dimensional shapes, including the contained pixel data, across the Worksheet. Shape_Copy The example instruction works on a stack that has had the contents of the example Composite_Outline pushed onto the stack i.e. all the push instructions listed plus the Composite_Outline instruction pushed:

[0418] [Push_Opcode_8bit| Composite_Outline_Subpixel_Opcode_8bit | (Number_Of_Segments_N_bits | Close_Shape_Flag_1_bit | Global_Line_Width_M_bits | padding_P_bits)] Data pertaining to colour may be removed from the pushed information as it is not typically used, as this is an instruction to move a region of pixels.

[0419] Additional parameters required by the IPE are then pushed:

[0420] [Push_Opcode_8bit | Destination_Y_Abs_16int_8sub_24bit]

[0421] [Push_Opcode_8bit | Destination_X_Abs_16int_8sub_24bit]

[0422] [Push_Opcode_8bit | X_Rotation_Angle_24bit]

[0423] [Push_Opcode_8bit | Y_Rotation_Angle_24bit]

[0424] [Push_Opcode_8bit | Z_Rotation_Angle_24bit]

[0425] [Push_Opcode_8bit | Scale_Factor_Shrink_Magnify_24bit]

[0426] [Push_Opcode_8bit | Copy_Method_ID_e.g._Bilinear_24bit]

[0427] The actual IPE Instruction:

[0428] [Shape_Move_Opcode_8bit | (Pre_Copy_Mod_Flag_1 bit | Arbitrary_Param_23bit)]

[0429] The Shape_Move IPE may be particularly useful in motion prediction, allowing the encoder to predict a future frame from exiting information at the decoder by selecting boundaries to the reference pixels that are not restricted to a particular shape (e.g., a rectangle). It may also rotate, tilt or scale the reference pixels to optimise prediction. Selection of these parameters may be by analysis of the reference image itself and / or metadata available to the Encoder (e.g., camera information, information from a Volumetric Screen).

[0430] Advanced Painting and Drawing Tools with Dynamic Optimisation

[0431] The THWITRS system supports integration with and enhancement of digital painting and drawing applications, offering an environment for both human and artificial intelligence-driven image creation. A typical paint or drawing program relies on a suite of tools such as pens, brushes, airbrushes, erasers, eyedroppers, and transparency tools. Within the THWITRS framework, these program elements are capable of being incorporated and variably configured. These diverse tools, and the complex patterns they can produce, can be represented within the THWITRS instruction set, typically utilising Integrated Push Extended (IPE) instructions. An IPE instruction, upon execution by a Virtual Processor, can delegate a complex drawing function to a specialised processing unit (e.g., a Special Purpose Engine (SPE) or a Host Pixel Generator (HPG)). This architecture allows for a range of configurable parameters to be passed to the tool, such as color (full RGB, CMYK, or extended depth), width, pressure, opacity, blending modes, texture, and complex drawing path data (e.g., linear segments, cubic or quadratic Bezier curves, elliptic arc curves, or spline functions). This configuration can also facilitate the creation of highly specialised brushes, capable of rendering intricate details like realistic skin tones, varying hair strands with different shades, or complex environmental textures.

[0432] Integrated Data Optimising Painter (IDOP)

[0433] A notable capability within this application context is the Integrated Data Optimising Painter (IDOP). The IDOP can function as an operational mode where the THWITRS encoder is coupled to a computer paint or drawing program, participating actively and dynamically in the image creation process. As a user draws or paints, the IDOP can continuously, or at user-defined or system-determined intervals (e.g., with each stroke, after a brief pause, or at a specific time interval), analyze the newly created image data.

[0434] The core function of the IDOP can include determining if a specific patch or region of the image can be optimally represented and compressed using alternative encoding strategies from the encoder's available tools. This process provides another possible method of compressing an image. For example, if a user draws what visually appears as a solid rectangle with a brush, the IDOP can analyze this pixel data and determine that it can be more efficiently represented by a rect_fill instruction with a solid color, rather than a sequence of individual pixel or brush stroke commands. Similarly, a smoothly varying gradient can be replaced by a blend ine instruction, or a repetitive pattern by a texture_tile command. These paint instructions themselves can be used to represent part of an image, even a photographic image, as an integral part of its compression.

[0435] This dynamic re-evaluation can enable the output to be an optimally compiled outcome that targets desired compression and efficiency. The encoder can optionally present these alternatively encoded versions to the user (e.g., as a preview) for acceptance, rejection, or further modification, which can provide an interactive feedback loop on compression performance. A user interface element, such as a slider, may even allow the artist to select a desired level of compression, whereupon the encoder can attempt to meet this level, offering the resulting optimised version for user review.

[0436] Al Integration for Image Creation and Transformation

[0437] The structured, programmatic nature of the THWITRS instruction set can lend itself to artificial intelligence applications for both learning and de novo image creation.

[0438] Al Learning (Style Transfer and Transformation): The THWITRS Painting Tools can provide a framework for Al to learn how to transform images. An Al model can analyse source images (e.g., photographs) and learn to convert them into stylised "painted" versions by generating sequences of THWITRS instructions. Unlike raw pixel data, which may offer limited inherent structure for Al to interpret artistic "rules," the discrete, semantically meaningful THWITRS instructions (e.g., draw_circle, blendjine, specific brush parameters) can provide a higher-level representation. This can allow Al to learn Advanced Painting and Drawing Tools with Dynamic Optimisation

[0439] The THWITRS system supports integration with and enhancement of digital painting and drawing applications, offering an environment for both human and artificial intelligence-driven image creation. A typical paint or drawing program relies on a suite of tools such as pens, brushes, airbrushes, erasers, eyedroppers, and transparency tools. Within the THWITRS framework, these program elements are capable of being incorporated and variably configured.

[0440] These diverse tools, and the complex patterns they can produce, can be represented within the THWITRS instruction set, typically utilising Integrated Push Extended (IPE) instructions. An IPE instruction, upon execution by a Virtual Processor, can delegate a complex drawing function to a specialised processing unit (e.g., a Special Purpose Engine (SPE) or a Host Pixel Generator (HPG)). This architecture allows for a range of configurable parameters to be passed to the tool, such as color (full RGB, CMYK, or extended depth), width, pressure, opacity, blending modes, texture, and complex drawing path data (e.g., linear segments, cubic or quadratic Bezier curves, elliptic arc curves, or spline functions). This configuration can also facilitate the creation of highly specialised brushes, capable of rendering intricate details like realistic skin tones, varying hair strands with different shades, or complex environmental textures.

[0441] Integrated Data Optimising Painter (IDOP)

[0442] A notable capability within this application context is the Integrated Data Optimising Painter (IDOP). The IDOP can function as an operational mode where the THWITRS encoder is coupled to a computer paint or drawing program, participating actively and dynamically in the image creation process. As a user draws or paints, the IDOP can continuously, or at user-defined or system-determined intervals (e.g., with each stroke, after a brief pause, or at a specific time interval), analyze the newly created image data.

[0443] The core function of the IDOP can include determining if a specific patch or region of the image can be optimally represented and compressed using alternative encoding strategies from the encoder's available tools. This process provides another possible method of compressing an image. For example, if a user draws what visually appears as a solid rectangle with a brush, the IDOP can analyze this pixel data and determine that it can be more efficiently represented by a rect_fill instruction with a solid color, rather than a sequence of individual pixel or brush stroke commands. Similarly, a smoothly varying gradient can be replaced by a blend ine instruction, or a repetitive pattern by a texture_tile command. These paint instructions themselves can be used to represent part of an image, even a photographic image, as an integral part of its compression.

[0444] This dynamic re-evaluation can enable the output to be an optimally compiled outcome that targets desired compression and efficiency. The encoder can optionally present these alternatively encoded versions to the user (e.g., as a preview) for acceptance, rejection, or further modification, which can provide an interactive feedback loop on compression performance. A user interface element, such as a slider, may even allow the artist to select a desired level of compression, whereupon the encoder can attempt to meet this level, offering the resulting optimised version for user review.

[0445] Al Integration for Image Creation and Transformation

[0446] The structured, programmatic nature of the THWITRS instruction set can lend itself to artificial intelligence applications for both learning and de novo image creation.

[0447] Al Learning (Style Transfer and Transformation): The THWITRS Painting Tools can provide a framework for Al to learn how to transform images. An Al model can analyse source images (e.g., photographs) and learn to convert them into stylised "painted" versions by generating sequences of THWITRS instructions. Unlike raw pixel data, which may offer limited inherent structure for Al to interpret artistic "rules," the discrete, semantically meaningful THWITRS instructions (e.g., draw_circle, blendjine, specific brush parameters) can provide a higher-level representation. This can allow Al to learn and apply artistic styles by understanding and manipulating the underlying drawing primitives and their parameters, rather than primarily transforming pixel arrays.

[0448] Al De Novo Creation: Extending this concept, Al can leverage the THWITRS instruction set to create entirely new images and visual content from scratch. By learning the relationships between instructions and their visual outcomes, Al can synthesize complex scenes, characters, or abstract art directly as optimised THWITRS instruction streams. This can offer an alternative to the rasterization pipeline of some generative Al models, potentially leading to more efficient, scalable, and editable Al-generated content. The programmatic nature of the output can make it inherently vector-like and resolution-independent, even when comprising pixel-level operations, which can offer advantages for scaling and manipulation.

[0449] Bilinear Colour Gradient Encoding (BCGE).

[0450] The Encoder expands a source image frame, layer, or patch by Upsampling, spreading out the image details, so sharp details become gradients. Existing gradients (like sky) just become bigger. The encoder analyses the expanded image to identify regions of monotonic colour gradients with a rule set that typically ignores small variations. This becomes a tessellation of different sized tiles (typically rectangular but may be another shape). The more complex the region, the smaller the tiles in the tessellation. The encoder then typically encodes blend rectangles (as one example method) to recreate the blown-up image at the decoder. The Encoder includes a Block_copy() instruction in the AES, operable at the Engine to shrink down the recreated enlarged image at the desired position in the Worksheet. Before drawing the blend rectangles, the Encoder may instruct the Engine to prepare a rectangular region with a fill of alpha=0 pixels. The drawn rectangles inside this region may then be irregular or have spaces and gaps between them. This would imply that the unfilled regions are encoded in another method.

[0451] For grey scale (luminance) the blend rectangle may be a single instruction. The 24 bits of data would be 4 x 6b it luminance values. The blend would interpolate these as 8-bit values.

[0452] For another embodiment of BCGE, the image is split into luminance and colour, with a different mosaic of tiles created for each, with the results combined at the Engine Workspace.

[0453] BCGE typically achieves image encoding and compression because:

[0454] 1 . The image tiles are represented as four colour points (12 bits each typically) which means that the block can be any of 2A48 representations.

[0455] 2. The position of the block has inherent information encoded in that position.

[0456] 3. The block size has inherent information encoded in the size.

[0457] After the encoder expands the initial image, it becomes blurry because the sharp edges are smeared out. The end result is that the image is represented as a spatial representation of features. The greater the expansion, the more noticeable this may become. This controlled ‘blur’ reduces excess fine detail. In effect this is what DCT does- culling out details that the eye cannot see very well, although DCT is fundamentally different working in the frequency domain. While the typical embodiment uses 12 bit colour for the reference points, another colour depth may be used. The Encoder may attempt variations of the corner pixel attributes to determine if a change of value improves the reconstructed image by improved fidelity or lower bit cost. The encoder may select and target any out of bounds pixel for repair using one or more of multiple methods that may include writing to a single pixel

[0458] An alternative approach that avoids the Encoder expanding the image for an arbitrary rectangle is to determine the colour for each corner by averaging the pixels around each corner location, e.g., for a particular corner, averaging the pixel values for pixels between the corner and an arc formed with centre at the corner and a radius extending to the centre of the rectangle, said patch bounded by the two sides of the rectangle forming the corner. The out of bounds pixels generated by BCGE may be repaired using one of the disclosed methods for updating values using residual values or a drawing instruction to adjust attribute values.

[0459] Bidirectional Image Resolution Transitioning (BIRT).

[0460] The bit count of an image may be compressed by Downsampling an image at an Encoder while typically retaining its colour depth, for subsequent Upsampling at the Engine to restore the initial resolution. Downsampling may be applied to a frame, layer, or patch as determined by the Encoder. The Patch is typically a rectangular array of pixels; however, other shapes may be used. The Encoder may select an arbitrary number of patches in a frame for downsampling and subsequent upsampling in the Worksheet. The Encoder typically then determines how the reduced patch is encoded into the AES. The attributes for each pixel may be packed into a sequence of push instructions and an IPE for processing at the decoder, transformed or another method (for example a disclosed method in this specification).

[0461] A downsampled patch at the Encoder may then be further compressed using one or more methods disclosed in this specification or another method. A first and second patch may be the same or different in size and / or shape; downsampled using the same or different methods to the same or different resolutions; upsampled using the same or different methods to the same or different resolutions. For sequential BIRT (see below) a first patch may be sequentially down sampled a first number of times and a second patch a second number of times, wherein said first and second numbers may be the same or distinct. The Encoder may downsample (and subsequent upsample at the decoder) a patch as RGB, Or LUV or L as a separate down sample to Cr and another as Cb or some other arrangement. For sequential BIRT (see below) a first patch (or set of attributes for a patch) may be sequentially down sampled a first number of times and a second patch the same or a different number of times. A method for downsampling a patch may include one or more of the following examples: Nearest Neighbour Resampling, Bilinear Interpolation, Bicubic Interpolation, Lanczos Resampling, or Deep Learning Models. Gaussian blurring may be applied before downsampling.

[0462] An initial patch is referenced as an Original Patch. A down sampled patch is referenced as a Small Patch. The encoder typically includes an instruction for the Engine to Upsample the Small Patch to a Reconstructed Original Patch that is usually the same resolution as the Initial Patch. For example, by using a block copy instruction that copies the smaller patch to a larger patch. The disclosed example instructions describe bilinear scaling; however, this may be replaced with another method, for example: Nearest- Neighbour Upsampling, Linear Interpolation Upsampling, Bicubic Interpolation, Deep Learning Models, Polynomial and Spline Interpolation, Fourier Transform-Based Upsampling. The Reconstructed Original Patch is usually of reduced fidelity compared to the Original Patch. The encoder typically selects a set of residual values to adjust the Reconstructed Original Patch (set) to the required degree of fidelity. Residual values may be encoded using a suitable method, typically a method disclosed in this specification.

[0463] Sequential BIRT

[0464] The system allows that a single iteration of downsampling followed by upsampling and restoration, may be extended to a plurality of iterations of downsampling at the encoder that are iteratively upsampled at the decoder. This process is referenced as Sequential BIRT. Having determined an optimal strategy for downsampling an arbitrary patch in a frame a first amount using a first Downsampling method for a first small patch, and Upsampling it using a First Upsampling method to a Reconstructed Original Patch and further encoding, if required, a method to modify the Reconstructed Original Patch to a predetermined degree of fidelity, the first small patch may then be downsampled a second amount (distinct or the same as the first amount) to a second small patch using a second downsampling method (distinct or the same as the first method), said second patch then upsampled using a Second Upsampling method (distinct or the same as the first upsampling method) to a Reconstructed First Small Patch that is typically adjusted with residual values to restore it to an exact replica of the First Small Patch, although it may be lossy, in which case the residuals and or upsampling method to a reconstructed original patch may require modification. For the Encoder to send the original patch to the decoder, the encoder only needs to encode a) the second small patch using any disclosed method to optimise compression of the second small patch, b) an instruction to Upsample the second patch to the resolution of the first patch, c) information to correct the upsampled second patch to that of the first patch, d) a command to upsample the restored first patch to the Reconstructed Original Patch and e) information to restore the Reconstructed Original Patch to the predetermined degree of fidelity.

[0465] The described process may use an arbitrary number of iterations of Downsampling and Upsampling as determined by the Encoder. It is the last patch in the downsampling sequence that requires encoding in the bitstream, with the remainder of the information to restore each level of upsamplingto the degree of fidelity (usually lossless) before it in turn is upsampled. This process permits an arbitrary number of arbitrary patches in a frame to be each be encoded / decoded using Sequential BIRT an arbitrary number of levels. Sequential BIRT allows the upsamplingto be staged, with adjustments to the process using residual values (or another disclosed method) at each stage that usually improves the accuracy of attribute values in subsequent upsampled stages.

[0466] It should be noted that an earlier process in the encoding may have stripped out objects (e.g., text) for alternate encoding, facilitating improved Down / Upsampling of a patch using One Step or Sequential BIRT. The final small patch in the process may be entropy encoded or use any known or disclosed method to compress the final small patch for transfer to the decoder.

[0467] Pixel Prediction Special Purpose Engine (PPSPE)

[0468] The prior art discloses a method of Intraframe Prediction to predict the value of a block (Prediction Block) of pixels or pixel attributes (e.g., luma) using previously decoded reference pixels for spatial prediction. Predicted pixel attributes are then adjusted using residual values encoded into the bitstream to bringthem closer to their intended values. These residuals are typically encoded as a block of values that are transformed, quantised, and entropy compressed. The reference pixels are typically adjacent to the block of pixels being predicted, usually including the row of pixels immediately above and the column immediately to the left.

[0469] An alternative method referred to as transform prediction, transforms a block of previously reconstructed pixels into a block of transform coefficients. These coefficients are used to predict the transform coefficients of a typically adjacent block. The predicted coefficients are then adjusted as necessary by residual values that are compressed at the encoder through quantisation and entropy encoding. The compressed residual values are transmitted to the decoder, where they are decompressed, dequantised, and used to adjust the predicted coefficients. Finally, the adjusted coefficients are inverse transformed to produce the block of reconstructed pixels. THWITRS may use an arbitrary set of pixels from anywhere in the Worksheet for prediction of another pixel in the worksheet, however, it typically uses local pixels. THWITRS is not limited to predicting a rectangular block of pixels and may predict a set of pixels in another arrangement e.g., a geometric shape (e.g., triangle, polygon, circle). Pixel prediction may act on all the attributes of a pixel or a lesser number (e.g., prediction may be for Luma or U or V or red, green, or blue). THWITRS may select an arbitrary set or sets of pixels for prediction from anywhere in the worksheet, wherein said worksheet may contain pixels from any frame in a video. The prediction process may use pixels classified into the following categories:

[0470] Reference pixels or Reference Transform Coefficients that provide the data used by the prediction algorithm. The reference data may be populated with values from a previously predicted set of pixels (usually repaired using a residual) or prediction process, or written by another THWITRS process (e.g., drawing instruction) or another method. The reference information may be an exact replica of information in the original image for encoding or may be of a lesser fidelity.

[0471] Prediction Pixel is a pixel pending prediction.

[0472] Predicted Pixel contains a predicted value that has not been updated with any required residual.

[0473] Confirmed Pixel is a Predicted Pixel that has been updated with residual data.

[0474] Pixel prediction algorithms may be enhanced through integration with the pixel map system for improved efficiency and reduced residual requirements. We describe two distinct methods of predicting a set of pixels:

[0475] Spatial Domain Prediction that uses the values of known pixel values that are (typically) local to a block of pixels to predict the value of the pixels in the block.

[0476] Transform Domain Prediction involves predicting blocks directly in the transformed domain (e.g., after applying the DCT). This approach can offer some advantages in specific scenarios, but it also comes with challenges. Like spatial domain prediction, the patch for prediction is divided into smaller blocks. Neighbouring blocks that have already been encoded and reconstructed are selected as references for prediction. In contrast to the spatial domain that typically predicts from top row, left column using extrapolation techniques on the pixel values, transform domain uses correlation models on transformed coefficients, in a block of previously reconstructed pixels the same size as the Prediction Block. The reference block is typically immediately above and to the left of the Prediction Block.

[0477] The HAS String (see hereunder) may be used to switch between Spatial and Transform prediction on a block basis.

[0478] Spatial Prediction provides a plurality of modes for mathematically combining the values of selected reference pixels to produce an estimate for the values of Prediction Pixels. Each mode is a distinct algorithm addressable by a distinct Prediction Mode ID. These are well understood by the industry and readily implemented in a PPSPE. Example options include DC, Planar, Directional (e.g., horizontal, vertical, diagonal), Angular (56 distinct angles in AV1), or another arrangement. The Encoder may select any of the available prediction modes for a particular Prediction Block. The HAS String described hereunder facilitates inter block or intra block mode switching by instructing the PPSPE as to which mode to use for each Prediction Block. The Adaptive Switcher may also switch modes within a prediction block if the benefit is greater than the bit cost of the switch (for example, an active Pixel Map signal may indicate a pixel in a block where a switch may occur, or significant change between adjacent attributes may signal the PPSPE to check if it should switch). A first and second block may use a first distinct and second distinct prediction mode. A third block may use a prediction algorithm distinct to said first or second mode.

[0479] The Encoder may instruct the PPSPE to use a particular Mode for a Prediction Block by specifying its Prediction Mode ID associated with the Mode for said Block. Additionally, and referenced as a Dynamic Mode ID, the PPSPE may be configured with a Prediction Code Management System, wherein a tally of code usage is maintained. The system dynamically adapts the assignment of codes based on the current usage frequency or recency, ensuring that the most compact codes (e.g., Huffman codes) are coupled with the most frequently or recently used identifiers. The Method comprises: a) tracking the utilisation of a plurality of Prediction Mode identification codes; b) dynamically adjusting the length of codes assigned to said identifiers, such that shorter codes are assigned to more frequently or recently used identifiers; and c) employing a coding scheme (e.g., Huffman coding) to generate codes of varying lengths.

[0480] The Encoder knows the state of its virtual machine at anytime and may instruct the current Dynamic Mode ID to a particular block.

[0481] THWITRS may provide a new prediction mode algorithm to the decoder by including it in the AES. For example, [Push (PPalgo).1 .... Push (PPalgo).n, Set_IPF_Algo (Number, Algo ID)] that programs the IPSPE with a new Pixel Prediction algorithm in the PPalgo data pushed onto the stack and the Set_PP_Algo instruction that specifies the number of push instructions pertaining to the instruction and the ID code for the AES to subsequently specify use of this Algorithm.

[0482] In contrast to the prior art, THWITRS may instruct the PPSPE to commence Block Prediction at an arbitrary location in the Worksheet that may be part of the next frame for output or another frame. The block for prediction may be an arbitrary size. Prior art intraframe prediction typically processes sequential blocks, whereas THWITRS may process blocks in an arbitrary sequence.

[0483] Although typical reference pixels are the row above and the column to the left of a block, an PPSPE may be configured to use any pixels in the worksheet, for example, while the default is the typical arrangement, this may be overridden, e.g., by a bit in the push stack of the IPE used to start intraframe prediction, said push stack providing the Worksheet x,y coordinates of a pixel that is to be the left most pixel in the reference row and the topmost pixel in the reference column.

[0484] The presence of a Valid Pixel in a Prediction block may influence the predicted value of a Predicted or Confirmed Pixel in the block. For example: a) When a mode is operational and is pending processing of a Valid Pixel, this may be a signal to interrupt the process and seek further instructions (e.g., Change Modes Intra Block). b) The Prediction Mode may modify its normal course of action by considering the effect on said mode by the value in the Valid Pixel (e.g., it may bring the Predicted value of adjacent pixels closer to fidelity without the use of a residual or use a more efficiently coded residual) . c) The Prediction Mode may process as normal; however, the valid pixel data may be applied algorithmically to a local Predicted pixel restoring it towards fidelity without the requirement for a residual d) Control of the usage of a Valid Pixel is typically by a Hierarchical Adaptive Switch String (HAS String) pushed onto the THWITRS Stack as part of the IPE instruction that initiates block prediction for a patch of the worksheet.

[0485] For a typical prior art Intraframe Prediction Process, the encoder predicts a first block using information from already encoded neighbouring blocks. The residual is computed by subtracting the predicted first block from the original first block. The residuals for the first block are transformed, quantised, and entropy coded. The encoder moves on to the next block, using the reconstructed values of the first block and or previously processed blocks as reference for prediction. The decoder predicts said first block using the same process as the encoder, receives the compressed data, decodes it, and reconstructs the first block by adding the decoded residual to the predicted block. THWITRS may be configured to likewise reconstruct a patch of pixels. This process may be integrated into the PPSPE. The preferred method for an PPSPE is for the residual values to be handled separately by a Transform SPE (see hereunder) and returned to worksheet memory as a block of signed residual values for an attribute of each pixel. Said attributes may be for RGB or LUV or another model. The transform block typically represent pixels for a plurality of predicted blocks. The residual data may also be available prior to intraframe prediction for a block. The PPSPE may predict a pixel, then read the related residual and replace the residual value with a corrected version.

[0486] The prior art typically fixes all the Predicted Pixels as required and then moves on to predict the next block. THWITRS may be configured to try and reduce the number of bits to encode the residuals to correct the predicted block to a required level of fidelity, by using Confirmed Pixel Values to reduce the bit count needed to fix other Predicted pixels in the block. Referenced as Iterative Intraframe Prediction, this method requires the encoder / decoder to use a prediction algorithm that predicts the first pixel, then fixes it with residual information in the Worksheet, then uses the fixed information for a subsequent prediction of other prediction pixels in the block. This is computationally more intensive. A potential complication is that residuals are typically sent to the decoder as quantised transform coefficients and inherently lossy. Because of the recursive adverse effects of wrong residuals this may readily corrupt the process that is difficult for the Encoder to overcome. One solution is to use lossless encoding of the residuals, in which instance, the bit savingfrom the iterative process may outweigh the additional bit cost of lossless encoding. Another approach is to limit the number of confirmed pixels processed this way, that if appropriately selected, may tolerate errors introduced by the lossy transform encoding. It may also be that any number of confirmed pixels may be effectively used iteratively, regardless of residual errors. Another method may fix a percentage of the Predicted pixels (e.g., 50%) and average these fixed values with the remaining predicted pixels data to achieve sufficient fidelity that additional residuals are not required. By automatically setting a complete pixel signal in the Pixel Map for each completed pixel, the system can readily track progress of the process. Control of the various described processes is implemented using a combination of default behaviour in the prediction mode algorithm, information in the HAS String, and information in the Pixel Map.

[0487] For a patch of pixels for Block Prediction in the Spatial Domain, an Extended Rectangle is defined in the Worksheet that encompasses where said pixels are to be reconstructed. Multiple prediction blocks are typically defined inside said Extended Rectangle. Push (x,y) places the TLC coordinate of the rectangle on the Engine stack, Push (x1 ,y1 ) the coordinate of the Bottom Right Corner (BRC). Push (Nx, Ny) defines the number of horizontal and vertical blocks for prediction inside the extended rectangle. THWITRS may use a disclosed method to populate initial reference pixels with a value. For example, the initial reference pixels may be those in the row above the extended rectangle and the column to the left. THWITRS may also have filled the pixel locations within the extended rectangle with residuals required to repair ‘out of bounds’ predicted values. Data may also be pushed that alters the sequence that blocks are predicted, the default is to process the blocks sequentially, a row at a time commencing with the left most block of the top row. The default is to use the adjacent top row and left column of a block for prediction. Control parameters for use of a Pixel Map may be pushed onto the stack, however, the Encoder typically controls this separately and will turn the Map off if not required. The HAS String is then pushed onto the stack that includes the first Prediction Mode ID for the first Block (subsequent modes may be instructed using a Dynamic Prediction ID as this table is constructed in the PPSPE). The Instruction to activate the predictive process on the nominated block is then pushed on the stack: [Activate_Predict_Sp, (attribute)]. Attribute instructs the PPSPE which attribute(s) is being predicted. Unless otherwise instructed, the blocks are typically processed starting with the top left, proceeding across the row to the end of the row and then moving to the left most block of the row below.

[0488] Transform Domain Prediction:

[0489] Encoder Process: A THWITRS encoder may divide a patch (typically a rectangle, referenced as an Extended Rectangle) for transform domain prediction reconstruction at the decoder into blocks (e.g., 4x4, 8x8, or 16x16 pixels).

[0490] A first block of pixels is for reconstruction at the decoder by determining a suitable block of reference transform coefficients at the decoder that can be processed by a Prediction Model (algorithm) to generate a block of transform coefficients (First Prediction Block of Transform Coefficients) that when inverse transformed, generate an approximate reconstruction of said first block of pixels. Prior to said inverse transform, the first prediction block of coefficients is combined with residual coefficients generated by the encoder and encoded in the AES, to improve the fidelity of the first prediction block of coefficients and hence, the fidelity of the reconstructed first block of pixels. A reference block of coefficients may be available at the decoder as a result of previous processing at the decoder, e.g., a previous block reconstructed using transform domain prediction and stored in this format instead of, or in addition to, inverse transform to reconstruct the previous block of pixels, or b) a reference block of pixels previously reconstructed at the decoder by any method (including transform prediction) that can be transformed to a reference block of coefficients.

[0491] The reference block of pixels at the decoder may be a lossy or lossless compared to the block prior to encoding. The encoder knows what is available at the decoder at any time.

[0492] To encode a first block of pixels for reconstruction at the decoder by transform prediction, the encoder first needs to determine either a) a suitable block of pixels that will be at the decoder timely for transform (e.g., DCT, DST) to a reference block of coefficients or b) a suitable block of transform coefficients at the decoder in a timely manner. For option (a) it locates the reference block of pixels at the encoder and needs to determine if that block of pixels will be exactly the same at the decoder (e.g., lossless) or will have lost fidelity. The AES needs to identify the location of the reference block of pixels at the decoder and encode this location into the AES. The Encoder determines a Transform (e.g., DCT, DST) to apply to the reference block to generate a reference block of coefficients. The type of transform is encoded into the AES or is a default transform used by the decoder. If the reference block of pixels at the encoder that the transform will be applied to will be a lossless reconstruction at the decoder, said block is transformed to the reference block of coefficients. If the reconstruction is lossy, the Encoder modifies its copy of the reference block of pixels to the reconstructed version at the decoder and then transforms the adjusted block to generate the reference block of coefficients. The encoder now has a block of reference coefficients that it knows it can instruct the decoder to be generate. Option (b) typically applies where a reference block of coefficients is already present at the decoder from a prior operation, for example, a previous block of pixels may have been generated by transform prediction that becomes the reference for predicting a current block, and if the block of coefficients used to generate said previous block using an inverse transform are kept in decoder memory, they may be used as the reference instead of having to retransform said previous block. As the encoder will have processed this already in encoding the image, the block of coefficients may still remain in memory, and it may use these, otherwise it will need to create them following the process for option (a). The encoder then determines a first block of pixels in the image for reconstruction using transform prediction and performs two tasks- a) transforms the first block using the same transform applied the reference block of pixels, and b) applies a transform prediction model to the reference block of transform coefficients to generate a predicted block of coefficients that will be the block generated at the decoder in the reconstruction process. The Encoder compares the difference between the actual coefficients generated by transforming the First block and the predicted block coefficients that will be generated at the decoder. The Encoder calculates the values to correct the predicted residuals, quantises the residuals and then entropy compresses them.

[0493] The process usually commences using a reference block(s) outside the Extended Rectangle that may have previously been reconstructed by Transform prediction or another method. As blocks within the rectangle are reconstructed at the decoder they may be used as reference blocks to predict other blocks in the Extended Rectangle. The selection process can depend on the specific prediction mode. A prediction mode may reference multiple blocks. Typically, blocks above and to the left of the current block are used, but other configurations are possible. Apply the same transform (e.g., DCT, DST) that will be used for the current block to the selected reference blocks. The disclosed embodiments aim to describe the use of THWITRS with Transform Prediction, options enabled by THWITRS and address the mismatch issue that arises when the encoder uses original transform coefficients for prediction while the decoder only has access to quantised and reconstructed coefficients.

[0494] A typical process to reconstruct a patch of pixels at the decoder, by predicting pixels from known values at the decoder using Transform Prediction, may include the following steps:

[0495] At the Encoder:

[0496] 1 ) Select one or more first blocks of reference pixels for transform to one or more first blocks of reference transform coefficients, said blocks for encoding in the bitstream and reconstruction at the decoder in advance of required use in transform prediction.

[0497] 2) As reconstruction of the reference block may be lossy, the Encoder adjusts said one or more first blocks of reference pixels to their actual reconstructed value at the decoder. (For a reference block previously reconstructed using the same Transform Prediction model, the adjustment is typically adjusting for quantisation losses).

[0498] 3) Transform (e.g., DCT) said one or more adjusted first reference block of pixels to one or more adjusted first reference blocks of coefficients.

[0499] 4) Select a first prediction block of pixels, usually the same size as the reference block, for reconstruction by transform prediction at the decoder.

[0500] 5) Transform the first prediction block using the same transform applied to the adjusted reference block(s) to generate a first Actual Prediction block of coefficients.

[0501] 6) Select a Prediction Model that will be used to predict the first Prediction block of coefficients at the decoder. The model can be: Simple: e.g., averaging the corresponding coefficients from the reference blocks. Complex: e.g., linear regression models that consider the spatial correlation between coefficients, or machine learning models trained on a large dataset.

[0502] 7) Apply said model to the one or more adjusted blocks of reference coefficients to Generate a first Estimated Prediction block of coefficients.

[0503] 8) Compare the first Actual Prediction block of coefficients with the first Estimated Prediction block of coefficients and generate a first block of signed residual coefficients.

[0504] 9) Quantise the first block of signed residual coefficients to compress the data. This is a lossy step.

[0505] 10) Entropy Encode the location (if not predetermined) of the reference block(s), the prediction model, and the quantised first block of signed residual coefficients into the bitstream.

[0506] 11) Dequantise the first block quantised residual coefficients and add them to the first block predicted coefficients and inverse the resulting block of coefficients to restore the block to pixel space. ,

[0507] 12) Compare the reconstructed first block of pixels with the original first block of pixels using a known method that may include a disclosed example method. If unacceptable, the quantisation parameters may need revisiting, or a decision may be made to fix the errant pixels in pixel space at the decoder using a THWITRS process. Other methods may include: a. Quantisation Parameter Signalling: The encoder may transmit additional information about the quantisation parameters used for each block. The decoder could then use this information to dequantise the reference block coefficients in a way that more closely matches the original values used by the encoder. b. Adaptive Quantisation: The encoder may use adaptive quantisation schemes that consider the properties of the reference block and the predicted block. This could help minimise the quantisation error and reduce the mismatch between the encoder and decoder's reference blocks. c. Rate-Distortion Optimisation: The encoder may use rate-distortion optimisation techniques to find the best trade-off between quantisation accuracy and compression efficiency. This would involve balancing the quantisation error against the bitrate required to transmit the residual coefficients. d. Transform Domain Denoising: Before using the reconstructed coefficients for prediction, the decoder may apply denoising or smoothing filters in the transform domain to mitigate the effects of quantisation noise. This could help reduce the mismatch between the reconstructed and original coefficients.

[0508] 13) If the quantised residual coefficients are deemed acceptable, they are entropy encoded for inclusion in the AES. (with or without described adjustments)

[0509] 14) The encoding process is repeated using the first block of reconstructed pixels for predicting the second block of coefficients at the decoder with an important proviso, namely the reference patch of pixels at the decoder for predicting the second block of coefficients is unlikely to be identicalto that at the Encoder, due to quantisation loss. The first block of restored predicted coefficients is preferable for use as the reference block of coefficients for predicting the second block of coefficients, rather than transforming the pixels at the encoder that represent the first block of predicted pixels at the decoder to obtain the reference block of coefficients for predicting the second block of coefficients. This also minimises accumulated errors as subsequent blocks are predicted at the encoder.

[0510] Decoder Process: For a patch of pixels for intraframe Prediction, an Extended Rectangle is usually defined in the Worksheet that encompasses said pixels. Multiple prediction blocks are typically defined inside said extended rectangle. Push (x,y) places the TLC coordinate of the rectangle on the Engine stack, Push (x1 ,y1 ) the coordinate of the Bottom Right Corner (BRC). Push (Nx, Ny) defines the number of horizontal and vertical blocks for prediction inside the extended rectangle. The TLC of the first reference block is pushed onto the Stack. THWITRS may use a disclosed method to populate the initial reference block with pixel attributes. For example, a block above and to the left of the TLC. Quantised residual coefficients to correct predicted coefficients are pushed onto the stack together with the quantiser parameters or the ID of a default quantiser (or previously transferred) quantiser at the PPSPE. A HAS String for controlling Prediction Mode selection or another process is pushed on the stack. The Instruction to activate the predictive process on the nominated block is then pushed on the stack:

[0511] [Activate_Predict_Tr, (attribute)]. In response to the instruction, the PPSPE dequantises the pushed residual coefficients and stores the result in the related pixel locations of the Extended Rectangle. The PPSE then transforms the reference block of pixels using the same transform used by the Encoder to generate the predicted coefficients, adding the block of resulting coefficients to the related block of residual coefficients in the Extended Rectangle. THWITRS maybe configured to use plural reference blocks for predicting a block of coefficients, a process known to the art. The process described for a PPSPE may be implemented in a HPG.

[0512] Smart phones, Smart TV’s and personal computers are frequently equipped with a custom chip to process intraframe prediction for H.264 / AVC, with a similar trend expected for H.265 and AV1. The PPSPE may take advantage of these devices to offload processing without requiring additional hardware. It may also be able to utilise other functions within the chips.

[0513] Fractal Compression SPE This a method of image compression that uses fractals, or mathematical structures that are self-similar across different scales, to encode images. This technique exploits the fact that many parts of an image often resemble other parts of the same image, allowing these sections to be represented mathematically by transformations of other sections. It is not our intention to teach the methods of encoding an image using fractal compression as these are well understood by those experienced in the art. What THWITRS provides is a method of choosing an arbitrary patch of pixels that may be sent to a component configured for encoding the patch using fractal compression with the result returned for comparison with an alternative method (if required). The algorithms for reversing the fractal compression are embodied in a Special Purpose Pixel Generator configured to decode fractal compression. A Fractal Integrated Push Extended Instruction packages the data required for the fractal decoder and instructions as to where to place the result in the Worksheet.

[0514] Particle Generator SPE This may be used to generate fire, smoke, water spray, clouds, fog, dust (e.g., kicking up from a moving vehicle), sparks, exploding or dissolving effects. The Particle Generator typically creates its effect on a transparent rectangle for each frame that is placed in the Worksheet as directed by the bitstream. The Encoder may instruct the Particle Generator to produce its effect in advance of it being required for a frame. A Pixel Generator Integrated Push Extended Instruction packages the data required for the pixel generator and instructions as to where to place the result in the Worksheet.

[0515] Inverse Transform SPE (ITSPE)

[0516] Pixels or residual values may be compressed using a transform. The THWITRS Encoder may be configured to use a plurality of prior art transforms and may be readily configured to include a future transform. The decoder is typically configured for an Inverse Transform SPE to accommodate the inverse transform libraries for said plurality of prior art transforms.

[0517] The following are examples of Transforms that may be used by a THWITRS encoder (their respective inverse transforms included in a Inverse transform SPE:

[0518] 1 D Transforms: Discrete Cosine Transform (DCT): Decomposes a signal (a single row or column of pixels) into a weighted sum of cosine functions with different frequencies. The DCT exhibits excellent energy compaction properties, concentrating most of the signal's energy in a few low-frequency coefficients. This makes it ideal for quantisation, where high- frequency coefficients can be discarded with minimal impact on visual quality.

[0519] Discrete Sine Transform (DST): Similar to the DCT but uses sine functions instead of cosine functions. It's often used for lossless compression or as part of hybrid transform schemes.

[0520] Hadamard Transform: A simpler transform than DCT or DST, using only additions and subtractions, making it computationally efficient. However, it's not as effective at energy compaction.

[0521] Haar Wavelet Transform: A type of wavelet transform that uses a simple pair of basis functions (a square wave and its inverse) to decompose a signal into different scales and positions. It's particularly useful for detecting edges and sharp transitions in images.

[0522] 2D Transforms 2D Discrete Cosine Transform (DCT): A widely used transform in image and video compression, operating on blocks of pixels. It extends the 1 D DCT to two dimensions, transforming both the rows and columns of the block. The resulting coefficients represent the spatial frequency content of the block, with low-frequency coefficients carrying most of the energy.

[0523] 2D Discrete Sine Transform (DST): Similar to the 2D DCT but uses sine functions as basis functions. It can be used for lossless compression or as part of hybrid transform schemes.

[0524] 2D Discrete Wavelet Transform (DWT): Decomposes an image into multiple scales and orientations, providing a multi-resolution representation that is useful for both lossy and lossless compression. It's particularly good at preserving details and edges.

[0525] 2D Hadamard Transform: Extends the 1 D Hadamard transform to two dimensions, operating on blocks of pixels. It's computationally efficient but not as good at energy compaction as the DCT.

[0526] The preferred method of encoding transform parameters uses an IPE instruction. For example, the transform coefficients are encoded as a sequence of Push instructions PushO to Pushn. The TLC of the array in the Worksheet to store the coefficients in Push(n+1) (X,Y), the BRC of the array Push(n+2) (X1 ,Y1), Push(n+3) (Default Block Width, Default Block Height), [lnv_Trans (transform (e.g., DCT), Number of Push Instructions, Quantisation Code (identifies a default quant table or table previously pushed to the SPE) MS 7bit, LSB= Coefficient Structure Flag (CSF))]. The aforementioned writes the pushed coefficients to the rectangle in the Worksheet defined by the TLS and BRC. If the CSF=0 the SPE is instructed that the transform blocks are all the same size as the default block dimensions and the SPE dequantises the blocks using the specified quantisation table. One or more default size blocks may be divided into smaller blocks or enlarged into larger blocks. A HAS string may be used to define non-default blocks and their division as described elsewhere. A quantisation table may be sent to the Inverse Transform SPE using an IPE: Quantisation Values in PushO to Pushn , [Quant_Table (Number of Push Instructions, Number Quant Values, DC). The optimisation of the coefficients for entropy encoding is preferably performed by the AEC, e.g., a selected pattern of arranging coefficients (e.g. the zig zag pattern of 8x8 block DCT), irrational quantising, 2d to 3d Array structures or another AEC method.

[0527] Prior art transforms typically transform a block of pixel attributes and then quantise the transform coefficients, reducing the number of distinct values and usually reducing less important values to zero, in which case the decoder performs the inverse transform after multiplying the coefficients by the quantisation values . The Encoder may decide that a patch of pixels is better handled by quantising the pixel attributes prior to the transform, in which case the decoder performs the inverse transform first and then multiples the resultant values by the quantisation values. Transform coefficients may be arranged in a 3d structure, for example, with a HAS sent to the ITSPE signalling the structure.

[0528] Text SPE. The large number of different fonts and the uncertainty as to which fonts may be present (or accessible) for a particular THWITRS Engine means that rendering text at the host computer may be problematic. Our preference is for a Text SPE operable to render a limited set of fonts in response to instructions in an AES and have the Encoder pre-render other fonts that may be compiled to instructions to build the font in the THWITRS Engine ‘bitmap space’ of the Worksheet. The Text SPE may also have more extensive font rendering capability; however, the preference is for the Engine to pass text rendering to a library on the host computer for processing for return of the result to the Engine. Vector fonts use mathematical descriptions for each glyph and may be scaled to any size without losing quality (e.g., TrueType and OpenType fonts) that may be rendered to a graphics context at the desired size. Example rendering libraries may include: FreeType that is an open-source software library that renders text onto bitmaps and provides support for various font formats, Pango, a library that lays out and renders text, with an emphasis on internationalisation. Most graphics APIs have some facility for text rendering. For instance: OpenGL / DirectX that may be used alongside a library like FreeType to render text into textures. Text rendering may be leveraged by using a GPU (e.g., by using WebGPU, Metal, Vulcan).

[0529] A font rendering library, e.g., FreeType may be embedded in the Decoder as a Special Purpose Processor (SPP), referenced as a Text SPP and parameters passed to it using an Integrated Push Extended instruction, with a bit map of the font returned to the Workspace. Alternatively, parameters may be passed to a library on the destination computer for processing and return of fonts in bitmap to the Worksheet. The latter has the disadvantage of requiring the library to be available on the host.

[0530] The Text SPP would typically include a limited set of fonts for things like “thought bubbles” or an image of text displayed on a smartphone. For example, a standard sans-serif font for readability, a script font for stylistic purposes, and preferably a monospace font for displaying code or similar text. Additional fonts may be sent in the bitstream; however, the Encoder determines if this is more efficient than just encoding a bitmap of the fonts as required.

[0531] Interframe Prediction Using Interframe Motion Prediction a. Traditional Motion Vectors, wherein a best case block of pixels is located in a previous or future frame and copied to a new location in a current frame. The coordinates of the reference block may be subpixel. b. Prior Art Overlapping Block Motion Compensation. c. Asymmetric Subpixel Quad Shift where the reference blocks are distorted by averaging (or another algorithm) the coordinates of the adjacent corners of adjacent reference blocks. A group of quads so derived are typically contiguous, resulting in improved prediction. This method may use prior art methods of locating suitable blocks that just requires averaging of the coordinates of adjacent corners of 4 blocks and a method to efficiently encode this information. THWITRS discloses multiple instructions for block copy and bilinear block copy that facilitate copying a reference patch that is not a simple rectangle. A subpixel resolution of up to 256 divisions may also reduce prediction errors. d. Asymmetric Subpixel Quad Transform is an extension of the preceding method that does not require the use of rectangular reference blocks and may be used to allow for additional transforms to those in the XY plane, e.g., rotation, tilting, distortion. It entails searching for a patch of pixels that when rotated or tilted or distorted- usually to subpixel coordinates, can be approximated to a patch of pixels in the prediction frame. The reference patch may be any suitable patch in the Worksheet. This process may be extended using , for example, the Shape_Copy instruction that may be used to define almost any 2d shape with a sequence of lines and or curves. This is expected to provide fertile ground for Al or CNN to analyses an image for a suitable reference patch. e. The conversion of a patch (e.g., background) to a set of polygons (e.g., as used in game technology) or the computer synthesis of a patch of polygons, and the manipulation of the vertices of the polygons from a first to second frame

[0532] It is preferable that vertex and pixel shaders in a GPU are used to map the quads or alternate shapes to integer pixel coordinates in the prediction frame. Out of bounds pixels may be adjusted by sending residuals or transformed residuals using a method selected from the instruction set.

[0533] The following sequence of instructions copies a prediction rectangle. It sets a reference origin for the source (reference blocks) and destination (prediction blocks.

[0534] [set_origin (0,0)]

[0535] [set_d_origin (0,0)]

[0536] Extended reference origins may also be used that reference each coordinate as 16 bits of integer and 8 bits of fractional coordinates. For multiple block transfers the encoder may change one or more references duringthe copy instructions.

[0537] [src_size (x,y)] the size of source (reference) block in px

[0538] [dst_size (x,y)] the size of the destination block in px (typically the same as the src size).

[0539] [src_pos (x,y)] coordinates of the top left corner (TLC) the source rectangle (reference block).

[0540] May be replaced by the extended version of the instruction if integer (16 bits) and sub pixel (another 8 bits) are required.

[0541] [dst_pos (x,0y)] coordinates TLC of the destination rectangle (prediction block).

[0542] [blockMV_copy] bilinear copy the source rectangle to the destination rectangle.

[0543] Alternate copy methods are readily implemented.

[0544] The Encoder may use the pixel map to prevent the block copy overwriting a pixel previously updated by a prior process. Similarly, a residual for said pixel may not be required.

[0545] Prediction may be based on luma, chroma, luma and chroma, or RGB attributes. Prediction based on motion of a first attribute may be applied to another attribute, said motion to another attribute (e.g., one or both chroma, or RGB).

[0546] The Encoder may have separated a plurality of objects in a frame into a plurality of layers, each layer for reconstruction in a distinct region of the Worksheet that may improve the accuracy of reference block values.

[0547] Encoder may use motion prediction for one or more arbitrary regions of a frame and may use one or more other methods for one or more arbitrary regions of a frame. Methods may overlap.

[0548] One reason for a discrepancy between a reference block and a predicted block and the actual values for the predicted block at the encoder, may be scene lighting changes between frames. The Encoder may analyse an image for lighting changes (or be provided this information, e.g., a volumetric screen may provide a component of the scene lighting and can encode this separately). Lighting data may be extracted from a frame, providing more stable reference information for predictive purposes, and added back in a backlight viewport as described elsewhere. For example, if the only changes between a first and second frame are lighting changes (e.g., a flash of lightening), removing part or all of scene lighting from the two frames may result in identical or similar images.

[0549] THWITRS is not limited to using rectangular blocks for reference or prediction. The Encoder may arbitrarily select any geometric shape it is configured to process, including copy circle that use the present default circle size (that may be changed with circle_R (r)) copying the pixels within and typically including the circumference of the circle centred at the current src_pos (x,y) or alternatively [src_posX (x, fraction)] and [src_Y (y, fraction)] to the same sized circle with centre at dst_pos (x,y). shape_copy is an IPE instruction that defines the boundary of a shape by a set of lines joining a plurality of pushed x, y coordinates of a shape, and copies the pixels enclosed by the boundary, typically including those of the boundary, to a prediction shape.

[0550] The disclosed process thus far, is flexible but inefficient in terms of bit cost compared to prior art motion prediction, a situation rectified by secondary compression using a THWITRS Adaptive Entropy Compressor. Asymmetric Subpixel Quad Shift. The coordinates of adjacent corners of reference blocks are averaged or otherwise weighted to improve prediction. Since we know the Top Left (TL) position of every reference block, and the blocks are fixed size, we also know the TR, BL, and BR coordinates. The quads which do the transform to the next frame have corners which are simply the average of the 4 associated block corners. This may be written as a mathematical formula for doing the motion vector to quad vertex transform. Once the quad vertex points are determined, the encoder can check the x and y sizes of adjacent quads, and if the changes are small and same polarity, the encoder can just collapse those quads into a single one. That means if the deformation (frame to frame) is uniform (like a stretch), then a single quad can replace the smaller ones. If the deformation is irregular, then the base quad that corresponds to the block analysis is kept. In many cases the legacy algorithm for using bigger blocks will be appropriate. The technique of averaging block corner positions works for overlapping blocks as well as mixed size blocks. The reader is directed to figures 7. In most cases the interframe movement of the image is a low data adjustment of block positions. If a block is characterised by a large random movement, then by definition its new position is not compressible to a few bits. As long as the interframe transform is effectively monotonic (the blocks are not jumbled out-of-order), this method will eliminate residuals. Using the corner average method, the centre of each quad will be the same pixel as the centre of the corresponding block. The quads are just "stretched blocks" that line up to eliminate residuals. Because using the quads preserves the original texture (just stretch it a bit), the process can be spread over several frames. The first pass can use large coarse quads, and then later frames can adjust finer regions with more quads. At 24fps or so, the viewer will not really notice. A use for this would be human faces. The background may only need slight pan / zoom adjustments every few frames, and then the face details get finer grain quads. Block systems may do similar things, but with block moves there are inherent residuals.

[0551] The following IPE instruction will copy a quad with it four corner coordinates from the quad defined by the parameters in the push to a rectangle predefined in a previous instruction set to x,y size and location push (X_hires_1 ), push (Y_hires_1), push ( X_hires_2), push (Y_hires_2), push (X_hires_3) push (Y_hires_3), push ( X_hires_4), push (Y_hires_4), pos(x, y), vertex_4_copy (x_size, y_size).

[0552] The ASQR subpixel operable block copy instruction is typically used to adjust a patch in a first frame for changes in a subsequent frame, providing a novel alternative to motion vectors. A plurality of this instruction may define an n+1 frame as an array of blocks and calculate the patches in the n frame that matches frame n+1 . For example, if the camera is just rotating, the n+1 image is just an array of blocks, but the source quads will be rotated. Using this operation, the decoder may perform an arbitrary transform using a tile-like process with little information required by the decoder per tile. The tiles may be of arbitrary size, with smaller tiles more likely for complicated image distortion. The instruction may replace motion vectors, edge repair, and rotate or scaling problems. It effectively generates a new block of pixels from an arbitrary quad in a source frame, preferably by using vertex and pixel shaders in a GPU in a fast and efficient way. It solves camera movement problems and may be used to paste things (e.g., leaves or objects) that twist and move over time. The instruction may also be used intraframe to obtain a better match between a first and second patch. Vertex_4_copy takes a patch of the worksheet (a quad in GPU terms) and transforms it (e.g., bilinear copy and scaling) to a destination quad. The quads in this case do not need to be rectangular, although the destination quad is typically rectangular. The copied patch will be scaled to match the source and destination quad. This transform may manage a camera change, including rotation. The vertex_4_copy will not fit in a 4 byte instruction, so it is an extended instruction (16 bit opcode in this instance) that uses the stack for parameters. To avoid problems with edge alignment the four corners of the source quad use precision coordinates (i.e. subpixel coordinates) - 16 bit integer for the pixel location and 8 bits to move it to a subpixel coordinate. This effectively forces the destination (typically in the next frame) to be composed of tiles, which means that the drawn block in the destination patch will not bleed into adjacent pixels. X-hires_1 , Y_hires_1 locate the top left corner of a source quad, X-hires_2, Y_hires_2 locate the top right corner of the quad, X-hires_3, Y_hires_3 locate the bottom left corner of the quad, and X-hires_4, Y_hires_4 locate the bottom right corner of the quad. The pos (x,y) (typically referenced to the reference destination origin for this instruction) is the top left corner of the destination quad (which is just a rectangle). The parameter x_size is the horizontal width of the destination quad and y_size its height. If the destination quads are the same size and share a common side, their respective source quads will share two common vertices. For example, if the quads are sequenced from left to right, each subsequent transform only needs to push two more coordinates. For horizontally aligned tiles, the vertex_h_copy is used for subsequent quads in the sequence after the first quad. Vertex_h_copy does not need to push the coordinates for vertices 1 and 3 as it automatically copies these from the 2nd and 4th vertices of the previous quad. It may not require x_size or y_size as these may be copied from the previous instruction. Pos (x,y) is also not required as vertex_h_copy automatically adds x_size to the x of pos (x,y). Vertex_v_copy accommodates vertically aligned quads (does not need to push vertices 1 and 2 and automatically adds the previous y_size to the y of pos (x,y).

[0553] The AEG may pull apart the instructions, locate key information, entropy compress this, send it to the ADC at the decoder and restore the rectangles. For example, to set up the a block of prediction rectangles, the coordinates of TLC of first rectangle in an array of blocks, the x and y dimensions of the blocks, and number horizontal blocks and vertical blocks are collated. The size of the reference blocks and there number and approximate arrangement can be predicted from the prediction block information. From the coordinates for the centre of each reference block and its size, the corners of each quad can be calculated. The centre coordinates for a reference block (not the derived quad block) are calculated and typically converted to a series of relative offsets. This is then entropy encoded. The ADC reverses the entropy coding, reconstitutes the instructions and sends them to the VP for execution.

[0554] PIXEL MAP SYSTEM

[0555] Known codecs typically reconstruct a plurality of patches (typically rectangular blocks) of pixels in a frame by progressively sequencing reconstruction of said patches in a predetermined pattern determined by the encoder as permitted by preprogrammed processes at the decoder. The known method for reconstructing a patch typically generates the pixel attributes to the required fidelity for the patch directly or after adjustment using residual values encoded into the bitstream. There is no requirement to revisit the patch for additional processing that may alter the value of a pixel in the patch or use a pixel attribute to adjust the attribute of a pixel in the patch. In contrast to the known art, a THWITRS Encoder may arbitrarily determine the sequencing or location of a patch for reconstruction and may revisit the same patch a plurality of times that may include a distinct method for each visit, said distinction not necessarily constrained to residual repair of pixels. For example, a THWITRS Drawing instruction may draw a blue line diagonally across a patch (e.g., rectangular block) of pixels wherein other pixels in the patch external to the line are to be reconstructed by spatial prediction and residual repair. Having drawn a blue pixel to a location in the patch the encoder may not want this pixel altered by a prediction or other algorithm operating on the patch including said blue pixel. Furthermore, to modify a patch using residuals, the encoder may prepares a sequence of residual values that are sequentially applied to pixels in the patch using a path selected by the encoder, wherein a residual value of zero would not alter the pixel attribute, it may be still a waste of bandwidth compared to a process that flags said pixel or pixel attribute, allowing the residual update process to skip the pixel attribute and instead apply it to the next pixel in sequence requiring application of a residual. The pixel map is a method to flag a pixel attribute that may enable a current method that may otherwise modify, or use said attribute, to bypass said modification or use. The flagged pixel attribute may contain a final value written by a previous method for the attribute as indicated by a Complete Attribute Signal or it may contain an intermediate value that may require further modification as indicated by an Intermediate Attribute Signal. The Encoder may also require a pixel attribute to be protected from change or excluded from a process where said pixel has not had a value set by a previous operation.

[0556] The present invention discloses a method for signalling in a decoder that reconstructs an image encoded into a bitstream by an encoder. This method is designed to enhance control over image processing by generating a signal that governs the processing of the identified attribute for the pixel data of one or more pixels of a frame or worksheet, wherein the signal can govern one or more of the following:

[0557] • Exclusion: the identified attribute is not modified by processing of said pixel data;

[0558] • Inclusion: the identified attribute value is for use in processing the value of another pixel of the frame;

[0559] • Self-Modification: the identified attribute can be used to modify the attribute;

[0560] • A specific processing role for the identified attribute beyond exclusion, inclusion, or self- modification; wherein the signal is based on at least one of:

[0561] • a final value of the attribute,

[0562] • an intermediate value of the pixel during processing,

[0563] • selective access controls communicated by the encoder.

[0564] The signal related to the attribute typically comprises storing a Pixel Signal Map (Pixel Map) in decoder- accessible computer memory, said map representing a plurality of pixels of a frame or worksheet. The Pixel Map typically includes at least a first flag and a second flag, wherein the first flag is associated with a first pixel of the frame or worksheet , and the second flag is associated with a second pixel of the frame or worksheet, wherein the first pixel is not associated with the second flag, and the second pixel is not associated with the first flag. In practice the Pixel Map includes a set of 'n' flags, where n is an integer greater than or equal to 2, and wherein:

[0565] For each pixel P associated with a flag F from the set, there exists at least one other flag G in the set such that P is not associated with G. For each pair of distinct flags F and G in the set, there exists at least one pixel associated with F that is not associated with G, and at least one pixel associated with G that is not associated with F. The preferred signalling method comprises storing a Pixel Signal Map (Pixel Map) in decoder- accessible computer memory. This Pixel Map represents a plurality of pixels, and the pixels selected for representation in the map may be set by default within the decoder's implementation but are usually under the control of the Encoder, or both. The Pixel Map includes a plurality of flags, with each flag corresponding to one or more pixels of the frame. Each pixel associated with a flag is typically distinct from pixels associated with any other flag, ensuring clear and unambiguous representation in the Pixel Map. This arrangement may also be mirrored in the context of the worksheet used for the reconstruction of the frame. Similar to the flags used for the frame, each flag in the worksheet corresponds to one or more pixels, maintaining the distinctness of each pixel’s association with a flag. Each flag within the map may encode one or more distinct signals. The preferred method of representing these signals within a flag utilises a bit-based approach, where each distinct signal is represented by a specific bit. A bit set to zero indicates that the corresponding signal is inactive (or not applicable), and a bit set to one indicates that the signal is active (or applicable). While this bit-based encoding is preferred, other encoding methods known in the art may also be employed depending on specific application needs.

[0566] The Pixel Map itself is typically configured as a two-dimensional (2D) array of Flag elements, each capable of representing part or all of the pixels in a Frame or Worksheet. Alternatively, for complex data structures, e.g., 3d, the Pixel Map may be arranged as a three-dimensional (3D) array to accommodate three- dimensional Worksheets or reconfigured as a 2D array, such as dividing it into sections (e.g., four quarters) that are then treated as separate layers.

[0567] In the context of pixel attributes within the Pixel Map, an attribute may encompass a range of color components or other characteristics such as depth. Specifically, an attribute can be a composite RGB value for the pixel, represented as 24RGB for the combination of red, green, and blue components, or 32RGBA when including the alpha component for transparency. Alternatively, an attribute might represent individual color components separately — such as the red, green, or blue components alone. Similarly, parts of a frame encoded using the YUV color model (also known as YCrCb), attributes may include the composite YUV. Alternatively, an attribute might represent individual YUV components separately — such as the Y, the U, or the V components alone.

[0568] As a frame is progressively reconstructed at the decoder, an increasing number of pixels will be populated with final values, as such, these pixels have valid information that may be of use for processing data for other pixels in the frame or worksheet. They are also pixels that are usually excluded from subsequent modification. In other words, a pixel map for these pixels may be constructed for free (or minimal overhead) in terms of additional bits in the bitstream. There will be a pixel where an attribute has been modified by a process (e.g., a THWITRS Instruction, for example, pix_888, pix_run or rect_888, that may be relied on to have accurately written a final value for said attribute, and the decoder may be configured to automatically set a signal bit in the flag related to said pixel attribute to active. Said signal is referenced as a Complete Pixel Signal. Other instruction may be less defined in this regard, for example, an instruction that fixes pixels using residual values might be expected to have finalised a pixel’s attributes, however, this may be less certain than specific pixel instructions. The Encoder may want to control enabling or disabling of the automated setting of a complete pixel signal by the decoder, for example, by the Act_Auto_PixComp and Dis_Auto_PixComp instructions respectively. This may be a coarse control (e.g., on / off for the entire map) or more finely tuned (e.g., an extra bit for each pixel flag) or something in between. An Active Complete Pixel Signal usually signals an attribute as non- modifiable by a process that would normally write to the attribute, for example, an inverse transform normally results in a block of luma attributes for a block of pixels, that would normally include modifying a luma value of a pixel already finalised by another process.

[0569] A second instruction may permit other pixel operations (e.g. applying a residual value to update a pixel) to automatically update the Pixel Map for a pixel. An instruction may disable the operation permitted by said second Instruction (typically until re-enabled by execution of another said second instruction). An instruction to counteract the effect of said first instruction may also terminate the effect of said second instruction.

[0570] During Image reconstruction, a pixel may have an intermediate value (for example, BCGE (see hereunder) or after a step of sequential BIRT (see hereunder)) that may be of use for processing data for a pixel in the frame or worksheet. In contrast to a pixel that has a final value and is excluded from change, an intermediate value may be amenable to change by said processing. The Pixel Map may include a bit to code the status of a pixel with an intermediate value, said signal referenced as an Intermediate Pixel Signal. When said pixel is populated with a final value, said intermediate signal may be cleared and a Complete Pixel Signal set. An active Intermediate Signal may be operable in two alternate states, a first state signals that the related pixel contains intermediate data that may be of use for processing the pixel data of one or more pixels of a frame or worksheet, however, the intermediate information is excluded from modification and a second state that also permits modification. It should be noted that an Intermediate value may mean that the pixel has a final value for one or more attributes (e.g., red) an intermediate or absent value for another attribute.

[0571] The complete and intermediate signals are typically derived at the decoder for free or little cost in terms of additional bits in the AES. The Encoder may also require a pixel to be protected from change or excluded from a process where said pixel has not had a flag bit set by a previous operation. For example, said pixel may be in the default state which is defined as having an initial value assigned during the initialisation or clearing of the Worksheet or not specifically assigned and assumed to be unknown. This initial value may be preset or undetermined. The preference is to include an additional bit to code this Selective Control Signal for a pixel. An example use, may be to map out pixels forming an edge or other structure that will introduce errors into a transform and require subsequent fixup. Setting a Selective Control Signal for a pixel has a cost to implement as it typically requires an additional instruction in the bitstream. Said instruction may address a particular bit or bits in the Map, or it may define a geometric shape encompassing a plurality of bits in the Pixel Map. Although not limiting, the example Pixel Map Flag as described may include 1 -3 bits to signal the status of a pixel in the Worksheet. Signalling distinct pixel attributes (e.g., red, green, and / or blue) is a straightforward implementation within the system.

[0572] THWITRS may reconstruct an image in a plurality of distinct regions of the worksheet, wherein, a first region of said plurality may be collapsed onto a second region (said collapse typically within the Worksheet or the Render Image). For a first pixel in the first region that will be collapsed with a second pixel in said second region, a Pixel Flag pertaining to said first pixel may signal exclusion of said second pixel from modification by, or participation in, said first method and or signal that an attribute of said first pixel may be used by said first method for processing said second region as though said first pixel attribute were that of the second pixel.

[0573] Example instructions for controlling use of the Pixel Map may include:

[0574] 1 . Set_PixMap to set the size of the Map that may be an arbitrary size up to that required to accommodate a pixel flag for each pixel in the Worksheet. A plurality of maps may be constructed using the same opcode with a distinct value in the operand for a distinct map (e.g., a first map for red attributes and another for green attributes).

[0575] 2. Clr_Map to clear all pixel flags. It may be configured to remove the map from memory. It may be configured to clear a particular signal (e.g., Complete Pixel or Selective Control and or to apply to a subset of pixel flags. The instruction may identify flags in the Map similarly to processes described for accessing pixels in the Worksheet (e.g. address a pixel flag or of flags or define flags to be cleared by a region encompassed by a geometric shape).

[0576] 3. Resize_PixMap It is similar to the Set_PixMap except that it copies the contents of the current Map (assuming they are within the new map coordinates) to the new map.

[0577] 4. Write_Map can clear or set one or more signal bits in a Flag(s). This is typically to set or clear the Selective Control Signal but may be used for other signals. For example, a distinct Flag (s) may be addressed, or a group of flags identified by a geometric shape in the Map Array.

[0578] In parallel processing embodiments of a THWITRS Engine the Encoder typically ensures that the preceding instructions 1-4 wait until processing completes for current pipelines that interact with the Pixel Map, or complete prior to initiating execution for a new pipe that will interact with the Map.

[0579] 5. Act_Auto_PixComp activate automatic update of the Complete Pixel Signal of the Flag related to a pixel(s) updated by execution of an instruction configured to enable this process.

[0580] 6. Dis_Auto_PixComp disables auto update of the Complete Pixel Signal.

[0581] 7. Act_Auto_Pixl nt activate automatic update of the Intermediate Pixel Signal of the Flag related to a pixel(s) updated by execution an instruction configured to enable this process.

[0582] 8. Dis_Auto_Pixlnt disables auto update of the Intermediate Pixel Signal.

[0583] 9. Enable_PixComp enables a reconstruction method configured for use with a Pixel Complete Signal to do so as applicable. 10. Disable_PixComp turns off the preceding instruction.

[0584] 11 . Enable_Pixlnt enables a reconstruction method configured for use with an Intermediate Pixel Signal to recognise an Intermediate Pixel and may use information stored in said Pixel.

[0585] 12. Disable_Pixlnt turns off the preceding instruction.

[0586] 13. Modify_Pixlnt allows said First Method to change a value in the related intermediate pixel.

[0587] 14. DisMod_Pixlnt disables the previous instruction.

[0588] 15. Enable_Selective enables a reconstruction method configured for use with a Selective Signal to do so as applicable.

[0589] 16. Disable_Selective turns off the preceding instruction.

[0590] A single instruction may be used to provide the function of all instructions 5-16 by using one byte of operand to signal the on / off states. For Example: Bit 0= Act_Auto_PixComp Active / lnactive, Bit 1= Act_Auto_Pixlnt Active / lnactive, Bit 2= Enable_PixComp Active / lnactive, Bit 3= Enable_Pixlnt Active / lnactive, Bit 4= Modify_Pixlnt Active / lnactive, Bit 5= Enable_Selective Active / lnactive. Reconfiguring the use of Bit 0 and using bits 6 and 7 may be used to flag final Values for each of Red, Green and Blue Attributes.

[0591] For a parallel processing embodiment, a new pipe typically takes the current register contents for instructions 5-16 into the pipe, said instructions remaining in their pipe entry state for the duration of the pipe, altered by MAP instruction in the pipe (that usually only acts locally in the pipe).

[0592] Examples uses of Pixel Map Signal include:

[0593] For a patch of pixels (typically a rectangular or square block) for encoding using a transform (e.g., DCT, DST, DWT, or another transform, including those disclosed elsewhere in this document), an inverse transform for decoding the patch may be configured to take advantage of an excluded pixel. The Encoder may have plural options, for example:

[0594] The Encoder may replace the pixel values in the block with any value that it determines will enhance the value of the transform (e.g., improved reproduction of a pixel attribute, less filtering or correction, etc.). This may include averaging with surrounding pixels or Al processing to optimise a value for the pixel prior to transform. This may improve the inverse transform, improve quantisation and or reduce the number of nonzero coefficients. For excluded pixels with a final or intermediate value, said value may be used to augment or replace the quantisation of one or more pixels for transform (e.g., an excluded pixel attribute may be added, subtracted, divided by, multiplied by a coefficient prior to inverse transform. The result of an inverse transform may also be mathematically combined with a value of an excluded pixel to reduce error in the restored inverse transform pixel. The number of residuals required to repair pixels after the inverse transform may be reduced by an excluded pixel in the block (see hereunder).

[0595] Prior Art Intraframe prediction use known pixels attributes to predict the values for other pixels. It typically predicts a block of pixels using the row of known pixels immediately above the block and the column immediately to the left of the block. For each pixel in the block an algorithm predicts said pixel using one or more pixels in the row and or column. DC, Planar or Directional modes describe the particular algorithm for using the known values. AV1 use 56 directional modes identified by various angles of lines drawn through the block. The value of excluded pixels may be used to provide additional algorithms that may modify their behaviour depending on the location or value of the excluded pixel. Additionally, an excluded pixel does not require prediction. Predicted pixels typically require repair of predicted values outside an acceptable range and an excluded pixel does not require said repair.

[0596] Many of the processes in the reconstruction of an image produce an approximate value for a pixel that may require improvement usinga residual value (the difference between the approximated value and the actual value). A repair process may only result in an improved approximation. Other pixels will not have been reconstructed at all and may require further processing. Residuals may be entropy encoded to reduce the bit count of the bitstream used to transfer them to the decoder or they may be transformed first and then entropy encoded. A plurality of patterns (that may be defaults programmed into the decoder or included in the bitstream) may be provided to order residual values, selecting the optimal pattern for entropy encoding. This is described elsewhere; however, a residual is not required for an excluded complete pixel and may not be needed for other types of excluded pixels.

[0597] For residuals applied to pixels along a particular path, the simplest approach is to skip an excluded pixel that it would normally have processed and instead process the next available pixel in the path. THWITRS includes instructions to operate on pixels and auto increment the drawing in the x and or y direction. Said instruction may be configured to adjust the auto increment of the x or y coordinate when encountering an excluded pixel to improve the efficiency of the process.

[0598] As a frame is reconstructed and the number of complete pixels increase, the opportunity for utilising the Pixel Map typically improves. The bit cost of operating the Pixel Map may be trivial, offering Al in particular, the opportunity to capitalise on minimalist potential improvements or infrequent opportunities (e.g., excluded pixels useful as quantisation) for little cost.

[0599] A sequence of residuals may be provided that include additional information in the sequence (or coupled to the sequence, e.g. a separate sequence) to respond in a particular way when encountering an excluded pixel. For example, it may skip over, turn right, or left or for an array of pixels represented as a 3D array (or synthetic 3D array), change depths. Values in an excluded pixel may be used alone or in combination with information in the sequence of residuals. For example, the least significant bit of an attribute may have little impact of human perception of the displayed image, and the Encoder may use this Isb to signal another process to behave in a particular way (e.g., 0= skip pixel, 1 = turn right in the path of updating with residuals). We reference this as Interactive Redirection. It becomes increasingly effective as the Worksheet is populated with final pixel values. This process may be facilitated by constructing a boundary within the Worksheet that is represented by a pattern of Selective Control Signals in the Pixel Map, for example to identify a circle of pixels (or another shape, e.g., as described for drawing objects / shapes in the Worksheet), said boundary modifying the behaviour of a process (e.g., THWITRS drawing instructions, Interactive Redirection) when it meets the boundary. This may apply for a process operating outside the boundary (e.g., outside the circle) or within the boundary.

[0600] It should be noted that the Encoder knows the content of each pixel in the Worksheet at each step of reconstruction. As such, with the exception of the Selective Control Signal, the decoder may be instructed to read the value of the next pixel and if not a default value, treat it as a final or intermediate pixel to provide an alternative method to provide the same functionality as the pixel map. The encoder knows if it can take advantage of this information and needs to provide guidance in the bitstream for a Pixel Map or alternative method. For example, after an inverse transform, the pixel values can be written back to the block of pixels, with each location checked first for a non-default value, and if already populated, the result of the inverse transform for that pixel does not overwrite information present in the pixel. A difficulty of replacing the Pixel Map method is that the process updating pixels with residuals will not know which pixels to skip, as previous and new values will not be the default values. This may be circumvented by keeping a copy of the previously written pixels elsewhere in the Worksheet and referencing the copy. This is messy and may require more processing while providing no advantage over the use of a Pixel Map that has the added advantage of a Selective Control Signal and arbitrary boundaries within the Map.

[0601] Reconstruction processes may leverage the pixel map to consider the completion or intermediate status of pixels when making processing decisions. However, for some processes, the same leverage may be available without use of the map because the Encoder knows during the encoding process that it will fix a pixel after said process. Those skilled in the art can determine the appropriate approach based on the implementation details provided herein. A Pixel Map is further described with reference to Figure 5 of the drawings.

[0602] Parallel Processing Controls Embedded in the Bitstream

[0603] The techniques disclosed herein for embedding control information within threads of a stream are not limited to image systems or codecs, but apply generally to any digital processing environment capable of executing a stream of instructions, data, or control signals. In one embodiment, a computer program stored on a non-transient medium — such as a solid-state drive, optical disk, flash memory, or remote server — is configured to include embedded multiprocessor control information that directs execution order, resource allocation, and synchronisation of concurrent tasks when the program is executed on a suitable processing system. In another embodiment, the program is downloaded over a network and executed within a virtual machine, GPU, CPU cluster, or programmable logic unit. Regardless of form or delivery mechanism, the stream comprises segments or “threads” with internal control structures such as semaphores, resource requests, and dependency indicators that manage how the system executes the program concurrently. The encoder, compiler, or authoring system responsible for generating this stream may optimise the placement and structure of control instructions to improve execution efficiency, reduce synchronisation overhead, or align with known hardware or virtual architecture.

[0604] This environment is facilitated by a variety of processing units such as CPU cores, GPU cores, or other processor elements, each referred to herein as a processor element. The term bitstream processor in the context of processing an AES refers to a virtual processor or other processing component for executing instructions in an AES at the decoder, however, in the broader context for other applications, it is a processing component of the multiprocessor environment that is fundamentally guided by the bitstream itself, with control information embedded directly in the stream. A stream suitable for multiprocessing usually comprises an arbitrary number of threads, each containing a variable number of bits, and typically includes a unique thread identifier for coordination. Identifiers may be recycled for new threads once prior usage has completed.

[0605] Multiprocessor control information is embedded within individual threads. This may include wait semaphores referencing one or more prerequisite threads, completion semaphores to indicate that processing is complete, or power semaphores that suggest or request resource allocation such as processor priority or type (e.g., GPU vs CPU). A thread allocated for processing or currently executing may share a processor, be isolated to one, or execute concurrently across multiple. A power semaphore may request specific resource levels or types; for example, a thread required to process downstream threads may request faster or higher priority processing.

[0606] Importantly, the control information embedded in the stream may be read, interpreted, or executed by a virtual processor, hardware block, firmware agent, or other execution environment. The stream may exist in serial or segmented form, and may be stored in non-volatile memory, streamed over a network, or received by a decoder in realtime. This general framework is applicable not only to image decoding, but to any parallel execution architecture that benefits from stream-embedded control, including Al models, edge processing pipelines, streaming media processors, task-based simulation engines, or custom silicon decoding arrays.

[0607] The encoder, having insight into the structure, sequence, and dependencies of the original input data, may construct the stream in a manner optimised for parallel execution, balancing resource usage and preserving correct ordering. This stands in contrast to systems where the decoder or processor is responsible for deriving parallelism after reception. Here, parallel processing behaviour is embedded within the stream itself by the encoder or compiler, forming an active and entangled stream.

[0608] This active control structure may be embodied in a file, software object, firmware image, or in-system program, enabling its execution on a wide variety of general-purpose and domain-specific processors. The same stream format and execution framework may be applied to the decoding of images (e.g., THWITRS virtual machine), structured audio, scene graph evaluation, or any system where encoder-authored control over task parallelism is beneficial.

[0609] The embed control of parallel process is further described with reference to its application for controlling the parallel reconstruction of images at the decoder, however, the exemplary processes described may be used for other applications that embed multiprocessor control in the bitstream.

[0610] Control of multiple instantiations of the virtual processor to process multiple threads of an AES is fundamentally guided by the bitstream, with control information typically embedded in the actual bitstream. An AES configured for multiprocessing usually comprises an arbitrary number of threads, where a thread consists of a variable number of bits and is usually uniquely identified to maintain clear differentiation from other threads. However, after processing a certain number of threads, it may be appropriate to recycle an ID for a new thread without causing ambiguity. This reuse mechanism allows for efficient management of identifiers over long sequences of threads. Multiprocessor control information pertaining to a particular thread is usually embedded in said thread. This design dictates the operational dynamics of the system, enabling a versatile processing approach.

[0611] A Resource Allocation component interconnected with the Engine provides the capability to manage and facilitate the multiprocessing of the bitstream. This component is equipped to manage various operations as dictated by the bitstream's content, which may include initiating, orchestrating, or managing processing a thread. Processing threads can occur in parallel across multiple processor elements, be dedicated to a single processor element, or share a processor element with other threads in a concurrent execution setup. The distribution and management of these processing tasks are dictated by scheduling and control mechanisms within the multiprocessor environment, in conjunction with any synergistically linked components. A thread is catalogued in a management structure, such as a table, where it is marked with a Thread ID and a specific status indicating whether it is awaiting execution, currently executing, or has completed execution. This management structure plays a role in orchestrating the sequence of processing activities, ensuring an organised and efficient execution flow. A thread typically identifies the Thread IDs of other threads that to be processed prior to its own execution. This dependency mapping ensures that the necessary precedents are met before a thread is processed, maintaining the integrity and sequence of the overall processing task. The system allows flexible processing sequences, wherein a thread can commence processing up to a predetermined point and then pause, pending the completion of prerequisite threads, before resuming and finalising its processing. Upon the completion of its processing, a thread triggers a 'complete' flag within the management structure, signifying the end of its execution phase. This flagging mechanism aids in the dynamic monitoring and coordination of the multi-stage processing environment, facilitating a seamless and logical progression of thread processing within the bitstream processor's multiprocessor framework. The process may be further refined, by including a Power Semaphore in a thread that indicates a requested amount of processing capability for the thread (e.g., plural processor elements, a dedicated single processor element). For example, a thread that must be processed before the processing of multiple dependent threads may request faster processing than a less important thread. Whether or not the request is granted (or can be granted) may depend on available resources or the importance of the semaphore. The internal mechanics of the system may downgrade the resource for a first thread to enhance a second thread. A semaphore (e.g., a power semaphore) may also request a particular type of core (e.g., CPU, GPU). The disclosed semaphores are not intended to be limiting.

[0612] A Semaphore is typically implemented as an instruction in theTHWITRS Instruction Set, wherein execution of the instruction initiates the associated event, or as metadata.

[0613] The encoder, armed with comprehensive knowledge of the source image, the encoded image, and or the encoding methods, optimises the bitstream for processing in a multiprocessor environment. This optimisation offloads the task from destination computer resources, which lack such insight, but also enhances efficiency due to the encoder's superior understanding. For an encoder implementation that includes a competitive compiling, various multiprocessor strategies may be evaluated for optimal performance.

[0614] The bitstream is segmented into an arbitrary number of threads, each containing a variable number of bits, facilitating parallel processing. At the start of each thread, a Wait Semaphore control and associated Thread IDs are typically placed, preventing any processing of the thread until the prerequisites set by these Thread IDs are met. This setup ensures that the processing sequence adheres to the necessary dependencies, maintaining an orderly and efficient flow. Additionally, the encoder may stagger one or more Wait Semaphores and their related Thread IDs throughout the thread. This method allows for parts of a thread to be processed as soon as its specific prerequisites are fulfilled, optimising the use of multiprocessing resources, and enabling a more fluid and continuous processing pipeline. To clarify this, in certain embodiments, a thread may have multiple dependencies on other prerequisite threads, but not all parts of the thread may require all dependencies to be met simultaneously. To optimise parallel processing throughput and reduce idle processor time, the encoder is configured to strategically embed Wait Semaphores at various points within a thread's bitstream. Each such embedded Wait Semaphore indicates specific prerequisite threads that must complete before the portion of the current thread following that particular Wait Semaphore can execute. This allows for a 'pipelined' or 'staged' execution of a single thread. For example, a thread T may have dependencies on prerequisite threads P1 , P2, and P3 for its full execution. However, an initial segment of thread T (T_segment_A) might only require P1 and P2 to complete. A Wait Semaphore referencing P1 and P2 would be embedded at the end of T_segment_A. Once P1 and P2 complete, T_segment_A can begin execution. A later segment of thread T (T_segment_B) might then require P3. A second Wait Semaphore referencing P3 would be embedded at the end of T_segment_B. This enables T_segment_A to execute concurrently with P3's completion, rather than waiting for P3 to finish before any part of thread T can begin. This dynamic, intra-thread dependency management allows for finer- grained control over execution flow, significantly improving processor utilisation by allowing partial thread execution even when all its ultimate dependencies are not yet resolved.

[0615] The process may be further refined by including a Power Semaphore control in a thread, indicating a requested amount of processing capability for the thread, such as requiring multiple processor elements for faster processing or a dedicated single processor element for less urgent processing tasks. Threads crucial for the processing of multiple dependent threads may thus request faster processing compared to less critical ones. The actual allocation of resources, influenced by the Power Semaphore, may lead to the adjustment of resources among threads to optimise processing efficiency, potentially downgrading the resource allocation for one thread to enhance another. A semaphore (e.g., a power semaphore) may also request a particular type of core (e.g., CPU, GPU). The disclosed arrangement for parallel processing of a bitstream, may also be executable by a Bitstream Processor consisting of a single processor (e.g., one CPU or one processor core) by configuring it to share processing between multiple threads.

[0616] The usual implementation of the bitstream is a sequence of computer instructions encoding the image, such that the execution of the program reconstructs the image at the decoder. The Semaphore ID may be implemented through a Semaphore ID instruction. A Wait Semaphore is represented by includingthe ID of threads that must be processed beforehand in the operand of the instruction. These Semaphore instructions can be placed arbitrarily throughout the program as determined. A Completion Semaphore instruction signifies the end of a thread's processing. Additionally, a Power Semaphore Instruction, with an operand specifying priority, dictates the allocation of processing power to the thread.

[0617] In Summary for the parallel processing of a bitstream for reconstruction of an image encoded in the bitstream, we have described:

[0618] • An Encoder component operable for encoding information into a bitstream, said component further operable to embed information within the bitstream to manage parallel processing of a plurality of threads of bits in the bitstream.

[0619] • Non-transient computer readable media storing or for storing a bitstream incorporating information specifically designed to manage the parallel processing of said bitstream.

[0620] • A Decoder component operable for processing a bitstream in a parallel processing environment, wherein the environment is configured to dynamically allocate multiple resources across different threads of bits in the bitstream, guided by the information encoded within the bitstream itself.

[0621] Timing differences may be critical for the parallel processing of threads. A thread may set registers local to the thread, e.g., pos (x,y) or set origin that only apply to said thread. A solution is to specifically encode the local parameters into the thread; however, this may be inefficient as multiple threads may be using the same parameters and duplicating these parameters for each thread. The preferred embodiment uses global registers values for these parameters (e.g. pos x,y, set origin) that are updated by the encoder as required and collected by a thread as required. As the timing of execution of a thread and a change to a global register may be uncoordinated, a method is disclosed to circumvent this problem to ensure that a thread collects the correct parameter values. A preferred method creates a plurality of registers for a particular parameter and a thread loads data from the correct register of said plurality. The Encoder knows the byte position of a Global Register instruction in a bitstream and the byte position of the start of a new thread (or another reference for the thread). Global Register Instructions may be executed immediately and stored with the ID of the Register, the parameters, and the byte position in the bitstream of the instruction. A plurality of the same register ID and coupled data may be stored in a pipe and fall out when no longer required (a process readily controlled by the Encoder). Other variations are known to the art. When a new thread arrives at the decoder it can be tagged with its byte position in the bitstream. When said thread is executed, it is coupled with the stored parameters for the register with closest byte position count that is lower than the byte position of the thread. For example, if two pos (x,y) instructions have entered the Engine, the most recent byte position #3452872 for the frame and the earlier #3453704, a thread with a byte position greater than 3453704 and less than 3452872 would be coupled to the earlier pos (x,y). If greater than 3452872 it would couple with the latter pos (x,y). If less than 3453704 it would couple with an earlier pos (x,y) than the aforementioned two pos (x,y). This process avoids the Encoder having to provide specific register values for each thread unless necessary.

[0622] EXAMPLE APPLICATIONS USING THWITRS

[0623] THWITRS Integration with Existing Codecs

[0624] Vulkan Video leverages the dedicated video decode / encode engines present on many GPUs. These engines are specifically designed to handle video codecs like H.264 efficiently. New Vulcan extensions to the Vulkan API provide the necessary interfaces and data structures for applications to interact with the hardware video engines. The separate queues for video decode and encode operations allows video tasks to be processed independently of other graphics or compute workloads. THWITRS may structure a compressed bitstream (e.g., H.264) in the AES as a sequence of Push Instructions using Integrated Push Extended (IPE) Instruction plus a location in the worksheet to return the decoded image, frame or patch, and an IPE instruction to activate transfer of the pushed data to the Vulcan decode queue, receiving the decoded image in the requested worksheet (or a host resource). This method may be applied to any codec. For encoding, a raw patch / frame / image may be submitted to the encode queue and the compressed bitstream returned for conversion to an IPE instruction. Although the data in the push stack is a compressed patch of pixels using a prior art method, it may be that the Adaptive Entropy Encoder may have improved the compression by using a novel method not available to the prior art algorithm.

[0625] THWITRS with 3D Graphics and Games

[0626] The THWITRS system may present image and texture data as a single structured data blob (e.g., a MsgPack object), interpreted by a small player module and rendered into an image for deployment. This architecture integrates naturally into modern game engines, where polygon skins and objects are often derived from image-based textures. By embedding the THWITRS virtual machine (VM) within a GPU shader, textures can be generated or updated in real-time. For example, dynamic in-game billboards, which map a texture onto a polygon surface, can be updated by simply refreshing the THWITRS render image. All spatial transformations — including lighting and camera effects — are handled by the host game engine. This system allows subtle or frequent content changes, such as animating shirt logos, modifying vehicle decals, or integrating tiny video elements into clothing. Unlike conventional methods that depend on external video codecs (e.g., AV1 or JPEG), THWITRS requires only one data format and one lightweight player. THWITRS also supports Markov jump modelling, enabling probabilistic content variation. For instance, configuring the VM to process chunks at 10 per second with a jump probability of 1 in 36,000 creates a roughly hourly trigger event. By cascading multiple low-probability jumps, rare content variations — such as randomized in-ga...

Claims

. The method of any one of claims 14 to 18, wherein said executable instructions comprise reading or writing pixel attributes.

20. The method of any one of claims 12 to 19, wherein allocation of memory, lifetime of pixel regions, or reuse of a region of pixels is determined by the encoder.

21. The method of any one of claims 12 to 20, wherein locations, regions, or addresses specified for construction are determined by the encoder and are arbitrary, and are not constrained to any predetermined raster sequence, scan order, or sequential construction protocol of the decoding system.

22. The method of claim 20 or claim 21 , wherein said determination is based on optimising image compression independent of a predetermined construction protocol of the decoding system.

23. The method of claim 22, wherein said optimisation is facilitated by a competitive compiler operatively coupled to the encoder.

24. The method of claim 23, wherein the competitive compiler selects from a plurality of distinct encoding strategies for encoding a patch of pixels.

25. The method of claim 24, wherein said patch is one of a plurality of patches for use in constructing a frame of the image at the decoding system.

26. The method of any one of claims 15 to 25, wherein the decoding system comprises a processor for executing the instructions, said execution constructing patches in encoder-determined locations.

27. The method of claim 26, wherein the processor is a virtual processor.

28. The method of claim 27, wherein said virtual processor is configured for execution in a graphics processing unit.

29. The method of any of claims 12 to 28, wherein the sequence decoded at the decoding system causes construction of the image by constructing a plurality of patches of pixels in memory.

30. The method of any one of claims 12 to 29, wherein construction of the image at the decoding system comprises constructing a plurality of patches of pixels, each patch in a respective region of the memory.31 . The method of claim 30, further comprising performing an operation on the constructed patch.

32. The method of claim 31 , wherein the operation comprises at least one of copying, scaling, blending, overwriting, or modifying pixel attributes.

33. The method of claim 32, wherein copying comprises copying the constructed patch to another region of the memory.

34. The method of claim 33, wherein copying the constructed patch comprises copying the constructed patch onto another constructed patch in the memory.

35. The method of claim 34, wherein copying the constructed patch onto the other constructed patch comprises compositing the constructed patch with the other constructed patch.

36. The method of claim 35, wherein the compositing comprises at least one of overwriting, blending, or applying an alpha contribution.

37. The method of any one of claims 34 to 36, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of the other constructed patch.

38. The method of any one of claims 34 to 36, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of the other constructed patch.

39. The method of any one of claims 34 to 38, wherein the compositing comprises modifying a pixel attribute of the other constructed patch.

40. The method of any one of claims 30 to 39, wherein the constructed patch is constructed in a worksheet region of the memory.41 . The method of claim 33 or claim 40, wherein the constructed patch is copied to a region of the memory for grouping a plurality of patches.

42. The method of claim 41 , wherein copying the constructed patch to the grouping region comprises compositing the constructed patch with at least one patch already in the grouping region.

43. The method of claim 42, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the grouping region.

44. The method of claim 42 or claim 43, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the grouping region.

45. The method of claim 42 or claim 43, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the grouping region.

46. The method of any one of claims 41 to 45, wherein copying the constructed patch to the grouping region comprises transforming the constructed patch.

47. The method of claim 46, wherein the transforming comprises scaling the constructed patch.

48. The method of claim 46 or claim 47, wherein the transforming comprises at least one of rotation, mirroring, flipping, skewing, warping, shearing, or geometric distortion of the constructed patch.

49. The method of any one of claims 41 to 48, wherein the copying comprises changing a pixel attribute of the constructed patch.

50. The method of any one of claims 41 to 49, wherein the grouping comprises at least part of a layer for a frame of the image.51 . The method of claim 50, wherein the grouping is copied to another region of the memory for grouping with another patch or plurality of patches for representing a frame of the image.

52. The method of claim 51 , wherein the copying comprises scaling the grouping.

53. The method of claim 51 or claim 52, wherein the copying comprises compositing the grouping with at least one patch previously in the region of memory used for representing the frame.

54. The method of claim 53, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the region for representing a frame.

55. The method of claim 53 or claim 54, wherein the patch used in the compositing comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the region for representing a frame.

56. The method of claim 53 or claim 54, wherein the patch used for the compositing comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the region for representing a frame.

57. The method of any of claims 50 to 56, wherein the region for representing a frame is a Render Image.

58. The method of any of claims 41 to 57, wherein the region for grouping is a Viewport.

59. The method of any one of claims 12 to 58, wherein construction of patches occurs asynchronously with respect to a frame rate, raster timing, or display timing of the decoding system.

60. The method of any one of claims 12 to 59, wherein the encoder determines an arbitrary temporal order for construction of patches, the temporal order being independent of a predetermined scan order or picture order count of the decoding system.

61. The method of any one of claims 12 to 60, wherein at least one constructed patch persists across a plurality of frames without being reconstructed for each frame.

62. The method of any one of claims 12 to 61 , wherein a patch constructed in memory for a first frame is reused in a subsequent frame without modification.

63. The method of any one of claims 12 to 62, wherein the encoder specifies a duration over which a patch is retained in memory for reuse in constructing a plurality of frames.

64. The method of any one of claims 12 to 63, wherein a constructed patch is constructed at a resolution that differs from a resolution of the image being encoded or displayed.

65. The method of any one of claims 12 to 64, wherein the encoder determines a grouping structure for patches comprising at least one of a layer, sub-layer, viewport, or composite region.

66. The method of any one of claims 12 to 65, wherein at least one constructed patch is used to apply a special effect comprising modification of colour, brightness, tone, contrast, or a geometric or stylistic transformation of another patch or region.

67. The method of any one of claims 12 to 66, wherein at least one constructed patch is used to compensate for lighting variation, colour variation, or other inter-frame visual changes.

68. The method of any one of claims 12 to 67, wherein at least one constructed patch is used to modify attributes of another patch, the modification comprising at least one of luminance adjustment, chrominance adjustment, colour balancing, tinting, or brightness correction.

69. The method of any one of claims 12 to 68, further comprising maintaining, at the decoding system, a per-pixel or per-region state structure indicating whether a pixel or region of pixels has been updated, constructed, modified, or remains valid, and wherein construction of patches is performed conditionally based on said state structure so as to avoid reconstructing pixels or regions that remain valid.

70. The method of claim 69, wherein the state structure incurs minimal or no overhead in the bitstream, the decoder dynamically determining the state structure from operations executed during construction of patches, and the encoder determining the state at each step from the instructions it generates.71 . The method of any of claims 12 to 70, wherein constructing a patch of pixels comprises constructing a reduced-resolution representation of the patch in memory.

72. The method of claim 71 , wherein constructing the patch further comprises upscaling the reduced- resolution representation to a higher resolution and applying refinement information encoded in the bitstream to the upscaled representation.

73. The method of any one of claims 71 or 72, wherein the encoder determines two or more resolution levels for progressive reconstruction of the patch, each level being constructed asynchronously with respect to construction of a frame of the image.

74. The method of any one of claims 71 to 73, wherein the progressive reconstruction comprises constructing the reduced-resolution representation and applying one or more refinement patches comprising luminance or chrominance updates.

75. The method of any one of claims 71 to 74, wherein refinement information applied between resolution levels comprises residual pixel-attribute differences relative to a prediction derived from a lower-resolution representation.

76. The method of any of claims 12 to 75, further comprising synchronising a reconstruction state of memory at the decoding system by applying state-correction information encoded in the bitstream.

77. The method of claim 76, wherein the state-correction information comprises at least one of: a) pixelattribute deltas; b) replacement of pixel attributes; c) overwriting a subregion of the memory; or d) reconciling drift between the reconstruction state at the decoding system and a reference reconstruction state maintained by the encoder.

78. The method of any one of claims 76 or 77, wherein the state-correction information is applied when the decoding system initiates or resumes playback from a non-sequential position in the bitstream.

79. The method of claim 78, wherein the non-sequential position arises from at least one of: a change of playback speed, a jump in playback position, a change of rendered resolution, a reconfiguration of a viewport, or a change in selection of content to be displayed.

80. The method of any one of claims 76 to 79, wherein the state-correction information brings the reconstruction state of memory into alignment with a state that would have been obtained by continuous sequential decoding to the non-sequential position.81 . The method of any one of claims 76 to 80, wherein the synchronising is performed independently of any group-of-pictures structure, frame sequence, or hierarchical frame dependency of the decoding system.

82. The method of any of claims 12 to 81 , comprising: identifying, at the encoder, a rectangular prediction block of an image; identifying a set of equal-sized reference blocks adjacent to or surrounding the prediction block; determiningthatthe reference blocks do not align with the prediction block due to at least one of: spatial offsets, intervening gaps, or differing coordinate origins; deriving an asymmetric quadrilateral by averaging pixel attributes at corners of adjacent reference blocks; and constructing a predictor for the rectangular prediction block by copying or mapping the asymmetric quadrilateral into the rectangular prediction block.

83. The method of claim 82, wherein the predictor constructed from the asymmetric quadrilateral reduces residual magnitude between the prediction block and the image content encoded for that block.

84. The method of any of claims 12 to 83, comprising constructing an asymmetric region of pixels in memory based on pixel attributes taken from two or more reference regions that are not spatially aligned, wherein the asymmetric region is derived by interpolating or combining pixel attributes from misaligned boundaries of the reference regions, and the asymmetric region is used for constructing at least part of the image at the decoding system.

85. The method of claim 84, wherein the reference regions are equal-sized or equal-resolution regions that are displaced, offset, or separated by gaps relative to the asymmetric region.

86. The method of claim 84 or 85, wherein constructing the asymmetric region comprises determining a mapping between non-coincident edges or corners of the reference regions and applying the mapping to populate the asymmetric region.

87. The method of any one of claims 84 to 86, wherein the asymmetric region is used as at least one of: a) a predictor region; b) a constructed patch; c) a subregion of a viewport; or d) a subregion of a render image.

88. The method of any of claims 12 to 87, wherein construction of a patch in memory is performed according to a construction mode selected by the encoder.

89. The method of claim 88, wherein the construction mode comprises invoking a Special Purpose Engine (SPE) to perform operations defined by a sequence of symbols in the bitstream.

90. The method of claim 89, wherein the SPE is supplied with pixel data, parameters, or intermediate values pushed onto a stack in memory, and wherein the SPE outputs constructed pixel data to at least one region of memory.

91. The method of claim 90, wherein the SPE writes the constructed pixel data to a worksheet region of memory.

92. The method of any one of claims 88 to 91 , wherein the construction mode comprises constructing the patch by executing drawing primitives, geometric primitives, or analytical functions defined by the sequence of symbols.

93. The method of claim 92, wherein the drawing or geometric primitives comprise at least one of: a line, curve, vector path, parametric shape, polygon fill, region fill, or filter kernel.

94. The method of any one of claims 88 to 93, wherein the construction mode comprises constructing the patch from a reduced-resolution representation of the patch determined by the encoder.

95. The method of claim 94, wherein constructing the patch comprises upscaling the reduced-resolution representation and applying refinement information including at least one of luminance updates, chrominance updates, residual updates, or enhancement information.

96. The method of any one of claims 88 to 95, wherein the construction mode comprises constructing the patch using an asymmetric predictor derived from reference regions determined by the encoder.

97. The method of claim 96, wherein constructing the patch comprises applying a mapping from noncoincident boundaries of the reference regions to populate an asymmetric region used as a predictor.

98. The method of any one of claims 88 to 97, wherein the construction mode comprises synthesising pixel attributes for at least a portion of the patch using interpolation, extrapolation, neighbourhood statistics, or encoder-determined analytic synthesis.

99. The method of any one of claims 88 to 98, wherein the construction mode comprises combining pixel attributes drawn from two or more reference patches, reference regions, or previously constructed patches.

100. The method of any one of claims 88 to 99, wherein the encoder selects the construction mode from a plurality of construction modes based on a competitive assessment of alternative patch-construction strategies.

101. The method of claim 100, wherein the competitive assessment comprises optimising at least one of: entropy of the resulting bitstream, prediction error, memory allocation efficiency, execution cost at the decoding system, or the number of instructions required to construct the patch.

102. An encoder for encoding an image into a bitstream stored on non-transitory computer-readable media, the encoder comprising a processor configured to: generate a sequence of symbols that includes: a) a sequence defining image content; b) a sequence defining control operations for directing an order, manner, or selection of operations for construction of the image; and c) a sequence defining memorymanagement operations for controlling allocation, reuse, retention, or lifetime of pixel regions in a memory of a decoding system; wherein the sequences collectively specify locations, regions, or addresses in said memory for construction of at least part of the image at the decoding system; and encode the sequences as the bitstream for provision to the decoding system to cause the image to be constructed.

103. The encoder of claim 102, wherein the processor is configured to generate a sequence of symbols for controlling parallel processing of the bitstream at the decoding system.

104. The encoder of claim 102 or claim 103, wherein the sequence comprises instructions.

105. The encoder of claim 104, wherein said instructions are executable by the decoding system.

106. The encoder of claim 105, wherein said executable instructions are operable on pixel space.

107. The encoder of claim 106, wherein said executable instructions address a pixel attribute by an (x, y) coordinate in a two-dimensional array of pixels.

108. The encoder of claim 106 or claim 107, wherein said executable instructions address a pixel attribute by an (x, y, z) coordinate in a three-dimensional array of pixel attributes.

109. The encoder of any one of claims 104 to 108, wherein said executable instructions comprise reading or writing pixel attributes.

110. The encoder of any one of claims 102 to 109, wherein the processor is configured to determine allocation of memory, lifetime of pixel regions, or reuse of a region of pixels.

111. The encoder of any one of claims 102 to 110, wherein the processor is configured to determine locations, regions, or addresses for construction arbitrarily, not constrained to any predetermined raster sequence, scan order, or sequential construction protocol of the decoding system.

112. The encoder of claim 110 or claim 111 , wherein said determination is based on optimising image compression independent of a predetermined construction protocol of the decoding system.

113. The encoder of claim 112, wherein said optimisation is facilitated by a competitive compiler operatively coupled to the encoder.

114. The encoder of claim 113, wherein the competitive compiler is configured to select from a plurality of distinct encoding strategies for encoding a patch of pixels.

115. The encoder of claim 114, wherein said patch is one of a plurality of patches for use in constructing a frame of the image at the decoding system.

116. The encoder of any one of claims 105 to 115, wherein the processor is configured to generate instructions executable by a processor of the decoding system for constructing patches in encoder- determined locations.

117. The encoder of claim 116, wherein the processor of the decoding system is a virtual processor.

118. The encoder of claim 117, wherein said virtual processor is configured for execution in a graphics processing unit.

119. The encoder of any of claims 102 to 118, wherein the processor is configured to generate a sequence that causes construction of the image at the decoding system by constructing a plurality of patches of pixels in memory.

120. The encoder of any one of claims 102 to 119, wherein the processor is configured to generate symbols that cause construction of the image at the decoding system by constructing a plurality of patches of pixels, each patch in a respective region of the memory.

121. The encoder of claim 120, wherein the processor is configured to generate symbols defining an operation to be performed on the constructed patch.

122. The encoder of claim 121 , wherein the operation comprises at least one of copying, scaling, blending, overwriting, or modifying pixel attributes.

123. The encoder of claim 122, wherein copying comprises copying the constructed patch to another region of the memory.

124. The encoder of claim 123, wherein copying the constructed patch comprises copying the constructed patch onto another constructed patch in the memory.

125. The encoder of claim 124, wherein copying the constructed patch onto the other constructed patch comprises compositing the constructed patch with the other constructed patch.

126. The encoder of claim 125, wherein the compositing comprises at least one of overwriting, blending, or applying an alpha contribution.

127. The encoder of any one of claims 124 to 126, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of the other constructed patch.

128. The encoder of any one of claims 124 to 126, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of the other constructed patch.

129. The encoder of any one of claims 124 to 128, wherein the compositing comprises modifying a pixel attribute of the other constructed patch.

130. The encoder of any one of claims 120 to 129, wherein the processor is configured to specify that the constructed patch is to be constructed in a worksheet region of the memory.

131. The encoder of claim 123 or claim 130, wherein the processor is configured to generate symbols specifying that the constructed patch is to be copied to a region of the memory for grouping a plurality of patches.

132. The encoder of claim 131 , wherein the processor is configured to generate symbols specifying that copying the constructed patch to the grouping region comprises compositing the constructed patch with at least one patch already in the grouping region.

133. The encoder of claim 132, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the grouping region.

134. The encoder of claim 132 or claim 133, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the grouping region.

135. The encoder of claim 132 or claim 133, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the grouping region.

136. The encoder of any one of claims 131 to 135, wherein the processor is configured to generate symbols specifying that copying the constructed patch to the grouping region comprises transforming the constructed patch.

137. The encoder of claim 136, wherein the transforming comprises scaling the constructed patch.

138. The encoder of claim 136 or claim 137, wherein the transforming comprises at least one of rotation, mirroring, flipping, skewing, warping, shearing, or geometric distortion of the constructed patch.

139. The encoder of any one of claims 131 to 138, wherein the copying comprises changing a pixel attribute of the constructed patch.

140. The encoder of any one of claims 131 to 139, wherein the grouping comprises at least part of a layer for a frame of the image.

141. The encoder of claim 140, wherein the processor is configured to generate symbols specifying that the grouping is to be copied to another region of the memory for grouping with another patch or plurality of patches for representing a frame of the image.

142. The encoder of claim 141 , wherein the copying comprises scaling the grouping.

143. The encoder of claim 141 or claim 142, wherein the copying comprises compositing the grouping with at least one patch previously in the region of memory used for representing the frame.

144. The encoder of claim 143, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the region for representing a frame.

145. The encoder of claim 143 or claim 144, wherein the patch used in the compositing comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the region for representing a frame.

146. The encoder of claim 143 or claim 144, wherein the patch used for the compositing comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the region for representing a frame.

147. The encoder of any of claims 140 to 146, wherein the region for representing a frame is a Render Image.

148. The encoder of any of claims 131 to 147, wherein the region for grouping is a Viewport.

149. The encoder of any one of claims 102 to 148, wherein the processor is configured to generate symbols such that construction of patches occurs asynchronously with respect to a frame rate, raster timing, or display timing of the decoding system.

150. The encoder of any one of claims 102 to 149, wherein the processor is configured to determine an arbitrary temporal order for construction of patches, the temporal order being independent of a predetermined scan order or picture order count of the decoding system.

151. The encoder of any one of claims 102 to 150, wherein the processor is configured to generate symbols such that at least one constructed patch persists across a plurality of frames without being reconstructed for each frame.

152. The encoder of any one of claims 102 to 151 , wherein the processor is configured to generate symbols such that a patch constructed in memory for a first frame is reused in a subsequent frame without modification.

153. The encoder of any one of claims 102 to 152, wherein the processor is configured to specify a duration over which a patch is retained in memory for reuse in constructing a plurality of frames.

154. The encoder of any one of claims 102 to 153, wherein the processor is configured to generate symbols such that a constructed patch is constructed at a resolution that differs from a resolution of the image being encoded or displayed.

155. The encoder of any one of claims 102 to 154, wherein the processor is configured to determine a grouping structure for patches comprising at least one of a layer, sub-layer, viewport, or composite region.

156. The encoder of any one of claims 102 to 155, wherein the processor is configured to generate symbols such that at least one constructed patch is used to apply a special effect comprising modification of colour, brightness, tone, contrast, or a geometric or stylistic transformation of another patch or region.

157. The encoder of any one of claims 102 to 156, wherein the processor is configured to generate symbols such that at least one constructed patch is used to compensate for lighting variation, colour variation, or other inter-frame visual changes.

158. The encoder of any one of claims 102 to 157, wherein the processor is configured to generate symbols such that at least one constructed patch is used to modify attributes of another patch, the modification comprising at least one of luminance adjustment, chrominance adjustment, colour balancing, tinting, or brightness correction.

159. The encoder of any one of claims 102 to 158, wherein the processor is configured to generate symbols that enable the decoding system to maintain a per-pixel or per-region state structure indicating whether a pixel or region of pixels has been updated, constructed, modified, or remains valid, and wherein construction of patches is performed conditionally based on said state structure so as to avoid reconstructing pixels or regions that remain valid.

160. The encoder of claim 159, wherein the state structure incurs minimal or no overhead in the bitstream, the decoder dynamically determining the state structure from operations executed during construction of patches, and the encoder determining the state at each step from the instructions it generates.

161. The encoder of any of claims 102 to 160, wherein the processor is configured to generate symbols that cause constructing a patch of pixels to comprise constructing a reduced-resolution representation of the patch in memory.

162. The encoder of claim 161 , wherein the processor is configured to generate symbols such that constructing the patch further comprises upscaling the reduced-resolution representation to a higher resolution and applying refinement information encoded in the bitstream to the upscaled representation.

163. The encoder of any one of claims 161 or 162, wherein the processor is configured to determine two or more resolution levels for progressive reconstruction of the patch, each level being constructed asynchronously with respect to construction of a frame of the image.

164. The encoder of any one of claims 161 to 163, wherein the progressive reconstruction comprises constructing the reduced-resolution representation and applying one or more refinement patches comprising luminance or chrominance updates.

165. The encoder of any one of claims 161 to 164, wherein refinement information applied between resolution levels comprises residual pixel-attribute differences relative to a prediction derived from a lower-resolution representation.

166. The encoder of any of claims 102 to 165, wherein the processor is configured to generate statecorrection information for synchronising a reconstruction state of memory at the decoding system.

167. The encoder of claim 166, wherein the state-correction information comprises at least one of: a) pixelattribute deltas; b) replacement of pixel attributes; c) overwriting a subregion of the memory; or d) reconciling drift between the reconstruction state at the decoding system and a reference reconstruction state maintained by the encoder.

168. The encoder of any one of claims 166 or 167, wherein the state-correction information is configured to be applied when the decoding system initiates or resumes playback from a non-sequential position in the bitstream.

169. The encoder of claim 168, wherein the non-sequential position arises from at least one of: a change of playback speed, a jump in playback position, a change of rendered resolution, a reconfiguration of a viewport, or a change in selection of content to be displayed.

170. The encoder of any one of claims 166 to 169, wherein the state-correction information brings the reconstruction state of memory into alignment with a state that would have been obtained by continuous sequential decodingto the non-sequential position.

171. The encoder of any one of claims 166 to 170, wherein the synchronising is performed independently of any group-of-pictures structure, frame sequence, or hierarchical frame dependency of the decoding system.

172. The encoder of any of claims 102 to 171 , wherein the processor is configured to: identify a rectangular prediction block of an image; identify a set of equal-sized reference blocks adjacent to or surrounding the prediction block; determine that the reference blocks do not align with the prediction block due to at least one of: spatial offsets, intervening gaps, or differing coordinate origins; derive an asymmetric quadrilateral by averaging pixel attributes at corners of adjacent reference blocks; and generate symbols for constructing a predictor for the rectangular prediction block by copying or mapping the asymmetric quadrilateral into the rectangular prediction block.

173. The encoder of claim 172, wherein the predictor constructed from the asymmetric quadrilateral reduces residual magnitude between the prediction block and the image content encoded for that block.

174. The encoder of any of claims 102 to 173, wherein the processor is configured to generate symbols for constructing an asymmetric region of pixels in memory based on pixel attributes taken from two or more reference regions that are not spatially aligned, wherein the asymmetric region is derived by interpolating or combining pixel attributes from misaligned boundaries of the reference regions, and the asymmetric region is used for constructing at least part of the image at the decoding system.

175. The encoder of claim 174, wherein the reference regions are equal-sized or equal-resolution regions that are displaced, offset, or separated by gaps relative to the asymmetric region.

176. The encoder of claim 174 or 175, wherein constructing the asymmetric region comprises determining a mapping between non-coincident edges or corners of the reference regions and applying the mapping to populate the asymmetric region.

177. The encoder of any one of claims 174 to 176, wherein the asymmetric region is used as at least one of: a) a predictor region; b) a constructed patch; c) a subregion of a viewport; or d) a subregion of a render image.

178. The encoder of any of claims 102 to 177, wherein the processor is configured to select a construction mode for construction of a patch in memory.

179. The encoder of claim 178, wherein the construction mode comprises invoking a Special Purpose Engine (SPE) to perform operations defined by a sequence of symbols in the bitstream.

180. The encoder of claim 179, wherein the processor is configured to generate symbols that supply the SPE with pixel data, parameters, or intermediate values pushed onto a stack in memory, and wherein the SPE outputs constructed pixel data to at least one region of memory.

181. The encoder of claim 180, wherein the SPE writes the constructed pixel data to a worksheet region of memory.

182. The encoder of any one of claims 178 to 181 , wherein the construction mode comprises constructing the patch by executing drawing primitives, geometric primitives, or analytical functions defined by the sequence of symbols.

183. The encoder of claim 182, wherein the drawing or geometric primitives comprise at least one of: a line, curve, vector path, parametric shape, polygon fill, region fill, or filter kernel.

184. The encoder of any one of claims 178 to 183, wherein the construction mode comprises constructing the patch from a reduced-resolution representation of the patch determined by the encoder.

185. The encoder of claim 184, wherein constructing the patch comprises upscaling the reduced- resolution representation and applying refinement information including at least one of luminance updates, chrominance updates, residual updates, or enhancement information.

186. The encoder of any one of claims 178 to 185, wherein the construction mode comprises constructing the patch using an asymmetric predictor derived from reference regions determined by the encoder.

187. The encoder of claim 186, wherein constructing the patch comprises applying a mapping from noncoincident boundaries of the reference regions to populate an asymmetric region used as a predictor.

188. The encoder of any one of claims 178 to 187, wherein the construction mode comprises synthesising pixel attributes for at least a portion of the patch using interpolation, extrapolation, neighbourhood statistics, or encoder-determined analytic synthesis.

189. The encoder of any one of claims 178 to 188, wherein the construction mode comprises combining pixel attributes drawn from two or more reference patches, reference regions, or previously constructed patches.

190. The encoder of any one of claims 178 to 189, wherein the processor is configured to select the construction mode from a plurality of construction modes based on a competitive assessment of alternative patch-construction strategies.

191. The encoder of claim 190, wherein the competitive assessment comprises optimising at least one of: entropy of the resulting bitstream, prediction error, memory allocation efficiency, execution cost at the decoding system, or the number of instructions required to construct the patch.

192. A decoder for decoding an image from a bitstream stored on non-transitory computer-readable media, the decoder comprising a processor configured to: receive a sequence of symbols that includes: a) a sequence defining image content; b) a sequence defining control operations for directing an order, manner, or selection of operations for construction of the image; and c) a sequence defining memory-management operations for controlling allocation, reuse, retention, or lifetime of pixel regions in a memory of the decoder; wherein the sequences collectively specify locations, regions, or addresses in said memory for construction of at least part of the image; and construct the image by executing operations defined by the sequences.

193. The decoder of claim 192, wherein the processor is configured to receive a sequence of symbols for controlling parallel processing of the bitstream.

194. The decoder of claim 192 or claim 193, wherein the sequence comprises instructions.

195. The decoder of claim 194, wherein the processor is configured to execute said instructions.

196. The decoder of claim 195, wherein said executable instructions are operable on pixel space.

197. The decoder of claim 196, wherein said executable instructions address a pixel attribute by an (x, y) coordinate in a two-dimensional array of pixels.

198. The decoder of claim 196 or claim 197, wherein said executable instructions address a pixel attribute by an (x, y, z) coordinate in a three-dimensional array of pixel attributes.

199. The decoder of any one of claims 194 to 198, wherein said executable instructions comprise reading or writing pixel attributes.

200. The decoder of any one of claims 192 to 199, wherein allocation of memory, lifetime of pixel regions, or reuse of a region of pixels is determined by an encoder.

201. The decoder of any one of claims 192 to 200, wherein the processor is configured to construct at locations, regions, or addresses that are determined by an encoder arbitrarily, not constrained to any predetermined raster sequence, scan order, or sequential construction protocol of the decoder.

202. The decoder of claim 200 or claim 201 , wherein said determination is based on optimising image compression independent of a predetermined construction protocol of the decoder.

203. The decoder of claim 202, wherein said optimisation is facilitated by a competitive compiler operatively coupled to an encoder.

204. The decoder of claim 203, wherein the competitive compiler selects from a plurality of distinct encoding strategies for encoding a patch of pixels.

205. The decoder of claim 204, wherein said patch is one of a plurality of patches for use in constructing a frame of the image at the decoder.

206. The decoder of any one of claims 195 to 205, wherein the processor is configured to execute instructions for constructing patches in encoder-determined locations.

207. The decoder of claim 206, wherein the processor is a virtual processor.

208. The decoder of claim 207, wherein said virtual processor is configured for execution in a graphics processing unit.

209. The decoder of any of claims 192 to 208, wherein the processor is configured to construct the image by constructing a plurality of patches of pixels in memory.

210. The decoder of any one of claims 192 to 209, wherein the processor is configured to construct the image by constructing a plurality of patches of pixels, each patch in a respective region of the memory.

211. The decoder of claim 210, wherein the processor is configured to perform an operation on the constructed patch.

212. The decoder of claim 211 , wherein the operation comprises at least one of copying, scaling, blending, overwriting, or modifying pixel attributes.

213. The decoder of claim 212, wherein copying comprises copying the constructed patch to another region of the memory.

214. The decoder of claim 213, wherein copying the constructed patch comprises copying the constructed patch onto another constructed patch in the memory.

215. The decoder of claim 214, wherein copying the constructed patch onto the other constructed patch comprises compositing the constructed patch with the other constructed patch.

216. The decoder of claim 215, wherein the compositing comprises at least one of overwriting, blending, or applying an alpha contribution.

217. The decoder of any one of claims 214 to 216, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of the other constructed patch.

218. The decoderof any one of claims 214 to 216, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of the other constructed patch.

219. The decoder of any one of claims 214 to 218, wherein the compositing comprises modifying a pixel attribute of the other constructed patch.

220. The decoder of any one of claims 210 to 219, wherein the processor is configured to construct the constructed patch in a worksheet region of the memory.

221. The decoder of claim 213 or claim 220, wherein the processor is configured to copy the constructed patch to a region of the memory for grouping a plurality of patches.

222. The decoder of claim 221 , wherein the processor is configured to composite the constructed patch with at least one patch already in the grouping region when copying the constructed patch to the grouping region.

223. The decoder of claim 222, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the grouping region.

224. The decoder of claim 222 or claim 223, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the grouping region.

225. The decoder of claim 222 or claim 223, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the grouping region.

226. The decoder of any one of claims 221 to 225, wherein the processor is configured to transform the constructed patch when copying the constructed patch to the grouping region.

227. The decoder of claim 226, wherein the transforming comprises scaling the constructed patch.

228. The decoder of claim 226 or claim 227, wherein the transforming comprises at least one of rotation, mirroring, flipping, skewing, warping, shearing, or geometric distortion of the constructed patch.

229. The decoder of any one of claims 221 to 228, wherein the copying comprises changing a pixel attribute of the constructed patch.

230. The decoder of any one of claims 221 to 229, wherein the grouping comprises at least part of a layer for a frame of the image.

231. The decoder of claim 230, wherein the processor is configured to copy the grouping to another region of the memory for grouping with another patch or plurality of patches for representing a frame of the image.

232. The decoder of claim 231 , wherein the copying comprises scaling the grouping.

233. The decoder of claim 231 or claim 232, wherein the copying comprises compositing the grouping with at least one patch previously in the region of memory used for representing the frame.

234. The decoder of claim 233, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the region for representing a frame.

235. The decoder of claim 233 or claim 234, wherein the patch used in the compositing comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the region for representing a frame.

236. The decoder of claim 233 or claim 234, wherein the patch used for the compositing comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the region for representing a frame.

237. The decoder of any of claims 230 to 236, wherein the region for representing a frame is a Render Image.

238. The decoder of any of claims 221 to 237, wherein the region for grouping is a Viewport.

239. The decoder of any one of claims 192 to 238, wherein the processor is configured to construct patches asynchronously with respect to a frame rate, raster timing, or display timing of the decoder.

240. The decoder of any one of claims 192 to 239, wherein the processor is configured to construct patches in an arbitrary temporal order determined by an encoder, the temporal order being independent of a predetermined scan order or picture order count of the decoder.241 . The decoder of any one of claims 192 to 240, wherein the processor is configured such that at least one constructed patch persists across a plurality of frames without being reconstructed for each frame.

242. The decoder of any one of claims 192 to 241 , wherein the processor is configured to reuse a patch constructed in memory for a first frame in a subsequent frame without modification.

243. The decoder of any one of claims 192 to 242, wherein the processor is configured to retain a patch in memory for reuse in constructing a plurality of frames according to a duration specified by an encoder.

244. The decoder of any one of claims 192 to 243, wherein the processor is configured to construct a constructed patch at a resolution that differs from a resolution of the image being decoded or displayed.

245. The decoder of any one of claims 192 to 244, wherein the processor is configured to construct patches according to a grouping structure determined by an encoder, the grouping structure comprising at least one of a layer, sub-layer, viewport, or composite region.

246. The decoder of any one of claims 192 to 245, wherein the processor is configured such that at least one constructed patch is used to apply a special effect comprising modification of colour, brightness, tone, contrast, or a geometric or stylistic transformation of another patch or region.

247. The decoder of any one of claims 192 to 246, wherein the processor is configured such that at least one constructed patch is used to compensate for lighting variation, colour variation, or other inter-frame visual changes.

248. The decoder of any one of claims 192 to 247, wherein the processor is configured such that at least one constructed patch is used to modify attributes of another patch, the modification comprising at least one of luminance adjustment, chrominance adjustment, colour balancing, tinting, or brightness correction.

249. The decoder of any one of claims 192 to 248, wherein the processor is configured to maintain a per- pixel or per-region state structure indicating whether a pixel or region of pixels has been updated, constructed, modified, or remains valid, and wherein the processor is configured to perform construction of patches conditionally based on said state structure so as to avoid reconstructing pixels or regions that remain valid.

250. The decoder of claim 249, wherein the state structure incurs minimal or no overhead in the bitstream, the decoder dynamically determining the state structure from operations executed during construction of patches.251 . The decoder of any of claims 192 to 250, wherein the processor is configured to construct a patch of pixels by constructing a reduced-resolution representation of the patch in memory.

252. The decoder of claim 251 , wherein the processor is configured to upscale the reduced-resolution representation to a higher resolution and apply refinement information received in the bitstream to the upscaled representation.

253. The decoder of any one of claims 251 or 252, wherein the processor is configured to progressively reconstruct the patch at two or more resolution levels determined by an encoder, each level being constructed asynchronously with respect to construction of a frame of the image.

254. The decoder of any one of claims 251 to 253, wherein the progressive reconstruction comprises constructing the reduced-resolution representation and applying one or more refinement patches comprising luminance or chrominance updates.

255. The decoder of any one of claims 251 to 254, wherein refinement information applied between resolution levels comprises residual pixel-attribute differences relative to a prediction derived from a lower-resolution representation.

256. The decoder of any of claims 192 to 255, wherein the processor is configured to synchronise a reconstruction state of memory by applying state-correction information received in the bitstream.

257. The decoder of claim 256, wherein the state-correction information comprises at least one of: a) pixelattribute deltas; b) replacement of pixel attributes; c) overwriting a subregion of the memory; or d) reconciling drift between the reconstruction state at the decoder and a reference reconstruction state maintained by an encoder.

258. The decoder of any one of claims 256 or 257, wherein the processor is configured to apply the statecorrection information when the decoder initiates or resumes playback from a non-sequential position in the bitstream.

259. The decoder of claim 258, wherein the non-sequential position arises from at least one of: a change of playback speed, a jump in playback position, a change of rendered resolution, a reconfiguration of a viewport, or a change in selection of content to be displayed.

260. The decoder of any one of claims 256 to 259, wherein the state-correction information brings the reconstruction state of memory into alignment with a state that would have been obtained by continuous sequential decodingto the non-sequential position.261 . The decoder of any one of claims 256 to 260, wherein the synchronising is performed independently of any group-of-pictures structure, frame sequence, or hierarchical frame dependency of the decoder.

262. The decoder of any of claims 192 to 261 , wherein the processor is configured to: receive symbols identifying a rectangular prediction block of an image; receive symbols identifying a set of equal-sized reference blocks adjacent to or surrounding the prediction block; determine that the reference blocks do not align with the prediction block due to at least one of: spatial offsets, intervening gaps, or differing coordinate origins; derive an asymmetric quadrilateral by averaging pixel attributes at corners of adjacent reference blocks; and construct a predictor for the rectangular prediction block by copying or mapping the asymmetric quadrilateral into the rectangular prediction block.

263. The decoder of claim 262, wherein the predictor constructed from the asymmetric quadrilateral reduces residual magnitude between the prediction block and the image content decoded for that block.

264. The decoder of any of claims 192 to 263, wherein the processor is configured to construct an asymmetric region of pixels in memory based on pixel attributes taken from two or more reference regions that are not spatially aligned, wherein the asymmetric region is derived by interpolating or combining pixel attributes from misaligned boundaries of the reference regions, and the asymmetric region is used for constructing at least part of the image.

265. The decoder of claim 264, wherein the reference regions are equal-sized or equal-resolution regions that are displaced, offset, or separated by gaps relative to the asymmetric region.

266. The decoder of claim 264 or 265, wherein constructing the asymmetric region comprises determining a mapping between non-coincident edges or corners of the reference regions and applying the mapping to populate the asymmetric region.

267. The decoder of any one of claims 264 to 266, wherein the asymmetric region is used as at least one of: a) a predictor region; b) a constructed patch; c) a subregion of a viewport; or d) a subregion of a render image.

268. The decoder of any of claims 192 to 267, wherein the processor is configured to construct a patch in memory according to a construction mode selected by an encoder.

269. The decoder of claim 268, wherein the construction mode comprises invoking a Special Purpose Engine (SPE) to perform operations defined by a sequence of symbols in the bitstream.

270. The decoder of claim 269, wherein the SPE is supplied with pixel data, parameters, or intermediate values pushed onto a stack in memory, and wherein the SPE outputs constructed pixel data to at least one region of memory.271 . The decoder of claim 270, wherein the SPE writes the constructed pixel data to a worksheet region of memory.

272. The decoder of any one of claims 268 to 271 , wherein the construction mode comprises constructing the patch by executing drawing primitives, geometric primitives, or analytical functions defined by the sequence of symbols.

273. The decoder of claim 272, wherein the drawing or geometric primitives comprise at least one of: a line, curve, vector path, parametric shape, polygon fill, region fill, or filter kernel.

274. The decoder of any one of claims 268 to 273, wherein the construction mode comprises constructing the patch from a reduced-resolution representation of the patch determined by an encoder.

275. The decoder of claim 274, wherein constructing the patch comprises upscaling the reduced- resolution representation and applying refinement information including at least one of luminance updates, chrominance updates, residual updates, or enhancement information."2JQ. The decoder of any one of claims 268 to 275, wherein the construction mode comprises constructing the patch using an asymmetric predictor derived from reference regions determined by an encoder.

277. The decoder of claim 276, wherein constructing the patch comprises applying a mapping from noncoincident boundaries of the reference regions to populate an asymmetric region used as a predictor.

278. The decoder of any one of claims 268 to 277, wherein the construction mode comprises synthesising pixel attributes for at least a portion of the patch using interpolation, extrapolation, neighbourhood statistics, or encoder-determined analytic synthesis.

279. The decoder of any one of claims 268 to 278, wherein the construction mode comprises combining pixel attributes drawn from two or more reference patches, reference regions, or previously constructed patches.

280. The decoder of any one of claims 268 to 279, wherein the construction mode is selected from a plurality of construction modes based on a competitive assessment of alternative patch-construction strategies performed by an encoder.281 . The decoder of claim 280, wherein the competitive assessment comprises optimising at least one of: entropy of the resulting bitstream, prediction error, memory allocation efficiency, execution cost at the decoder, or the number of instructions required to construct the patch.

282. A bitstream stored on non-transitory computer-readable media for conveying an encoded image, the bitstream comprising a sequence of symbols that includes: a) a sequence defining image content; b) a sequence defining control operations for directing an order, manner, or selection of operations for construction of the image; and c) a sequence defining memory-management operations for controlling allocation, reuse, retention, or lifetime of pixel regions in a memory of a decoding system; wherein the sequences collectively specify locations, regions, or addresses in said memory for construction of at least part of the image at the decoding system.

283. The bitstream of claim 282, further comprising a sequence of symbols for controlling parallel processing of the bitstream at the decoding system.

284. The bitstream of claim 282 or claim 283, wherein the sequence comprises instructions.

285. The bitstream of claim 284, wherein said instructions are executable by the decoding system.

286. The bitstream of claim 285, wherein said executable instructions are operable on pixel space.

287. The bitstream of claim 286, wherein said executable instructions address a pixel attribute by an (x, y) coordinate in a two-dimensional array of pixels.

288. The bitstream of claim 286 or claim 287, wherein said executable instructions address a pixel attribute by an (x, y, z) coordinate in a three-dimensional array of pixel attributes.

289. The bitstream of any one of claims 284 to 288, wherein said executable instructions comprise reading or writing pixel attributes.

290. The bitstream of any one of claims 282 to 289, wherein allocation of memory, lifetime of pixel regions, or reuse of a region of pixels is determined by an encoder.291 . The bitstream of any one of claims 282 to 290, wherein locations, regions, or addresses specified for construction are determined by an encoder arbitrarily, and are not constrained to any predetermined raster sequence, scan order, or sequential construction protocol of the decoding system.

292. The bitstream of claim 290 or claim 291 , wherein said determination is based on optimising image compression independent of a predetermined construction protocol of the decoding system.

293. The bitstream of claim 292, wherein said optimisation is facilitated by a competitive compiler operatively coupled to an encoder.

294. The bitstream of claim 293, wherein the competitive compiler selects from a plurality of distinct encoding strategies for encoding a patch of pixels.

295. The bitstream of claim 294, wherein said patch is one of a plurality of patches for use in constructing a frame of the image at the decoding system.

296. The bitstream of any one of claims 285 to 295, comprising instructions executable by a processor of the decoding system for constructing patches in encoder-determined locations.

297. The bitstream of claim 296, wherein the processor of the decoding system is a virtual processor.

298. The bitstream of claim 297, wherein said virtual processor is configured for execution in a graphics processing unit.

299. The bitstream of any of claims 282 to 298, wherein the sequence causes construction of the image at the decoding system by constructing a plurality of patches of pixels in memory.

300. The bitstream of any one of claims 282 to 299, wherein the symbols cause construction of the image at the decoding system by constructing a plurality of patches of pixels, each patch in a respective region of the memory.

301. The bitstream of claim 300, comprising symbols defining an operation to be performed on the constructed patch.

302. The bitstream of claim 301 , wherein the operation comprises at least one of copying, scaling, blending, overwriting, or modifying pixel attributes.

303. The bitstream of claim 302, wherein copying comprises copying the constructed patch to another region of the memory.

304. The bitstream of claim 303, wherein copying the constructed patch comprises copying the constructed patch onto another constructed patch in the memory.

305. The bitstream of claim 304, wherein copying the constructed patch onto the other constructed patch comprises compositing the constructed patch with the other constructed patch.

306. The bitstream of claim 305, wherein the compositing comprises at least one of overwriting, blending, or applying an alpha contribution.

307. The bitstream of any one of claims 304 to 306, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of the other constructed patch.

308. The bitstream of any one of claims 304 to 306, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of the other constructed patch.

309. The bitstream of any one of claims 304 to 308, wherein the compositing comprises modifying a pixel attribute of the other constructed patch.

310. The bitstream of any one of claims 300 to 309, wherein the constructed patch is constructed in a worksheet region of the memory.

311. The bitstream of claim 303 or claim 310, comprising symbols specifying that the constructed patch is to be copied to a region of the memory for grouping a plurality of patches.

312. The bitstream of claim 311 , comprising symbols specifying that copying the constructed patch to the grouping region comprises compositing the constructed patch with at least one patch already in the grouping region.

313. The bitstream of claim 312, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the grouping region.

314. The bitstream of claim 312 or claim 313, wherein the constructed patch comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the grouping region.

315. The bitstream of claim 312 or claim 313, wherein the constructed patch comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the grouping region.

316. The bitstream of any one of claims 311 to 315, comprising symbols specifying that copying the constructed patch to the grouping region comprises transforming the constructed patch.

317. The bitstream of claim 316, wherein the transforming comprises scaling the constructed patch.

318. The bitstream of claim 316 or claim 317, wherein the transforming comprises at least one of rotation, mirroring, flipping, skewing, warping, shearing, or geometric distortion of the constructed patch.

319. The bitstream of any one of claims 311 to 318, wherein the copying comprises changing a pixel attribute of the constructed patch.

320. The bitstream of any one of claims 311 to 319, wherein the grouping comprises at least part of a layer for a frame of the image.321 . The bitstream of claim 320, comprising symbols specifying that the grouping is to be copied to another region of the memory for grouping with another patch or plurality of patches for representing a frame of the image.

322. The bitstream of claim 321 , wherein the copying comprises scaling the grouping.

323. The bitstream of claim 321 or claim 322, wherein the copying comprises compositing the grouping with at least one patch previously in the region of memory used for representing the frame.

324. The bitstream of claim 323, wherein the compositing comprises at least one of overwriting, blending, applying an alpha contribution, or modifying a pixel attribute of the patch in the region for representing a frame.

325. The bitstream of claim 323 or claim 324, wherein the patch used in the compositing comprises a luminance patch and the compositing comprises modifying brightness or luminance of a patch already in the region for representing a frame.

326. The bitstream of claim 323 or claim 324, wherein the patch used for the compositing comprises a chrominance patch and the compositing comprises modifying colour or chrominance of a patch already in the region for representing a frame.

327. The bitstream of any of claims 320 to 326, wherein the region for representing a frame is a Render Image.

328. The bitstream of any of claims 311 to 327, wherein the region for grouping is a Viewport.

329. The bitstream of any one of claims 282 to 328, wherein the symbols specify that construction of patches occurs asynchronously with respect to a frame rate, raster timing, or display timing of the decoding system.

330. The bitstream of any one of claims 282 to 329, comprising symbols specifying an arbitrary temporal order for construction of patches determined by an encoder, the temporal order being independent of a predetermined scan order or picture order count of the decoding system.

331. The bitstream of any one of claims 282 to 330, comprising symbols specifying that at least one constructed patch persists across a plurality of frames without being reconstructed for each frame.

332. The bitstream of any one of claims 282 to 331 , comprising symbols specifyingthat a patch constructed in memory for a first frame is reused in a subsequent frame without modification.

333. The bitstream of any one of claims 282 to 332, comprising symbols specifying a duration over which a patch is retained in memory for reuse in constructing a plurality of frames.

334. The bitstream of any one of claims 282 to 333, comprising symbols specifyingthat a constructed patch is constructed at a resolution that differs from a resolution of the image being encoded or displayed.

335. The bitstream of any one of claims 282 to 334, comprising symbols defining a grouping structure for patches determined by an encoder, the grouping structure comprising at least one of a layer, sub-layer, viewport, or composite region.

336. The bitstream of any one of claims 282 to 335, comprising symbols specifying that at least one constructed patch is used to apply a special effect comprising modification of colour, brightness, tone, contrast, or a geometric or stylistic transformation of another patch or region.

337. The bitstream of any one of claims 282 to 336, comprising symbols specifying that at least one constructed patch is used to compensate for lighting variation, colour variation, or other inter-frame visual changes.

338. The bitstream of any one of claims 282 to 337, comprising symbols specifying that at least one constructed patch is used to modify attributes of another patch, the modification comprising at least one of luminance adjustment, chrominance adjustment, colour balancing, tinting, or brightness correction.

339. The bitstream of any one of claims 282 to 338, comprising symbols that enable the decoding system to maintain a per-pixel or per-region state structure indicating whether a pixel or region of pixels has been updated, constructed, modified, or remains valid, and wherein construction of patches is performed conditionally based on said state structure so as to avoid reconstructing pixels or regions that remain valid.

340. The bitstream of claim 339, wherein the state structure incurs minimal or no overhead in the bitstream, the decoder dynamically determining the state structure from operations executed during construction of patches, and an encoder determining the state at each step from the instructions it generates.

341. The bitstream of any of claims 282 to 340, comprising symbols that cause constructing a patch of pixels to comprise constructing a reduced-resolution representation of the patch in memory.

342. The bitstream of claim 341 , comprising symbols such that constructing the patch further comprises upscaling the reduced-resolution representation to a higher resolution and applying refinement information encoded in the bitstream to the upscaled representation.

343. The bitstream of any one of claims 341 or 342, comprising symbols defining two or more resolution levels for progressive reconstruction of the patch determined by an encoder, each level being constructed asynchronously with respect to construction of a frame of the image.

344. The bitstream of any one of claims 341 to 343, wherein the progressive reconstruction comprises constructing the reduced-resolution representation and applying one or more refinement patches comprising luminance or chrominance updates.

345. The bitstream of any one of claims 341 to 344, wherein refinement information applied between resolution levels comprises residual pixel-attribute differences relative to a prediction derived from a lower-resolution representation.

346. The bitstream of any of claims 282 to 345, comprising state-correction information for synchronising a reconstruction state of memory at the decoding system.

347. The bitstream of claim 346, wherein the state-correction information comprises at least one of: a) pixel-attribute deltas; b) replacement of pixel attributes; c) overwriting a subregion of the memory; or d) reconciling drift between the reconstruction state at the decoding system and a reference reconstruction state maintained by an encoder.

348. The bitstream of any one of claims 346 or 347, wherein the state-correction information is configured to be applied when the decoding system initiates or resumes playback from a non-sequential position in the bitstream.

349. The bitstream of claim 348, wherein the non-sequential position arises from at least one of: a change of playback speed, a jump in playback position, a change of rendered resolution, a reconfiguration of a viewport, or a change in selection of content to be displayed.

350. The bitstream of any one of claims 346 to 349, wherein the state-correction information brings the reconstruction state of memory into alignment with a state that would have been obtained by continuous sequential decodingto the non-sequential position.351 . The bitstream of any one of claims 346 to 350, wherein the synchronising is performed independently of any group-of-pictures structure, frame sequence, or hierarchical frame dependency of the decoding system.

352. The bitstream of any of claims 282 to 351 , comprising symbols defining: a rectangular prediction block of an image; a set of equal-sized reference blocks adjacent to or surrounding the prediction block; wherein the reference blocks do not align with the prediction block due to at least one of: spatial offsets, intervening gaps, or differing coordinate origins; and instructions for deriving an asymmetric quadrilateral by averaging pixel attributes at corners of adjacent reference blocks, and for constructing a predictor for the rectangular prediction block by copying or mapping the asymmetric quadrilateral into the rectangular prediction block.

353. The bitstream of claim 352, wherein the predictor constructed from the asymmetric quadrilateral reduces residual magnitude between the prediction block and the image content encoded for that block.

354. The bitstream of any of claims 282 to 353, comprising symbols for constructing an asymmetric region of pixels in memory based on pixel attributes taken from two or more reference regions that are not spatiallyaligned, wherein the asymmetric region is derived by interpolating or combining pixel attributes from misaligned boundaries of the reference regions, and the asymmetric region is used for constructing at least part of the image at the decoding system.

355. The bitstream of claim 354, wherein the reference regions are equal-sized or equal-resolution regions that are displaced, offset, or separated by gaps relative to the asymmetric region.

356. The bitstream of claim 354 or 355, wherein constructing the asymmetric region comprises determining a mapping between non-coincident edges or corners of the reference regions and applying the mapping to populate the asymmetric region.

357. The bitstream of any one of claims 354 to 356, wherein the asymmetric region is used as at least one of: a) a predictor region; b) a constructed patch; c) a subregion of a viewport; or d) a subregion of a render image.

358. The bitstream of any of claims 282 to 357, comprising symbols defining a construction mode selected by an encoder for construction of a patch in memory.

359. The bitstream of claim 358, wherein the construction mode comprises invoking a Special Purpose Engine (SPE) to perform operations defined by a sequence of symbols in the bitstream.

360. The bitstream of claim 359, comprising symbols that supply the SPE with pixel data, parameters, or intermediate values pushed onto a stack in memory, and wherein the SPE outputs constructed pixel data to at least one region of memory.361 . The bitstream of claim 360, wherein the SPE writes the constructed pixel data to a worksheet region of memory.

362. The bitstream of any one of claims 358 to 361 , wherein the construction mode comprises constructing the patch by executing drawing primitives, geometric primitives, or analytical functions defined by the sequence of symbols.

363. The bitstream of claim 362, wherein the drawing or geometric primitives comprise at least one of: a line, curve, vector path, parametric shape, polygon fill, region fill, or filter kernel.

364. The bitstream of any one of claims 358 to 363, wherein the construction mode comprises constructing the patch from a reduced-resolution representation of the patch determined by an encoder.

365. The bitstream of claim 364, wherein constructing the patch comprises upscaling the reduced- resolution representation and applying refinement information including at least one of luminance updates, chrominance updates, residual updates, or enhancement information.

366. The bitstream of any one of claims 358 to 365, wherein the construction mode comprises constructing the patch using an asymmetric predictor derived from reference regions determined by an encoder.

367. The bitstream of claim 366, wherein constructing the patch comprises applying a mapping from noncoincident boundaries of the reference regions to populate an asymmetric region used as a predictor.

368. The bitstream of any one of claims 358 to 367, wherein the construction mode comprises synthesising pixel attributes for at least a portion of the patch using interpolation, extrapolation, neighbourhood statistics, or encoder-determined analytic synthesis.

369. The bitstream of any one of claims 358 to 368, wherein the construction mode comprises combining pixel attributes drawn from two or more reference patches, reference regions, or previously constructed patches.

370. The bitstream of any one of claims 358 to 369, wherein the construction mode is selected from a plurality of construction modes based on a competitive assessment of alternative patch-construction strategies.371 . The bitstream of claim 370, wherein the competitive assessment comprises optimising at least one of: entropy of the resulting bitstream, prediction error, memory allocation efficiency, execution cost at the decoding system, or the number of instructions required to construct the patch.

372. The method of representing an image, comprising:generating, at an encoder, a sequence of executable instructions operable to construct the image in memory of a decoding system; and transmitting the instructions to the decoding system for execution to construct said image, the representation being independent of any pixel array encoding or raster-based encoding scheme.

373. The method of encoding an image, comprising: converting the image into a sequence of executable instructions representing pixel operations; and subsequently entropy-encoding at least part of said sequence using a process independent of the instruction generation process.

374. The method of encoding an image, comprising: analysing the image to identify a plurality of regions; selecting, for different regions, mutually distinct encoding methods; and generating a single executable instruction stream configured to reconstruct all said regions using the selected methods.

375. The method of reconstructing an image, comprising: providing, at an encoder, instructions selected from a non-transient instruction set operable on a virtual processor of the decoder; and executing the instructions at the virtual processor to construct the image.

376. The method of encoding an image, comprising: generating a plurality of executable instructions for reconstructing the image; rearranging the order of at least some instructions independently of the pixel operations they represent; and entropy-encoding the rearranged instruction sequence.

377. The method of modifying an image represented in an executable instruction format, comprising: editing, without decompressing the image to a pixel array, one or more of the executable instructions definingthe image; and executing the edited instructions to construct an updated image.

378. The method of reconstructing an image, comprising: executing an instruction stream directly in graphics memory of a decoder to construct pixel attributes in a memory texture operatively coupled to GPU processing cores.

379. The method of providing image content, comprising: receiving a first instruction stream defining primary image content; receiving a second instruction stream defining secondary or substitute content; and executing both streams in a decoding system to construct respective layers for composition into a frame.

380. The method of claim 379., wherein each of the first and second instruction streams comprises a sequence of symbols defining image-content operations, control operations, and memory-management operations.

381. The method of claim 380., wherein at least one of the instruction streams comprises executable instructions operable on pixel space.

382. The method of claim 381 ., wherein the executable instructions comprise at least one of: reading pixel attributes, writing pixel attributes, modifying pixel attributes, or addressing pixel attributes in two- dimensional or three-dimensional coordinate form.

383. The method of any one of claims 379.-382., wherein executing the instruction streams comprises constructing, in decoder memory, respective sets of patches corresponding to primary content and secondary or substitute content.

384. The method of any one of claims 379.-383., wherein the primary content patches and the secondary content patches are constructed in respective regions of memory defining distinct layers.

385. The method of any one of claims 379.-384., wherein constructing each layer comprises compositing a plurality of patches according to encoder-determined ordering, patch interactions, or pixel-attribute operations.

386. The method of any one of claims 379.-385., wherein the secondary or substitute content comprises at least one of: advertising content, augmented-reality content, informational overlays, metrics, statistics, or user-specific replacement imagery.

387. The method of any one of claims 379.-386., wherein composition of the primary and secondary layers comprises at least one of: overwriting, blending, alpha compositing, depth-ordered compositing, or modifying pixel attributes.

388. The method of any one of claims 379.-387., wherein construction of the primary and secondary layers is performed asynchronously with respect to a frame rate, raster timing, or picture order of the decoding system.

389. The method of any one of claims 379.-388., wherein the secondary layer is constructed in response to a trigger condition comprising at least one of: geographic location, user preference, device capability, available bandwidth, or a server-initiated instruction.

390. The method of any one of claims 379.-389., wherein the secondary layer is constructed at a resolution different from that of the primary layer.391 . The method of any one of claims 379.-390., wherein the secondary layer is geometrically transformed relative to the primary layer, the transformation comprising at least one of: translation, scaling, rotation, mirroring, flipping, skewing, shearing, warping, or geometric distortion.

392. The method of any one of claims 379.-391 ., wherein at least one patch of the secondary layer modifies colour, luminance, tone, brightness, tint, or chrominance attributes of at least a portion of the primary layer.

393. The method of any one of claims 379.-392., wherein the decoding system maintains per-patch or per- region state information indicating whether a portion of memory requires reconstruction, and reconstruction of primary or secondary content is performed conditionally using said state information.

394. The method of any one of claims 379.-393., wherein the primary and secondary layers are represented in decoder memory as viewports or render-image regions.

395. The method of any one of claims 379.-394., wherein at least one patch of the secondary layer is copied into a render-image region for composition with at least one patch of the primary layer.

396. The method of any one of claims 379.-395., wherein execution of the instruction streams is performed by a virtual processor at the decoding system.

397. The method of claim 396., wherein the virtual processor is configured for execution in graphics- processing-unit memory.

398. The method of claim 396. or claim 397., wherein the virtual processor is embodied at least in part in shader code.

399. The method of any one of claims 379.-398., wherein at least one of the instruction streams specifies encoder-determined spatial positions or memory addresses for constructing the primary or secondary layer.

400. The method of any one of claims 379.-399., wherein substituting or overlaying the secondary layer comprises applying an encoder-determined rule defining interactions between patches of the primary layer and patches of the secondary layer.

401. The method of any one of claims 379.-400., wherein a patch of the secondary layer replaces, supplements, or modifies a corresponding region of the primary layer according to encoder-determined selection criteria.

402. The method of any one of claims 379.-401., wherein constructing the secondary layer comprises constructing at least one luminance patch or chrominance patch.

403. The method of claim 402., wherein the luminance patch modifies brightness or luminance of at least part of the primary layer.

404. The method of claim 402., wherein the chrominance patch modifies colour or chrominance of at least part of the primary layer.

405. The method of any one of claims 379.-404., wherein the decoding system processes the first and second instruction streams in parallel by interleaving execution or executing them in distinct virtual- processor instances.

406. The method of any one of claims 379.-405., wherein construction of primary and secondary content includes copying at least one patch into a viewport for presentation at an encoder-determined spatial position.

407. The method of any one of claims 379.-406., wherein copying of a patch into the viewport comprises scaling the patch to match a required output resolution.

408. The method of any one of claims 379.-407., wherein the secondary layer comprises a substitute object or region that replaces an object, surface, advertisement, or element originally encoded in the primary content.

409. An encoder for providing image content, the encoder comprising a processor configured to: generate a first instruction stream defining primary image content; generate a second instruction stream defining secondary or substitute content; and output the instruction streams in a bitstream for execution in a decoding system to construct respective layers for composition into a frame.

410. The encoder of claim 409, wherein the processor is configured such that each of the first and second instruction streams comprises a sequence of symbols defining image-content operations, control operations, and memory-management operations.411 . The encoder of claim 410, wherein the processor is configured such that at least one of the instruction streams comprises executable instructions operable on pixel space.

412. The encoder of claim 411 , wherein the executable instructions comprise at least one of: reading pixel attributes, writing pixel attributes, modifying pixel attributes, or addressing pixel attributes in two- dimensional or three-dimensional coordinate form.

413. The encoder of any one of claims 409 to 412, wherein the processor is configured to generate instruction streams that cause construction, in decoder memory, of respective sets of patches corresponding to primary content and secondary or substitute content.

414. The encoder of any one of claims 409 to 413, wherein the processor is configured to specify that the primary content patches and the secondary content patches are to be constructed in respective regions of memory defining distinct layers.

415. The encoder of any one of claims 409 to 414, wherein the processor is configured to generate symbols specifyingthat constructing each layer comprises compositing a plurality of patches according to encoder- determined ordering, patch interactions, or pixel-attribute operations.

416. The encoder of any one of claims 409 to 415, wherein the secondary or substitute content comprises at least one of: advertising content, augmented-reality content, informational overlays, metrics, statistics, or user-specific replacement imagery.

417. The encoder of any one of claims 409 to 416, wherein the processor is configured to generate symbols specifying that composition of the primary and secondary layers comprises at least one of: overwriting, blending, alpha compositing, depth-ordered compositing, or modifying pixel attributes.

418. The encoder of any one of claims 409 to 417, wherein the processor is configured to generate instruction streams such that construction of the primary and secondary layers is performed asynchronously with respect to a frame rate, raster timing, or picture order of the decoding system.

419. The encoder of any one of claims 409 to 418, wherein the processor is configured to generate symbols specifying that the secondary layer is to be constructed in response to a trigger condition comprising at least one of: geographic location, user preference, device capability, available bandwidth, or a server- initiated instruction.

420. The encoder of any one of claims 409 to 419, wherein the processor is configured to specify that the secondary layer is to be constructed at a resolution different from that of the primary layer.421 . The encoder of any one of claims 409 to 420, wherein the processor is configured to specify that the secondary layer is to be geometrically transformed relative to the primary layer, the transformation comprising at least one of: translation, scaling, rotation, mirroring, flipping, skewing, shearing, warping, or geometric distortion.

422. The encoder of any one of claims 409 to 421 , wherein the processor is configured to generate symbols specifying that at least one patch of the secondary layer modifies colour, luminance, tone, brightness, tint, or chrominance attributes of at least a portion of the primary layer.

423. The encoder of any one of claims 409 to 422, wherein the processor is configured to generate symbols that enable the decoding system to maintain per-patch or per-region state information indicating whether a portion of memory requires reconstruction, and reconstruction of primary or secondary content is performed conditionally using said state information.

424. The encoder of any one of claims 409 to 423, wherein the processor is configured to specify that the primary and secondary layers are to be represented in decoder memory as viewports or render-image regions.

425. The encoder of any one of claims 409 to 424, wherein the processor is configured to generate symbols specifying that at least one patch of the secondary layer is to be copied into a render-image region for composition with at least one patch of the primary layer.

426. The encoder of any one of claims 409 to 425, wherein the processor is configured to generate instruction streams executable by a virtual processor at the decoding system.

427. The encoder of claim 426, wherein the virtual processor is configured for execution in graphics- processing-unit memory.

428. The encoder of claim 426 or claim 427, wherein the virtual processor is embodied at least in part in shader code.

429. The encoder of any one of claims 409 to 428, wherein the processor is configured such that at least one of the instruction streams specifies encoder-determined spatial positions or memory addresses for constructing the primary or secondary layer.

430. The encoder of any one of claims 409 to 429, wherein the processor is configured to generate symbols defining an encoder-determined rule for interactions between patches of the primary layer and patches of the secondary layer when substituting or overlaying the secondary layer.

431. The encoder of any one of claims 409 to 430, wherein the processor is configured to generate symbols specifying that a patch of the secondary layer replaces, supplements, or modifies a corresponding region of the primary layer according to encoder-determined selection criteria.

432. The encoder of any one of claims 409 to 431 , wherein the processor is configured to generate symbols for constructing the secondary layer comprising at least one luminance patch or chrominance patch.

433. The encoder of claim 432, wherein the luminance patch modifies brightness or luminance of at least part of the primary layer.

434. The encoder of claim 432, wherein the chrominance patch modifies colour or chrominance of at least part of the primary layer.

435. The encoder of any one of claims 409 to 434, wherein the processor is configured to generate instruction streams such that the decoding system processes the first and second instruction streams in parallel by interleaving execution or executing them in distinct virtual-processor instances.

436. The encoder of any one of claims 409 to 435, wherein the processor is configured to generate symbols specifying that construction of primary and secondary content includes copying at least one patch into a viewport for presentation at an encoder-determined spatial position.

437. The encoder of any one of claims 409 to 436, wherein the processor is configured to specify that copying of a patch into the viewport comprises scaling the patch to match a required output resolution.

438. The encoder of any one of claims 409 to 437, wherein the processor is configured to generate a secondary layer comprising a substitute object or region that replaces an object, surface, advertisement, or element originally encoded in the primary content.

439. A decoder for decoding image content, the decoder comprising a processor configured to: receive a first instruction stream defining primary image content; receive a second instruction stream defining secondary or substitute content; and execute both streams to construct respective layers for composition into a frame.

440. The decoder of claim 439, wherein each of the first and second instruction streams comprises a sequence of symbols defining image-content operations, control operations, and memory-management operations.

441. The decoder of claim 440, wherein the processor is configured to execute at least one of the instruction streams comprising executable instructions operable on pixel space.

442. The decoder of claim 441 , wherein the executable instructions comprise at least one of: reading pixel attributes, writing pixel attributes, modifying pixel attributes, or addressing pixel attributes in two- dimensional or three-dimensional coordinate form.

443. The decoder of any one of claims 439 to 442, wherein the processor is configured to execute the instruction streams by constructing, in memory, respective sets of patches corresponding to primary content and secondary or substitute content.

444. The decoder of any one of claims 439 to 443, wherein the processor is configured to construct the primary content patches and the secondary content patches in respective regions of memory defining distinct layers.

445. The decoder of any one of claims 439 to 444, wherein the processor is configured to construct each layer by compositing a plurality of patches according to encoder-determined ordering, patch interactions, or pixel-attribute operations.

446. The decoder of any one of claims 439 to 445, wherein the secondary or substitute content comprises at least one of: advertising content, augmented-reality content, informational overlays, metrics, statistics, or user-specific replacement imagery.

447. The decoder of any one of claims 439 to 446, wherein the processor is configured to compose the primary and secondary layers by at least one of: overwriting, blending, alpha compositing, depth-ordered compositing, or modifying pixel attributes.

448. The decoder of any one of claims 439 to 447, wherein the processor is configured to construct the primary and secondary layers asynchronously with respect to a frame rate, raster timing, or picture order of the decoder.

449. The decoder of any one of claims 439 to 448, wherein the processor is configured to construct the secondary layer in response to a trigger condition comprising at least one of: geographic location, user preference, device capability, available bandwidth, or a server-initiated instruction.

450. The decoder of any one of claims 439 to 449, wherein the processor is configured to construct the secondary layer at a resolution different from that of the primary layer.

451. The decoder of any one of claims 439 to 450, wherein the processor is configured to geometrically transform the secondary layer relative to the primary layer, the transformation comprising at least one of: translation, scaling, rotation, mirroring, flipping, skewing, shearing, warping, or geometric distortion.

452. The decoder of any one of claims 439 to 451 , wherein the processor is configured such that at least one patch of the secondary layer modifies colour, luminance, tone, brightness, tint, or chrominance attributes of at least a portion of the primary layer.

453. The decoder of any one of claims 439 to 452, wherein the processor is configured to maintain perpatch or per-region state information indicating whether a portion of memory requires reconstruction, and to perform reconstruction of primary or secondary content conditionally using said state information.

454. The decoder of any one of claims 439 to 453, wherein the processor is configured to represent the primary and secondary layers in memory as viewports or render-image regions.

455. The decoder of any one of claims 439 to 454, wherein the processor is configured to copy at least one patch of the secondary layer into a render-image region for composition with at least one patch of the primary layer.

456. The decoder of any one of claims 439 to 455, wherein the processor comprises a virtual processor configured to execute the instruction streams.

457. The decoder of claim 456, wherein the virtual processor is configured for execution in graphics- processing-unit memory.

458. The decoder of claim 456 or claim 457, wherein the virtual processor is embodied at least in part in shader code.

459. The decoder of any one of claims 439 to 458, wherein the processor is configured to receive at least one of the instruction streams specifying encoder-determined spatial positions or memory addresses for constructing the primary or secondary layer.

460. The decoder of any one of claims 439 to 459, wherein the processor is configured to apply an encoder- determined rule defining interactions between patches of the primary layer and patches of the secondary layer when substituting or overlaying the secondary layer.461 . The decoder of any one of claims 439 to 460, wherein the processor is configured such that a patch of the secondary layer replaces, supplements, or modifies a corresponding region of the primary layer according to encoder-determined selection criteria.

462. The decoder of any one of claims 439 to 461 , wherein the processor is configured to construct the secondary layer comprising at least one luminance patch or chrominance patch.

463. The decoder of claim 462, wherein the processor is configured such that the luminance patch modifies brightness or luminance of at least part of the primary layer.

464. The decoder of claim 462, wherein the processor is configured such that the chrominance patch modifies colour or chrominance of at least part of the primary layer.

465. The decoder of any one of claims 439 to 464, wherein the processor is configured to process the first and second instruction streams in parallel by interleaving execution or executing them in distinct virtual- processor instances.

466. The decoder of any one of claims 439 to 465, wherein the processor is configured such that construction of primary and secondary content includes copying at least one patch into a viewport for presentation at an encoder-determined spatial position.

467. The decoder of any one of claims 439 to 466, wherein the processor is configured such that copying of a patch into the viewport comprises scaling the patch to match a required output resolution.

468. The decoder of any one of claims 439 to 467, wherein the processor is configured to construct the secondary layer comprising a substitute object or region that replaces an object, surface, advertisement, or element originally encoded in the primary content.

469. A bitstream stored on non-transitory computer-readable media for conveying image content, the bitstream comprising: a first instruction stream defining primary image content; and a second instructionstream defining secondary or substitute content; wherein the instruction streams are executable in a decoding system to construct respective layers for composition into a frame.

470. The bitstream of claim 469, wherein each of the first and second instruction streams comprises a sequence of symbols defining image-content operations, control operations, and memory-management operations.

471. The bitstream of claim 470, wherein at least one of the instruction streams comprises executable instructions operable on pixel space.

472. The bitstream of claim 471 , wherein the executable instructions comprise at least one of: reading pixel attributes, writing pixel attributes, modifying pixel attributes, or addressing pixel attributes in two- dimensional or three-dimensional coordinate form.

473. The bitstream of any one of claims 469 to 472, wherein the instruction streams cause construction, in decoder memory, of respective sets of patches corresponding to primary content and secondary or substitute content.

474. The bitstream of any one of claims 469 to 473, comprising symbols specifying that the primary content patches and the secondary content patches are to be constructed in respective regions of memory defining distinct layers.

475. The bitstream of any one of claims 469 to 474, comprising symbols specifying that constructing each layer comprises compositing a plurality of patches according to encoder-determined ordering, patch interactions, or pixel-attribute operations.

476. The bitstream of any one of claims 469 to 475, wherein the secondary or substitute content comprises at least one of: advertising content, augmented-reality content, informational overlays, metrics, statistics, or user-specific replacement imagery.

477. The bitstream of any one of claims 469 to 476, comprising symbols specifying that composition of the primary and secondary layers comprises at least one of: overwriting, blending, alpha compositing, depth- ordered compositing, or modifying pixel attributes.

478. The bitstream of any one of claims 469 to 477, comprising instruction streams such that construction of the primary and secondary layers is performed asynchronously with respect to a frame rate, raster timing, or picture order of the decoding system.

479. The bitstream of any one of claims 469 to 478, comprising symbols specifying that the secondary layer is to be constructed in response to a trigger condition comprising at least one of: geographic location, user preference, device capability, available bandwidth, or a server-initiated instruction.

480. The bitstream of any one of claims 469 to 479, comprising symbols specifying that the secondary layer is to be constructed at a resolution different from that of the primary layer.481 . The bitstream of any one of claims 469 to 480, comprising symbols specifying that the secondary layer is to be geometrically transformed relative to the primary layer, the transformation comprising at least one of: translation, scaling, rotation, mirroring, flipping, skewing, shearing, warping, or geometric distortion.

482. The bitstream of any one of claims 469 to 481 , comprising symbols specifying that at least one patch of the secondary layer modifies colour, luminance, tone, brightness, tint, or chrominance attributes of at least a portion of the primary layer.

483. The bitstream of any one of claims 469 to 482, comprising symbols that enable the decoding system to maintain per-patch or per-region state information indicating whether a portion of memory requires reconstruction, and reconstruction of primary or secondary content is performed conditionally using said state information.

484. The bitstream of any one of claims 469 to 483, comprising symbols specifying that the primary and secondary layers are to be represented in decoder memory as viewports or render-image regions.

485. The bitstream of any one of claims 469 to 484, comprising symbols specifying that at least one patch of the secondary layer is to be copied into a render-image region for composition with at least one patch of the primary layer.

486. The bitstream of any one of claims 469 to 485, comprising instruction streams executable by a virtual processor at the decoding system.

487. The bitstream of claim 486, wherein the virtual processor is configured for execution in graphics- processing-unit memory.

488. The bitstream of claim 486 or claim 487, wherein the virtual processor is embodied at least in part in shader code.

489. The bitstream of any one of claims 469 to 488, wherein at least one of the instruction streams specifies encoder-determined spatial positions or memory addresses for constructing the primary or secondary layer.

490. The bitstream of any one of claims 469 to 489, comprising symbols defining an encoder-determined rule for interactions between patches of the primary layer and patches of the secondary layer when substituting or overlaying the secondary layer.

491. The bitstream of any one of claims 469 to 490, comprising symbols specifying that a patch of the secondary layer replaces, supplements, or modifies a corresponding region of the primary layer according to encoder-determined selection criteria.

492. The bitstream of any one of claims 469 to 491 , comprising symbols for constructing the secondary layer comprising at least one luminance patch or chrominance patch.

493. The bitstream of claim 492, wherein the luminance patch modifies brightness or luminance of at least part of the primary layer.

494. The bitstream of claim 492, wherein the chrominance patch modifies colour or chrominance of at least part of the primary layer.

495. The bitstream of any one of claims 469 to 494, comprising instruction streams such that the decoding system processes the first and second instruction streams in parallel by interleaving execution or executing them in distinct virtual-processor instances.

496. The bitstream of any one of claims 469 to 495, comprising symbols specifying that construction of primary and secondary content includes copying at least one patch into a viewport for presentation at an encoder-determined spatial position.

497. The bitstream of any one of claims 469 to 496, comprising symbols specifying that copying of a patch into the viewport comprises scaling the patch to match a required output resolution.

498. The bitstream of any one of claims 469 to 497, wherein the secondary layer comprises a substitute object or region that replaces an object, surface, advertisement, or element originally encoded in the primary content.

499. A method of constructing image content at a decoding system, comprising: identifying, at an encoder, a reference region of pixels of an image, the reference region having an encoder-determined shape, size, or boundary geometry; identifying a prediction region of pixels to be constructed, the prediction region having a boundary geometry that is not coincident with that of the reference region; deriving from the reference region an asymmetric mapping region that compensates for geometric mismatch between the boundary geometry of the reference region and the boundary geometry of the prediction region, the asymmetric mapping region being generated by interpolating, combining, or sampling pixel attributes from noncoincident boundaries or subregions of the reference region; and constructing the prediction region at the decoding system by mapping the asymmetric mapping region into the prediction region according to encoder-determined instructions encoded in a bitstream.

500. The method of claim 499, wherein deriving the asymmetric mapping region comprises interpolating pixel attributes at non-coincident corners, edges, or boundary segments of the reference region.

501. The method of claim 499 or claim 500, wherein constructingthe prediction region comprises reducing residual differences between the prediction region and image content encoded for that region.

502. The method of any one of claims 499 to 501 , wherein the reference region and the prediction region are not related by a fixed translational, affine, projective, global-motion, or motion-compensated mapping.

503. The method of any one of claims 499 to 502, wherein the asymmetric mapping region compensates for at least one of: non-overlapping boundaries, displaced boundaries, differing shapes, differing orientations, or irregular subregions of the reference region.

504. The method of any one of claims 499 to 503, wherein the asymmetric mapping region is derived without reference to motion vectors, projective transforms, or block-based displacement prediction of any kind.

505. The method of any one of claims 499 to 504, wherein the asymmetric mapping region is constructed in a worksheet region of memory of the decoding system.

506. The method of claim 505, wherein the asymmetric mapping region is transformed, scaled, blended, overwritten, or composited with another region of memory prior to constructing the prediction region.

507. The method of any one of claims 499 to 506, wherein instructions for deriving the asymmetric mapping region and mapping it into the prediction region are executable by a virtual processor of the decoding system operating in pixel space.

508. An encoder for encoding image content, the encoder comprising a processor configured to: identify a reference region of pixels of an image, the reference region having an encoder-determined shape, size, or boundary geometry; identify a prediction region of pixels to be constructed at a decoding system, the prediction region having a boundary geometry that is not coincident with that of the reference region; determine derivation operations for an asymmetric mapping region that compensates for geometric mismatch between the boundary geometry of the reference region and the boundary geometry of the prediction region, the asymmetric mapping region being generated by interpolating, combining, or sampling pixel attributes from non-coincident boundaries or subregions of the reference region; and output symbols defining instructions for constructing the prediction region at the decoding system by mapping the asymmetric mapping region into the prediction region.

509. The encoder of claim 508, wherein the processor is configured to determine derivation operations comprising interpolating pixel attributes at non-coincident corners, edges, or boundary segments of the reference region.

510. The encoder of claim 508 or 509, wherein the processor is configured to generate symbols that enable construction of the prediction region to reduce residual differences between the prediction region and image content encoded for that region.

511. The encoder of any one of claims 508 to 510, wherein the reference region and the prediction region are not related by a fixed translational, affine, projective, global-motion, or motion-compensated mapping.

512. The encoder of any one of claims 508 to 511 , wherein the asymmetric mapping region compensates for at least one of: non-overlapping boundaries, displaced boundaries, differing shapes, differing orientations, or irregular subregions of the reference region.

513. The encoder of any one of claims 508 to 512, wherein the processor is configured to derive the asymmetric mapping region without reference to motion vectors, projective transforms, or block-based displacement prediction of any kind.

514. The encoder of any one of claims 508 to 513, wherein the processor is configured to specify that the asymmetric mapping region is to be constructed in a worksheet region of memory of the decoding system.

515. The encoder of claim 514, wherein the processor is configured to generate symbols defining operations for transforming, scaling, blending, overwriting, or compositingthe asymmetric mapping region with another region of memory prior to constructing the prediction region.

516. The encoder of any one of claims 508 to 515, wherein the processor is configured to generate instructions for deriving the asymmetric mapping region and mapping it into the prediction region, the instructions being executable by a virtual processor of the decoding system operating in pixel space.

517. A decoder for decoding encoded image content, the decoder comprising a processor configured to: receive symbols identifying a reference region of pixels of an image, the reference region having an encoder- determined shape, size, or boundary geometry; receive symbols identifying a prediction region of pixels to be constructed, the prediction region having a boundary geometry that is not coincident with that of the reference region; derive from the reference region an asymmetric mapping region that compensates for geometric mismatch between the boundary geometry of the reference region and the boundary geometry of the prediction region, the asymmetric mapping region being generated by interpolating, combining, or sampling pixel attributes from non-coincident boundaries or subregions of the reference region; and construct the prediction region by mapping the asymmetric mapping region into the prediction region according to encoder-determined instructions received in a bitstream.

518. The decoder of claim 517, wherein the processor is configured to derive the asymmetric mapping region by interpolating pixel attributes at non-coincident corners, edges, or boundary segments of the reference region.

519. The decoder of claim 517 or 518, wherein the processor is configured to construct the prediction region to reduce residual differences between the prediction region and image content encoded for that region.

520. The decoder of any one of claims 517 to 519, wherein the reference region and the prediction region are not related by a fixed translational, affine, projective, global-motion, or motion-compensated mapping.521 . The decoder of any one of claims 517 to 520, wherein the asymmetric mapping region compensates for at least one of: non-overlapping boundaries, displaced boundaries, differing shapes, differing orientations, or irregular subregions of the reference region.

522. The decoder of any one of claims 517 to 521 , wherein the processor is configured to derive the asymmetric mapping region without reference to motion vectors, projective transforms, or block-based displacement prediction of any kind.

523. The decoder of any one of claims 517 to 522, wherein the processor is configured to construct the asymmetric mapping region in a worksheet region of memory.

524. The decoder of claim 523, wherein the processor is configured to transform, scale, blend, overwrite, or composite the asymmetric mapping region with another region of memory prior to constructing the prediction region.

525. The decoder of any one of claims 517 to 524, wherein the processor comprises a virtual processor configured to execute instructions for deriving the asymmetric mapping region and mapping it into the prediction region, the virtual processor operating in pixel space.

526. A bitstream for conveying encoded image content, the bitstream comprising symbols defining: a reference region of pixels of an image, the reference region having an encoder-determined shape, size, or boundary geometry; a prediction region of pixels to be constructed at a decoding system, the prediction region having a boundary geometry that is not coincident with that of the reference region; and instructions for deriving from the reference region an asymmetric mapping region that compensates for geometric mismatch between the boundary geometry of the reference region and the boundary geometry of the prediction region, the asymmetric mapping region being generated by interpolating, combining, or sampling pixel attributes from non-coincident boundaries or subregions of the reference region, and for constructing the prediction region by mapping the asymmetric mapping region into the prediction region.

527. The bitstream of claim 526, comprising symbols defining operations for interpolating pixel attributes at non-coincident corners, edges, or boundary segments of the reference region.

528. The bitstream of claim 526 or 527, comprising symbols that enable construction of the prediction region to reduce residual differences between the prediction region and image content encoded for that region.

529. The bitstream of any one of claims 526 to 528, wherein the reference region and the prediction region are not related by a fixed translational, affine, projective, global-motion, or motion-compensated mapping.

530. The bitstream of any one of claims 526 to 529, wherein the asymmetric mapping region compensates for at least one of: non-overlapping boundaries, displaced boundaries, differing shapes, differing orientations, or irregular subregions of the reference region.

531. The bitstream of any one of claims 526 to 530, wherein the symbols define derivation of the asymmetric mapping region without reference to motion vectors, projective transforms, or block-based displacement prediction of any kind.

532. The bitstream of any one of claims 526 to 531 , comprising symbols specifying that the asymmetric mapping region is to be constructed in a worksheet region of memory of the decoding system.

533. The bitstream of claim 532, comprising symbols defining operations for transforming, scaling, blending, overwriting, or compositing the asymmetric mapping region with another region of memory prior to constructing the prediction region.

534. The bitstream of any one of claims 526 to 533, comprising instructions executable by a virtual processor of the decoding system operating in pixel space for deriving the asymmetric mapping region and mapping it into the prediction region.

535. A method of encoding image content, comprising: constructing, at an encoder, an encoder- determined patch of pixels, the patch being a region not constrained to a raster grid, tile, block, or frame boundary; deriving, from the constructed patch, a first reduced-resolution form of the patch; and deriving, from the first reduced-resolution form, a second reduced-resolution form of the patch.

536. The method of claim 535, further comprising generating, for at least one reduced-resolution form, a sequence of symbols defining operations for constructing the patch at a decoding system.

537. The method of any one of claims 535 to 536, wherein construction of the patch at the decoding system is performed by executing instructions specifying operations on pixel attributes in memory regions used for constructing the image.

538. The method of any one of claims 535 to 537, further comprising generating refinement data that increases detail of the patch relative to the second reduced-resolution form, the refinement data being defined for the same encoder-determined patch region.

539. The method of claim 538, wherein the decoding system reconstructs the patch in stages by first constructing the second reduced-resolution form in a memory region and subsequently applying the refinement data to said region.

540. The method of any one of claims 535 to 539, wherein the refinement data comprises at least one of: a residual defined for the encoder-determined patch; or a higher-resolution representation of the encoder- determined patch.541 . The method of any one of claims 535 to 540, wherein selection of the encoder-determined patch is based on a competitive assessment between a plurality of encoding strategies for the patch.

542. The method of claim 541 , wherein the competitive assessment comprises comparing, for the patch, at least two alternative encoding methods to determine which method yields a more favourable compression outcome.

543. The method of any one of claims 535 to 542, wherein the encoding method selected for the patch is not predetermined by a frame structure, raster alignment, or fixed block partitioning.

544. The method of any one of claims 535 to 543, wherein the sequence of symbols generated for the patch comprises executable instructions operable on pixel space.

545. The method of claim 544, wherein the executable instructions address pixel attributes by coordinate values defining locations in a memory region used for constructing the image.

546. The method of any one of claims 544 or 545, wherein the executable instructions specify pixel-wise operations comprising at least one of: reading, writing, modifying, blending, or transforming pixel attributes.

547. The method of any one of claims 535 to 546, wherein the competitive assessment is performed independently for each encoder-determined patch, enabling different patches to be encoded using different encoding strategies within a single image.

548. The method of any one of claims 535 to 547, wherein the selected encoding strategy for a patch determines whether the patch is downscaled, retained at full resolution, or replaced with refinement data.

549. The method of any one of claims 535 to 548, wherein the competitive assessment includes determining whether encoding the patch by direct pixel operations, by a reduced-resolution form, or by refinement data results in reduced bitstream size.

550. The method of any one of claims 535 to 549, wherein the encoder determines memory-management operations for the encoder-determined patch, the operations comprising at least one of: allocating a memory region, retaining the region for a defined duration, reusing the region for subsequent constructions, or releasing the region.

551. The method of claim 550, wherein the encoder specifies a lifetime for the constructed patch, the lifetime defining how long the patch remains valid in memory for reuse in later reconstruction stages.

552. The method of any one of claims 535 to 551 , wherein construction of the patch at the decoding system comprises writing pixel attributes to encoder-specified memory regions, the regions comprising at least one of: a worksheet region, a grouping region, or a render region.

553. The method of any one of claims 535 to 552, wherein memory management at the decoding system includes tracking validity of pixels or regions based on operations executed during patch construction.

554. The method of claim 553, wherein the decoder dynamically derives a state structure indicating whether a pixel or region of pixels remains valid, without explicit signalling of the structure in the bitstream.

555. The method of any one of claims 535 to 554, wherein the encoder determines both the spatial region and the temporal duration for which a constructed patch remains accessible for reuse during reconstruction.

556. An encoder for encoding image content, the encoder comprising a processor configured to: construct an encoder-determined patch of pixels; determine memory-management operations for the encoder- determined patch, the operations comprising at least one of allocating a memory region, retaining the region for a defined duration, reusing the region for subsequent constructions, or releasing the region; and output symbols defining the memory-management operations for execution at a decoding system.

557. The encoder of claim 556, wherein the processor is configured to specify a lifetime for the constructed patch, the lifetime defining how long the patch remains valid in memory for reuse in later reconstruction stages.

558. The encoder of claim 556 or 557, wherein the processor is configured to specify memory regions for patch construction, the regions comprising at least one of: a worksheet region, a grouping region, or a render region.

559. The encoder of any one of claims 556 to 558, wherein the processor is configured to determine both the spatial region and the temporal duration for which a constructed patch remains accessible for reuse during reconstruction.

560. The encoder of any one of claims 556 to 559, wherein the processor is configured to generate symbols that cause the decoding system to track validity of pixels or regions based on operations executed during patch construction.561 . The encoder of any one of claims 556 to 560, wherein the processor is configured to generate symbols that enable the decoding system to dynamically derive a state structure indicating whether a pixel or region of pixels remains valid, without explicit signalling of the structure in the bitstream.

562. A decoder for decoding encoded image content, the decoder comprising a processor configured to: receive symbols defining memory-management operations for an encoder-determined patch; execute the memory-management operations, the operations comprising at least one of allocating a memory region, retaining the region for a defined duration, reusing the region for subsequent constructions, or releasing the region; and construct the patch by performing operations defined by the received symbols.

563. The decoder of claim 562, wherein the processor is configured to process a lifetime specification for the constructed patch, the lifetime defining how long the patch remains valid in memory for reuse in later reconstruction stages.

564. The decoder of claim 562 or 563, wherein the processor is configured to write pixel attributes to encoder-specified memory regions during patch construction, the regions comprising at least one of: a worksheet region, a grouping region, or a render region.

565. The decoder of any one of claims 562 to 564, wherein the processor is configured to track validity of pixels or regions based on operations executed during patch construction.

566. The decoder of claim 565, wherein the processor is configured to dynamically derive a state structure indicating whether a pixel or region of pixels remains valid, without explicit signalling of the structure in the bitstream.

567. The decoder of any one of claims 562 to 566, wherein the processor is configured to maintain accessibility of a constructed patch for reuse during reconstruction based on both a spatial region specification and a temporal duration specification received in the symbols.

568. A bitstream for conveying encoded image content, the bitstream comprising symbols defining: memory-management operations for an encoder-determined patch, the operations comprising at least one of allocating a memory region, retaining the region for a defined duration, reusing the region for subsequent constructions, or releasing the region; and construction operations for the patch executable at a decoding system.

569. The bitstream of claim 568, comprising symbols specifying a lifetime for the constructed patch, the lifetime defining how long the patch remains valid in memory for reuse in later reconstruction stages.

570. The bitstream of claim 568 or 569, comprising symbols specifying memory regions for patch construction, the regions comprising at least one of: a worksheet region, a grouping region, or a render region.571 . The bitstream of any one of claims 568 to 570, comprising symbols that enable the decoding system to track validity of pixels or regions based on operations executed during patch construction.

572. The bitstream of claim 571 , wherein the symbols enable the decoding system to dynamically derive a state structure indicating whether a pixel or region of pixels remains valid, without the bitstream explicitly signalling the structure.

573. The bitstream of any one of claims 568 to 572, comprising symbols specifying both a spatial region and a temporal duration for which a constructed patch remains accessible for reuse during reconstruction.

574. A method of providing interactive content from a server to a remote device, comprising: an encoder encoding for transmission to the remote device, a first data stream comprising a plurality of image components, each for construction or storage in a respective distinct first location of memory of the remote device, and instructions for constructing said image components and their locations for storage; and encoding for transmission to the remote device, a data stream, together with or independently of said first data stream, that comprises instructions for causing copying of each of a selection of said stored image components from said first locations to one or more respective distinct second locations in the memory; wherein said first data stream and said data stream collectively comprise a streaming bitstream; and a processor at the remote device for causing said construction and copying.

575. The method of claim 574, wherein the interactive content comprises a streaming game.

576. The method of claim 574 or 575, wherein the first data stream further comprises an image component for storage in part at least of a first location occupied or previously occupied by a prior stored component.

577. The method of claim 574 or 575, further comprising an image component for compositing with part at least of a previously stored image component at a first location.

578. The method of claim 574 or 575, wherein copying to the second locations produces a composite component.

579. The method of claim 574 or 575, wherein copying to the second location image component occupies at least part of the memory location of a previous image component.

580. The method of claims 578 or 579, wherein the depth of a composited image component is determined by the encoder order of copying the component.581 . The method of claim 580, wherein said ordering is independent of a z-axis coordinate.

582. The method of claims 574 to 581 , wherein copying to the second location is for producing a frame or an intermediate representation for output.

583. The method of claim 582, wherein the one or more distinct second locations comprise a region of memory for frame assembly.

584. The method of claim 583, wherein the region of memory comprises pixel attributes for an encoded frame size or part thereof.

585. The method of claim 583, wherein the region of memory comprises pixel attributes for an output frame size or part thereof.

586. The method of claim 584, wherein copying comprises copying from the region of memory comprising pixel attributes for an encoded frame size to a region of memory comprising pixel attributes for an output frame size.

587. The method of claim 584, wherein the region of memory comprising pixel attributes for an encoded frame size comprises worksheet memory.

588. The method of claim 585, wherein the region of memory comprising pixel attributes for an output frame size comprises render image memory.

589. The method of claim 582, wherein an image component is used to construct multiple frames without retransmission.

590. The method of claim 589, wherein the encoder determines which frames utilize each stored image component.591 . The method of any of claims 574 to 590, wherein determination of location for construction or copying, duration of storage, or sequencing of construction or copying of a component, is independent of a predetermined protocol at the remote device.

592. The method of claim 591 , wherein said determination is arbitrary and is made by the encoder.

593. The method of claim 592, wherein said determination is based on optimising the encoding.

594. The method of any of claims 574 to 593, wherein the construction of image components is asynchronous to frame output.

595. The method of any of claims 574 to 594, wherein part at least of an image component at a first distinct location is modified in response to an instruction in the streaming bitstream.

596. The method of any of claims 574 to 595, wherein said image component comprises a patch of pixels.

597. The method of any of claims 574 to 596, wherein the remote device includes a decoder for decoding the encoded data stream.

598. The method of claim 597, wherein the processor is part of the decoder.

599. The method of any of claims 574 to 598, wherein the memory is accessible by said processor.

600. The method of claim 599, wherein said processor comprises a virtual processor.

601. The method of claim 600, wherein said virtual processor is configured for execution in a graphics processing unit.

602. The method of claim 600 or 601 , wherein said virtual processor is embodied in shader code.

603. The method of any of claims 574 to 602, wherein the memory is configured as pixel space.

604. The method of any of claims 574 to 603, wherein the streaming bitstream comprises control information, image component data, and memory management directives.

605. The method of claim 604, wherein said streaming bitstream comprises executable instructions that, when executed by the processor, implement said control information, image component data, and memory management directives.

606. The method of any of claims 574 to 605, wherein the streaming bitstream comprises control information for parallel processing.

607. The method of claim 606, wherein said streaming bitstream comprises executable instructions that, when executed by the processor, implement said control information for parallel processing.

608. The method of claims 605 or 607, wherein said executable instructions are operable on pixel space.

609. The method of claim 608, wherein operations on pixel space comprise at least one of: addressing a pixel as a coordinate in an array of pixels, reading pixel attributes, writing pixel attributes, or locating a pointer to a pixel coordinate for subsequent operations.

610. The method of any of claims 574 to 609, wherein construction of an image component utilizes specialized processing capabilities at the remote device.

611. The method of claim 610, wherein the specialized processing capabilities perform 3D model generation.

612. The method of claim 610, wherein the specialized processing capabilities perform at least one of: 2D model generation, transform operations, text rendering, fractal decoding, vector graphics generation, prediction processing, particle generation, or secure processing.

613. The method of claim 610, 611 or 612, wherein the instructions specify memory locations for placement of reconstructed pixel attributes, said locations determined during encoding.

614. The method of any of claims 610 to 613, wherein the specialized processing operates independently of main image reconstruction processes.

615. The method of any of claims 574 to 614, wherein the image components comprise at least one of: textures, 3D model data, vector graphics, particle effects, or geometric primitives.

616. The method of any of claims 574 to 615, wherein an image component comprises a texture.

617. The method of claim 616, wherein the texture is passed to a processing function for texture wrapping.

618. The method of claim 617, wherein the processing function comprises 3D model generation.

619. The method of claim 618, wherein the texture is applied to a 3D model.

620. The method of any of claims 616 to 619, wherein the texture is constructed in graphics processing unit memory.

621. The method of claim 620, wherein the texture is constructed directly in graphics processing unit memory without transfer from system memory.

622. The method of any of claims 610 to 621 , wherein the specialized processing capabilities receive information via a stack.

623. The method of claim 622, wherein the processor pushes data to said stack for use by the specialized processing capabilities.

624. The method of any of claims 610 to 623, wherein the specialized processing capabilities return reconstructed data to the memory.

625. The method of any of claims 610 to 624, wherein the specialized processing capabilities comprise at least one of a Special Purpose Engine or a Host Pixel Generator.

626. The method of any of claims 574 to 625, further comprising inserting advertising or custom imagery onto an image component.

627. The method of claim 626, wherein the advertising or custom imagery is delivered in a separate data stream.

628. The method of claim 626 or 627, wherein the advertising or custom imagery is composited at the remote device.

629. The method of claim 628, wherein the compositing is by the decoder.

630. The method of any of claims 626 to 629, wherein the advertising or custom imagery is targeted to a viewer.631 . The method of any of claims 574 to 630, further comprising the server receiving user input from the remote device.

632. The method of claim 631 , wherein user input comprises player interaction with the interactive content.

633. The method of claim 631 or 632, wherein the encoder encodes subsequent image components based on said user input.

634. The method of any of claims 631 to 633, wherein game logic is executed at the server in response to the user input.

635. The method of claim 634, wherein the encoder generates frames based on game state determined by execution of the game logic.

636. The method of claim 634 or 635, wherein the decoder at the remote device outputs frames for display.

637. The method of any of claims 631 to 633, further comprising: a games engine at the remote device operating under control of instructions in the streaming bitstream; wherein textures and parameters constructed in the memory are passed to the games engine.

638. The method of claim 637, wherein the games engine performs 3D modeling or texture wrapping and returns processed image data to the memory.

639. The method of claim 638, wherein the returned image data is combined with other image components in the memory for output as frames.

640. The method of any of claims 635 to 639, wherein the one or more distinct second locations comprise a region of memory for frame assembly.

641. The method of claim 640, wherein the region of memory comprises pixel attributes for an encoded frame size or part thereof.

642. The method of claim 640, wherein the region of memory comprises pixel attributes for an output frame size or part thereof.

643. The method of claim 641 , wherein copying comprises copying from the region of memory comprising pixel attributes for an encoded frame size to a region of memory comprising pixel attributes for an output frame size.

644. The method of claim 641 , wherein the region of memory comprising pixel attributes for an encoded frame size comprises worksheet memory.

645. The method of claim 642, wherein the region of memory comprising pixel attributes for an output frame size comprises render image memory.

646. The method of any of claims 635 to 645, wherein an image component is used to construct multiple frames without retransmission.

647. The method of any of claims 574 to 646, wherein the first distinct locations for storage of image components comprise worksheet memory.

648. The method of any of claims 574 to 630, further comprising: a games engine at the remote device controlling game logic; wherein the games engine receives user input directly at the remote device.

649. The method of claim 648, wherein the games engine requests textures from the server based on game state.

650. The method of claim 649, wherein requested textures are constructed by the encoder and transmitted via the streaming bitstream.651 . The method of any of claims 648 to 650, wherein textures are constructed in graphics processing unit memory at the remote device.

652. The method of any of claims 648 to 651 , wherein the first distinct locations for storage of image components comprise worksheet memory.

653. The method of any of claims 648 to 652, wherein the games engine outputs frames to a display.

654. A method of delivering data by encoding it into a bitstream structured for an encoded image, said bitstream for processing by a decoder at a computer, said processing configured to transfer the data to a secure processing module coupled to the computer, wherein said data is cryptographically protected in transit to the secure module.

655. The method of claim 654, wherein the data is protected from a process required for its delivery to the secure module, said process operable on the computer or under the control of the computer operating system.

656. The method of claims 654 or 655, wherein the secure module outputs processed information to a memory accessible by a component of the computer.

657. The method of claim 656, wherein the memory is GPU memory.

658. The method of claims 656 or 657, wherein memory is configured in pixel space.

659. The method of claim 658, wherein a virtual processor (VP) is operable on said memory to reconstruct a patch of pixels.

660. The method of claims 654 or 655, wherein said VP transfers the cryptographically protected data to the secure module.661 . The method of any of claims 654 to 660, wherein the bitstream further comprises an encrypted image and the secure module outputs an image (first image) in a format for use in displaying said image on a display.

662. The method of claim 661 , wherein the display is configured to also receive an image (second image) produced by a component of the computer external to the secure module.

663. The method of claim 662, wherein the secure module controls the output of the first and second images to the display.

664. The method of claims 661 , 662, or 663, wherein the secure module controls a signal indicating to a viewer that an image on the display purported to be from the secure module, is from the secure module.

665. A non-transitory computer-readable medium storing a bitstream structured for an encoded image, said bitstream comprising data for processing by a decoder at a computer and subsequent transfer to a secure module coupled to the computer, wherein said data is cryptographically protected during transit to the module.

666. An encoder comprising: a processor configured to receive encrypted data; and encoding logic configured to encode said encrypted data into a bitstream structured for an encoded image; wherein said bitstream, when delivered to a decoder, enables transfer of said encrypted data to a secure processing module, and wherein said encrypted data is cryptographically protected such that access by a computer hosting said decoder does not compromise security.

667. A decoder at a computer comprising: an input configured to receive a bitstream structured for an encoded image, said bitstream comprising encrypted data; processing logic configured to: identify said encrypted data within said bitstream; and route said encrypted data to a secure processing module coupled to said computer; wherein said decoder operates without decrypting said encrypted data.CLAIMS 668-719.

668. A system for verifying authenticity of displayed content, comprising: a secure module connected to or for connection to a host computing device, said secure module configured to output securely processed content to a display; and a verification signal mechanism controlled by said secure module that provides a user with verification that content being displayed on said display originates from said secure module.

669. The system of claim 668, wherein said secure module simultaneously controls both the content output to the display and the verification signal mechanism.

670. The system of claim 668, wherein said verification signal mechanism is controlled exclusively by said secure module.671 . The system of claim 668, wherein said verification signal mechanism comprises a visible indicator.

672. The system of claim 671 , wherein said visible indicator is positioned on or near said display.

673. The system of claim 671 , wherein said visible indicator comprises one or more light emitting elements.

674. The system of claim 668, wherein said verification signal mechanism exhibits a predetermined pattern or state that a user can match with an expected secure state.

675. The system of claim 668, wherein said verification signal creates a relationship between the displayed content and said verification signal that cannot be reproduced by said host computing device.

676. The system of claim 668, wherein said verification signal mechanism comprises a visual state having at least one of: a specific colour, a flash pattern, and an intensity level.

677. The system of claim 668, wherein said verification signal provides attestation that information presented on said display has not been tampered with by said host computing device.

678. The system of claim 668, wherein said secure module operates independently of said host computing device's general-purpose logic when controlling said verification signal mechanism.

679. The system of claim 668, wherein said verification signal mechanism is physically constructed to be controllable only by said secure module and not by said host computing device.

680. The system of claim 668, wherein said secure module activates said verification signal mechanism when displaying security-sensitive information on said display.

681. The system of claim 668, wherein said secure module outputs content directly to a video port, bypassing a display pipeline of said host computing device.

682. The system of claim 668, wherein the secure module comprises a self-contained unit having a secure processor and secure memory.

683. The system of claim 682, wherein the secure module is physically separable from said host computing device and configured in a pluggable format.

684. The system of claim 683, wherein the pluggable format comprises a SIM-card style format.

685. The system of claim 683, wherein the secure module operates independently of said host computing device's general-purpose processing components.

686. The system of claim 683, wherein the secure module is provided by a vendor independent of a manufacturer of said host computing device.

687. The system of claim 683, wherein the secure module is configured to cease functioning if removed from an authorised host computing device.

688. The system of claim 687, wherein the secure module is configured to: (a) securely register a unique identifier of said host computing device within secure memory upon initial installation; and (b) verify a match between the stored unique identifier and said host computing device's identifier during operation.

689. The system of claim 688, wherein the unique identifier comprises a MAC address, CPU ID, or platformspecific hardware fingerprint of said host computing device.

690. The system of claim 668, further comprising a trusted intermediary configured to: (a) verify identity of a content source; (b) receive content from the verified content source; and (c) package the content for secure transmission to the secure module.691 . The system of claim 669, wherein simultaneous control of both the content output to the display and the verification signal mechanism prevents spoofing of secure content by software operating on said host computing device.

692. The system of claim 668, wherein said host computing device is unable to control said verification signal mechanism independently of said secure module.

693. The system of claim 668, wherein said verification signal mechanism provides a user-verifiable indication that displayed content has not been intercepted or replaced by processes operating on said host computing device.

694. The system of claim 669, wherein the relationship between the displayed content and the verification signal mechanism's state is determinable only by said secure module and not by said host computing device.

695. The system of claim 668, wherein said verification signal mechanism operates through a hardware pathway that is inaccessible to software processes of said host computing device.

696. The system of claim 668, wherein said secure module controls said verification signal mechanism through a dedicated hardware connection that bypasses control pathways of said host computing device.

697. The system of claim 681 , wherein bypassing the display pipeline of said host computing device prevents interception or modification of the securely processed content by said host computing device.

698. A method for verifying authenticity of displayed content, comprising: outputting, by a secure module connected to or for connection to a host computing device, content to a display; and controlling, by said secure module, a verification signal mechanism that provides a user with verification that content being displayed on said display originates from said secure module.

699. The method of claim 698, further comprising simultaneously controlling, by said secure module, both the content output to the display and the verification signal mechanism.

700. The method of claim 698, wherein said verification signal mechanism is controlled exclusively by said secure module.701 . The method of claim 698, wherein said verification signal mechanism comprises a visible indicator.

702. The method of claim 701 , wherein said visible indicator is positioned on or near said display.

703. The method of claim 698, further comprising activating said verification signal mechanism according to a predetermined pattern or state that a user can match with an expected secure state.

704. The method of claim 698, further comprising creating, via said verification signal, a relationship between the displayed content and said verification signal that cannot be reproduced by said host computing device.

705. The method of claim 698, wherein said verification signal mechanism comprises a visual state having at least one of: a specific colour, a flash pattern, and an intensity level.

706. The method of claim 698, wherein said verification signal provides attestation that information presented on said display has not been tampered with by said host computing device or malicious software.

707. The method of claim 698, further comprising operating said secure module independently of said host computing device's general-purpose logic when controlling said verification signal mechanism.

708. The method of claim 698, further comprising activating said verification signal mechanism when displaying security-sensitive information on said display.

709. The method of claim 698, further comprising outputting content directly to a video port, bypassing a display pipeline of said host computing device.

710. The method of claim 698, wherein the secure module comprises a self-contained unit having a secure processor and secure memory that operate independently of said host computing device's general- purpose processing components.

711. The method of claim 698, further comprising receiving encrypted data at said secure module and decrypting said encrypted data prior to outputting corresponding content to the display.

712. The method of claim 699, wherein simultaneously controlling both the content output and the verification signal mechanism prevents spoofing of secure content by software operating on said host computing device.

713. The method of claim 698, wherein said host computing device is unable to control said verification signal mechanism independently of said secure module.

714. The method of claim 698, further comprising providing, via said verification signal mechanism, a user- verifiable indication that displayed content has not been intercepted or replaced by processes operating on said host computing device.

715. The method of claim 709, wherein bypassing the display pipeline of said host computing device prevents interception or modification of the securely processed content by said host computing device.

716. A non-transitory computer-readable medium having stored thereon a bitstream that when processed by a secure module connected to or for connection to a host computing device, causes the secure module to: output content to a display; and control a verification signal mechanism that provides a user with verification that content being displayed on said display originates from the secure module.

717. The non-transitory computer-readable medium of claim 716, wherein said bitstream comprises encrypted content that, when decrypted by the secure module, is output as visual content on the display.

718. The non-transitory computer-readable medium of claim 716, wherein the bitstream causes the secure module to simultaneously control both the content output to the display and the verification signal mechanism.

719. The non-transitory computer-readable medium of claim 718, wherein simultaneous control of both the content output and the verification signal mechanism prevents spoofing of secure content by software operating on said host computing device.

720. A system for secure visual content display, comprising: a) a host computing device comprising a processor and memory; and b) a secure module operatively coupled to, or configured for operative coupling with, the host computing device, the secure module comprising: i) a secure processor; ii) a secure memory operatively coupled to the secure processor; and iii) a display interface directly coupled to the secure processor; and c) wherein the secure module is configured to: i) receive data, including encrypted or otherwise encoded display data, intended for display; ii) validate, reconstruct, decrypt, or otherwise process the received data within a secure execution environment isolated from the host computing device's operating system; and iii) generate and output display signals for a display device independently of the host operating system, such that the perceptible appearance or semantic content of the displayed visual information cannot be altered by processes outside the secure module after validation.721 . The system of claim 720, wherein the secure module is configured to output data.

722. The system of claim 721 , wherein the secure module outputs data to the host computing device.

723. The system of claim 722, wherein the secure module writes data to memory of the host computing device.

724. The system of claim 723, wherein said memory comprises worksheet memory.

725. The system of claim 720, wherein the secure module has access to GPS information.

726. The system of claim 725, wherein the GPS information is obtained from a GPS component within the secure module.

727. The system of claim 725, wherein the GPS information is obtained via an interface with the host computing device.

728. The system of claim 725, wherein the GPS information is obtained from a tamper-proof GPS component operatively coupled to the secure module.

729. The system of any of claims 725 to 728, wherein the secure module is configured to restrict display of content based on geographical location determined from the GPS information.

730. The system of claim 729, wherein access to content is conditioned upon the geographical location being within a predetermined geographical area.

731. The system of claim 729, wherein access to content is conditioned upon a predetermined time window.

732. The system of claim 729, wherein access to content is conditioned upon presence of a second authorized secure device or biometric confirmation.

733. The system of claim 720, wherein the secure memory stores cryptographic routines.

734. The system of claim 720, wherein the secure memory stores one-time pad data.

735. The system of claim 733 or 734, wherein the secure memory stores both cryptographic routines and one-time pad data.

736. The system of claim 720, wherein data is transferred to the secure module by pushing said data onto a stack accessible to the secure module.

737. The system of claim 736, wherein the secure module retrieves data from said stack for processing within the secure execution environment.

738. The system of claim 737, wherein the secure module processes the data asynchronously.

739. The system of claim 724, wherein the worksheet memory is accessible to a display controller for generating display output.

740. The system of claim 720, wherein access to the secure module is conditioned upon user authorization.741 . The system of claim 740, wherein user authorization comprises at least one of: biometric verification or presence of an authorized device.

742. The system of claim 740, wherein user authorization comprises multi-factor authentication.

743. The system of claim 742, wherein multi-factor authentication comprises both presence of a second authorized secure device and biometric confirmation.

744. The system of any of claims 720 to 743, wherein the data received by the secure module comprises a display request, content identifier, or encoded display data stream referencing one or more visual assets to be validated or reconstructed for secure display.

745. The system of any of claims 720 to 744, wherein the secure module is configured to: i) verify the integrity of the received data; ii) detect any unauthorized modification, corruption, or interference that may have occurred to the data before or during transmission to the secure module; and iii) prevent display of data that fails integrity verification, thereby ensuring that only validated data influences the visual output.

746. The system of any of claims 720 to 745, wherein the data is provided as a bitstream on non-transient computer-readable media.

747. The system of claim 746, wherein the bitstream is structured for an encoded image.

748. The system of claim 747, wherein said bitstream includes an encoded image.

749. The system of claim 746, 747 or 748, wherein the bitstream further comprises control information and memory management directives.

750. The system of any of claims 746 to 749, wherein the bitstream comprises executable instructions.751 . The system of claim 750, wherein said instructions are executed by a processor integral to an image codec of the host.

752. The system of claim 751 , wherein said processor is a virtual processor.

753. The system of claim 751 or 752, wherein said processor is operable on pixel space.

754. The system of any of claims 750 to 753, wherein execution of an instruction signals the processor to transfer said data to the secure module.

755. The system of claim 752, wherein said virtual processor is configured in a GPU.

756. The system of claim 750, wherein said executable instructions direct data to be pushed onto a stack accessible to the secure module.

757. The system of any of claims 720 to 756, wherein the secure module is physically separable from the host computing device and configured in a pluggable format.

758. The system of claim 757, wherein the secure module is provided by a vendor independent of the manufacturer of the host computing device.

759. The system of claim 757, wherein the secure module is configured to cease functioning if removed from an authorized host computing device.

760. The system of claim 759, wherein the secure module is configured to: i) securely register a unique identifier of the host computing device within the secure memory upon initial installation; and ii) verify the match between the stored unique identifier and the host computing device's identifier during operation.

761. The system of claim 760, wherein the unique identifier comprises a MAC address, CPU ID, or other platform-specific hardware fingerprint of the host computing device.

762. The system of any of claims 720 to 761 , wherein the secure module is configured to control a physical indicator that provides visual confirmation of secure display operation.

763. The system of claim 762, wherein the secure module is configured to: i) control both the display content output to the display device and the physical indicator in a synchronized manner; and ii) generate a specific pattern, colour sequence, or visual state on the physical indicator that corresponds to the secure content being displayed.

764. The system of claim 763, wherein the specific pattern, colour sequence, or visual state displayed by the physical indicator provides a user with a means to verify that the display content originates from the secure module.

765. The system of claim 764, wherein verification is achieved by the user visually matching the physical indicator's state with a pre-informed expected secure state.

766. The system of claim 763, wherein the synchronized control of both display content and physical indicator by the secure module provides verification that the displayed content has not been tampered with by the host system or malicious software.

767. The system of claim 762, wherein the physical indicator is positioned on or near the display device receiving output from the secure module.

768. The system of any of claims 720 to 767, further comprising a trusted intermediary configured to: i) verify identity of a content source; ii) receive content from the verified content source; and iii) package the content for secure transmission to the secure module.

769. The system of claim 768, wherein the secure module is configured to accept validated data exclusively from trusted intermediaries.

770. The system of claim 769, wherein the secure module is configured to reject data that does not originate from a trusted intermediary.

771. The system of claim 768, wherein the trusted intermediary maintains identity records of content sources.

772. The system of claim 771 , wherein the trusted intermediary is configured to deactivate a content source's authorization based on detection of unsolicited content transmission.

773. The system of claim 734, wherein the one-time pad data is known only to a trusted intermediary and the secure module.

774. The system of claim 734, wherein the secure module is configured to dynamically update the onetime pad data based on encrypted information received in a bitstream.

775. The system of any of claims 720 to 774, wherein the secure module operates as a secure thin client by: i) receiving encrypted data from a remote processing system; ii) decrypting and processing said datawithin the secure execution environment isolated from the host computing device; and iii) generating display signals for the display device without exposing semantic content of said data to the host computing device.

776. The system of claim 775, wherein the secure module provides tamper-resistant input and output for the remote processing system.

777. The system of any of claims 720 to 776, wherein the secure module is configured to provide tamperresistant output for a remote processing system by outputting display signals that are inaccessible to processes of the host computing device.

778. The system of any of claims 720 to 777, wherein the secure module outputs display signals directly to a video port, with access to said video port controlled by the secure module.

779. The system of claim 778, wherein the video port is shared by the secure module and the host computing device.

780. The system of claim 779, wherein the secure module controls host computing device access to the shared video port.

781. The system of claim 780, wherein the secure module blocks host computing device access to the video port during secure content display.

782. The system of claim 780, wherein the secure module selectively permits or denies host computing device access to the video port based on display regions.

783. A method for secure visual content display, comprising: receiving, by a secure module, data including encrypted or otherwise encoded display data; validating, reconstructing, decrypting, or otherwise processing the received data within a secure execution environment isolated from a host computing device's operating system; and generating and outputting display signals fora display device independently of the host operating system.

784. The method of claim 783, further comprising outputting display signals directly to a video port, with access to said video port controlled by the secure module.

785. The method of claim 784, wherein the video port is shared by the secure module and the host computing device.

786. The method of claim 785, further comprising controlling host computing device access to the shared video port.

787. The method of claim 786, further comprising blocking host computing device access to the video port during secure content display.

788. The method of claim 783, further comprising controlling a physical indicator that provides visual confirmation of secure display operation.

789. The method of claim 788, further comprising synchronizing control of both display content output and the physical indicator.

790. A non-transitory computer-readable medium storing a bitstream that when processed by a secure module, causes the secure module to: validate, reconstruct, decrypt, or otherwise process data within a secure execution environment; and generate and output display signals for a display device.791 . The non-transitory computer-readable medium of claim 790, wherein the bitstream is structured for an encoded image.

792. An encoder for generating secure visual content, comprising: a processor; and memory storing instructions that, when executed, cause the encoder to: encode content into a bitstream for processing by a secure module; and embed control information in the bitstream for controlling display output by the secure module.

793. A system for location-based access control, comprising: a computing device comprising a processor and memory; a hardware security module operatively coupled to the computing device, the hardware security module comprising: i) a secure processor; ii) secure memory; and iii) access to GPS information; and wherein the hardware security module is configured to: i) receive a request to access an application ordata; ii) determine a geographical location based on the GPS information; iii) compare the geographical location to a predetermined authorized location; and iv) selectively permit or deny access to the application or data based on the comparison, while permitting continued operation of other functions of the computing device.

794. The system of claim 793, wherein the GPS information is obtained from a GPS component within the hardware security module.

795. The system of claim 793, wherein the GPS information is obtained from a tamper-proof GPS component operatively coupled to the hardware security module.

796. The system of claim 793, wherein access is denied when the geographical location is outside the predetermined authorized location.

797. The system of claim 793, wherein the predetermined authorized location comprises a geofenced area.

798. The system of claim 793, wherein access is further conditioned upon a predetermined time window.

799. The system of claim 793, wherein access is further conditioned upon presence of a second authorized device or biometric confirmation.

800. The system of claim 793, wherein the hardware security module is physically separable from the computing device and configured in a pluggable format.

801. The system of claim 793, wherein the application comprises a financial application, healthcare application, or enterprise data access application.

802. The system of claim 793, wherein denial of access prevents display, execution, or decryption of the application or data without affecting other operations of the computing device.

803. The system of any of claims 793 to 802, wherein the hardware security module outputs display signals directly to a video port, with access to said video port controlled by the hardware security module.

804. The system of claim 803, wherein the video port is shared by the hardware security module and the computing device.

805. The system of claim 804, wherein the hardware security module controls computing device access to the shared video port.

806. The system of claim 805, wherein the hardware security module blocks computing device access to the video port during secure content display.

807. The system of claim 805, wherein the hardware security module selectively permits or denies computing device access to the video port based on display regions.

808. A method for location-based access control, comprising: receiving, by a hardware security module, a request to access an application or data; determining a geographical location based on GPS information; comparing the geographical location to a predetermined authorized location; and selectively permitting or denying access based on the comparison.

809. The method of claim 808, further comprising outputting display signals directly to a video port, with access to said video port controlled by the hardware security module.

810. The method of claim 809, further comprising controlling computing device access to the shared video port.811 . A non-transitory computer-readable medium storing instructions that when executed by a hardware security module, cause the hardware security module to: determine a geographical location based on GPS information; compare the geographical location to a predetermined authorized location; and selectively permit or deny access to an application or data based on the comparison.

812. A method for secure steganographic encoding, comprising: capturing or creating image data within a secure processing environment; and embedding steganographic information within said image data during capture or creation within said secure processing environment.

813. The method of claim 812, wherein the secure processing environment comprises a restricted memory component of an image capture device.

814. The method of claim 812, wherein the secure processing environment comprises a restricted memory component of a computing device executing image creation software.

815. The method of claim 814, wherein the image creation software comprises painting software, video editing software, or design software.

816. The method of any of claims 812 to 815, wherein the steganographic information is embedded before the image data is accessible outside the secure processing environment.

817. The method of any of claims 812 to 816, further comprising restricting access to decryption information for the steganographic information to trusted entities.

818. The method of claim 817, wherein the decryption information comprises a key for identifying and sequencing the steganographic information.

819. The method of claim 818, wherein the key is embedded within the image data within the secure processing environment.

820. The method of claim 818, wherein the key is encrypted using cryptographic routines stored in the secure processing environment.

821. The method of claim 817, wherein the trusted entities comprise at least one of: legal authorities, content verification services, or social media platforms.

822. The method of any of claims 812 to 821 , wherein the steganographic encoding process is performed by executable instructions operating within the secure processing environment.

823. The method of claim 822, wherein the image data is represented as executable instructions operable on pixel space.

824. The method of claim 823, wherein embedding steganographic information comprises modifying pixel attributes through said executable instructions.

825. The method of claim 823, wherein the executable instructions enable arbitrary selection of pixels for steganographic information embedding.

826. The method of claim 825, wherein selected pixels are chosen to retain information integrity during subsequent encoding operations.

827. The method of any of claims 812 to 826, wherein the steganographic encoding process is unique to a particular device.

828. The method of claim 827, wherein uniqueness is achieved through device-specific cryptographic routines stored in the secure processing environment.

829. The method of claim 827, wherein compromise of one device does not compromise integrity of steganographic data embedded by another device.

830. The method of any of claims 812 to 829, wherein the steganographic information comprises at least one of: device identifier, creator identifier, creation timestamp, or location data.

831. The method of claim 830, wherein the image data comprises a plurality of frames, and wherein the steganographic information includes location data for deriving velocity or trajectory of the image capture device.

832. The method of claim 830, wherein the steganographic information includes time information indicating whether the image data originates from a live feed.

833. The method of claim 830, wherein the steganographic encoding process affects different pixels from frame to frame.

834. The method of any of claims 812 to 833, wherein the image data encoded with steganographic information provides verification of image authenticity for use as evidence.

835. The method of claim 834, wherein verification comprises validating the steganographic information by a trusted entity having access to decryption information.

836. The method of claim 834, wherein the image data is accepted in legal proceedings based on successful verification of the steganographic information.

837. The method of claim 834, wherein absence of verifiable steganographic information results in the image data being flagged as unverified.

838. The method of any of claims 812 to 833, wherein the steganographic information enables identification of inappropriate content for content moderation.

839. The method of claim 838, wherein content moderation comprises determining whether content requires restriction before dissemination on social media platforms.

840. The method of claim 838, wherein the steganographic information is validated by a social media platform to determine content authenticity prior to publication.841 . The method of claim 840, wherein Al-driven content moderation processes utilize the steganographic information to assess content appropriateness.

842. The method of claim 841 , wherein the steganographic information assists in identifying deepfake content, manipulated images, or synthetically generated content.

843. The method of any of claims 812 to 842, wherein the steganographic information associates ownership, copyright, or licensing information with the image data.

844. A system for secure steganographic encoding, comprising: a secure processing environment comprising: i) a secure processor; ii) secure memory storing cryptographic routines; and iii) instructions stored in said secure memory; wherein execution of said instructions causes the system to: capture or create image data; embed steganographic information within said image data during capture or creation; and restrict access to decryption information to trusted entities.

845. The system of claim 844, wherein the secure processing environment is integral to an image capture device.

846. The system of claim 844, wherein the secure processing environment is integral to a computing device executing image creation software.

847. The system of claim 844, wherein the instructions comprise executable instructions operable on pixel space.

848. The system of claim 847, wherein the executable instructions enable arbitrary pixel selection for steganographic information embedding.

849. The system of claim 844, wherein the steganographic encoding process is unique to the system through device-specific cryptographic routines.

850. A non-transitory computer-readable medium storing image data comprising: encoded image content created within a secure processing environment; and steganographic information embedded within said image data during creation within said secure processing environment, wherein access to decryption information for said steganographic information is restricted to trusted entities.851 . The non-transitory computer-readable medium of claim 850, wherein the steganographic information enables verification of image authenticity for evidentiary purposes.

852. The non-transitory computer-readable medium of claim 850, wherein the steganographic information enables content moderation by social media platforms.

853. A method for secure data transmission, comprising: receiving, by a trusted intermediary, data from a first party; verifying identity of the first party; validating the data received from the first party; packaging the validated data for secure transmission; and transmitting the packaged data to a second party.

854. The method of claim 853, wherein the trusted intermediary is configured to verify both identity of the first party and identity of the second party.

855. The method of claim 853 or 854, wherein validating the data comprises verifying authenticity and integrity of the data.

856. The method of any of claims 853 to 855, wherein packaging comprises encrypting the data for transmission to the second party.

857. The method of claim 856, wherein encryption uses one-time pad data known only to the trusted intermediary and the second party.

858. The method of any of claims 853 to 857, wherein the first party comprises a content provider.

859. The method of claim 858, wherein the content provider comprises a financial institution, healthcare provider, or government entity.

860. The method of any of claims 853 to 859, wherein the second party comprises a user operating a secure device.861 . The method of claim 860, wherein the secure device comprises a secure module configured to receive and process the packaged data.

862. The method of claim 861 , wherein the secure module is configured to accept data exclusively from trusted intermediaries.

863. The method of claim 861 or 862, wherein the secure module comprises a secure display output system.

864. The method of claim 863, wherein the secure display output system provides verification to the user that displayed content originates from the validated data.

865. The method of claim 864, wherein verification comprises a physical indicator controlled by the secure module.

866. The method of claim 865, wherein the physical indicator displays a synchronized pattern corresponding to secure content being displayed.

867. The method of any of claims 853 to 866, further comprising maintaining, by the trusted intermediary, identity records of authorized first parties.

868. The method of claim 867, further comprising deactivating authorization of a first party based on detection of unsolicited or malicious content transmission.

869. The method of any of claims 861 to 868, wherein the secure device is configured to reject data that does not originate from a trusted intermediary.

870. The method of any of claims 853 to 869, wherein access to the transmitted data is conditioned upon geographical location of the second party.871 . The method of claim 870, wherein geographical location is determined by GPS information accessible to the secure device.

872. The method of claim 871 , wherein access is denied when the geographical location is outside a predetermined authorized location.

873. The method of any of claims 870 to 872, wherein access to the transmitted data is further conditioned upon a predetermined time window.

874. The method of any of claims 870 to 873, wherein geographical and temporal conditioning of access mitigates coercion attacks.

875. The method of claim 874, wherein coercion mitigation comprises preventing access to sensitive data when the second party is outside authorized locations or time windows.

876. The method of any of claims 853 to 875, wherein the data comprises display data for secure visual content.

877. The method of claim 876, wherein the display data comprises financial transaction information, healthcare records, or confidential business information.

878. The method of any of claims 853 to 877, further comprising establishing an end-to-end trust chain from the first party to the second party through the trusted intermediary.

879. The method of claim 878, wherein the end-to-end trust chain ensures that content displayed to the second party originates from the verified first party and has not been tampered with.

880. A system for secure data transmission, comprising: a trusted intermediary configured to: receive data from a first party; verify identity of the first party; validate the data; package the validated data for secure transmission; and transmit the packaged data to a second party.

881. The system of claim 880, wherein the trusted intermediary is further configured to verify identity of the second party.

882. The system of claim 880 or 881 , wherein the second party comprises a secure device having a secure module configured to receive and process the packaged data.

883. The system of claim 882, wherein the secure module is configured to accept data exclusively from trusted intermediaries.

884. The system of claim 882 or 883, wherein the secure module comprises a secure display output system.

885. The system of claim 884, wherein the secure display output system comprises a physical indicator that provides visual verification of secure content display.

886. The system of any of claims 882 to 885, wherein the secure device has access to GPS information for determining geographical location.

887. The system of claim 886, wherein access to the transmitted data is conditioned upon the geographical location being within a predetermined authorized area.

888. The system of claim 886 or 887, wherein access to the transmitted data is further conditioned upon a predetermined time window.

889. The system of any of claims 886 to 888, wherein geographical and temporal conditioning mitigates coercion attacks by preventing unauthorized access outside authorized locations or times.

890. The system of any of claims 880 to 889, wherein the trusted intermediary maintains identity records and is configured to deactivate authorization based on detection of malicious content.

891. A non-transitory computer-readable medium storing instructions that when executed by a trusted intermediary system, cause the system to: receive data from a first party; verify identity of the first party; validate the data; package the validated data for secure transmission; and transmit the packaged data to a second party.

892. A non-transitory computer-readable medium comprising a two-dimensional barcode encoding an image as a sequence of executable instructions, wherein said executable instructions, when executed by a processor, reconstruct said image for display.

893. The non-transitory computer-readable medium of claim 892, wherein said two-dimensional barcode is selected from the group consisting of: QR codes, Data Matrix codes, Aztec codes, and PDF417 codes.

894. The non-transitory computer-readable medium of claims 892 or 893, wherein, the instructions are operable on pixel space.

895. The non-transitory computer-readable medium of claims 892, 893, or 894, wherein, the reconstruction comprises reconstruction of a plurality of patches of a frame at arbitrary locations determined by the encoder of the image.

896. The non-transitory computer-readable medium of any of claims 892 to 895, wherein the sequence of instructions comprise control, image content and memory management.

897. The non-transitory computer-readable medium of any of claims 892 to 896, wherein said executable instructions, when executed, reconstruct the image independently of a network connection.

898. The non-transitory computer-readable medium of any of claims 892 to 897, wherein said image comprises an animated sequence.

899. The non-transitory computer-readable medium of any of claims 892 to 898, wherein said two- dimensional barcode is machine-readable by an augmented reality device for rendering displayable content within an augmented environment.

900. The non-transitory computer-readable medium of claim 899, wherein said displayable content comprises three-dimensional object geometry.

901. A display module comprising: a display panel; a display driver component for driving the panel; a component for receiving a bitstream encoding an image as a sequence of executable computer instructions operable on pixel space memory, said component comprising: memory arranged in pixel space and a processor for executing said instructions for reconstruction of the image in said pixel space to a format that enables the display driver to output the image to the display panel.

902. The display module of claim 901 , wherein the display module comprises a Liquid Crystal Display (LCD) or Organic Light Emitting Diode (OLED).

903. The display module of claims 901 or 902, wherein the processor reads or writes pixel attributes by addressing pixel coordinates.

904. The display module of claim 903, wherein the processor is a virtual processor.

905. The display module of any of claims 901 to 904, wherein the bitstream includes control, image content and memory management.

906. The display module of any of claims 901 to 905, wherein the display driver and the component for receiving an image are integrated.

907. A method for encoding data for parallel reconstruction, comprising: dividing content into a plurality of threads for parallel processing; embedding execution control information within a bitstream that specifies execution dependencies between threads, whereby parallel execution is self-scheduled from said bitstream for at least one thread; and outputting said bitstream.

908. The method of claim 907, wherein said self-scheduling is without reliance on operating system thread scheduling.

909. The method of claim 907 or claim 908, wherein said execution control information comprises one or more selected from: thread identifiers, wait instructions referencing prerequisite threads, completion signals, resource allocation requests, and staged execution controls positioned at multiple locations within a thread.

910. The method of claim 909, wherein said wait instructions prevent execution of a thread until one or more prerequisite threads complete.

911. The method of claim 909, wherein said completion signals indicate thread completion status and trigger execution of dependent threads.

912. The method of claim 909, wherein said resource allocation requests specify one or more of: processing priority, processor type, memory allocation, or execution resources.

913. The method of claim 909, wherein said staged execution controls are positioned at multiple locations within a thread to provide fine-grained synchronization points.

914. The method of claim 907 or claim 908, wherein said execution control information is read by a decoder and used to control execution of said at least one thread during parallel reconstruction.

915. The method of claim 908, wherein thread synchronization is achieved through said embedded execution control information without operating system synchronization primitives.

916. The method of claim 908, wherein all threads are executed according to said embedded execution control information without invoking operating system thread scheduling.

917. The method of claim 908, wherein execution order of threads is deterministic and platform independent.

918. The method of any of claims 907 to 917, wherein said content comprises encoded image data.

919. The method of claim 918, wherein said image is represented as a sequence of executable instructions that when executed reconstruct the image.

920. The method of claim 919, wherein said executable instructions are operable on pixel space.

921. The method of claim 919, wherein said executable instructions are executed by a virtual processor.

922. The method of claim 921 , wherein said virtual processor is configured for execution in a graphics processing unit.

923. The method of claim 922, wherein said virtual processor is embodied in shader code.

924. An encoder for encoding data for parallel reconstruction, comprising: a processor; and memory storing instructions that, when executed, cause the encoder to: divide content into a plurality of threads for parallel processing; embed execution control information within a bitstream that specifies execution dependencies between threads, whereby parallel execution is self-schedulable from said bitstream for at least one thread; and output said bitstream.

925. The encoder of claim 924, wherein said self-scheduling is without reliance on operating system thread scheduling.

926. The encoder of claim 924 or claim 925, wherein said execution control information comprises one or more selected from: thread identifiers, wait instructions referencing prerequisite threads, completion signals, resource allocation requests, and staged execution controls.

927. The encoder of claim 926, wherein said wait instructions prevent execution of a thread until one or more prerequisite threads complete.

928. The encoder of claim 926, wherein said completion signals indicate thread completion status and trigger execution of dependent threads.

929. The encoder of claim 926, wherein said resource allocation requests specify one or more of: processing priority, processor type, memory allocation, or execution resources.

930. The encoder of claim 926, wherein said staged execution controls are positioned at multiple locations within a thread to provide fine-grained synchronization points.

931. The encoder of claim 924 or claim 925, wherein said execution control information is usable by a decoder to control execution of said at least one thread during parallel reconstruction.

932. The encoder of claim 925, wherein thread synchronization is achievable through said embedded execution control information without operating system synchronization primitives.

933. The encoder of claim 925, wherein all threads are executable according to said embedded execution control information without invoking operating system thread scheduling.

934. The encoder of claim 925, wherein execution order of threads is deterministic and platform independent.

935. The encoder of any of claims 924 to 934, wherein said content comprises encoded image data.

936. The encoder of claim 935, wherein said image is represented as a sequence of executable instructions that when executed reconstruct the image.

937. The encoder of claim 936, wherein said executable instructions are operable on pixel space.

938. The encoder of claim 936, wherein said executable instructions are executed by a virtual processor.

939. The encoder of claim 938, wherein said virtual processor is configured for execution in a graphics processing unit.

940. The encoder of claim 939, wherein said virtual processor is embodied in shader code.941 . A decoder for processing data encoded for parallel execution, comprising: a processor; and memory storing instructions that, when executed, cause the decoder to: receive a bitstream comprising multiple threads with embedded execution control information specifying dependencies between threads; read said execution control information from said bitstream; execute at least one thread according to said execution control information in a self-scheduled manner; and reconstruct content through parallel thread execution.

942. The decoder of claim 941 , wherein said self-scheduled manner is without reliance on operating system thread scheduling.

943. The decoder of claim 941 or 942, wherein said execution control information comprises one or more selected from: thread identifiers, wait instructions, completion signals, resource allocation requests, and staged execution controls.

944. The decoder of claim 943, wherein said wait instructions prevent execution of a thread until one or more prerequisite threads complete.

945. The decoder of claim 943, wherein said completion signals indicate thread completion status and trigger execution of dependent threads.

946. The decoder of claim 943, wherein said resource allocation requests specify one or more of: processing priority, processor type, memory allocation, or execution resources.

947. The decoder of claim 943, wherein said staged execution controls are positioned at multiple locations within a thread to provide fine-grained synchronization points.

948. The decoder of claim 941 or claim 942, wherein the decoder uses said execution control information to control execution of said at least one thread during parallel reconstruction.

949. The decoder of claim 942, wherein thread synchronization is achieved through said embedded execution control information without operating system synchronization primitives.

950. The decoder of claim 942, wherein all threads are executed according to said embedded execution control information without invoking operating system thread scheduling.

951. The decoder of claim 942, wherein execution order of threads is deterministic and platform independent.

952. The decoder of any of claims 941 to 951 , wherein said content comprises encoded image data.

953. The decoder of claim 952, wherein said image is represented as a sequence of executable instructions that the decoder executes to reconstruct the image.

954. The decoder of claim 953, wherein said executable instructions are operable on pixel space.

955. The decoder of claim 953, further comprising a virtual processor that executes said executable instructions.

956. The decoder of claim 955, wherein said virtual processor is configured for execution in a graphics processing unit.

957. The decoder of claim 956, wherein said virtual processor is embodied in shader code.

958. A non-transitory computer-readable medium storing a bitstream for parallel execution, comprising: a plurality of threads; and execution control information embedded within at least one thread that specifies execution dependencies between threads, whereby parallel execution is self-schedulable from said bitstream for at least one thread during decoding.

959. The computer-readable medium of claim 958, wherein said self-scheduling is without reliance on operating system thread scheduling.

960. The computer-readable medium of claim 958 or 959, wherein said execution control information comprises one or more selected from: thread identifiers, wait instructions, completion signals, resource allocation requests, and staged execution controls.

961. The computer-readable medium of claim 960, wherein said wait instructions prevent execution of a thread until one or more prerequisite threads complete.

962. The computer-readable medium of claim 960, wherein said completion signals indicate thread completion status and trigger execution of dependent threads.

963. The computer-readable medium of claim 960, wherein said resource allocation requests specify one or more of: processing priority, processor type, memory allocation, or execution resources.

964. The computer-readable medium of claim 960, wherein said staged execution controls are positioned at multiple locations within a thread to provide fine-grained synchronization points.

965. The computer-readable medium of claim 958 or claim 959, wherein said execution control information is readable by a decoder and usable to control execution of said at least one thread during parallel reconstruction.

966. The computer-readable medium of claim 959, wherein thread synchronization is achievable through said embedded execution control information without operating system synchronization primitives.

967. The computer-readable medium of claim 959, wherein all threads are executable according to said embedded execution control information without invoking operating system thread scheduling.

968. The computer-readable medium of claim 959, wherein execution order of threads is deterministic and platform-independent.

969. The computer-readable medium of any of claims 958 to 968, wherein said bitstream comprises encoded image data.

970. The computer-readable medium of claim 969, wherein said image is represented as a sequence of executable instructions that when executed reconstruct the image.971 . The computer-readable medium of claim 970, wherein said executable instructions are operable on pixel space.

972. The computer-readable medium of claim 970, wherein said executable instructions are executed by a virtual processor.

973. The computer-readable medium of claim 972, wherein said virtual processor is configured for execution in a graphics processing unit.

974. The computer-readable medium of claim 973, wherein said virtual processor is embodied in shader code.

975. A computer-implemented method for adaptively augmenting a stream of symbolic data with support for repeatable patterns, comprising: analysing a stream to identify repeatable subsequences that are location-separable, meaning structurally invariant across non-contiguous positions while allowing variation in parameter content; generating pattern definitions by inserting a bundling directive into the stream, the bundling directive associating an identifier with a self-contained payload representing a template subsequence of two or more symbolic elements, the template including one or more placeholders for the variable parameter content; transmitting or storing the stream including the bundling directive and its payload; and whereby a receiving system processing the stream can detect bundling directives, extract their payloads, store template subsequences mapped to their identifiers, and upon subsequent encounters of an identifier, retrieve the corresponding template, insert variable parameter content from accompanying data into the placeholders, and substitute the instantiated subsequence for the identifier to produce an expanded stream segment.

976. The method of claim 975, wherein: the symbolic data comprises executable instructions; the analysing and generating steps are performed at an encoder that identifies the repeatable subsequences and generates the macro definitions by inserting the bundling directive into the stream; the receiving system comprises a decoder that processes the stream to detect bundling directives, extract their payloads, and store template subsequences mapped to their identifiers in an expansion registry, thereby enabling on-demand expansion without external configuration; upon subsequent encounters of the identifier in the stream, the decoder retrieves the corresponding template from the registry, inserts variable operand content from accompanying data in the stream into the placeholders of the template, and substitutes the instantiated subsequence for the identifier to produce an expanded stream segment; and the decoder forwards the expanded stream to a target execution engine for processing to effect the stream's intended computation.

977. The computer implemented method of claims 975 or 976, wherein said identifier is unique.

978. The method of claims 975, 976, or 977, further comprising entropy-encoding the stream including the bundling directive and its payload prior to transmitting or storing, and entropy-decoding the stream at the receiving system prior to processing for bundling directive detection, wherein the expansion registry operates post-entropy-decoding to handle the location-separable repeatable subsequences.

979. The method of any of claims 975 through 978, wherein the identifier element is not processable by a target execution system.

980. The method of any of claims 975 through 979, wherein the identifier, pattern definition or invocation are transient.

981. The method of claim 980, wherein an identifier or pattern definition at the receiving system is invalidated.

982. The method of claim 981 , wherein the identifier or pattern definition is invalidated by processing a deallocation directive in the stream.

983. The method of claim 982, wherein said deallocation directive comprises a Kill instruction or functionally equivalent marker that targets a specific identifier for inactivation.

984. The method of claims 975, 976, or 977, wherein identifying repeatable subsequences that are location-separable comprises scanning for structural patterns in the stream that recur in different positions without altering processing flow, allowing for different parameter content per recurrence, and wherein the bundling directive comprises a Tie_Knot instruction or a functionally equivalent marker that encapsulates the payload as an arbitrary number of bytes representing the template subsequence.

985. The method of any of claims 975 through 984, wherein inserting variable parameter content into the placeholders comprises placing accompanying data from the stream into the stored template, the datadiffering between a first and second invocation of the identifier to enable flexibility in representing varied instances of the repeatable pattern.

986. The method of claim 985, wherein the symbolic data comprises executable instructions, and wherein the variable parameter content comprises operand content, and wherein the expansion registry converts each invocation of the identifier to a sequence of executable instructions with the operand content inserted into corresponding positions in the template instructions.

987. The method of claim 982 or 983, wherein the deallocation directive targets one or more identifiers for inactivation, including specific or grouped identifiers.

988. The method of claim 976 or 986, wherein the identifier is a non-executable pseudocode element processed prior to forwarding to the execution engine.

989. The method of any of claims 975 through 988, wherein said instructions encode a digital image for reconstructing a plurality of patches of the image in memory at the receiving system, wherein placement of a patch is to an arbitrary address in said memory determined during the analysing step.

990. The method of claim 989, wherein the patch is located within a region of a memory storing a viewport.

991. The method of claim 989, wherein a patch is copied to a second location arbitrarily determined during the analysing step.

992. The method of claim 991 , wherein said second location is a viewport.

993. The method of claim 992, wherein the viewport represents part at least of one or more layers of a frame of the image.

994. The method of claim 993, wherein the viewport is copied to a memory (Render Image) for constructing a frame of the image.

995. The method of claim 989, wherein the patch is copied to an arbitrary location in a memory (Render Image) for constructing a frame of the image, said location determined during the analysing step.

996. The method of any of claims 989 through 995, wherein processing of said symbolic data reconstructs the image patches in the memory.

997. The method of any of claims 989 through 996, wherein said memory is arranged in pixel space.

998. The method of claim 997, wherein the symbolic data is operable on pixel space.

999. The method of any of claims 989 through 998, wherein said symbolic data is processed by a virtual processor.1000. The method of claim 999, wherein the virtual processor is configured in GPU elements or memory.1001. The method of claim 1000, wherein the memory is configured in GPU memory.1002. An apparatus for adaptively augmenting a stream of symbolic data with support for repeatable patterns, comprising: a pattern identifier configured to identify repeatable subsequences in the stream that are location-separable, meaning structurally invariant across non-contiguous positions while allowing variation in parameter content, and to generate pattern definitions by inserting a bundling directive into the stream, the bundling directive associating an identifier with a self-contained payload representing a template subsequence of two or more symbolic elements, the template including one or more placeholders for the variable parameter content; and a transmitter configured to transmit or store the stream including the bundling directive and its payload for processing at a receiving system.1003. The apparatus of claim 1002, wherein the apparatus comprises an encoder, wherein the symbolic data comprises executable instructions, the parameter content comprises operand content, and the transmitter is configured to transmit or store the stream for processing at a decoder to enable on-demand expansion via an expansion registry, insertion of variable operand content into placeholders upon encounters of the identifier, substitution of the instantiated subsequence, and forwarding of the expanded stream to a target execution engine for processing to effect the stream's intended computation.1004. The apparatus of claim 1002 or 1003, wherein said symbolic data encodes a digital image for reconstructing a plurality of reconstructed components of the image in memory at the receiving system, wherein placement of a component is to an arbitrary address in said memory determined by the apparatus.1005. The apparatus of claim 1004, configured such that processing of said symbolic data reconstructs the image component in the memory.1006. The apparatus of claim 1004 or 1005, wherein said memory is arranged in pixel space.1007. The apparatus of claim 1006, wherein the symbolic data is operable on pixel space.1008. The apparatus of any of claims 1002 through 1007, wherein said symbolic data is processed by a virtual processor.1009. An apparatus for processing a stream of symbolic data augmented with support for repeatable patterns, comprising: a stream processor configured to detect bundling directives in the stream, extract payloads from the bundling directives, and store template subsequences mapped to identifiers, eachtemplate subsequence comprising two or more symbolic elements with one or more placeholders for variable parameter content; and an expander configured to, upon subsequent encounters of an identifier in the stream, retrieve a corresponding template, insert variable parameter content from accompanying data in the stream into the placeholders of the template, and substitute an instantiated subsequence for the identifier to produce an expanded stream segment.1010. The apparatus of claim 1009, wherein the apparatus comprises a decoder, wherein the symbolic data comprises executable instructions, the parameter content comprises operand content, the stream processor stores the template subsequences in an expansion registry thereby enabling on-demand expansion without external configuration, and the apparatus further comprises an output interface configured to forward the expanded stream to a target execution engine for processing to effect the stream's intended computation.1011. The apparatus of claim 1009 or 1010, wherein said symbolic data encodes a digital image for reconstructing a plurality of reconstructed components of the image in memory, wherein placement of a component is to an arbitrary address in said memory specified in the stream.1012. The apparatus of claim 1011 , configured such that processing of said symbolic data reconstructs the image component in the memory.1013. The apparatus of claim 1011 or 1012, wherein said memory is arranged in pixel space.1014. The apparatus of claim 1013, wherein the symbolic data is operable on pixel space.1015. The apparatus of any of claims 1009 through 1014, wherein said symbolic data is processed by a virtual processor.1016. A non-transitory computer-readable medium storing a stream of symbolic data augmented with support for repeatable patterns, the stream comprising: one or more bundling directives, each bundling directive associating an identifier with a self-contained payload representing a template subsequence of two or more symbolic elements, the template including one or more placeholders for variable parameter content; and one or more instances of the identifier followed by accompanying data; whereby a receiving system processing the stream can detect the bundling directives, extract their payloads, store template subsequences mapped to their identifiers, and upon encountering an identifier, retrieve the corresponding template, insert variable parameter content from the accompanying data into the placeholders, and substitute an instantiated subsequence for the identifier to produce an expanded stream segment.1017. The non-transitory computer-readable medium of claim 1016, wherein the symbolic data comprises executable instructions, the parameter content comprises operand content, and the stream is configured for processing at a decoder that stores the template subsequences in an expansion registry and forwards an expanded stream to a target execution engine for processing to effect the stream's intended computation.1018. The non-transitory computer-readable medium of claim 1016 or 1017, wherein said symbolic data encodes a digital image for reconstructing a plurality of reconstructed components of the image in memory at the receiving system, wherein placement of a component is to an arbitrary address in said memory specified in the stream.1019. The non-transitory computer-readable medium of claim 1018, wherein processing of said symbolic data reconstructs the image component in the memory.1020. The non-transitory computer-readable medium of claim 1018 or 1019, wherein said memory is arranged in pixel space.1021. The non-transitory computer-readable medium of claim 1020, wherein the symbolic data is operable on pixel space.1022. The non-transitory computer-readable medium of any of claims 1016 through 1021 , wherein said symbolic data is processed by a virtual processor.1023. A method for bandwidth adaptation in an image rendering system, comprising: encoding a video into a bitstream structured into sections with breakpoints for progressive reconstruction at lesser resolution or color due to reduced bandwidth; and decoding the bitstream to terminate reconstruction early at a breakpoint and output intermediate quality when bandwidth is insufficient.1024. The method of claim 1023, wherein said encoding comprises representation of the video as a sequence of executable instructions for execution at a decoder system memory to reconstruct the image.1025. The method of claim 1024, wherein said instructions are executable in pixel space memory.1026. The method of claim 1025, wherein said pixel space comprises GPU memory.1027. The method of claims 1024, 1025, or 1026, wherein said execution is by a virtual processor.1028. The method of claim 1027, wherein said virtual processor is configured in GPU memory.1029. The method of any of claims 1023 through 1028, wherein the encoding further comprises embedding metadata in breakpoints indicating byte counts or processing times for sections, enabling adaptation to variable bandwidth by skipping higher-fidelity sections.1030. The method of any of claims 1023 through 1029, wherein the decoding further comprises a player monitoring available bandwidth and processing rate to decide whether to fetch and process the next section or signal early termination, outputting viable intermediate quality via conditional instructions.1031. The method of any of claims 1024 through 1030, further comprising using a ramp-on method as a recovery point to reestablish a better picture after bandwidth variation, updating assets in decoder system memory to enable ongoing reconstruction.1032. The method of any of claims 1023 through 1031 , wherein the encoding further comprises using simulations to account for bandwidth as an unknown parameter, structuring sections to cater to a plurality of distinct bandwidth capabilities while leveraging knowledge of worksheet state and future modifications for asset updates.1033. An encoder for bandwidth adaptation in an image rendering system, configured to encode a video into a bitstream structured into sections with breakpoints for progressive reconstruction at lesser resolution or color due to reduced bandwidth, the encoder embedding metadata in breakpoints indicating byte counts and processing times for sections to enable adaptation to variable bandwidth by skipping higher-fidelity sections.1034. The encoder of claim 1033, further configured to structure sections to cater to a plurality of distinct bandwidth capabilities while leveraging knowledge of decoder system memory state and future modifications for asset updates.1035. The encoder of claims 1033 or 1034, wherein said bitstream comprises executable instructions for execution in a decoder system memory for reconstruction of the encoded video.1036. The encoder of claim 1035, wherein said memory comprises pixel space memory.1037. The encoder of claims 1035 or 1036, wherein said execution is by a virtual processor operable on pixel space.1038. The encoder of claims 1035, 1036, or 1037, wherein said virtual processor is configured in GPU memory.1039. A decoder system for bandwidth adaptation in an image rendering system, configured to reconstruct a video encoded into a bitstream, said bitstream structured into sections with breakpoints for progressive reconstruction, the decoder system terminating a frame reconstruction early at a breakpoint and outputting intermediate quality when bandwidth is insufficient, the decoder system comprising a player monitoring available bandwidth and processing rate to decide whether to fetch and process the next section or signal early termination.1040. The decoder system of claim 1039, further configured to use a ramp-on method as a recovery point to reestablish a better picture after bandwidth variation, updating assets in worksheet memory to enable subsequent reconstruction of an image.1041. The decoder system of claims 1039 or 1040, wherein said bitstream comprises executable instructions for execution in the decoder system memory for reconstruction of the encoded image.1042. The decoder system of claim 1041 , wherein said memory comprises pixel space memory.1043. The decoder system of claims 1041 or 1042, wherein said execution is by a virtual processor operable on pixel space.1044. The decoder system of claims 1041 , 1042, or 1043, wherein said virtual processor is configured in GPU memory.1045. The decoder system of claim 1041 , wherein said reconstruction is in the pixel space.1046. The decoder system of claim 1041 , wherein the reconstruction comprises assembling image data in a first memory space with arbitrary spatial arrangement and transferring the assembled image to a second memory space arranged for display output.1047. The decoder system of claim 1046, wherein the first memory space comprises a Worksheet memory and the second memory space comprises a Render Image.1048. A non-transient computer-readable medium storing a bitstream encoded from a video for bandwidth adaptation in an image rendering system, the bitstream structured into sections with breakpoints for progressive reconstruction at lesser resolution or color due to reduced bandwidth, the bitstream embedding metadata in breakpoints indicating byte counts and processing times for sections to enable adaptation to variable bandwidth by skipping higher-fidelity sections.1049. The non-transient computer-readable medium of claim 1048, wherein the bitstream further comprises instructions for using a ramp-on method as a recovery point to reestablish a better picture after bandwidth variation, updating assets in worksheet memory to enable said improved image reconstruction.1050. The non-transient computer-readable medium of claims 1048 or 1049, wherein said bitstream comprises executable instructions for execution in the decoder system memory for reconstruction of the encoded image.1051. The non-transient computer-readable medium of claim 1050, wherein said memory comprises pixel space memory.1052. The non-transient computer-readable medium of claims 1050 or 1051 , wherein said execution is by a virtual processor operable on pixel space.1053. The non-transient computer-readable medium of claims 1050, 1051 , or 1052, wherein said virtual processor is configured in GPU memory.1054. The non-transient computer-readable medium of claim 1051 , wherein said reconstruction is in the pixel space.1055. The non-transient computer-readable medium of claim 1050, wherein the reconstruction comprises assembling image data in a first memory space with arbitrary spatial arrangement and transferring the assembled image to a second memory space arranged for display output.1056. The non-transient computer-readable medium of claim 1055, wherein the first memory space comprises a Worksheet memory and the second memory space comprises a Render Image.1057. A method for enabling alteration of playback position in a video decoding system, comprising: receiving by the decoding system during sequential playback, first instructions configured to progressively establish decoder accessible memory state for video reconstruction using previously established memory contents derived from image data previously sent to or derived at the decoder; detecting a request to alter playback from a current playback position; determining a target temporal location for the playback alteration; in response to the request, receiving by the decoding system second instructions for compensating disruption of the flow of first instructions by the playback alteration, said second instructions for establishing decoder accessible memory state that enables reconstruction of the target temporal location; and executing the second instruction sequence to establish decoder accessible memory contents consistent with the memory state required for reconstruction of the target temporal location.1058. The method of claim 1057, wherein the second instructions are distinct from first instructions that would have been used during sequential playback for reconstruction of said target temporal location.1059. The method of claim 1057 or 1058, wherein execution of said second instructions enables resumption of normal sequential processing of first instructions for temporal locations following the target temporal location.1060. The method of any of claims 1057 to 1059, wherein: the second instructions are transmitted to a first decoder in response to a playback alteration request at said first decoder; and a second decoder receiving the video without a playback alteration request receives first instructions to reconstruct said temporal location and does not require said second instructions; and the selective transmission of the second instructions to the first decoder and not the second decoder reduces transmission bandwidth relative to systems that transmit state establishment data to all decoders regardless of whether playback alteration events occur.1061. The method of any of claims 1057 to 1060, wherein the temporal positions for which second instructions are predefined at the encoder and stored for use in responding to future user-directed playback changes.1062. The method of claim 1061 , wherein said temporal positions are spaced at intervals of approximately one second.1063. The method of any of claims 1057 to 1062, wherein said instructions comprise control, image content and memory management for constructing, modifying or copying a patch of pixels.1064. The method of claim 1063, wherein said instructions direct construction of a patch of pixels at an address determined by the encoder.1065. The method of claim 1064, wherein said determination is based on optimising the encoding.1066. The method of any of claims 1063 to 1065, wherein determination of location for construction or copying, duration of storage, or sequencing of construction or copying of a component, is independent of a predetermined protocol at the decoding system.1067. The method of any of claims 1063 to 1066, wherein said constructing, modifying or copying a patch of pixels is asynchronous to frame output.1068. The method of any of claims 1057 to 1067, wherein the first and second instructions comprise instructions executable directly on pixel space.1069. The method of claim 1068, wherein said execution is by a virtual processor.1070. The method of claim 1069, wherein said virtual processor is configured for execution in a graphics processing unit.1071. The method of claim 1069 or 1070, wherein said virtual processor is embodied in shader code.1072. The method of any of claims 1057 to 1071 , wherein: the video decoding system does not rely on a predetermined Group of Pictures structure to establish decoder memory state; and the second instructions are sufficient to establish decoder memory state for the target temporal location independently of frame sequence dependencies.1073. An encoder configured to generate instruction sequences for video reconstruction at a decoder, comprising: an input interface configured to receive video data for encoding; and a processor configured to: generate first instructions for reconstructing video frames during sequential playback using data retained in decoder accessible memory; generate second instructions for compensating disruption of the flow of first instructions caused by playback alteration, said second instructions corresponding to defined temporal locations within the video; and make available the second instructions for selective transmission to a decoder when a playback alteration to a corresponding temporal location is requested; wherein the second instructions are configured to establish decoder accessible memory contents required for reconstruction of said temporal location.1074. The encoder of claim 1073, wherein a playback management system receives playback alteration requests from one or more decoders and instructs the encoder or an associated delivery system to transmit corresponding second instructions.1075. The encoder of claim 1073 or 1074, wherein the processor pre-generates and stores said second instructions corresponding to predefined temporal intervals for subsequent retrieval upon detection of a playback alteration request.1076. The encoder of any of claims 1073 to 1075, wherein second instructions are transmitted only to decoders that have requested playback alteration, thereby reducing network bandwidth relative to systems transmitting state establishment data to all decoders regardless of playback alteration events.1077. The encoder of any of claims 1073 to 1076, wherein the defined temporal locations correspond to intervals of approximately one second.1078. The encoder of any of claims 1073 to 1077, wherein said instructions comprise control, image content and memory management for constructing, modifying or copying a patch of pixels.1079. The encoder of claim 1078, wherein said instructions direct construction of a patch of pixels at an address determined by the encoder.1080. The encoder of claim 1079, wherein said determination is based on optimising the encoding.1081. The encoder of any of claims 1078 to 1080, wherein determination of location for construction or copying, duration of storage, or sequencing of construction or copying of a component, is independent of a predetermined protocol at the decoder.1082. The encoder of any of claims 1078 to 1081 , wherein said constructing, modifying or copying s patch of pixels is asynchronous to frame output.1083. The encoder of any of claims 1073 to 1082, wherein the first and second instructions comprise instructions executable directly on pixel space.1084. The encoder of claim 1083, wherein said instructions are executable by a virtual processor.1085. The encoder of claim 1084, wherein said virtual processor is configured for execution in a graphics processing unit.1086. The encoder of claim 1084 or 1085, wherein said virtual processor is embodied in shader code.1087. A video decoder configured to reconstruct frames of a video, comprising: a processor configured to execute first instructions for reconstructing frames using decoder accessible memory; and an input configured to receive second instructions for compensating disruption of the flow of first instructions caused by playback alteration, said second instructions corresponding to a target temporal location; wherein execution of the second instructions establishes decoder accessible memory contents required for reconstruction of the target temporal location.1088. The video decoder of claim 1087, wherein the second instructions are distinct from first instructions that would have been used during sequential playback for reconstruction of said target temporal location.1089. The video decoder of claim 1087 or 1088, wherein subsequent execution of the first instructions resumes reconstruction for temporal locations following the target temporal location.1090. The video decoder of any of claims 1087 to 1089, wherein: the input receives second instructions only in response to a playback alteration request; and decoders engaged in uninterrupted sequential playback do not receive second instructions; thereby reducing reception bandwidth relative to systems that receive state establishment data regardless of playback alteration events.1091 . The video decoder of any of claims 1087 to 1090, wherein said instructions comprise control, image content and memory management for constructing, modifying or copying a patch of pixels.1092. The video decoder of claim 1091 , wherein said instructions direct construction of a patch of pixels at an address determined by an encoder.1093. The video decoder of claim 1092, wherein said determination is based on optimising the encoding.1094. The video decoder of any of claims 1091 to 1093, wherein determination of location for construction or copying, duration of storage, or sequencing of construction or copying of a component, is independent of a predetermined protocol at the video decoder.1095. The video decoder of any of claims 1091 to 1094, wherein said constructing, modifying or copying a patch of pixels is asynchronous to frame output.1096. The video decoder of any of claims 1087 to 1095, wherein the first and second instructions comprise instructions executable directly on pixel space.1097. The video decoder of claim 1096, wherein said execution is by a virtual processor.1098. The video decoder of claim 1097, wherein said virtual processor is configured for execution in a graphics processing unit.1099. The video decoder of claim 1097 or 1098, wherein said virtual processor is embodied in shader code.1100. The video decoder of any of claims 1087 to 1099, wherein: the video decoder does not rely on a predetermined Group of Pictures structure to establish decoder memory state; and the second instructions are sufficient to establish decoder memory state for the target temporal location independently of frame sequence dependencies.1101. A non-transitory computer-readable medium containing a video bitstream, comprising: one or more first instruction sequences configured, when executed by a decoder, to reconstruct video frames during sequential playback; and one or more second instruction sequences for compensating disruption of the flow of first instruction sequences caused by playback alteration, said second instruction sequences corresponding to defined temporal locations within the video and retrievable in response to a playback alteration request; wherein execution of the second instruction sequences establishes decoder accessible memory contents required for reconstruction of the respective temporal locations.1102. The non-transitory computer-readable medium of claim 1101 , wherein the second instruction sequences are distinct from first instruction sequences that would have been used during sequential playback for reconstruction of said temporal locations.1103. The non-transitory computer-readable medium of claim 1101 or 1102, wherein the temporal locations for which second instruction sequences are stored correspond to intervals of approximately one second.1104. The non-transitory computer-readable medium of any of claims 1101 to 1103, wherein said instruction sequences comprise control, image content and memory management for constructing, modifying or copying a patch of pixels.1105. The non-transitory computer-readable medium of claim 1104, wherein said instruction sequences direct construction of a patch of pixels at an address determined during encoding.1106. The non-transitory computer-readable medium of claim 1105, wherein said determination is based on optimisingthe encoding.1107. The non-transitory computer-readable medium of any of claims 1104 to 1106, wherein determination of location for construction or copying, duration of storage, or sequencing of construction or copying of a component, is independent of a predetermined protocol at a decoder.1108. The non-transitory computer-readable medium of any of claims 1104 to 1107, wherein said constructing, modifying or copying a patch of pixels is asynchronous to frame output.1109. The non-transitory computer-readable medium of any of claims 1101 to 1108, wherein the first and second instruction sequences comprise instructions executable directly on pixel space.1110. The non-transitory computer-readable medium of claim 1109, wherein said instructions are executable by a virtual processor.1111. The non-transitory computer-readable medium of claim 1110, wherein said virtual processor is configured for execution in a graphics processing unit.1112. The non-transitory computer-readable medium of claim 1110 or 1111 , wherein said virtual processor is embodied in shader code.1113. The non-transitory computer-readable medium of any of claims 1101 to 1112, wherein: the video bitstream does not rely on a predetermined Group of Pictures structure; and the second instruction sequences are sufficient to establish decoder memory state for the respective temporal locations independently of frame sequence dependencies.1114. The non-transitory computer-readable medium of any of claims 1101 to 1113, wherein the first and second instruction sequences are stored for selective retrieval and transmission to one or more decoders to enable user-directed alteration of playback position without reliance on Group of Pictures structures or full-sequence reinitialization.CLAIMS 1115-1197.1115. A computer-implemented method for characterising a patch of pixels in a digital image, the patch comprising arbitrarily selected pixels that are contiguous or non-contiguous, the method comprising: extracting a normalised property vector from the patch.1116. The method of claim 1115, wherein the property vector includes at least one parameter selected from: (a) colour variance calculated as the normalised sum of pixel deviations from an average colour of the patch; (b) luminance variance or chrominance variance indicating detail in brightness or colour components; and (c) a list of up to N most common pixel colours with their respective percentages within the patch.1117. The method of claim 1115 or 1116, wherein extracting the property vector comprises recursively subdividing the patch into sub-patches and extracting property vectors for the sub-patches to identify regular patterns.1118. The method of claim 1117, wherein the property vector is hierarchical, including self, parent, sibling, or child property vectors for the patch to identify boundaries of homogeneous regions or geometric features.1119. The method of claim 1117 or 1118, wherein the recursive subdivision continues to a minimum patch size.1120. The method of claim 1119, wherein the minimum patch size is 4 * 4 pixels.1121. The method of any of claims 1115 to 1120, wherein adjacent or touching patches with matching property vectors are consolidated into larger regions or sets of patches.1122. The method of claim 1121 , wherein the consolidated patches are contiguous or non-contiguous.1123. The method of any of claims 1115 to 1122, wherein the patch comprises any geometric shape.1124. The method of claim 1123, wherein the geometric shape is selected from: a circle, rectangle, polygon, irregular boundary, or non-rectangular region.1125. The method of any of claims 1117 to 1124, wherein the sub-patches comprise blocks of pixels.1126. The method of claim 1125, wherein the blocks comprise rectangular arrays of contiguous pixels.1127. The method of any of claims 1115 to 1126, wherein the property vectors are normalised for at least one of pixel count or variance to enable comparison across patches of different sizes.1128. The method of claim 1116, wherein the colour variance indicates an amount of detail in the patch, wherein: a solid colour region yields a colour variance of substantially zero; a high-detail or noise region yields a high colour variance; and a region with alternating extreme colour values yields a maximum colour variance.1129. The method of any of claims 1115 to 1128, wherein analysis of the patches uses machine-learning or adaptive techniques to identify geometric features from patterns in subdivided patches.1130. The method of claim 1129, wherein the geometric features comprise circles, rectangles, polygons, or other shapes.1131. The method of any of claims 1115 to 1130, wherein the property vectors are input to a machinelearning algorithm to classify regions or types in the image.1132. The method of claim 1131 , wherein the classification identifies at least one of: geometric shapes, cartoon animation elements, or human faces.1133. The method of claim 1131 or 1132, wherein the classification automates deconstruction of the image into higher-level structures for encoding.1134. The method of any of claims 1131 to 1133, wherein the machine-learning algorithm is fine-tuned on sets of related images to associate fingerprint ranges with content types, and wherein the method instructs a compiler to build reusable fragments at a decoder for recurring content.1135. The method of claim 1134, wherein the sets of related images comprise frames of a video sequence.1136. The method of any of claims 1115 to 1135, wherein extracting the property vector is combined with computer-vision techniques for image segmentation or object identification.1137. The method of claim 1136, wherein the computer-vision techniques comprise at least one of: edge detection, thresholding, region growing, clustering, contour detection, template matching, shape-based segmentation, colour-based segmentation, or texture-based segmentation.1138. The method of claim 1136 or 1137, wherein selection of computer-vision techniques is based on at least one of: image characteristics, computational resources, accuracy requirements, or availability of additional data.1139. The method of claim 1138, wherein the additional data comprises camera parameters or depth information.1140. The method of any of claims 1115 to 1139, wherein the property vector informs selection of an encoding strategy for the patch.1141. The method of claim 1140, further comprising: encoding the patch based on the encoding strategy informed by the property vector.1142. The method of claim 1141 , wherein encoding comprises representing the patch as a sequence of executable instructions.1143. The method of claim 1142, wherein the executable instructions are operable on decoder memory configured as pixel space.1144. The method of claim 1143, wherein the executable instructions include at least one instruction operable to direct a pointer to a coordinate in the pixel space.1145. The method of claim 1144, wherein the pointer facilitates arbitrary spatial addressing for subsequent pixel operations within the pixel space.1146. The method of any of claims 1115 to 1145, further comprising: storing the property vector in a database.1147. The method of claim 1146, further comprising: storing an encoding strategy in association with the property vector in the database.1148. A method for encoding a digital image, comprising: (a) identifying a patch of pixels in the image for encoding; (b) extracting a normalised property vector from the patch, the patch comprising arbitrarily selected pixels that are contiguous or non-contiguous; (c) comparing the extracted property vector with stored property vectors in a database; (d) when the extracted property vector matches or approximates a stored property vector, retrieving an encoding strategy associated with the stored property vector; and (e) encoding the patch using the retrieved encoding strategy.1149. The method of claim 1148, wherein the comparison identifies a match when the extracted property vector is within a predetermined similarity threshold of the stored property vector.1150. The method of claim 1148 or 1149, wherein extracting the normalised property vector comprises recursively subdividing the patch into sub-patches and extracting property vectors for the sub-patches to identify regular patterns.1151. The method of any of claims 1148 to 1150, wherein the property vector includes at least one parameter selected from: (a) colour variance calculated as the normalised sum of pixel deviations from an average colour of the patch; (b) luminance variance or chrominance variance indicating detail in brightness or colour components; and (c) a list of up to N most common pixel colours with their respective percentages within the patch.1152. A system for image characterisation, comprising: a processor; and memory storing instructions that, when executed by the processor, cause the system to: extract a normalised property vector from a patch of pixels in a digital image, the patch comprising arbitrarily selected pixels that are contiguous or noncontiguous.1153. The system of claim 1152, wherein the instructions further cause the system to recursively subdivide the patch into sub-patches and extract property vectors for the sub-patches to identify regular patterns.1154. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to: extract a normalised property vector from a patch of pixels in a digital image, the patch comprising arbitrarily selected pixels that are contiguous or non-contiguous.1155. The non-transitory computer-readable medium of claim 1154, wherein the instructions further cause the processor to recursively subdivide the patch into sub-patches and extract property vectors for the subpatches to identify regular patterns.1156. A method for encoding data with embedded memory management controls, comprising: encoding content into a bitstream; and embedding memory management directives within said bitstream thatcontrol memory allocation and memory resource management at a receiving system, whereby memory management is directed from said bitstream.1157. The method of claim 1156, wherein said receiving system comprises a decoder.1158. The method of claim 1156 or claim 1157, wherein said memory management is performed without reliance on operating system memory management.1159. The method of claim 1156, 1157 or 1158, wherein said memory management directives comprise one or more selected from: memory allocation directives, memory reuse directives, buffer management directives, scratchpad allocation directives, and memory region specification directives.1160. The method of claim 1159, wherein said memory allocation directives specify allocation of memory regions during execution at said receiving system.1161. The method of claim 1159, wherein said memory reuse directives specify reuse of previously allocated memory regions.1162. The method of claim 1158, wherein memory allocation is achieved through said embedded memory management directives without operating system memory allocation primitives.1163. The method of claim 1158, wherein memory allocation is deterministic and platform independent.1164. The method of any of claims 1156 to 1163, wherein an encoder determines memory allocation requirements and encodes corresponding memory management directives in said bitstream.1165. The method of claim 1164, wherein said encoder possesses knowledge of memory content state at points during execution based on structuring of said bitstream.1166. The method of any of claims 1156 to 1165, wherein said content comprises encoded image data.1167. The method of claim 1166, wherein said image data is represented as executable instructions that when executed reconstruct an image.1168. The method of claim 1167, wherein said executable instructions are operable on pixel space.1169. The method of claim 1168, wherein said memory management directives control allocation of memory configured as said pixel space.1170. The method of claim 1169, wherein said memory management directives control allocation of one or more of: worksheet memory, buffer memory, scratchpad memory, or frame stack memory within said pixel space.1171. The method of claim 1168, wherein said executable instructions are executed by a virtual processor.1172. The method of claim 1171 , wherein said virtual processor is configured for execution in a graphics processing unit.1173. The method of claim 1172, wherein said virtual processor is embodied in shader code.1174. An encoder for encoding data with embedded memory management controls, comprising: a processor; and memory storing instructions that, when executed, cause the encoder to: encode content into a bitstream; and embed memory management directives within said bitstream that control memory allocation and memory resource management at a receiving system, whereby memory management is directed from said bitstream.1175. The encoder of claim 1174, wherein said receiving system comprises a decoder.1176. The encoder of claim 1174 or claim 1175, wherein said content comprises encoded image data represented as executable instructions operable on pixel space.1177. A non-transitory computer-readable medium storing a bitstream comprising: encoded content; and embedded memory management directives that control memory allocation and memory resource management at a receiving system, whereby memory management is directed from said bitstream.1178. The non-transitory computer-readable medium of claim 1177, wherein said memory management is performed without reliance on operating system memory management.1179. The non-transitory computer-readable medium of claim 1177 or claim 1178, wherein said encoded content comprises image data represented as executable instructions operable on pixel space.1180. The non-transitory computer-readable medium of claim 1179, wherein said memory management directives control allocation of memory configured as said pixel space.1181. A method for adaptive image compression, comprising: encoding an image using available computing resources at a first time to produce a first encoded image; and re-encoding the image using additional computing resources at a second time to produce a second encoded image having improved compression compared to the first encoded image.1182. The method of claim 1181 , wherein the first encoded image is generated using limited processing time.1183. The method of claim 1181 or 1182, wherein re-encoding is performed on the same computing device at a later time when additional computing resources are available.1184. The method of claim 1183, wherein the later time corresponds to a period when the computing device is not actively capturing images.1185. The method of claim 1183 or 1184, wherein the later time corresponds to detection of connection to an external power source.1186. The method of claim 1181 or 1182, wherein re-encoding is performed on a different computing device having greater processing capability.1187. The method of claim 1186, wherein the image is transferred from an image capture device to a remote computing device for re-encoding.1188. The method of claim 1187, wherein transfer occurs while the image capture device is mobile or connected to power.1189. The method of any of claims 1181 to 1188, wherein re-encoding comprises applying competitive encoding strategies and selecting an encoding that achieves improved compression.1190. The method of claim 1189, wherein competitive encoding strategies are recursively applied to progressively improve compression.1191. The method of any of claims 1181 to 1190, wherein the image comprises a sequence of executable instructions operable on pixel space.1192. The method of claim 1191 , wherein re-encoding comprises modifying the sequence of executable instructions to reduce bitstream size while maintaining image fidelity.1193. The method of any of claims 1181 to 1192, further comprising displaying information pertaining to the re-encoding in response to user engagement with a computing device.1194. The method of claim 1193, wherein the displayed information comprises at least one of: compression progress, file size comparison, percentage reduction, or encoding status.1195. The method of claim 1193 or 1194, wherein the displayed information includes animated visual representations of encoding progress.1196. The method of any of claims 1193 to 1195, wherein the displayed information comprises a comparison between the first encoded image and the second encoded image.1197. The method of any of claims 1193 to 1196, further comprising receiving user input to modify encoding parameters or accept a proposed encoding strategy.1198. The method of claim 1197, wherein the proposed encoding strategy comprises replacing a portion of the image with alternative content.1199. The method of claim 1198, wherein the alternative content is selected from a library of encoded imagery.1200. The method of claim 1199, wherein the library comprises at least one of: scenery, objects, living things, textures, or computer-generated imagery.1201. The method of claim 1199 or 1200, wherein the library is stored on the computing device or accessible from a remote device.1202. The method of claim 1199, 1200 or 1201 , wherein the imagery in the library is optimized for efficient encoding.1203. The method of any of claims 1197 to 1202, further comprising: analysing the image to identify locations suitable for special effects or content replacement; and presenting suggestions to a user for incorporating alternative imagery.1204. The method of claim 1203, wherein user selection of a suggestion causes alternative imagery to be incorporated into one or more frames, replacing or augmenting portions of said frames.1205. A system for adaptive image compression, comprising: a processor; and memory storing instructions that, when executed by the processor, cause the system to: encode an image using available computing resources at a first time to produce a first encoded image; and re-encode the image using additional computing resources at a second time to produce a second encoded image having improved compression compared to the first encoded image.1206. The system of claim 1205, wherein the instructions further cause the system to re-encode when the system is connected to an external power source.1207. The system of claim 1205 or 1206, wherein re-encoding comprises recursively applying competitive encoding strategies to progressively improve compression.1208. The system of claim 1205, 1206 or 1207, wherein the instructions further cause the system to display information pertaining to re-encoding in response to user engagement.1209. The system of claim 1208, wherein the instructions further cause the system to receive user input to accept or modify a proposed encoding strategy.1210. The system of claim 1209, wherein the proposed encoding strategy comprises replacing a portion of the image with alternative content from a library of encoded imagery.1211. The system of any of claims 1205 to 1210, wherein the image comprises a sequence of executable instructions operable on pixel space.1212. A method for probabilistic content playback, comprising: storing a plurality of content chunks, each chunk associated with a tick identifier; executing instructions within a current content chunk; encountering a probabilistic jump instruction specifying a target tick identifier and an associated probability; determining, based on said probability, whether to alter a playback sequence counter to said target tick identifier; and retrieving a next content chunk based on the playback sequence counter.1213. The method of claim 1212, wherein the probabilistic jump instruction comprises a set_markov instruction specifying the probability and a jmp_markov instruction specifying the target tick identifier.1214. The method of claim 1212 or 1213, wherein the playback sequence counter comprises a VM_tick value maintained by a virtual processor.1215. The method of any of claims 1212 to 1214, wherein each content chunk comprises executable instructions for reconstructing image content.1216. The method of any of claims 1212 to 1215, wherein content chunks are independent such that any chunk can be executed without dependency on a previous chunk's execution.1217. The method of any of claims 1212 to 1216, wherein probabilistic jump instructions enable different playback sequences for repeated executions of the same content.1218. The method of any of claims 1212 to 1217, wherein the content comprises advertisement segments that play in a randomized order.1219. The method of any of claims 1212 to 1218, wherein at least one content chunk has a low probability of playback, creating rare content experiences.1220. The method of claim 1219, wherein the rare content comprises at least one of: discount codes, prizes, bonus content, or exclusive segments.1221. The method of any of claims 1212 to 1220, wherein all content chunks are stored locally on a playback device and probabilistic jumps occur without server interaction.1222. The method of any of claims 1212 to 1221 , wherein multiple probabilistic jump instructions in a single content chunk enable transitions to multiple potential target chunks.1223. The method of any of claims 1212 to 1222, wherein a probability value of 1 .0 creates a deterministic jump instruction.1224. A system for probabilistic content playback, comprising: a processor configured as a virtual machine; memory storing a plurality of content chunks, each chunk associated with a tick identifier; wherein the processor is configured to: maintain a playback sequence counter; execute instructions within content chunks; process probabilistic jump instructions to conditionally alter the playback sequence counter based on specified probabilities; and retrieve content chunks based on the playback sequence counter.1225. The system of claim 1224, wherein the content chunks comprise executable instructions operable on pixel space.1226. A non-transitory computer-readable medium storing encoded content comprising: a plurality of content chunks, each chunk associated with a tick identifier and comprising executable instructions for reconstructing image content; and probabilistic jump instructions embedded within content chunks for controlling playback sequence based on specified probabilities.1227. A method for delivering personalized content, comprising: generating a first bitstream comprising generic content for a video presentation; generating a plurality of personalized bitstreams, each personalized bitstream corresponding to a different receiving system; transmitting the first bitstream and a corresponding personalized bitstream to each receiving system; and combining, at each receiving system, the first bitstream with the corresponding personalized bitstream to produce individualized output content.1228. The method of claim 1227, wherein the generic content comprises general content and placeholders for targeted content.1229. The method of claim 1228, wherein the general content is visible in output content produced by all receiving systems.1230. The method of claim 1228 or 1229, wherein the placeholders are configured to receive targeted content from the personalized bitstreams.1231. The method of any of claims 1228 to 1230, wherein the general content comprises at least one of: presenters, audience members, set elements, or background content.1232. The method of any of claims 1228 to 1231 , wherein the placeholders comprise pre-staged objects configured for digital modification.1233. The method of claim 1227, wherein the generic content is common to all receiving systems and the personalized bitstreams contain content tailored for different audiences.1234. The method of claim 1233, wherein different audiences comprise at least one of: geographical groups, demographic groups, age groups, language groups, or individual viewers.1235. The method of any of claims 1227 to 1234, wherein combining comprises blending the generic content with the personalized content at a decoder of the receiving system.1236. The method of any of claims 1227 to 1235, wherein the first bitstream comprises a sequence of executable instructions.1237. The method of claim 1236, wherein the executable instructions are operable on pixel space.1238. The method of claim 1236 or 1237, wherein the executable instructions comprise embedded control information for image reconstruction.1239. The method of any of claims 1236 to 1238, wherein the executable instructions comprise memory management directives.1240. The method of any of claims 1227 to 1239, wherein each personalized bitstream comprises a sequence of executable instructions for blending with the first bitstream.1241 . The method of any of claims 1227 to 1240, wherein combining produces different output content at a first receiving system than at a second receiving system, despite both receiving the same first bitstream.1242. The method of any of claims 1227 to 1241 , wherein the personalized bitstream is selected based on a viewer profile.1243. The method of claim 1242, wherein the viewer profile comprises at least one of: age, learning progress, stated preferences, interaction history, or demographic data.1244. The method of claim 1242 or 1243, wherein the viewer profile is dynamically updated based on user engagement patterns.1245. The method of any of claims 1242 to 1244, wherein selection of personalized content is performed by a personalization engine.1246. The method of claim 1245, wherein the personalization engine utilizes viewer profile data and content metadata to determine content for delivery.1247. The method of any of claims 1227 to 1246, wherein content metadata describes at least one of: content attributes, target demographics, or content objectives.1248. The method of any of claims 1245 to 1247, wherein the personalization engine operates at a server location.1249. The method of claim 1248, wherein the server location comprises a network edge server, regional distribution point, or internet service provider location.1250. The method of any of claims 1227 to 1249, wherein combining occurs at the receiving system.1251. The method of any of claims 1227 to 1249, wherein combining occurs at an intermediate network location between a content source and the receiving system.1252. The method of claim 1251 , wherein the intermediate network location comprises an internet service provider or regional distribution point.1253. The method of any of claims 1227 to 1252, further comprising: presenting a cue in the output content; receiving input from a viewer in response to the cue; and transmitting the input to a server.1254. The method of claim 1253, wherein the cue comprises at least one of: a visual cue displayed on screen or an audio cue.1255. The method of claim 1253 or 1254, wherein receiving input comprises detecting, via an interactive device, the viewer's response to the cue.1256. The method of claim 1255, wherein the interactive device comprises a camera configured to capture visual information from the display screen.1257. The method of claim 1255, wherein the interactive device comprises a microphone configured to detect audio input from the viewer.1258. The method of claim 1255, wherein the interactive device comprises a sensor configured to detect viewer gestures or actions.1259. The method of any of claims 1253 to 1258, further comprising generating additional personalized content based on the transmitted input.1260. The method of claim 1259, wherein the additional personalized content is displayed to the viewer.1261. The method of any of claims 1227 to 1260, further comprising storing personalized content associated with a first viewer for subsequent viewing.1262. The method of claim 1261 , wherein subsequent viewing comprises replay of the personalized content without additional input.1263. The method of claim 1261 , wherein subsequent viewing comprises presenting opportunities for additional input to modify the personalized content.1264. The method of any of claims 1261 to 1263, wherein a second viewer is provided access to view content associated with the first viewer.1265. The method of claim 1264, wherein the second viewer views the personalized content created for the first viewer.1266. The method of claim 1264 or 1265, wherein the second viewer is provided an opportunity to add additional personalized content for the first viewer.1267. The method of claim 1266, wherein additional personalized content from the second viewer comprises at least one of: a selection, a message, or a virtual gift.1268. The method of claim 1266 or 1267, wherein the additional personalized content from the second viewer is incorporated into content displayed during a subsequent viewing by the first viewer.1269. The method of claim 1268, wherein the first viewer and second viewer view content at different times.1270. The method of any of claims 1227 to 1269, wherein the personalized content is configured for a special event application.1271. The method of claim 1270, wherein the special event comprises at least one of: a celebration, birthday, anniversary, achievement recognition, or personalized greeting.1272. The method of claim 1270 or 1271 , wherein personalized content includes viewer-specific information comprising at least one of: names, dates, selected preferences, or custom imagery.1273. The method of any of claims 1270 to 1272, wherein placeholders in the generic content are transformed to display personalized celebratory elements.1274. The method of claim 1273, wherein celebratory elements comprise at least one of: personalized text, colors, decorative elements, or age-specific imagery.1275. The method of any of claims 1270 to 1274, wherein the generic content comprises a presenter and the personalized content comprises modifications to the presenter's speech.1276. The method of claim 1275, wherein modifications comprise dynamically adjusting lip movements of the presenter to synchronize with personalized audio addressing a viewer by name.1277. The method of any of claims 1227 to 1269, wherein the personalized content comprises educational content adapted to a learner's knowledge level.1278. The method of claim 1277, wherein educational content comprises at least one of: questions, problems, learning challenges, or instructional material.1279. The method of claim 1277 or 1278, wherein the personalized bitstream is selected based on learning progress data in a viewer profile.1280. The method of any of claims 1277 to 1279, wherein difficulty of educational content is dynamically adjusted based on learner performance.1281. The method of any of claims 1277 to 1280, wherein the generic content comprises an on-screen character configured to present educational material.1282. The method of claim 1281 , wherein performance of the on-screen character is adjusted to maintain learner engagement.1283. The method of claim 1282, wherein the on-screen character's performance is configured to not consistently exceed the learner's performance.1284. The method of any of claims 1277 to 1283, wherein educational contentfor a first learner differs from educational content for a second learner based on their respective learning progress.1285. The method of any of claims 1227 to 1284, wherein the generic content comprises audio content and the personalized bitstream comprises personalized audio elements.1286. The method of claim 1285, wherein combining audio content comprises at least one of: selective attenuation of generic audio, mixing personalized audio with generic audio, or replacing generic audio segments with personalized audio.1287. A system for delivering personalized content, comprising: a processor; and memory storing instructions that, when executed, cause the system to: receive a first bitstream comprising generic content; receive a personalized bitstream corresponding to a receiving system; combine the generic content with the personalized content to produce individualized output content.1288. The system of claim 1287, wherein the instructions further cause the system to reconstruct the generic content and the personalized content using executable instructions operable on pixel space.1289. The system of claim 1287 or 1288, wherein the system is located at a receiving system.1290. The system of claim 1287 or 1288, wherein the system is located at an intermediate network location between a content source and a receiving system.1291 . The system of any of claims 1287 to 1290, wherein the instructions further cause the system to select the personalized bitstream based on viewer profile data.1292. The system of any of claims 1287 to 1291 , further comprising an interface configured to receive interaction input from an interactive device.1293. A non-transitory computer-readable medium storing: a first bitstream comprising generic content for a video presentation; and a plurality of personalized bitstreams, each correspondingto a different receiving system; wherein the first bitstream and personalized bitstreams are configured for combination at receiving systems to produce individualized output content.1294. The non-transitory computer-readable medium of claim 1293, wherein the generic content comprises general content and placeholders for targeted content.1295. The non-transitory computer-readable medium of claim 1293 or 1294, wherein the first bitstream comprises executable instructions operable on pixel space.1296. The non-transitory computer-readable medium of any of claims 1293 to 1295, wherein personalized bitstreams are selected based on viewer profile data.1297. The non-transitory computer-readable medium of any of claims 1293 to 1296, wherein the generic content comprises a presenter and personalized content comprises modifications to the presenter's speech synchronized with personalized audio.1298. A method for browser-based content rendering, comprising: receiving a bitstream comprising image data encoded as executable instructions operable on pixel space; executing said instructions using a plurality of virtual processor instances implemented as WebGPU shader programs; wherein each virtual processor instance reconstructs image content by executing instructions that address pixel coordinates and modify pixel attributes; and rendering output to a shared texture stored in GPU memory.1299. The method of claim 1298, wherein the executable instructions are generated directly from an artificial intelligence content generation system without intermediate bitmap rendering.1300. The method of claim 1299, wherein Al-generated content is encoded as instruction sequences for transmission to the browser.1301. The method of any of claims 1298 to 1300, wherein processing is offloaded from a central processing unit to GPU-based virtual processors executing instruction-encoded content.1302. The method of any of claims 1298 to 1301 , wherein the virtual processor instances share a common instruction set implementation code base.1303. The method of any of claims 1298 to 1302, wherein the virtual processor instances coordinate execution using lock and semaphore mechanisms embedded in the instruction sequences.1304. The method of any of claims 1298 to 1303, wherein the shared texture serves as a worksheet for multiple virtual processor instances operating in parallel.1305. The method of any of claims 1298 to 1304, wherein the method is implemented via WebGPU JavaScript API.1306. The method of claim 1305, wherein the method operates as a web application accessible via standard web browsers.1307. The method of claim 1305, wherein the method is integrated into browser native technology.1308. The method of any of claims 1298 to 1307, wherein the bitstream is formatted using msgpack or binary JSON.1309. The method of any of claims 1298 to 1308, wherein content generation systems output instruction sequences directly without pre-rendering to bitmap format.1310. The method of claim 1309, wherein the content generation system comprises an Al image generation system.1311. The method of claim 1309, wherein the content generation system comprises a 3D rendering engine.1312. A system for instruction-based content rendering in a web browser, comprising: a graphics processing unit; a web browser configured to execute WebGPU API calls; a plurality of virtual processor instances implemented as shader programs on GPU cores; wherein the virtual processor instances are configured to: receive a bitstream comprising image data encoded as executable instructions; execute said instructions to reconstruct image content by addressing pixel space; and render output to a shared texture in GPU memory.1313. The system of claim 1312, wherein the bitstream originates from an Al content generation system that encodes output directly as executable instructions.1314. The system of claim 1312 or 1313, wherein the virtual processor instances utilize lock and semaphore mechanisms for coordinated parallel execution.1315. A non-transitory computer-readable medium storing a bitstream comprising: image data encoded as executable instructions operable on pixel space; wherein the executable instructions are configured for parallel execution by virtual processor instances implemented as WebGPU shader programs; and wherein the executable instructions reconstruct image content without requiring transmission of bitmap pixel data.1316. The non-transitory computer-readable medium of claim 1315, wherein the bitstream is generated directly from an Al content generation system.1317. The non-transitory computer-readable medium of claim 1315 or 1316, wherein the bitstream is formatted using msgpack or binary JSON.1318. The non-transitory computer-readable medium of any of claims 1315 to 1317, wherein the content generation system comprises at least one of: an Al image generation system or a 3D rendering engine.1318. A computer-implemented method of providing access to a plurality of image components stored on non-transitory computer-readable media for use in constructing an image comprising one or more of said plurality, said components selectable under manual or machine determination, wherein at least one of the image components is associated with at least one selected from the group consisting of: a method to convey content of the component to a human or machine, a cost for use of the component, ownership information for the component, and terms of use forthe component.1319. The method of claim 1318, wherein the method to convey content to a human comprises text embedded in or otherwise associated with the component.1320. The method of claim 1318, wherein the method to convey content to a machine comprises a coded description understandable by artificial intelligence, the coded description comprising text or another method.1321 . The method of claim 1318, wherein the method to convey content includes at least one of semantic tags, usage strategies, or characterizing fingerprints forthe component.1322. The method of claim 1321 , wherein the ownership information distinguishes between public domain and proprietary components.1323. The method of claim 1322, further comprising enforcing terms of use or cost during selection or assembly via the manual or machine determination.1324. The method of claim 1318, wherein the machine determination of selection is performed by artificial intelligence or convolutional neural networks sharing access to the plurality of image components.1325. The method of claim 1324, wherein the shared access enables dynamic strategy selection for encodingthe image components.1326. The method of claim 1325, further comprising assembling selected components into an active entangled stream for image reconstruction, wherein the associated information is preserved within the stream.1327. The method of claim 1318, further comprising examining elements comprised within the image components by artificial intelligence to access underlying image structure in compute space beyond pixel data, for use in constructing the image.1328. The method of claim 1323, wherein enforcing the terms of use or cost comprises secure processing with encryption and validation to prevent unauthorized access or tampering.1329. The method of anyone or more of claims 1318 through 1328, further comprising tracking usage of selected components during execution or display to facilitate billing for intellectual property utilization based on the cost or terms of use.1330. The method of claim 1329, wherein enforcing the terms of use includes digital rights management with encryption or validation of encrypted strands or snippets to prevent unauthorized access, replication, or tampering.1331 . The method of anyone or more of claims 1318 through 1330, further comprising facilitating a marketplace for distributing the image components via a trusted compilation entity that enforces usage rights or collects billing based on tracked utilization.1332. The method of any one or more of claims 1318 to 1331 , wherein the image components comprise reusable modules executable as instructions in compute space for operation on pixel space.1333. The method of claim 1332, further comprising assembling the reusable modules into an active entangled stream entangled with control information for memory management or parallel processing in pixel space.1334. The method of any one or more of claims 1318 to 1333, further comprising reconstructing the image component by directing a pointer to a coordinate location in memory, wherein the module includes or is associable with the pointer, enabling position-independent placement in the memory.1335. The method of claim 1334, wherein the coordinate location is a pixel coordinate in decoder memory configured in pixel space.1336. The method of any one or more of claims 1318 to 1335, further comprising updating the plurality of image components in the non-transitory computer-readable media with a new module generated by an encoder after analysing an image for encoding strategies.1337. The method of claim 1336, wherein the new module comprises a pre-encoded, positionindependent sequence of instructions or a characterizing fingerprint, dynamically integrated into the repository for subsequent selection.1338. The method of claim 1331 , further comprising distributing the image components while maintaining control over their usage through tiered security that protects against unauthorized replication or analysis during active use in building new images or experiences.1339. The method of any one of claims 1318 to 1338, further comprising encrypting the module for subsequent decryption and execution in a secure environment.1340. The method of claim 1339, further comprising decrypting the module in secure memory protected by system digital rights management methods.1341 . The method of claim 1339, further comprising decrypting the module in a secure memory independent of the host system.1342. The method of claim 1341 , further comprising transferring the decrypted module to a host display manager or worksheet for output to a display device.1343. The method of claim 1341 , further comprising directing the decrypted module from the secure memory to the display using a method resistant to unauthorized host component access.1344. An encoder for encoding image data into a bitstream comprising a sequence of computer instructions executable by a processor at a decoder to reconstruct the image, the sequence being operable to direct placement or modification of pixel attributes at encoder-determined coordinates in a memory space at the decoder.1345. The encoder of claim 1344, wherein the computer instructions are executable by a virtual processor configured for pixel-space operations.1346. The encoder of claim 1345, wherein the virtual processor is operable in graphics- processing-unit memory.1347. The encoder of claim 1345 or claim 1346, wherein the virtual processor is embodied at least in part in shader code.1348. The encoder of any one of claims 1344-1347, wherein the sequence of computer instructions comprises at least: a) instructions defining image-content operations; b) instructions defining control operations for directing an order, manner, or selection of reconstruction operations; andc) instructions defining memory-management operations for controlling allocation, reuse, retention, or lifetime of pixel regions in the decoder memory.1349. The encoder of any one of claims 1344-1348, wherein the specified coordinates permit arbitrary spatial addressing of pixels in the decoder memory space.1350. The encoder of claim 1349, wherein arbitrary spatial addressing is not constrained by sequential patterns, raster order, tile boundaries, or block-grid structures.1351 . The encoder of any one of claims 1344-1350, wherein the computer instructions comprise position-independent instructions that maintain correctness when reordered.1352. The encoder of claim 1351 , wherein the encoder rearranges position-independent instructions to optimise at least one of: compression, entropy-coding efficiency, decoder coherence, reconstruction performance, or bandwidth utilisation.1353. The encoder of any one of claims 1344-1352, comprising a processor operatively coupled to non-transitory computer-readable media storing instructions for encoding.1354. The encoder of any one of claims 1344-1353, wherein the decoder memory space comprises a worksheet region for image reconstruction, the size, structure, and layout of the worksheet region being encoder-determined.1355. The encoder of any one of claims 1344-1354, wherein the bitstream comprises an Active Entangled Stream comprising a single instruction stream entangling image-content symbols, control information, memory-management directives, and decoding methods.1356. The encoder of claim 1355, wherein the control information comprises at least one of: memory-management directives, parallel-processing controls, ordering constraints, or execution-flow controls embedded in the instruction stream.1357. The encoder of any one of claims 1344-1356, comprising an input interface configured to receive image data.1358. The encoder of claim 1357, wherein the input interface is configured to receive image data in multiple formats.1359. The encoder of claim 1358, wherein the formats comprise at least one of: pixel-space formats, vector-graphics formats, camera raw data, previously encoded bitstreams, computergenerated content, text, font files, three-dimensional model data, or multi-layer image data.1360. The encoder of claim 1357, wherein the input interface receives the image data as a plurality of layers.1361 . The encoder of claim 1357, wherein the input interface receives metadata associated with the image data.1362. The encoder of claim 1361 , wherein the metadata comprises at least one of: camera parameters, depth information, lighting parameters, or temporal information.1363. The encoder of any one of claims 1344-1362, further comprising an Analyzer component configured to analyse the image data.1364. The encoder of claim 1363, wherein the Analyzer component determines one or more encoding strategies for encoding the image data into the sequence of computer instructions.1365. The encoder of claim 1364, wherein encoding strategies are determined for patches of the image.1366. The encoder of claim 1365, wherein the patches are selected using the arbitrary spatial addressing of claim 1349.1367. The encoder of claim 1363, wherein the Analyzer component segments the image data.1368. The encoder of claim 1367, wherein segmentation comprises identifying patches, objects, layers, or regions.1369. The encoder of claim 1368, wherein identification uses at least one of: neural networks, edge detection, depth estimation, colour-based segmentation, texture-based segmentation, or recursive subdivision.1370. The encoder of claim 1363, wherein the Analyzer component extracts property vectors from blocks of pixels.1371 . The encoder of claim 1370, wherein the property vectors comprise parameters characterising the block.1372. The encoder of claim 1371 , wherein the parameters comprise one or more of: colour variance, luminance variance, chrominance variance, or pixel-colour distribution.1373. The encoder of claim 1370, wherein the Analyzer compares extracted property vectors against stored fingerprints.1374. The encoder of claim 1373, wherein the comparison identifies encoding strategies associated with matching fingerprints.1375. The encoder of claim 1363, wherein the Analyzer analyses inter-frame relationships.1376. The encoder of claim 1375, wherein inter-frame analysis comprises at least one of: motion detection, luminance-variation analysis, or identification of reference patches.1377. The encoder of claim 1364, wherein the Analyzer determines multiple distinct encoding strategies for a single patch.1378. The encoder of any one of claims 1344-1377, further comprising a Compiler component configured to compile encoding strategies into instruction sequences.1379. The encoder of claim 1378, wherein the Compiler compiles the strategies into the computer instructions executable by the processor at the decoder.1380. The encoder of claim 1378, wherein multiple encoding strategies are compiled for competitive comparison.1381 . The encoder of claim 1380, wherein competitive comparison comprises executing compiled strategies and evaluating reconstruction results.1382. The encoder of claim 1381 , wherein the evaluation is based on at least one of: compression efficiency, reconstruction fidelity, or computational complexity.1383. The encoder of any one of claims 1344-1382, further comprising an Engine component configured to execute instruction sequences.1384. The encoder of claims 1378 and 1383, wherein the Engine executes compiled strategies to reconstruct encoded portions for evaluation.1385. The encoder of claims 1354 and 1384, wherein the Engine comprises a local worksheet memory for reconstruction.1386. The encoder of any one of claims 1344-1385, further comprising an Encoding Decision Component configured to evaluate encoding results.1387. The encoder of claim 1386, wherein the Encoding Decision Component compares reconstructed portions against source image data.1388. The encoder of claim 1387, wherein the comparison uses fidelity metrics.1389. The encoder of claim 1386, wherein the Encoding Decision Component selects an encoding strategy based on the evaluation.1390. The encoder of claim 1389, wherein the selection considers predetermined criteria.1391 . The encoder of any one of claims 1344-1390, further comprising a Resource Library.1392. The encoder of claim 1391 , wherein the Resource Library is stored on non-transitory computer-readable media.1393. The encoder of claim 1391 , wherein the Resource Library comprises one or more of: fingerprint databases, snippet libraries, strand libraries, encoding-strategy libraries, quantisation tables, or transform-coefficient databases.1394. The encoder of claim 1391 , wherein the encoder queries the Resource Library during encoding.1395. The encoder of claims 1391 and 1394, wherein the encoder retrieves encoding information from the Resource Library and incorporates it into the instruction sequence.1396. The encoder of claim 1391 , wherein the encoder stores newly created encoding patterns into the Resource Library.1397. The encoder of any one of claims 1391-1396, wherein the snippet library stores positionindependent instruction sequences.1398. The encoder of claim 1397, wherein the position-independent instruction sequences are incorporated into the bitstream.1399. The encoder of claim 1397, wherein snippet instruction sequences reconstruct image components.1400. The encoder of claim 1397, wherein snippet instruction sequences include metadata.1401 . The encoder of any one of claims 1344-1400, further comprising an Artificial Intelligence component.1402. The encoder of claim 1401 , wherein the Artificial Intelligence component analyses the image data.1403. The encoder of claims 1401 and 1402, wherein the analysis identifies objects, segments, or image characteristics.1404. The encoder of claim 1401 , wherein the Artificial Intelligence component determines encoding strategies.1405. The encoder of claims 1364 and 1404, wherein the encoding strategies determined by the Artificial Intelligence component are compiled into the instruction sequence.1406. The encoder of claim 1401 , wherein the Artificial Intelligence component learns encoding patterns from processed images.1407. The encoder of claim 1401 , wherein the Artificial Intelligence component provides encoding recommendations.1408. The encoder of claims 1391 and 1401 , wherein the Artificial Intelligence component accesses the Resource Library.1409. The encoder of claim 1401 , wherein the Artificial Intelligence component generates images de novo.1410. The encoder of claims 1344 and 1409, wherein de novo generated images are encoded into the instruction sequence.1411. The encoder of any one of claims 1344-1410, further comprising an Adaptive Entropy Compressor.1412. The encoder of claim 1411 , wherein the Adaptive Entropy Compressor receives the instruction sequence.1413. The encoder of claim 1411 or claim 1412, wherein the Adaptive Entropy Compressor rearranges the instruction sequence.1414. The encoder of claim 1413, wherein the rearrangement optimises entropy coding.1415. The encoder of claim 1411 , wherein the Adaptive Entropy Compressor disassembles the instruction sequence.1416. The encoder of claim 1415, wherein the disassembly separates instruction components.1417. The encoder of claim 1411 , wherein the Adaptive Entropy Compressor applies entropy encoding using at least one of: Huffman coding, arithmetic coding, ANS, or Golomb coding.1418. The encoder of claim 1411 , wherein the Adaptive Entropy Compressor provides feedback to one or more encoding components.1419. The encoder of claims 1389 and 1418, wherein the feedback influences encodingstrategy selection.1420. The encoder of claim 1411 , wherein the Adaptive Entropy Compressor implements an entropy pipe.1421 . The encoder of claim 1420, wherein the entropy pipe separates instruction bytes into distinct streams.1422. The encoder of claim 1411 , wherein the Adaptive Entropy Compressor creates macroinstructions.1423. The encoder of any one of claims 1344-1422, further comprising a Design Criteria Component.1424. The encoder of claim 1423, wherein the Design Criteria Component provides encoding parameters.1425. The encoder of claim 1423 or 1424, wherein the encoding parameters affect strategy selection.1426. The encoder of claim 1423, wherein the Design Criteria Component receives feedback from the encoder.1427. The encoder of claim 1423, wherein the Design Criteria Component suggests encoding strategies.1428. The encoder of claim 1423, wherein the Design Criteria Component provides a user interface.1429. The encoder of claim 1423, wherein the Design Criteria Component is machine- controlled.1430. The encoder of any one of claims 1344-1429, configured to encode a primary stream and one or more secondary streams.1431 . The encoder of claim 1430, wherein the primary stream comprises a primary sequence of instructions and each secondary stream comprises a secondary sequence.1432. The encoder of claim 1430, wherein the secondary streams comprise insertion content.1433. The encoder of claims 1430 and 1432, wherein the primary stream includes control information for compositing secondary streams.1434. The encoder of claim 1430, wherein the primary and secondary streams are entwined through inter-stream communication protocols.1435. The encoder of claim 1432, wherein the encoder encodes placeholder information in the primary stream.1436. The encoder of claim 1435, wherein the placeholder information comprises geometric parameters, transformation parameters, or masking information.1437. The encoder of any one of claims 1344-1436, configured to segment the bitstream into a plurality of threads.1438. The encoder of claim 1437, wherein the threads are for parallel processing at the decoder.1439. The encoder of claim 1437, wherein control information is embedded within the threads.1440. The encoder of claims 1356 and 1439, wherein the embedded control information comprises parallel-processing controls.1441 . The encoder of claim 1439, wherein the control information comprises semaphores.1442. The encoder of claim 1441 , wherein the semaphores comprise one or more of: wait semaphores, completion semaphores, or power semaphores.1443. The encoder of claim 1437, wherein each thread has an identifier.1444. The encoder of claims 1437 and 1439, wherein the embedded control information specifies thread dependencies.1445. The encoder of claim 1437, wherein the encoder determines thread structure based on image-reconstruction requirements.1446. The encoder of any one of claims 1344-1445, configured to perform sequential downsampling of image patches.1447. The encoder of claim 1446, wherein sequential downsampling comprises multiple stages.1448. The encoder of claim 1447, wherein each stage produces a progressively smaller patch.1449. The encoder of claim 1447, wherein the encoder determines upsampling instructions and residual corrections for each stage.1450. The encoder of claims 1344 and 1449, wherein the upsampling instructions are encoded as computer instructions in the bitstream.1451 . The encoder of claim 1446, wherein only a final downsampled representation is encoded for transmission.1452. The encoder of any one of claims 1344-1451 , configured to perform inter-frame motion prediction using quad transformations.1453. The encoder of claim 1452, wherein quad corner positions are determined from reference blocks.1454. The encoder of claim 1453, wherein corner positions are averaged from adjacent reference blocks.1455. The encoder of claim 1452, wherein quad transformations use sub-pixel precision.1456. The encoder of claims 1349 and 1455, wherein arbitrary spatial addressing enables subpixel precision.1457. The encoder of any one of claims 1344-1456, configured to generate pixel-map information.1458. The encoder of claim 1457, wherein the pixel-map information tracks pixel status.1459. The encoder of claim 1458, wherein the pixel status comprises one or more of: completion status, intermediate status, or exclusion status.1460. The encoder of claim 1457, wherein pixel-map information is encoded in the bitstream.1461 . The encoder of claim 1457, wherein the encoder uses pixel-map information to optimise encoding.1462. The encoder of claim 1461 , wherein optimisation comprises skipping processing of flagged pixels.1463. The encoder of claim 1461 , wherein optimisation comprises reducing residual encoding.1464. The encoder of claim 1461 , wherein optimisation comprises improving transform efficiency.1465. The encoder of any one of claims 1344-1464, further comprising a Wrapper component.1466. The encoder of claim 1465, wherein the Wrapper component adds metadata to the bitstream.1467. The encoder of claim 1465, wherein the Wrapper component serialises the bitstream.1468. The encoder of claim 1465, wherein the Wrapper component segments the bitstream for streaming.1469. The encoder of any one of claims 1344-1468, further comprising an encryption component.1470. The encoder of claim 1469, wherein the encryption component encrypts at least a portion of the bitstream.1471 . The encoder of claim 1470, wherein encrypted and unencrypted portions are integrated in the bitstream.1472. The encoder of claim 1469, wherein the encoder embeds encryption indicators.1473. The encoder of any one of claims 1344-1472, configured to embed steganographic information in the encoded image data.1474. The encoder of claim 1473, wherein the steganographic information comprises metadata.1475. The encoder of claim 1474, wherein the metadata comprises one or more of: ownership information, copyright information, timestamp, or location data.1476. The encoder of claim 1473, wherein steganographic information is embedded using pixel modification.1477. The encoder of claim 1473, wherein the steganographic information includes an encrypted key.1478. The encoder of any one of claims 1344-1477, configured to encode image patches using bilinear colour-gradient encoding.1479. The encoder of claim 1478, wherein the bilinear colour-gradient encoding comprises upsampling patches and analysingfor colour-gradient regions.1480. The encoder of claim 1479, wherein the colour-gradient regions are tessellated into tiles.1481 . The encoder of claim 1480, wherein the tile size varies based on gradient complexity.1482. The encoder of claim 1478, wherein the encoder encodes corner colours for the tiles.1483. The encoder of claim 1482, wherein the corner colours define gradient fills.1484. The encoder of any one of claims 1344-1483, wherein the worksheet size exceeds a display resolution at the decoder.1485. A method of constructing image content at a decoding system, comprising: receiving, at the decoding system, a bitstream comprising a sequence of computer instructions executable by a processor; executing the sequence of computer instructions to construct patches of pixels at encoder- determined coordinates in a memory space of the decoding system; maintaining, in the decoding system, pixel-map information comprising per-pixel or per- region state indicators identifying whether a pixel or region has been constructed, updated, modified, or remains valid; and controlling construction of patches based on the pixel-map information so as to avoid reconstructing pixels or regions that remain valid.1486. The method of claim 1485, wherein the pixel-map information comprises one or more of: completion status, intermediate status, invalid status, or exclusion status.1487. The method of claim 1485 or claim 1486, wherein the pixel-map information is updated automatically as a consequence of executing the sequence of computer instructions without requiring explicit signalling in the bitstream.1488. The method of claim 1485, wherein the pixel-map information is initialised or reset by the decoder upon at least one of: start of playback, change in viewport configuration, change in rendered resolution, or change in displayed content.1489. The method of anyone of claims 1485-1488, wherein the pixel-map information is encoded in the bitstream as state-correction information that reconciles drift between a reconstruction state at the decoder and a reference reconstruction state maintained by the encoder.1490. The method of claim 1489, wherein the state-correction information comprises pixelattribute deltas, replacement attributes, overwriting of subregions, or reconciliation of misaligned construction state.1491 . The method of anyone of claims 1485-1490, wherein the pixel-map information is used to suppress decoding of instructions that would modify pixels flagged as valid.1492. The method of anyone of claims 1485-1491 , wherein the pixel-map information is used to skip entropy-decoding of instructions corresponding to pixels flagged as completed.1493. The method of anyone of claims 1485-1492, wherein the pixel-map information is used to determine ordering, deferral, or omission of patch-construction operations.1494. The method of anyone of claims 1485-1493, wherein maintaining the pixel-map information reduces reconstruction workload at the decoding system.1495. The method of anyone of claims 1485-1494, wherein the pixel-map is maintained as a separate structure from the worksheet memory.1496. The method of anyone of claims 1485-1494, wherein the pixel-map is maintained as an overlay on the worksheet memory.1497. The method of anyone of claims 1485-1496, wherein the pixel-map information comprises block-granularity state information.1498. The method of anyone of claims 1485-1497, wherein the pixel-map information comprises pixel-granularity state information.1499. The method of any one of claims 1485-1498, wherein updating the pixel-map information comprises updating the state of pixels affected by patch construction, including pixels modified by copying, blending, overwriting, or special-effects operations.1500. The method of any one of claims 1485-1499, wherein the pixel-map is used to determine whether refinement patches are applied to a region.1501 . The method of claim 1500, wherein refinement patches comprise luminance or chrominance updates, residual corrections, or high-frequency detail restoration.1502. The method of any one of claims 1485-1501 , wherein the pixel-map is reset or partially reset upon detection of a state mismatch between the decoder and encoder.1503. The method of anyone of claims 1485-1502, wherein the pixel-map is used to resume decoding following a non-sequential playback jump.1504. The method of claim 1503, wherein the pixel-map is used to determine which patches must be reconstructed following the playback jump.1505. The method of anyone of claims 1485-1504, wherein the pixel-map is used to determine an execution schedule for multiple threads of the bitstream.1506. The method of claim 1505, wherein execution scheduling ensures that threads do not modify pixels flagged as valid.1507. A method for delivering targeted advertising within a multimedia stream, comprising: receiving a first bitstream encoding information for reconstructing a primary scene; receiving a second bitstream encoding information for reconstructing advertising content; transmitting the first and second bitstreams to a blending location; and at the blending location, processing the first and second bitstreams to generate, from each, a patch of a frame for display.1508. The method of claim 1507, wherein the blending location is selected from an encoder, a server, an internet service provider, a host computing device, or a destination decoder.1509. The method of claim 1507 or claim 1508, wherein processing the first bitstream generates a first patch comprising scene content and processing the second bitstream generates a second patch comprising advertising content.1510. The method of anyone of claims 1507-1509, wherein the first and second patches are composited at the blending location to integrate the advertising content directly into the primary scene.1511. The method of anyone of claims 1507-1510, wherein each of the first and second bitstreams comprises an Active Entangled Stream entangling executable instructions, imagecontent symbols, control directives, and memory-management information.1512. The method of claim 1511 , wherein processing comprises executing the AES using a virtual processor operating on a worksheet region of memory.1513. The method of claim 1512, wherein the virtual processor is operable in graphics- processing-unit memory.1514. The method of anyone of claims 1507-1513, further comprising analysing the primary scene to identify placeholder regions for advertising insertion.1515. The method of claim 1514, wherein the second bitstream is selected through a dynamic auction between potential advertisers based on relevance scores.1516. The method of claim 1515, wherein the auction uses variable pricing per relevance-score category to select the second bitstream.1517. The method of anyone of claims 1507-1516, wherein the advertising patch is wrapped onto a two-dimensional or three-dimensional object of the primary scene patch.1518. The method of claim 1517, wherein the blending location applies occlusion-aware compositing so that the advertising patch appears behind or in front of selected objects of the primary scene.1519. The method of claim 1517 or claim 1518, wherein seamless wrapping uses depth estimation, geometric transformation, or sub-pixel interpolation.1520. The method of any one of claims 1507-1519, further comprising inserting a pre-fetch instruction into the first bitstream to cause early buffering of the advertising patch.1521 . The method of claim 1520, wherein the pre-fetch instruction adjusts the advertising patch length for users who begin playback mid-placeholder region.1522. The method of anyone of claims 1507-1521 , wherein the primary-scene bitstream includes a control flag that activates or deactivates the advertising patch on a per-frame basis.1523. The method of claim 1522, wherein the control flag is embedded as metadata inaccessible to user-level modification.1524. The method of anyone of claims 1507-1523, wherein the patches are rendered as independent layers at the blending location.1525. The method of claim 1524, wherein compositing occurs using a graphics-processing unit without pre-decoding the primary-scene patch.1526. The method of anyone of claims 1507-1525, wherein the advertising content is targeted to individual users based on profile data.1527. The method of claim 1526, wherein multiple users receive identical primary-scene patches but different advertising patches.1528. An encoder for generating bitstreams for advertising delivery in multimedia content, comprising: a scene analysis component configured to identify placeholder regions within primary scene content suitable for advertising insertion; a transformation calculation component configured to determine positioning parameters for advertising content within identified placeholder regions across multiple frames; a primary stream encoding component configured to encode the primary scene content as a first bitstream comprising placeholder specifications and transformation parameters; and a secondary stream encoding component configured to encode selected advertising content as a second bitstream compatible with said transformation parameters for compositing with said primary scene content.1529. The encoder of claim 1528, wherein the scene analysis component comprises: an object detection module configured to identify scene objects and boundaries; a tracking module configured to track object positions and camera movements across frames; a depth estimation module configured to determine spatial relationships within the scene; and a placement optimization module configured to evaluate placeholder regions based on visibility, duration, and tracking stability.1530. The encoder of claim 1528 or claim 1529, wherein the transformation calculation component determines: affine transformation parameters including translation, rotation, scale, and skew; perspective transformation parameters accounting for camera three-dimensional movement; occlusion data identifying which scene objects appear in front of advertising positions; and luminance adjustment data for matching scene lighting conditions.1531 . The encoder of any one of claims 1528-1530, wherein the primary stream encoding component generates an Active Entangled Stream comprising: executable instructions for reconstructing scene content in processor addressable pixel space; control directives for managing advertising insertion timing; memory management information for worksheet allocation; and synchronization parameters for coordinating with secondary stream processing.1532. The encoder of claim 1531 , wherein the Active Entangled Stream includes: pre-fetch instructions triggering early buffering of advertising content; control flags activating or deactivating advertising on per-frame basis;metadata specifying blending location and compositing methodology; and timing markers for synchronizing advertising display with scene events.1533. The encoder of any one of claims 1528-1532, wherein the secondary stream encoding component: receives selected advertising content from an advertising server; applies transformation parameters to conform advertising to placeholder specifications; generates executable instructions for reconstructing transformed advertising; and embeds synchronization information for coordination with primary stream.1534. The encoder of claim 1533, wherein the secondary stream encoding component generates multiple alternative encodings of same advertising content optimized for different device capabilities or bandwidth conditions.1535. The encoder of any one of claims 1528-1534, further comprising: an auction interface component configured to communicate with advertising server to facilitate dynamic placement auctions; a profile matching component configured to identify target user characteristics for advertising selection; and a delivery optimization component configured to adjust encoding parameters based on network conditions and device capabilities.1536. The encoder of claim 1535, wherein the auction interface component provides: placeholder specifications including geometric characteristics, duration, and positioning; timing information for advertising opportunity windows; audience reach estimates based on expected viewership; and real-time availability updates as advertising opportunities are filled or expire.1537. A decoder for reconstructing and compositing advertising content with primary scene content, comprising: a first decoding engine configured to receive and process a first bitstream encoding primary scene content; a second decoding engine configured to receive and process a second bitstream encoding advertising content; an inter-engine communication interface providing data transfer and synchronization between the first and second decoding engines; and a compositing component configured to integrate reconstructed advertising content with reconstructed scene content according to transformation parameters encoded in at least one of the bitstreams.1538. The decoder of claim 1537, wherein each decoding engine comprises: a virtual processor configured to execute instructions from respective bitstream; a worksheet comprising processor addressable pixel space for reconstructing image content; and a render image component for final output preparation.1539. The decoder of claim 1538, wherein the virtual processor is implemented in graphics- processing-unit shader code and operates on texture memory in graphics-processing-unit RAM.1540. The decoder of any one of claims 1537-1539, wherein the first decoding engine comprises: a primary worksheet for reconstructing scene content; control logic configured to manage timing and placement of advertising content; and compositing logic configured to receive transformed advertising from second engine and integrate with scene content.1541 . The decoder of claim 1540, wherein the compositing logic: applies alpha blending accordingto transparency masks encoded in bitstreams; adjusts luminance for lighting consistency based on encoded adjustment data;implements occlusion ordering to position advertising behind or in front of scene objects; and maintains sub-pixel positioning accuracy for seamless integration.1542. The decoder of anyone of claims 1537-1541 , wherein the second decoding engine comprises: a secondary worksheet for reconstructing advertising content; transformation logic configured to apply positioning, scaling, rotation, and perspective adjustments; and transfer logic configured to transmit transformed advertising to first engine via inter-engine communication interface.1543. The decoder of claim 1542, wherein the transformation logic: receives transformation parameters from first bitstream or via inter-engine communication; applies affine and perspective transformations to advertising content; generates alpha transparency masks for seamless blending; and adjusts output timing to synchronize with primary scene reconstruction.1544. The decoder of any one of claims 1537-1543, wherein the inter-engine communication interface comprises: bidirectional data port for transferring image patches between engines; synchronization signal channels for timing coordination; control message passing capability for dynamic adjustment of compositing parameters; and shared memory regions for efficient data transfer.1545. The decoder of claim 1544, wherein the inter-engine communication operates at decoder level independent of operating system control, preventing user-level interception or modification of advertising delivery.1546. The decoder of any one of claims 1537-1545, further comprising: a request generation component configured to initiate requests for advertising content based on control information in primary bitstream; a profile transmission component configured to securely transmit de...

Images