'TRUE VISION IS SEEING THE INVISIBLE' (c) USER'S GUIDE FOR THE RAPID EXPLOITATION (REX) (c) VISUAL DISCOVERY ENGINE (VDE) (c) Rev. 08/2024 INTRODUCTION REX is an experimental 'big-data' image processing system that radically re-thinks digital image processing. REX supports a full suite of standard as well as experimental analysis functions in an immersive 'video-game' environment. REX was created by a scientist with formal artistic training for rigorous scientific work, but can also be used as a creative artistic medium in its own right. REX is a deep, immersive system designed for professional use but an Intelligence Wrapper shields users from its internal complexity. Anyone comfortable using a video game will feel at home using REX as an engine for Scientific and Artistic Discovery. There is no tedious learning curve. REX is designed for rapid trial- and-error use and 'accidental' discovery of its capabilities. The seamless REX environment supports GigaPixel (32,000 X 32,000 and larger) RGBA Color and Grayscale imagery; including High-Dynamic-Range (HDR) imagery. REX supports the following image formats: JPEG, (generic iPhoto) JPEG-2000, (Mars Reconnaisance Orbiter, etc.) GIF, (REX output format; load to ALPHA, very compact) TIFF, (generic large image) PNG, (REX output format; RGBA lossless compression) FITS, (professional Astronomy; Hubble, JWST, others) WEBP, (web imagery) AVIF, (web imagery; RGBA, HDR, next-gen) legacy PBM/PGM/TGA uncompressed formats. THE REX 'VISUAL DISCOVERY ENGINE' Much Information in imagery is invisible due to limitations of the human visual system and conceptual 'stovepipes' masking subliminal information. The REX Visual Discovery Engine facilitates visualization of these occult structures via a fast, rich, and minimally structured environment. REX avoids stovepipe solutions because stovepipe solutions impose boundaries that blind us to information outside the stovepipe. By Design, REX has no operational stovepipes or conceptual boundaries. REX IS NOT AN AI REX is NOT an Artificial Intelligence [AI] system. AI applied to imaging generates output from countless 'training' images pirated from human creators without attribution. This is exploitative, infringes creator Copyrights, and is legally problematic. In contrast, REX uses unique algorithms to reveal deep statistical structures in imagery [occult information] that would otherwise remain invisible. REX is a tool of Human Intelligence Augmentation. REX will reveal structures in your data that you never imagined were there. -- Guaranteed! -- NOTE TO SCIENTISTS Advanced algorithms used by REX often reveal complex, coherent structures but care must be exercised in extrapolation to Physical systems. Everything revealed by REX exists for a mathematical reason, but the reason may lie in high-order algorithmic resonances with periodicities in the data. Revealed invisible structures may, or may not, be real. NOTE TO ARTISTS Mathematically, any conceivable image is a tightly integrated, statistical ensemble. Something as simple as a line drawing of a rectangle becomes a visual universe of form when viewed as the Entropy of its Fast-Fourier Transform. Which visualizatiion of an image is more 'real' is subjective. There exists no single, 'correct' visual depiction of Reality. HIGH DYNAMIC RANGE IMAGERY (HDR) REX can load, scale, and exploit HDR imagery in scientific formats with very large Dynamic Range that exceeds the range of the human visual system. Both Color and B&W [grayscale] exploitation are supported, with a variety of interactive HDR scaling options. HDR data is always loaded at full dynamic range. ACCURACY REX maintains EXACT positional accuracy for support of datasets mapped to terrestrial or astronomical projections. This positional accuracy is maintained throughout all image transformations. Intensity values on the Display can be reliably mapped to their original physical values, even for HDR datasets. You can simultaneously view transformed imagery, and the original data, while roaming an image; even for zoomed views. REX HARDWARE REQUIREMENTS To exploit Gigapixel imagery, your computer must support basic 24 bit 'TrueColor' graphics, and should host at least 16 GB of RAM. Outside retail point-of-sale terminals it is difficult to find a modern personal computer configured with less. OPERATING SYSTEMS REX will run on Microsoft Windows-11 Subsystem for Linux (WSL) Version 2, or any x86 release of Native LINUX. See 'imagtek/doc/REX Installation Guide'. IT'S FAST REX is written entirely in C/C++ utilizing efficient algorithms optimized for speed. It accesses graphics devices and storage hardware at the lowest, most direct level supported by the operating system. REX represents Zen-like minimalism and Art-of-Archery directness applied to computer software design. Much of its source-code is deliberate cybernetic poetry. SYSTEM RESOURCES, HUGE IMAGERY AND REX REX defines no 'hard' limit on the size of imagery that can be exploited, but REX always querys the LINUX O/S for available resources before attempting large operations. REX will politely decline to load an image or perform an operation that may result in a drawdown of virtual memory on your system to an unstable level. REX enables you to subsample, or to crop, selected areas of huge images at load time to view on computers with limited memory. But if your System has sufficient memory, there is no problem loading and exploiting full resolution Giga-pixel 24-Bit RGBA imagery; including scientific HDR imagery. The only limits to REX are the physical limits of your machine. To view all defined commandline parameters to REX, on a commandline type: rex -v This will display: Rapid EXploitation Image Processing System by Imagtek Use: rex < display loader GUI > rex [/path/]image < load & display image > rex -c 'command string' < loader command string > rex -cd [ /path ] < set working directory > rex -dmin or -dmax < minimum | full Display > rex < file.cmd < loader batch commands > yourGUI | rex < alternate loader GUI > rex -L [ license ] < licensing subsystem > To display the REX Image Loader GUI, simply type: rex & Note: Commandline arguments override settings in the REX Defaults file (see below). If you specify an image on the commandline, then the path to the image becomes the default loader path. 'rex -cd' without a 'path' argument will override the Defaults setting and make the current working directory the default file path. ABOUT 'iBUFFs', 'sBUFFs', 'GUNS', 'BANDS' and 'EXPLOITATION' REX uses several words in specialized ways. For example, Image Buffer is 'iBUFF'. A Scaling Accumulator [sBUFF] is where HDR data is maintained at full resolution. We refer to Color Planes as 'guns', such as the 'Red gun', 'Green gun' or 'Blue gun'. This terminology is based upon the electronic design of 20th century color video Displays that used a separate electron emitter or 'electron gun' for each color. This antique terminology remains in common use. Each Gun is associated with a separate 'Band', or region of the electromagnetic spectrum that generated an image. For Color images, each band is different. For Grayscale images, the same Band is repeated for all three [R,G,B] guns. 'Exploitation refers to sophisticated, technical image analysis in a professional setting. REX supports image Exploitation as a technical discipline, or as a free-association Artistic medium with no conceptual boundaries. Both are valid paradigms of use. REX CORE CONCEPTS The REX system is based upon the following basic constructs: Color Planes: Without exception, all imagery defines 4 image data planes; RED, GREEN, BLUE, ALPHA. All image data is losslessly converted to RGBA automatically when loaded. The ALPHA plane is treated as an Overlay annotation layer that can be toggled on/off whose colors can be redefined or rendered transparent; a Transparency Operator as used in Web Design; or simply an ancillary data plane swapped in and out of the RGB color space. Color planes can be selectively viewed independently as grayscale images during exploitation. Loader GUI: The GUI is small and occupies only a small portion of your Display. You can toggle back and forth from the Loader GUI to a full-screen Exploitation, enabling you to have multiple full-screen REX sessions open simultaneously. If REX detects a command on the commandline, or in a stream from the O/S, then commands are read directly from the input stream. This enables complex image compositions to be composed as command files, or for specialized apps upstream to generate a loader command stream. If an error occurs, or if no command stream is detected, the REX Loader GUI accepts user commands. If the GUI appears due to a load error, the error will be displayed. If loading a Giga-pixel image, the GUI serves as a load-progress display. Pop-Up GUI: During image exploitation, REX displays no GUI until the user presses the Right-Mouse button. The REX GUI is a deep Pop-Up tree which selects parameters as you trace through the tree. When you release Right-Mouse, the GUI disappears. If you traced the GUI tree to the end of a branch, an app is activated. Some apps have their own local GUI that will then appear. The REX GUI has a 'fast' and a 'sticky' mode. Developers who extend REX integrate their work via the REX Pop-Up GUI API, but may support their own internal GUI. Ancillary Display: A non-intrusive side display provides a roam/zoom window, RGB histograms, real-time RGB data values, and cursor coordinates (Display / Buffer) that is updated automatically. This display is easily toggled off and on. Image Buffers: REX supports 16 image Buffers [iBUFFs]. An iBUFF may contain an unlimited number of images composed within it. Each image may be selected as the 'Image of Interest' that is centered on the display and defines current navigation and descaling parameters. Each image may consist of up to 4 Bands. An iBUFF 'mapped' to an HDR Scaling Accumulator may host only one image. See: Scaling Accumulator [ sBUFF ] below. Mapping: REX maintains an EXACT 1/1 mapping between an Image Buffer and the Display at all times for instant recovery of image state, and pinpoint locations supported by Geo/Astro projections. Color Lookup Tables (LUTs): REX supports functions which operate upon RED, GREEN, BLUE LUTs instead of image data. This enables image transforms that can be instantly toggled ON and OFF, yet do not change image data in any way. The ALPHA plane supports its own RGB Pseudocolor LUT where individual colors may be changed, or rendered individually Transparent with ALPHA treated as Overlay. Image Statistics: The REX Intelligence Wrapper maintains a detailed statistical snapshot of the internal exploitation environment at all times. No user input is required. If the Ancillary Display is enabled, a color Histogram of statistical state is Displayed. Statistics are always collated from the Foreground Area of Interest, which the User may define to be a limited area of the Display. The entire iBUFF may also be collated. The current statistical state controls all image transforms and HDR scaling. High Dynamic Range (HDR): REX supports advanced scientific data formats that define imagery with a spectral dynamic range beyond the human visual range. Access is via a powerful interactive scaling subsystem. Detailed HDR image statistics used for scaling are acqired when HDR imagery is loaded. HDR data is always loaded at full spectral range into a sBUFF accumulator. Scaling and re-scaling a HDR image for viewing has no effect on the sBUFF contents. Note: Once you set a scaling mode and range, that mode and range remain active until you change them. If loading an HDR image results in a strange display, it is probably because the scaling parameters in effect are ill suited to new HDR image statistics. You do not need to re-load a HDR image to change the scaling. It is simple to Reset or Re-define HDR scaling in the Exploitation system and refresh the display. HDR Scaling Accumulators: There are 2 Scaling Accumulators; one as a destination for loaded HDR imagery, and another for REX HDR exploitation operators. Either 'sBUFF' can be explored by re-scaling its contents. sBUFF enables apps to write precision HDR output in a form that can also be used as a HDR input stream; as in FFT and Inverse FFT calculation. REX maintains an exact mapping between the 'sBUFF' Scaling Accumulator, and the scaled 'iBUFF' visualization that maps to it. Scaling operations have no effect on sBUFF content. Multi-spectral: REX supports selecting arbitrary spectral bands from imagery that may contain many more spectral bands than traditional RGBA color imagery. Image Calculator: REX supports an interactive image calculator where image RGBA data planes can be operands in logical relations or math equations supporting a rich function set. Interaction is via a simple language based upon Reverse Polish Notation (RPN) which is optimal for fast, interactive computation. RPN takes about 5 minutes to learn. Saving Imagery; REX supports saving compressed imagery in either the GIF or PNG image formats. GIF is a very compact but lossy RGB image format ideal for presentations and documents. GIF imagery can be loaded directly to the ALPHA band as an annotation layer. PNG supports lossless compression of RGB datasets, as well as RGBA including ALPHA for Overlays or Transparency. Regions on the computer Display, or entire GigaPixel buffers may be saved in either format. Both formats are widely supported by 3rd Party format conversion utilities. Saved images may be encrypted via the AES-256 cipher as an option (Level-2 license required). If the above seems complicated, that's because it is. But this complexity is hidden beneath an Intelligence Wrapper that reveals only a simple and intuitive interface. Imagine REX as a video game for scientific and artistic exploration. REX RUNTIME DEFAULTS REX is delivered with a text file in '/opt/imagtek/doc/REXdefaults.txt'. This configures runtime default parameters for REX. Use of this file is optional. Move the defaults file to your home directory; i.e. '$HOME/REXdefaults.txt'. Set values with a text editor. Any setting may later be re-defined interactively. # # File: $HOME/REXdefaults.txt # Desc: This optional file defines the REX runtime defaults # NOTE: $HOME links to LINUX home account # $MHOME links to Microsoft Windows-11 home account # DISPLAY_SIZE= FIT-TO-BUFFER // or MINIMIZE, FULLSCREEN, COLS,ROWS IMAGE_PATH= $MHOME/Pictures/ // path to images to load SCRIPT_PATH= $MHOME/Pictures/scripts/ // path to loader scripts ISAVE_PATH= $MHOME/Pictures/art/ // path to images saved by REX MISC_PATH= $MHOME/Pictures/data/ // path to LUTS, saved sBUFF, etc. USER_KEY = '?2-3:4XY*CCnWag43r' // crypto User Key; replace or delete this TWO_BUTTON_MOUSE = false // emulate 3 button mouse on 2 button mouse? ANCIL_DISP = true // ancillary display visible? ALPHA = false // display ALPHA as overlay (if present)? FAST_MENU = true // enable fast or slow menu mode AUTOB = false // image loader buffer auto-sequencing? SBUFF_WRITE= false // enable ~app access to Scaling Accum sBUFF? SBUFF_AUTO = true // auto refresh sBUFF HDR scaling display ZOOM_MODE = BICUBIC // or REPLICATE | BILINEAR | CATMULL-ROM # This file, and all its contents, are optional. Defaults are used if absent. NOTE: REX encryption supports 'User' keys and an optional 'Domain' key. It is NOT advisable to have 'USER_KEY' in the defaults file unless a 'DOMAIN KEY' is also implemented and SECURELY maintained separately. Note that absent a 'Level 2' License, encryption is limited to displaying random RGB number fields. REX is fully compliant with legal prohibitions against encryption in its Evaluation, and Level-1 License modes. IMAGE LOADER BATCH COMMANDS Scaling and composing multiple images / bands is complex. REX supports batch processing of complex image compositions via pre-composed Loader Commands using 'COMPOSITION TAGS'. Examples are given below. Note that the '#' character flags beginning of a comment and and all text following it is ignored. All REX commands are limited to a single line of text, however a trailing '\' character flags command-continuation on the next line. A Loader command may reference only a single image, but that image may consist of multiple bands and a command file may contain any number of loader commands. All Composition Tags are optional and are not case-sensitive. Note that you cannot load HDR imagery into an unmapped iBUFF, but REX supports 16 separate iBUFFs that can be cropped, pasted, moved, etc. between one another. ABOUT $HOME and $MHOME Note that under LINUX, your home directory is referred to as $HOME. Under Microsoft WSL, REX is configured so that $MHOME refers to your Microsoft home directory. Files resident under your Windows filesystem are accessible from LINUX apps via $MHOME. If on a Microsoft Windows machine, it is advisable to maintain valuable files under the Windows O/S, since LINUX is treated as just another App under Windows. If LINUX is deleted from a Microsoft WSL system, then the contents of the LINUX file system are also deleted. For details see: doc/REXinstall.txt REX LOADER COMMAND FILE EXAMPLES ...non-HDR # # testFullLoadManip.cmd # Test image loader capabilities to compose and resize images, including Alpha # Note: The cols=, rows= tags define the area size read from the file. # The displayed cols,rows may be less if the 'sfact' tag is used. # REX automatically expands the iBUFF to accomodate new images # ipath=$HOME/Pictures/art/ i=MACS-J0717mcd256-H.png i=andromCoreMCD256.png fxy=1500,1500 bxy=2000,2000 cols=3000 rows=3000 sfact=0.4 i=5Ghosts.png bxy=3000,3000 sfact=0.8 i=hdr.gif gif2alpha bxy=500,500 # load GIF format image to Alpha plane ...HDR # # jwstCosmosweb115-277-444.cmd # Create a scaled, RGB composite image from 3 HDR single-band JWST images. # NOTE: A command file automatically initializes its target iBUFF. This # can be blocked by the 'INIT=F' loader Tag for special cases. # HDR images forming a color composite must be exactly the same size. # The 'STATIC' tag enforces size by clipping imagery to the 'STATIC' # dimensions. A static tag with no dimensions will use the dimensions # of the first image loaded. R,G,B images can be loaded in any sequence. # The 'FXY' tag defines the origin of data downloaded in the HDR file. # The 'BXY' tag is prohibited for HDR images due to sBUFF alignment issues. ipath=$HOME/Pictures/astro/jwst/cosmosweb/images/ static=20000,15000 \ i=mosaic_nircam_f444w_COSMOS-Web_30mas_v0_1_i2d.fits fxy=1500,14500 gun=R \ hdr=R,lin,lo-hi,-0.061,1.2 i=mosaic_nircam_f150w_COSMOS-Web_30mas_v0_1_i2d.fits fxy=1500,14500 gun=G \ hdr=G,lin,lo-hi,-0.104,1.295 i=mosaic_nircam_f115w_COSMOS-Web_30mas_v0_1_i2d.fits fxy=1500,14500 gun=B \ hdr=B,lin,lo-hi,-0.122,1.431 You execute batch commands on the commandline via: 'rex < commands.cmd' or 'cat commands.cmd | rex' or via selecting 'Script' on the Loader GUI, selecting the Command File, then selecting Exploit. ************************** TIME TO GET REAL You are now ready to run REX and begin image exploitation. REX is controlled with the Left Mouse Button [LMOUSE], Right Mouse Button [RMOUSE] and Middle Mouse Button [MMOUSE]. If your Mouse only has two buttons, MMOUSE is emulated by pressing and holding LMOUSE, then pressing RMOUSE while LMOUSE is depressed. Release buttons in any order. The keyboard may also be active in certain utilities. The REX Image Loader and Exploitation GUIs are intuitively obvious and the Loader GUI has an extensive help menu. Trial and error is a fun and effective way to learn things and has been a path to many important scientific discoveries. REX is a stable and forgiving system that is designed for trial-and-error discovery via rapid feedback. Like a video game, there is no 'wrong' user input that will crash REX. Used Artistically, REX allows you to do absurd things. Used professionally, it can replicate results of industry-standard scientific applications. The rest of this document expands upon the above in much more detail, but is optional. You are now ready to run REX and explore imagery on as serious or playful a level as you wish. REX will not lock or crash your computer. TECHNICAL OVERVIEW: NAVIGATING HUGE IMAGERY When the cursor symbol of your pointing device is the size of your monitor's display footprint in a huge image, getting lost in the data is a real issue. REX defines a unique graphical navigation interface specifically for navigating huge imagery. A 'Global View' of the entire dataset, and your exact position within it, is never more than a single mouse-click and 'eye-blink' away. You can PAN from one edge of a GigaPixel scene to the other as fast as you can move your pointing device. Once an image area is selected for full-resolution exploitation its EXACT mapping to a coordinate system is maintained through ALL image transformations. This enables precise Geo/Astro navigation of point locations for imagery possessing navigation attributes, and dereferencing of individual pixel values to physically calibrated sensor metrics via Inverse Lookup Tables (iLUTs). NOTE: 'Global View' is not to be confused with 'Global Scope' discussed below. IMAGE MAGNIFICATION Image data may be viewed at reduced-resolution, full-resolution, or magnified up to 16X above full-resolution. Magnification algorithms used are Replication, Bi-Linear, Bi-Cubic and Catmull-Rom. Giga-pixel datasets may be 'roamed' with magnification and LUT transforms turned on. Note that magnified imagery will be 'blurred' or defocused, since it is impossible to interpolate new information from a single image. NOTE: Scientific users should acquire statistics from unzoomed imagery. NOTE: If restoring a full-screen area with a high zoom factor using Bi-Cubic or Catmull-Rom algorithms, there may be a noticable delay since these are extremely compute-intensive. If speed is an issue, Bi-Linear is extremely fast and is fine for most applications. At 16X zoom using Replicate, individual image pixels will be of substantial size on the Display. GLOBAL-SCOPE TRANSFORMS ON HUGE IMAGERY REX supports numerous image transformations for enhancing the Display of subtle or hidden information. By default, these transforms are applied to data visible within the 'Foreground Area of Interest' [FG AOI] on the Display. Transforms may also be applied with GLOBAL-SCOPE, effecting an entire GigaPixel iBUFF. Fine-tune your transforms on a subsampled 'global view' of a huge image, then unleash it on the entire dataset using 'GLOBAL SCOPE' to run in the background while you attend to other tasks. NOTE: If you have sufficient memory, and your processor has multiple CPUs, multiple REX sessions will not noticably degrade one another. Most people use only a small fraction of their computer's capabilities. NON-DESTRUCTIVE ALPHA ANNOTATION REX supports image annotation to the ALPHA Plane (discussed below). No special graphics hardware is required. This means that you can annotate an image with up to 256 colors, including Transparent. The ALPHA plane can be switched off, or its colors selectively changed or rendered transparent. REX images with annotation in the ALPHA plane may be archived in the widely supported 'PNG' image format. There is no limit on the size of an image that can be annotated. An image in GIF format may be directly loaded to the ALPHA plane without impacting the RGB image beneath it. You can Annotate an Image with a GIF format Image that can be clicked on, off, or rendered selectively Transparent intractively. IMAGE ENCRYPTION USING ADVANCED ENCRYPTION STANDARD (AES-256) CIPHER FOR SECURE COMPARTMENTALIZATION OF INFORMATION NOTE: Those who DO NOT purchase a Level-2 permanent license enabling the encryption option are fully compliant with legal restrictions against encryption. Encryption is NOT accessible with the Free Evaluation License, or a Level-1 permanent license. Encryption capability cannot be hacked into operation except via a complex and criminal binary edit of the REX executable that voids legal access to the REX application. REX is the only image exploitation system on the market supporting fully inte- grated AES-256 image encryption for generic format support of information compartmentalization. There is no separate processing step with encrypted imagery. Encryption is format independent, enabling you to load and save encrypted images in popular, compressed formats. REX encryption uses an implementation of Advanced Encryption Standard (AES-256) cipher technology with industry standard PBKDF2 password/key processing. This technology has been exhaustively probed for vulnerabilities in volumnous, peer-reviewed literature by government and private security organizations. AES-256 is certified by the US Government for securing 'USA TOP SECRET' level information. Once activated, encryption support is fully transparent and is no different than exploiting unencrypted imagery. The REX AES implementation supports both User Keys, and Domain Keys, for compartmentalizing access. Encryption may be declined by those with no use for it, or for whom there are legal restrictions to its use. See Appendix F: 'REX Encryption And Key Management. REX encryption grew out of a need for 'pure' random numbers for research purposes. MAINSTREAM IMAGE FORMAT SUPPORT, AND BEYOND REX can provide a rapid path to support any conceivable static image format, of any dynamic range or datatype, supporting sensor calibration and Geo/Astro navigation, with minimal development within the existing framework. IMAGE MANIPULATION DETECTION Due to its reliance on deep statistics, REX is adept at revealing undisclosed manipulation of digital imagery since such manipulations are localized and 'ring' against the statistical background defined by the entire image. Sadly, analysis of legacy 'UFO' images of flying saucers reveal such manipulation. Modern AI based image manipulation is not so easy to detect since the entire image is algorithmic. ******************************************************************** * * * IMAGE EXPLOITATION * * TECHNICAL PRELIMINARIES * * * ******************************************************************** DIGITAL IMAGE PROCESSING: REX 32 BIT [RED-GREEN-BLUE-ALPHA] COLOR ARCHITECTURE The human eye cannot perceive more than 256 shades (8 bits) of intensity and contains only 3 color receptors sensitive to RED, GREEN and BLUE. Therefore, all computer color displays represent imagery as RED, GREEN and BLUE with 256 independently varying intensities for each color at every point. The countless shades and nuances of color arise from simultaneous variations in intensity of RED, GREEN and BLUE. REX embraces this fundamental architecture of the human visual system and extends it. All REX imaging is performed in 24 bit color (8 bits RED, 8 bits GREEN, 8 bits BLUE). Black and white images, or color images that are less than 24 bits (pseudocolor), are automatically converted to 24 bits internally (with no information loss or distortion) when loaded. High Dynamic Range (HDR) Imagery with more than 8 bits of resolution per color are automatically scaled to 8 bits per color by REX, with multiple scaling options available interactively. ALPHA CHANNEL 'ISSUES' REX supports an 'ALPHA' bitplane in addition to RED, GREEN and BLUE. REX supports ALPHA as an 'Overlay', as an 'Opacity Operator', or as a generic data channel that can be swapped in and out of the RGB Display space. ALPHA as a 'opacity operator' is used to render an image variably transparent relative to a background image. An ALPHA of zero means the image is transparent to an underlying image. If there is no underlying image, the image is invisible. An ALPHA of 255 means the image is fully opaque and visible. For this reason, the PNG and TIFF image formats populate the ALPHA channel of a RGBA image with the value 255 so it will display correctly. See iCALC (Image Calculator) subsystem (Appendix A) for REX image Transparency support. ALPHA as an 'Overlay operator' is treated as an index into a RGB pseudo-color LUT that overwrites the Display with a RGB pseudo-color rendition of the image in ALPHA. This enables image annotation, and even GIF format pseudocolor images to overlay the Display without corrupting the underlaying RGB image. For Overlays, an ALPHA value of zero signals that the overlay is Transparent enabling elements of the Overlay in ALPHA to be selectively rendered transparent. The entire ALPHA Display may also be switched on and off. The use of ALPHA as a 'Opacity Operator', and as an 'Overlay', are mutually exclusive and may result in the following issue. THE 'MAGENTA SCREEN' DILEMMA ALPHA AS TRANSPARENCY VS ALPHA AS OVERLAY The ALPHA band is important to web browsers and window managers displaying complex compositions of variably transparent overlapping imagery. The standard assigns an ALPHA value of zero to points on an image that are Transparent (invisible) to underlaying imagery. An ALPHA value of 255 indicates the corresponding point is opaque and obscures underlaying imagery. Numbers between 0 and 255 indicate variable transparency to underlaying imagery. Alternatively, ALPHA can be treated as a Pseudocolor Overlay image. A color image in GIF format may be directly loaded into the ALPHA plane and its display switched on and off, and its different elements made Transparent. By default, REX treats ALPHA as a Pseudo-color Overlay; with zero indicating Transparent, and 1-255 indicating a (R,G,B) triad from a LUT indexed by ALPHA. This means that REX will sometimes display a PNG or TIFF format RGBA image as a blank Magenta screen if ALPHA is enabled. This is because PNG and TIFF formats populate the ALPHA band with a default value of 255 if no ALPHA data is present. This prevents the image from being invisible when displayed on web browsers. Treated as an Overlay, Magenta is the default REX Overlay color for ALPHA=255. The easiest way to avoid a Magenta Screen is to disable display of ALPHA. You do this in the 'REXdefaults.txt' configuration file. Simply tag 'ALPHA=false'. Alpha data will continue to be loaded, but Alpha display will be turned off until re-activated. The Image Loader Tag 'XALPHA' also does this. Interactively, you use 'BUFF OPS/iBUFF/ALPHA/DISABLE' in the Exploitation System. If you wish to zero ALPHA and use it for annotation, use 'BUFF OPS/iBUFF/ALPHA/ZERO'. CREATE ALPHA OPACITY OPERATOR FOR SAVED PNG IMAGES The PNG data format supports the ALPHA Opacity operator. You may wish for your saved RGBA PNG format image to have a 255 encoded Opacity in the ALPHA plane if it is likely to be used for webpages in browsers. REX does NOT do this by default. To create an RGBA image with the ALPHA plane set to 255 (Opaque), use the REX Image Calculator, iCALC. Once in iCALC type: global=t # toggle global scope on 255:A # value 255 written to Alpha plane of entire iBUFF global=f # toggle global scope off exit This will write the value 255 to the ALPHA plane of the entire image. Then 'SAVE IMAGE' as RGBA [not RGB] in PNG format. When the image is displayed on browsers supporting Transparency, it will display correctly. When displayed on REX with ALPHA enabled you will get... a Magenta screen. CREATING ALPHA OVERLAYS ANNOTATION You can draw lines, create text and geometric shapes directly in ALPHA using the ANNOTATE/OVERLAY function. You can also directly write to RGB planes if saving images in a format that does not support ALPHA, such as .gif format. You can also assign any RGB plane to the ALPHA channel via the 'AOI OPS/ALPHA/ ASSIGN' or the 'BUFF OPS/iBUFF/ALPHA/ASSIGN' operators. You may also overwrite the ALPHA channel with a grayscale image in the LOADER. You can also use the REX image calculator to assign the results of computation to the ALPHA plane (GLOBAL or MAPPED mode only). RGB COLOR LOOKUP-TABLE [LUT] MANIPULATION REX provides complete emulation of 24 bit DirectColor. This means that REX can manipulate the RED, GREEN & BLUE color lookup tables of the DirectColor display independently. This enables instantaneous and reversible image transformations with a mouse button click. No specialized graphics hardware is required. RESOLUTION PYRAMIDS AND WAVELET BASED COMPRESSION REX supports the JPEG-2000 image format based upon wavelet compression. This enables image access at multiple-resolutions while retaining optimal fidelity at each resolution. Using the 'DERES' loader tag, each value > 0 is a power-of-2 reduction in resolution from the original image. This appears as an image of reduced X,Y dimensions. DERES=1,2,3,4 is equivalent to SFACT=0.5, 0.25, 0.125, 0.0625 The advantage of this is wavelet deresolution retains maximum fidelity. REX does not support non-JPEG2000 resolution pyramids of other formats since they are redundant. Such images will always be read at their maximum resolution. Use the DERES tag to reduce resolution during load. DEEP QUANTIZATION AND HIGH DYNAMIC RANGE (HDR) IMAGERY Human vision cannot discriminate more than about 256 levels (8-bits) of luminance. Therefore, each color plane of a 24-bit RGBA Display has 256 luminance levels. This results in 16,777,216 discrete colors from 256 levels of Red, Green, Blue. Some images have a High Dynamic Range (HDR), meaning they have more than 8 bits (256 levels) of luminance. Scientific imaging systems may support up to 16 bits ((0-65535) levels) of luminance for each color band. REX loads HDR images at Full spectral Resolution, but uses statistical scaling to visualize HDR data. This enables precise selection of ranges to be scaled into the 8-bit visual range. REX supports LINEAR, LOGARITHMIC, EXPONENTIAL, SINE-H [hyperbolic sine], and TAN-H [hyperbolic tangent] scaling modes (see sBUFF below). It also supports HDR display of Pseudocolor across the entire HDR range (Loader only). Non-Linear HDR scaling modes enhance contrast in some luminance ranges at the expense of contrast of other ranges. This is an unavoidable trade-off when working with HDR imagery. REX is designed to make experimenting with HDR scaling simple and very fast. HDR scaling is a complex skill learned by trial and error over time. NOTE: See also 'sBUFFER' [Scaling Buffer] for detailed HDR implementation on REX. THE REX SYSTEM ARCHITECTURE REX is divided into two main subsystems; the Image Loader and the Image Exploit- ation System. The image loader ingests imagery and organizes it into internal data structures that the REX image exploitation subsystem can display and manipulate. There is no direct interaction between these independent subsystems. REX and FREE OPEN SOURCE SOFTWARE (FOSS) Imagtek LLC provides a legal framework for extending REX into specialized domains using your proprietary code via 'Collaborative Development Licensing Technology' (CDLT). You retain full ownership & control of your trade secrets and intellectual property in your enhanced version of REX, if that is your business model. Or you can open-source and freely distribute your improved version of REX under the legal protection of the Imagtek LLC open-source CDLT License. CDLT (c) is a legal shield against Marxist, so-called 'CopyLeft' licensing that strips developers of their right to control what they create. REX is forensically clean of any CopyLeft source code and will remain so. See: imagtek/licensing The REX FOSS baseline will be released under github.com in 2024 when robust stability of the graphics kernel application is achieved. This will enable users to modify and extend REX under Open or Closed Source business models, via terms of the non-restrictive Imagtek CDLT license. CDLT protects Software Freedom, while preserving Human Freedom. REX LICENSING Distributing Free Open Source Software for nothing, or funded by 'donations' or 'consulting fees' is not a viable business model. Imagtek resorts to run-time licensing to generate revenue supporting development of this unique system. REX automatically creates a FREE evaluation license on your system upon first activation. Licensing consists of a short, encrypted text string you can read. There is no back-ground 'licensing process', nor access to the Internet. Imagtek retains no contact information about users of its products. See 'doc/REXinstall.txt' for the simple procedure to upgrade to a permanent license. We are very sorry if you object to our licensing policy, but we are not slaves or fools. REX is simple to cleanly delete from your system with basic LINUX commands. See the REX installation document for details. Thank you for considering IMAGTEK! ****************************************** * * * THE REX IMAGE LOADER SUBSYSTEM * * * ****************************************** The REX image loader creates iBUFFs in memory and populates them with images. The loader supports complex scaling, calibration, composition and other operations on imagery during image load. For this reason, the loader supports command scripting and a commandLine interface as supplements to the loader graphical user interface (GUI). Once an image has been successfully loaded, the REX interactive exploitation subsystem is automatically activated. Each image buffer may contain a composition of an unlimited number of selectable images. Each image contains a record that maintains detailed information on position, scaling, calibration, map/astro-projection, etc. The 'selected' image in a buffer defines the geometry, calibration, etc. for the entire buffer. Up to 16 independent iBUFFs may be active simultaneously. Menu selections exist for cross-buffer operations, and multiple REX sessions may be active. THUMBNAIL IMAGES NOT SUPPORTED IN IMAGE LIST The REX image loader GUI does not support 'thumbnail' image display. This is because REX supports exploitation of images that may be GigaPixels in size and in HDR scientific formats. If you configure your LINUX file browser for thumbnail display of popular image formats, double clicking on an image with REX configured as the default image viewer will provide the desired 'thumbnail' image interface. LOADING AN IMAGE The trivial case for loading an image into REX is double-click the REX icon on your LINUX desktop, or use the tabular REX Loader GUI. For use on a commandline, simply type REX. rex Or, you may specify an image on the commandline. The image loader will not appear unless there is an error. If 'path' is omitted, the current working directory is assumed. In either case, the directory containing the image becomes the working directory. rex /path/imageFileName REX always assumes images are in the current working directory unless this has been set to a different directory in the 'REXdefaults.txt' file. You can over- ride this behavior by specifying a new directory. When the image loader appears, it will offer file selections from the new directory. If '/path' is omitted, the current working directory is assumed. rex -cd /path/ If you have a long and complex series of image load commands defined in a script, direct the script to REX. The loader will read and execute the script. rex < imageLoadScript.cmd Alternatively, you can create a shell script or application that generates a complex load sequence interactively, then pipe the commands to REX. The REX loader GUI will not appear if the commands piped to it do not cause an error; i.e. you can replace the REX loader GUI with your own image loader interface written in Python or whatever GUI scripting language you like. yourScript.py | rex THE REX IMAGE LOADER GRAPHICAL USER INTERFACE (GUI) The trivial case of loading an image is to activate the GUI, select the 'Image' option, click the desired image file, then click the 'EXPLOIT' button. An exterior process may provide load commands to the REX loader, in which case the loader GUI will not be activated. The REX loader GUI appears only if no load commands have been streamed to REX, or if there was an error while processing externally generated loader commands. If this happens, the GUI will display the cause of the error. To avoid this, your pre-processor should error-check files before sending them to REX. The REX loader GUI is a hybrid interface that includes a 'Composition Tags' menu. All composition tags are optional. The file selector creates loader commands that define images to load and view. 'Composition Tags' are used to expand basic image load commands with fields for composition, scaling, band selection, etc. This makes REX simple to use for a novice user, while providing an advanced user with access to the full suite of REX image loader capabilities. Image load consists of executing a list of commands describing a load sequence. The loader GUI facilitates the creation of this 'command list'. A command list can be as simple as specifying a single image to load, or as complex as specifying multiple images, scaled, tiled, band selected, decrypted and composed, loaded into multiple independent iBUFFs. The upper left of the loader menu has a pull-down menu labeled 'File'. It has 4 entries: Image : Displays the 'image' selection 'point and click' GUI. Script : Displays the 'command script' selection 'point and click' GUI. Exploit : Executes the Image Load List, then activates image exploitation. Resumes previous exploitation if no new images were selected. Clear : Clear (erase) the Image Load List. Exit : Exit the REX application. 'Image' and 'Script' cause a pop-up file selector to appear. It has 4 buttons: Exploit : Immediately load and view the selected image, or execute the selected load script. Any images and/or scripts in the Image Load List will be loaded/executed first. Filter : Update the directory listing in the file selection GUI. Dismiss : Dismiss the image file selector; Image Load List is NOT deleted. Edit/Add : Edit load command with qualifiers from the 'Loader Composition Tags' menu. Press 'Enter' to add command to Image Load List. Casual users will click 'Image' to activate the file selector, select an image, using 'Select', then click 'Exploit' on the main menu to view it. That's it! Advanced users will select an image, then click 'Edit/Add' to edit the command on the commandline. Clicking the commandline enables adding composition tags from the command menu. Then press 'ENTER' on the keyboard to add the command to the Image Load List. Multiple image loads can be defined in this way without exiting the load GUI. When the command list is complete, click the 'Exploit' button to execute the entire loader command list and exploit the ingested imagery. If the command list is empty, 'Exploit' will resume exploitation of the most recently exploited iBUFF. If no iBUFF exists, REX will simply ignore the 'Exploit' request. Note that you may work entirely from the commandline. Some people (mostly aged and decrepit UNIX hacks) do this. Note: There may be a noticable delay loading GigaPixel images. REX will notify you if there is an error. Please be patient. The image will appear. If the loader encounters no errors, the REX exploitation window appears instantly, or soon, or after you have finished your coffee; depending upon the size of the image being loaded. REX does not waste bandwidth on a 'status' GUI. LOAD ERRORS A load error does not terminate REX or corrupt successfully loaded images. It simply displays the REX GUI, if it is not already displayed. Error messages will appear in the 'Command History' window. If an error occurred during a scripted load, the script is terminated. If the error occurred after one or more images was successfully ingested, these images may be viewed normally by selecting 'EXPLOIT'. ADVANCED LOADER COMMANDS: IMAGE COMPOSITION PRELIMINARIES An image consists of a rectangle, or 'raster' of very many picture elements, or 'pixels' ('pels' if you are Euro). Each RGBA pixel is represented by up to four numbers. For color images, each color plane may contain a different number. For grayscale images, the same number is repeated for each RGB color plane. The REX loader enables you to mix and match images in any RGBA color plane or spatial compositional arrangement in a single iBUFF. REX does NOT impose any sort of compositional control over user image editing. If you compose images to overlap in the iBUFF, they will. If a loaded image is larger than the boundaries of the existing iBUFF, the iBUFF is automatically expanded to accomodate the new image. Scientific users will obviously use different compositional protocols than photographers / graphics artists. Regardless of the image storage format, REX stores all images as 32 bit RGBA (24 bit Truecolor + 8 bit Alpha). REX is a direct RGBA system and imposes no confusing 'abstraction layer' between you and the computer hardware. Color images may be 'Truecolor', or 'Pseudocolor'. Truecolor images have 24 bits per pixel (3 numbers representing 3 colors; 8 bits per color; Red, Green,Blue). There also exist other color 'spaces' that can convert to and from RGB. 'Pseudocolor' images are represented like a grayscale image, except that the pixel value is used as an 'index' into a lookup table (LUT) of a RED, GREEN and BLUE color triad associated with that index. The pixel value simply determines which LUT entry will be displayed at that point. Pseudocolor images support a maximum 65536 individual colors, selected from a possible range of over 16 million colors. Variations on the above schemes exist, but share the general characteristics. Grayscale images can be loaded independently to the RED,GREEN,BLUE or ALPHA bitplanes. If the color gun for a grayscale image is not specified, it is assumed the image is to be loaded as a grayscale image, and all three (RGB) color bitplanes are overwritten by the same image. Note: Loading 2 color bitplanes in a single load command is undefined. You can load an image to a single color, to 3 colors (RGB), or to RGB plus ALPHA (RGBA) in a single load command; if supported by the image format. You cannot load multiple images with a single command. This is because REX is a strict 'single-thread' application and only a single image decompression 'thread' may be active. THE REX LOADER MENU: IMAGE COMPOSITION TAGS Most of the Composition Tags on the REX loader menu are of interest only to advanced users. Those using REX as a simple image viewer need not be concerned with this section. The reason Image Composition Tags are presented as a commandline interface instead of a GUI is because implementing the full range of loader commands as a GUI would result in a hopelessly complex GUI interface and application bloat. A menu of tag=values with a simple syntax is really much easier to use for complex loads. Complex load compositions should be implemented upstream as scripts pre- created by the user, or by specialized GUI apps that generate command streams. All Command Composition Tags take one of two possible forms: TAG=VALUE [,VALUE,...] or TAG Square brackets in a menu descriptor '[ ]' always indicate optional values. Round brackets in a menu descriptor '( )' always indicate required values. Vertical separators '|' indicate selection of one value from a group. Neither '[]', '()' or '|' appear in any command; they are notational. Angle brackets '< >', where indicated, ARE required in the command! Blanks separate command fields, and may NOT appear within a multi-field command. Commas ',' are the only recognized field separator for multi-field commands. An equals sign in brackets [=] means that the value field is optional and is expected only if the '=' sign is present. A tag missing an '=' sign usually turns off a function that was previously defined. A load command is a text string terminated by a line feed '\n'. Each command defines a single image load. There is no limit to the length of a commandline, so do not worry about long commands. If you wish to neatly format a single commandline in a scripted command file, terminate the line with a backslash '\' and the following line will be considered a continuation of the previous line. You may not break a tag=value pair with '\'. When creating 'command files' using a text editor, the commands are entered EXACTLY as if they were being entered interactively. There is no difference between the format of a scripted command or an interactively entered command. Commands are executed strictly in the order in which they were entered. An image load command is limited to a single image file. The 'tag' field MUST be one of the tags indicated on the menu. Based on the tag field, one or more 'value' fields may be required. Note that ALL loader Composition Tags are optional. The REX loader menu appears as follows: " REX IMAGE LOADER COMPOSITION TAGS" " All tags are optional." "BXY= load to (X,Y) offset in iBUFF. No HDR." "FXY= load from (X,Y) offset in image file" "COLS= columns (X) to load" "ROWS= rows (Y) to load" "SFACT= image subsampling factor (Xs,Ys) {0.01 4 bands; {1-N}" "SETB= set target iBUFF (1-16) [also turns off AUTOB]" "AUTOB enable [+] or disable [-] automatic buffer sequencing" "STATIC= (Xdim,Ydim) [] create static iBUFF" "KEY[=] set/clear User Crypto Key; ['keystring' [,WIPE]]" "DKEY= set Domain Crypto Key; ('keystring'). Once only!" "DUMPH dump image header to terminal. No image load" "XALPHA disable ALPHA display [prevents magenta screen]" "FLIP flip image top->bottom on load. No HDR." "MIRR mirror image left->right on load. No HDR." "R180[+|-] rotate image 180 deg on load (iPhone images). No HDR." "BSWAP 'endian' byte swap HDR pixels > 8 bits" "BGRtoRGB swap RED and GREEN when loading RGB image" "INIT discard existing iBUFF and recycle memory" "gif2alpha read a color GIF image as ALPHA Overlay" "CMD= (filename) insert command file (*.cmd) into load list" "HDR= (RGB,RED,GRN,BLU,ALPHA),(LIN|LOG|EXP|SINH|TANH|PSEUDO)," " (FULL|MEAN|MED|LO-HI)[,(stdDev|Low),[High]]" "IPATH= (string) path to images" "SPATH= (string) path to command scripts" " ***** FORMAT SPECIFIC TAGS *****" "HDU= (1-N) FITS format HDU [Header Data Unit]; i.e. image #" Detailed command descriptions: -> BXY= load TO (X,Y) offset in iBUFF for image composition Normally, loading an image to an existing iBUFF will destroy the contents and resize the buffer to the new image dimensions. This tag adds the image to the buffer image list, and composes the image with its origin at the specified BXY offset. If the image will not fit in the existing buffer, the buffer is expanded automatically, preserving existing contents. If the buffer does not exist, it is created. See also STATIC tag. The BXY tag is prohibited for HDR images since these are loaded to a Scaling Accumulator [file] and not directly to memory. WARN: For the first image, 'BXY' may not exceed the image dimensions. If loading into an existing buffer, 'BXY' may not exceed the dimensions of the buffer (i.e. start of adjoining Tile). Buffer and image origin [0,0] is top-left corner and loads top-down / left-right as viewed on display. See FLIP and MIRROR tags. Apple iPHONE (c) images must use 'R180+' tag to display correctly. -> FXY= load FROM (X,Y) offset in image file Load a subset (tile) of an image, instead of the entire image. Specify X,Y offset in image file for origin of image data transfer. The cols, rows of the image load are adjusted automatically for you. Image origin [0,0] is top-left corner of displayed image. -> COLS= image tile: columns (X) to ingest Specify number of columns (X dimension) to transfer to iBUFF. COLS will truncate to the actual number of columns in the image. Note that 'SFACT' below may cause displayed dimension to differ from actual number of columns read. -> ROWS= image tile: rows (Y) to ingest Specify number of rows (Y dimension) to transfer to iBUFF. ROWS will truncate to the actual number of rows in the image. Note that 'SFACT' below may cause displayed dimension to differ from actual number of rows read. -> SFACT= (Xs,Ys) image De-Resolution factor ( 0.0624 < SFACT < 1.0 ) Reduce resolution (and image dimensions) during load. This enables you to load a huge image on a computer with limited memory so you can select areas of interest for higher resolution load. If a single SFACT value is given, both X and Y are the same. If different values are given then the image will be warped proportionally. For HDR images, REX uses simple elimination to subsample imagery. For 8 bit images, REX uses bilinear averaging to preserve maximum information. SFACT >= 1.0 is an error. -> DERES= (1-4) Power-of-2 image De-Resolution level. 1-4 reduces resolution (and image dimensions) by a power-of-2; i.e. 1=-2X, 2=-4X ... 4=-16X. DERES is equivalent to the SFACT tag with DERES=1,2,3,4 equal to SFACT=1/2,1/4,1/8,1/16. SFACT and DERES cannot both be active. You MUST use DERES to reduce resolution of JPEG-2000 imagery. -> STATIC [=cols,rows][,] define static iBUFF Normally, image dimensions define the size of an iBUFF. The buffer will dynamically increase in size as image compositions dictate. This command allows you to create a fixed buffer of arbitrary size whose dimensions will not change. If the buffer already exists, it is clamped and static. Optional values enable you to specify the background color of the buffer by giving the RED, GREEN and BLUE components. Black is the default background. Use this command to define the dimensions of an empty buffer to pass to the exploitation system for purely creative work. If an image is too large to fit in a static buffer, the image will be automatically clipped to the buffer dimensions. This is useful to enforce dimensions of HDR images, which must be of matching size. Once a buffer is flagged 'static' it cannot change size or revert back to dynamic. WARN: If you request a buffer that exceeds your system's resources, REX will decline the operation and return to the Loader GUI. -> SETB Set 'current' iBUFF (1-16). 'SETB' designates the 'current' iBUFF (1-16) to be loaded. REX automatically creates any iBUFF that does not already exist. Absent 'SETB', the 'current' buffer is buffer '#1', or the last buffer viewed during exploitation. SETB with no value resets the current iBUFF to buffer '#1' EX: SETB Reset. Set current buffer to #1; automatic sequencing 'off' SETB=3 Current buffer is buffer #3; automatic sequencing 'off' -> AUTOB [=T|F] Enable, or disable automatic iBUFF sequencing. If automatic buffer sequencing is not enabled, image loads will overwrite the currently active iBUFF. If automatic buffer sequencing is enabled, then each image will be loaded to the next iBUFF in sequence. If that buffer is not empty, it will be overwritten. Auto- matic buffer sequencing will wrap back to image Buffer #1 when the target buffer exceeds Buffer #16. Automatic iBUFF sequencing remains active until turned off [=F] or image exploitation begins. The 'SETB' tag disables 'AUTOB'. NOTE: You cannot use the 'GUN' tag if AUTOB is active. -> KEY[=] Set User Crypto Key; ['keyString'][,WIPE] NOTE See Appendix F; REX ENCRYPTION KEY MANAGEMENT... The 'KEY' tag controls AES-256 image encryption/decryption in the loader. Note: 'KEY' must PRECEED any command script invocation on the command line. 'KEY' must FOLLOW a Domain Key definition, if 'DKEY' is defined. Encrypted filenames MUST have '#' as the last character before the file extension, or the last character in the filename. REX will NOT attempt to decrypt a file lacking this flag character in its name. This protects against accidental attempts to decrypt unencrypted compressed files, which could cause decompression algorithms to crash. Given 'KEY=' as input: The User Key is expected to immediately follow as a quoted string; i.e. Example: KEY='123xyzBBB' THE MINIMUM KEY LENGTH IS 8 CHARACTERS. Note that the quotes are NOT considered part of the key and that a quote character cannot be part of any key unless preceeded by a '\'. Blanks are permissible. If a key is defined, it remains defined until it is redefined, or the REX application terminates. 'KEY' with no parameters turns existing encryption off in the Loader and erases the User Key. Erasing the User Key has no effect on an installed Domain Key. Only a single User key is defined at one time. If the key is redefined in the exploitation system to save an encrypted image file, that key redefines the Loader key, until reset. The 'WIPE' tag may follow User key definition. If this tag is present, decrypted temporary files will be re-encrypted before deletion, so that no unencrypted trace is left on your system. Once set, this flag remains set until REX terminates. There is a small performance penalty, noticable only on very large files. Example: KEY='123xyz', WIPE A User Key may be from 8 to 32 characters long. -> DKEY= Set Domain Crypto Key; ('text string' | 0X--64 char--) The Domain Key gives users access to a secure information Domain. It enables User keys to be transmitted over insecure networks without compromising security. Its use is optional, and the default value is zero. The 'DKEY' tag -MUST PRECEED- the 'KEY' tag on the commandline. It can be text in quotes like a User Key, or a 64 character Hexadecimal [0-9,A-F] A Domain Key defines a Crypto-domain used to compartmentalize access by User Keys. A Domain Key is optional but it can only be defined once. The Domain Key remains in effect until REX terminates. The Domain Key, and User Key, should NEVER be stored on the same system or storage media, nor referenced together in any document, nor transmitted over a network to the same location. -> BANDS= band select(s) from file > 4 bands. [1-N, RGBA order] An image file may be 1 band (grayscale), 3 bands (RGB), or 4 bands (RGBA) Use BANDS to select image bands from a file containing more than 4 bands. If a single band is selected, it will be loaded as a GRAYSCALE image. If multiple bands are selected, the color designations are R,G,B,A left to right in sequence on commandline. See also tags: GUN, LUT To load a single band as other than GRAYSCALE, GUN tag. i.e. BANDS=6,1,15 loads band 6 to RED, band 1 to GRN, band 15 to BLU BANDS=6 GUN=G loads band 6 to Green color plane. -> GUN= (R|G|B|A)[,image-ID] single color overwrite GUN selects a destination color for a single band load. GUN is based on terminology of 20th Century analog video displays that used a separate electron emitter, or 'electron gun', to excite R, G, B phosphorous coatings on a glass screen under control of wire coil electromagnets. Values for GUN are R, G, B, A. If the GUN tag is absent, then a single band image will be written as GRAYSCALE. GUN (and BXY tag) prevents an image load from erasing the current buffer contents. The most recent image loaded is overwritten by GUN if you do not specify an image by adding its ID number [1-N]. An image ID number is the sequence it was loaded. The selected image will clip the input image dimensions as required to exactly overlay the selected image. Selecting an image during exploitation uses its meta-information to define image calibration and navigation. Note: If BAND was selected (above) with a single image, the selected band will be loaded to the GUN color. -> INIT Recycle current buffer resources and Initialize a new iBUFF. The 'CMD' tag which loads a file containing loader commands issues the 'INIT' tag automatically. Absent the 'BXY' or 'GUN' tags, loading a new image will also automatically issue the 'INIT' tag. INIT=F disables this feature for a command. -> FLIP flip image top->bottom on load some images have their origin at the bottom when acquired rather than the top, causing them to display inverted unless FLIP is used. WARN: FLIP and SFACT tags cannot be used simultaneously. No HDR support. -> MIRR mirror image left->right on load some images have their origin on the right edge when acquired rather than the left edge, causing them to display backwards unless MIRR is used. No HDR support. -> R180 rotate image 180 degrees on load (FLIP + MIRR) Apple iPhone images appear upside down due to coordinate system issues. Isn't it great to be a big corporation and make your own standards to capture customers? This tag rotates the image 180 degrees when loaded. NOTE: R180 and SFACT tags cannot be used simultaneously. No HDR support. -> BSWAP byte swap HDR raw pixels HDR images with pixels > 1 byte may be incompatible if created on a computer system with a different memory architecture (Little Endian / Big Endian). This flag will cause all multi-byte pixels to be 'byte swapped', fixing the problem. -> BGRtoRGB swap BLUE and RED color planes when loading RGBA color images are encoded into 32 bit, 4-byte pixels. Some imaging systems will encode RED in the low order byte. Some imaging systems will encode RED in the third byte position. This tag corrects the problem. -> DUMPH image header dump only Dump the image header to the loader GUI and terminal. No image load. -> CMD= execute (filename) containing REX loader commands Execute the loader commands in a command file. Give path from current working directory. Command files MAY NOT call other command files; this prevents recursion loops that might never terminate. NOTE: The 'SETB' tag MUST preceed the 'CMD' tag to assign target buffer, unless buffer assignment is taken care of in the command file. -> HDR= (RGB|R|G|B|A|RESET),(LIN|LOG|EXP|SINH|TANH|PSEUDO), (FULL|MEAN|MED|LO-HI)[,(stdDev|Low), High] High Dynamic Range scaling: (color plane),(scaling mode),(range mode), [,valA, valB]. Configure scaling for each color plane of a High Dynamic Range image. Select a single tag from each (|) scaling specifier. If 'image plane' is RGB, the same scaling is used for all image planes. Treat a grayscale image (no 'GUN=' tag) as 'RGB', or use same target image plane as 'GUN=' tag. Scaling remains as set until changed. You can also adjust scaling interactively in the Exploitation system. If the HDR tag for a HDR image is missing then HDR defaults, or the current scaling in effect is used. This may lead to unanticipated results, but is not a bug. See '...DEEP QUANTIZATION' above for more detailed description of scaling modes. If 'FULL' mode is specified, 'valA' and 'valB' are ignored and are a syntax error if present. 'LO-HI' range-mode is the only tag that requires both valA (low bound) and valB (high bound) in sensor units. All other range modes interpret 'valA' as the number of Standard Deviations defining the range for that range mode. NOTE: MIRR, FLIP, ROT180, BXY are not defined for HDR imagery 'HDR=RESET' options are: [,0] Linear, center on Median, 3.5 Std Dev [,1] Linear, center on Mean, 3.5 Std Dev [,2 or none] Linear, full-data-range. PSEUDO is accessible only in the image Loader for single band images. **** IMAGE FORMAT SPECIFIC TAGS *** -> HDU= (1-N) Image Header Data Unit (HDU) of FITS format files. FITS and IVIF files may contain multiple images and other datasets. HDU specifies which image in a multi-image file to access. Attempting to access a HDU that is not an image flags an error. -> GIF2ALPHA If the image is in GIF format, this tag will load the image to the ALPHA Plane where it will be interpreted as an Overlay. Colors in ALPHA may be selectively rendered Transparent, changed, or the entire image toggled off and on. The ALPHA plane has no effect on the RGB planes or RGB statistics. ************************************************************ * The following commands are used mainly for scripting * * and are not needed when using the loader GUI * ************************************************************ -> I= image file IMPORTANT: You cannot specify more than one image file on a commandline. Use the GUN tag and multiple commands to load grayscale images to individual color planes. -> IDIR[=path/] set/reset 'working directory' for imagery IMPORTANT: This tag must preceed image file specifiers on a commandline! IDIR remains as set until changed. IDIR with no value sets IDIR to the local directory. This option enables you to set the directory path to be inserted in front of all image filenames until it is reset. This saves you the work of entering the full path for every image file in your script. Imagery will be loaded from this directory until IDIR is redefined or reset. You may use environment variables ($HOME, etc.) with IDIR. If directory names contain blanks or special characters, enclose the directory string in double quotes; i.e. IDIR="$HOME/dumb dir name/" -> The BackSlash character '\' at the end of a line signals that the following line is a continuation of the current command. It is useful for formatting script files for appearance -> EXIT stop executing Loader commands and begin image exploitation. Load commands following this tag in a file will be ignored. There is no SKIP/RESUME capability for branching within Loader Command Files. QUICK REFERENCE: LOADER CAVEATS AND CONSTRAINTS A loader command is a string of tags and associated values, terminated with a 'newline' (carriage return); i.e. each command appears on a separate line. A load command may reference only a single image file. An image file may contain any number of color bands, but a maximum of 4 bands can be loaded in a single command. Loading multiple images requires multiple load commands. An image can be single band (grayscale) or a color composite of up to 4 bands. Single band images are assumed grayscale, unless a destination color plane 'GUN' is specified, in which case the image loads only to that color plane. Composition Tags are required if loading multiple images to an iBUFF. There is no limit on load commands that can be issued prior to Exploitation. A REX iBUFF consists of 4 bands; RED, GREEN, BLUE and ALPHA. There are 16 iBUFFs, all having identical RGBA architecture. There are two Scaling Accumulators [sBUFF] for High Dynamic Range imagery; one for the Image Loader, and one for Exploitation functions with HDR output. HDR data is written to the Scaling Accumulator [sBUFF] for interactive re-scaling to 8 Bits per color. The ALPHA band may be an 8 bit pseudocolor overlay, or a single band image that defines transparency of the underlaying RGB image (see iCALC). Multiple images may reside in a single buffer. Each image possesses an internal descriptive record enabling the image to be tracked throughout the exploitation process. Images may be arranged in spatial compositions of arbitrary complexity. There is no limit on number of images in an iBUFF. Compose images with the BXY, COLS, ROWS loader tags. REX does not auto-compose multiple images. Image composition is the responsibility of the user. REX does not prevent multiple images from obscuring one another. Rotating or warping an iBUFF voids spatial image tracking and geo- referencing, but has no effect on spectral calibration. Upon load, each image in an iBUFF is assigned an ID number, starting at 1. All references to the image in that buffer use this ID number. Selecting an image defines spectral calibration and georeferencing. Multiple, selectable iBUFFs (1-16) may be simultaneously active. Multi-band images with more than 4 bands must specify which bands to load. Band specifications are assumed in -> RGBA order. Only 1,3 or 4 bands may load. Specialized formats may support pixels in any storage scheme. Contact Imagtek. QUICK REFERENCE: LOADER SCRIPTING A loader script consists of a file (or stream) that contains one or more loader commands. Loader scripts are created using a text editor, or any process that generates a loader command stream directed to the image loader. The BackSlash character '\' at the end of a command causes the next line of text to be treated as a continuation of that command Running a script automatically resets the iBUFF being loaded unless the script contains the 'INIT=FALSE' tag. Each loader command in a script must reference a single image. A compressed COLOR image with 3 (or 4) bands is treated as a single image. Unanticipated loader script behavior is generally due to carelessness with IDIR SETB or HDR tags; i.e. not setting values, or not resetting them. The REX loader GUI creates an internal 'Command List'. You may interleave images and Command Scripts in the Command List. A script can never activate another script from within itself. This could lead to an endless loop. If REX detects a script from within another script it will terminate loading and issue an error. The REX loader GUI always provides the full path to any selected file. Manually created scripts may use the [IDIR=] tag to specify the default path for image files, so the file path need not be repeatedly typed in. IDIR should preceed the first file referenced in a script. If IDIR is set, the image filename is appended to the IDIR value, providing the full path to the image file. IDIR remains set until redefined, or reset. The reset of IDIR (tag WITHOUT a value) should trail the last command in a script. Script loader tags that set the current iBUFF [SETB=] should be on the first load command. A buffer remains the target buffer for image loads until it is explicitly set to a different buffer with the [SETB=] command; The most recent iBUFF loaded is the iBUFF the Exploitation system will open. You may, of course, select different buffers within the Exploitation system. The image loader always adds images to the end of the image list, however if a single color plane is to be overwritten, the GUN tag requires the image ID. Multiple commands may reference loading different colors (or bands) of the same image, i.e. selectively overwriting color planes. Overwriting color planes presumes the X,Y dimensions of all layers are the same. Images will be cropped to the size of the image they overwrite. If a command flags an error, the REX loader GUI will appear with a relevant error message in its 'History' pane. Command Scripts abort image load on Error. A loader script cannot 'resume' from where it exited. If an image file is less than 2500 scanlines in extent, and no error occurs, the loader GUI will not appear as a load status monitor. ****************************************** * * * THE REX IMAGE EXPLOITATION SUBSYSTEM * * * ****************************************** The REX image exploitation subsystem is an interactive environment where the user analyzes and manipulates (Exploits) an image. REX maintains the highly dynamic runtime exploitation environment automatically, while providing user control over its modes of operation. REX exploitation uses a 'cascading menu' interface. As you move the mouse down a menu, selections for each sub-pane will appear and disappear. You move the cursor down and across through the cascading menu selections. Menus appear only when the mouse button is depressed, and disappear when it is released. At all other times, the exploitation environment is uncluttered with GUI elements. We strongly urge users to read the section on mouse buttons, then 'just do it' as regards use of the exploitation subsystem. You can refer back to this guide as your curiosity or the need arises. REX will not crash using GUI input. THE REX MENU CASCADE; FAST vs STICKY MENU The REX menu can be 'fast' or 'sticky' (see ANCILLARY menu). 'Fast' displays the menu only while RMOUSE is depressed. The menu disappears when RMOUSE is released, or when the mouse cursor wanders off the cascading menu. This can be frustrating for some people. If RMOUSE is released with the cursor on a valid selection on the terminal pane of a window tree, that function is executed after the menu disappears. 'Fast' mode is for those who work quickly and have good dexterity. 'Sticky' displays the menu when RMOUSE is depressed, but the menu remains after RMOUSE is released. It remains visible until LMOUSE button is clicked. If LMOUSE clicks on a valid menu selection, it is executed after the menu disappears. RMOUSE At the top level of the exploitation subsystem, RMOUSE causes the main menu to appear when pressed. Moving the cursor over the menu causes the menu to cascade, revealing level after level of functionality. See 'fast' and 'sticky' menu description above. RMOUSE outside a sub-menu signals EXIT from that function. A 'blank' return in a dialog box expecting text input also signals EXIT. LMOUSE Pressing and releasing the left mouse button increases the zoom factor in the roam/zoom window when the ancillary display is activated. The zoom factor increases up to a maximum of 16X, then cycles back to a zoom of 2X. Pressing the LMOUSE button down and holding it down will cause the roam/zoom window to update with every mouse X,Y event, instead of every 4 events. The two modes exist to lighten the load on the CPU for roam/zoom refresh unless high positional resolution is desired. In all other contexts, LMOUSE is used to enter data points, such as defining lines in annotation, or LUT enhancement ramps on the histogram display. MMOUSE Pressing MMOUSE (or emulating MMOUSE) will toggle between default color lookup tables (LUTs) and transformed LUTs, if transformed LUTs are active. Activation of transform LUTs causes the roam/zoom window to overwrite the ancillary display. This is done because scaled intensities are undefined under a LUT transform, and because histogram colors are undefined under transformed LUTs. Change in the roam/zoom window occurrs whether transform luts are active or not. In all other contexts, MMOUSE is used to signal discarding input or repeating an operation. EXPLOITATION WINDOW RESIZING By default, loading an image may cause the size of an existing Display to change. However, some users may find a stable Display size more relaxing to use. For this reason, you may lock the Display dimensions after an image load, so future loads will not change the Display size. Select 'DISP OPS|RESIZE|DISABLE'. Making a selection from the Loader GUI 'DISPLAY' menu overrides and resets this setting. IMAGE NAVIGATION AND VIEWING MODES: MAPPED AND GLOBAL-VIEW Since most modern images are larger than a computer display, REX supports two viewing modes; GLOBAL and MAPPED. 'Global' mode subsamples the image down to a size that the entire image will fit on the screen without distortion. The image still exists at full resolution in its iBUFF. 'Mapped' mode displays at full resolution only that portion of an image that 'maps' to the display. This region is selected by use of the PAN utility, that also generates the 'Global view'. PAN uses the Global View as a frame of reference to select a sub-region to map to the display. To select MAPPED viewing, you exit PAN when your region of interest is visible at full (or zoomed) resolution on your display. To select GLOBAL viewing, you simply exit PAN when the Global view occupies the display. REX automatically tracks viewing modes and mapping internally. In 'Mapped' mode viewing, the precise geometric location of every point on the image is managed throughout the exploitation process. This enables precise locational positioning and measurement for geographic and astronomical images that possess locational metadata. It also enables precise selection of specific regions to be effected by image transformations, and selective update of the iBUFF with the results as well as quick restoration to original state. In 'Global View' mode, precise locational information is sacrificed in exchange for a view of the entire image. No mapping exists between a Global View and the Display. The PAN utility establishes such a mapping. Image transformations may be performed on the Global View, but they have no effect on the contents of the iBUFF, and cannot overwrite its contents. To run a transform on an entire iBUFF, you select 'Global Scope' mode from the exploitation menu (PIXL OPS below). This enables you to perform transforms on giga-pixel images interactively. 'Global View', and 'Global Scope' are two totally different concepts. THE 16 MAIN IMAGE BUFFERS (iBUFFER) The computer Display is a 'window' into the current iBUFF containing image compositions. REX supports 16 independent iBUFFs, and each image buffer may contain any number of images that are individually tracked. The only limit on size of an iBUFF is the amount of RAM memory on your machine. The 'active' iBUFF is memory mapped, and swapped in/out of RAM by the computer operating system as needed. Precise management of Display translation and magnification is performed automatically. Restoring an area on the display consists of overwriting it with the contents of the current iBUFF (or display accumulator) that maps to that display area. An image may be in as many as 3 states simultaneously; the iBUFF state, the displayed state, and the 'Display Accumulator' state (discussed below). It is possible to simultaneously roam the internal iBUFF state while viewing the transformed, displayed image. Although the user may define up to 16 iBUFFs, only one buffer may be active at a time. There are numerous cross-buffer operations however. You may also have as many simultaneous REX sessions open as you like. ACCUMULATORS REX also supports so-called 'accumulators'. An 'accumulator' is simply a logical object containing image data. Accumulators differ fundamentally from image buffers. REX always maintains a rigorous 1/1 mapping between the Display and the active iBUFF throughout all magnifications and translations. In contrast, an 'accumulator' is an unmapped image data object. REX supports functions that manage, scale output, and write accumulator content to iBUFFs for viewing. THE SCALING ACCUMULATOR (sBUFF) 32 BIT FLOATING POINT SUPPORT FOR HIGH DYNAMIC RANGE (HDR) IMAGERY The scaling accumulator (sBUFF) enables REX to visualize HDR scientific data at full precision. By using the scaling options available, HDR data may be viewed using different scaling modes and ranges without having to re-calculate a transform or re-load HDR image data. This makes it possible to quickly explore data sets with very large dynamic ranges. Re-scaling sBUFF content into an iBUFF for viewing has no effect on the sBUFF content. There are two sBUFF's; the Loader sBUFF and the Exploitation sBUFF. REX HDR Exploitation Apps [~Apps] can directly write to, or read from a sBUFF at full HDR precision. An sBUFF can contain only a single HDR image, but that image may consist of up to up to 4 bands [RGBA]. If an HDR image is a composite of multiple bands loaded a single band at a time, each band must have identical dimensions. Unlike the iBUFF, the sBUFF does NOT support composing dissimilar size HDR tiles. This is because sBUFF is a file [Accumulator] and not memory. Tiling areas of dissimilar size within an Accumulator is prohibitively complex. Use the Loader FXY,COLS,ROWS, SFACT,STATIC Tags to crop dissimilar HDR dimensions to a common sBUFF size. The contents of sBUFF can be used as input to other floating point image transforms, serving as an interface connecting iterative floating point calculations without loss of precision. This is done by toggling the Exploitation ~App sBUFF ON. This will preserve the HDR output of HDR ~Apps when scaling for RGB Display is completed. For example, you can compute the FFT of an image with the HDR result written to the Exploitation sBUFF, then compute the Inverse FFT on the sBUFF contents to restore the original image. You can also use the sBUFF as direct input to custom ~Apps. *** WARNING: sBUFF and GLOBAL SCOPE *** If running REX HDR ~Apps in GLOBAL SCOPE mode on huge images, having sBUFF 'WRITE' access enabled may result in creation of an sBUFF that is GIGABYTES in size. This will dramatically slow performance. Make certain that sBUFF write access is OFF if this behavior is NOT desired. ~Apps will run normally with the Exploitation sBUFF turned off, but you will not be able to rescale the output. Since use of the sBUFF is an advanced feature with significant processing overhead, automatic update of sBUFF by REX HDR ~Apps is turned off by default. Use the REX exploitation GUI to manually turn this feature on: 'BUFF OPS|sBUFF|EXPLOIT|ON'. You can also do this in the 'REXdefaults.txt' file. Why No 64 Bit Floating Point Support? REX is a data visualization system designed for potentially gigantic [Gigapixel] imagery. For this reason, REX truncates 64 Bit / Band Floating Point HDR data to 32 Bits / Band. It is arguable that physical sensors do not exist with a true precision exceeding 32 Bits / Band floating point range. The performance cost of supporting 64 Bit / Band HDR imagery, weighed against the marginal utility of such precision in an 8-Bit visualization space, informs this decision. Support for 64 Bit precision will be added if/when it becomes an issue. THE DISPLAY ACCUMULATOR REX supports a 'display accumulator' internally that manages the Display of LUT transforms, Alpha, window manager updates, etc. The Display accumulator is managed by the Intelligence Layer and is not directly accessible by the user. THE 'TOUCH' ACCUMULATOR The 'Touch Accumulator' preserves a snapshot of the current Display. It is manually updated using the 'TOUCH' command. (see DISPLAY OPERATIONS). The Touch Accumulator enables the Display to be refreshed from the last 'touched' state rather than the current iBUFF state. Active transform LUTs are part of the saved image state. The Touch Accumulator is precisely registered to the current iBUFF in memory. Therefore, if the active iBUFF is changed, warped, resized, Display window size changes or other event that invalidates precise registration, the Touch Accumulator contents are discarded and lost. FOUR 'USER' ACCUMULATORS; '@1','@2','@3','@4' REX supports four user accessable image accumulators, designated @1, @2, @3, @4. These accumulators are used to cut, temporarily store, and paste image contents defined by the current area of interest (AOI). User accumulator contents persist until redefined, or REX terminates. Accumulators permit image blocks to be passed between iBUFFs or to subsystems and manipulated (see iCALC). You can copy an entire iBUFF into an accumulator, or create an iBUFF from an accumulator. AREAS OF INTEREST (AOI) AND CURRENT STATISTICAL STATE REX maintains a 'Foreground AOI', 'Background AOI' and 'Limits AOI'. These are displayed as rectangular frames defining areas on the display. An AOI has no internal state or attributes; it merely defines a boundary. An AOI may be transformed into a visual state that differs from the underlying iBUFF. The iBUFF may then be updated from the AOI state (see AREA OPS/COMPOSITE) or the AOI state may be restored from the iBUFF (see AREA OPS/RESTORE). FOREGROUND AOI The Foreground AOI (FG AOI) defines the region effected by 'pixel operations' on the display. It also defines the 'Current Statistical State' of REX. The FG AOI is actively defined and managed by the user. Whenever the state of the display changes, the contents of the FG AOI are automatically tabulated and histograms and statistical metrics are computed and maintained internally. Similarly, altering the size or location of the Foreground AOI recomputes all statistical metrics. Like the Display, the Foreground AOI is rigorously mapped to the active Image Buffer. See 'AOI OPS' below for more details. BACKGROUND AOI The 'Background AOI' bounds the iBUFF that is visible, or 'maps' to the display. Like the Foreground AOI, the Background AOI is depicted on the display as a rectangular frame. Unlike the Foreground AOI, the Background AOI boundary cannot be changed except by changing the mapping from the Display to the iBUFF. The BG AOI and the FG AOI may define the same area on the Display, in which case only the FG AOI is visible. LIMITS AOI The Limits AOI is a cosmetic boundary depicting the dimensions of the Display. EXPLOITATION SUBSYSTEM MAIN DISPLAY WINDOWS The exploitation subsystem Display consists of several display areas that manage specialized exploitation capabilities; usually automatically. ANCILLARY WINDOW The ancillary area consists of 3 specialized visualization windows arranged vertically at the right of the mapped buffer area. The ancillary area consists of a roam/zoom window, a histogram/scattergram (or TBD) statistical visualization area, and a text display area. The ancillary display can be toggled on or off at any time by selecting 'ANCILLARY' on the main menu. If imagery maps to the area beneath the ancillary display, it overwrites the ancillary display when ANCILLARY is turned off. ROAM/ZOOM WINDOW When the mouse cursor is moved around the image, the area around the cursor will appear magnified by the current zoom factor in the roam/zoom window. Clicking the LEFTMOUSE button will snap the roam window to the current cursor position and increase the zoom factor by a power of 2X to 16X, then recycle. The zoom window updates every other mouse XY motion event. Pressing LEFTMOUSE and holding it depressed while moving it will cause the zoom window to update every mouse XY motion event, providing finer roam control. HISTOGRAM/SCATTERGRAM GRAPHICAL VISUALIZATION WINDOW The HISTOGRAM represents the statistical state of the exploitation system. The histogram display window shows the most recent histogram acquired, or the appearance of the histogram transformed by the current LUT transform. The histogram contents of the current area of interest (FG_AOI) are always updated automatically. When the mouse is within the histogram window, the statistics display window (described next) will give the intensity value (X) and corresponding count (Y) for RED, GREEN and BLUE color planes. The histogram window and statistics display window are closely coupled. A scattergram and future TBD visualizations will also be supported within this window. STATISTICS DISPLAY WINDOW The statistics display window gives the numeric textual representation of the RED, GREEN, BLUE values beneath the cursor, and the corresponding scaled values in the original dataset (if the data is scaled). For example, a value of 128 in the RED color planes may represent 9000, or 27.3 degrees celsius, or a 51.36 percent albedo, etc. in the original dataset. The histogram count for each of the R,G,B values at that point is also given, as is the X,Y coordinate of the point in the iBUFF (NOT the screen coordinate). If the image is geo- located (navigated), the earth or celestial coordinates will be given. All this occurrs automatically without user intervention if the ancillary display is active. FLOATING POINT HDR OPERATIONS '~' Certain REX apps are marked with the sign '~'. This sign indicates that the output of the operation is High Dynamic Range and may be saved at full precision in the Scaling Accumulator, sBUFF. The display of the output is determined by the scaling parameters defined by the scaling buffer menu ( BUFF OPS|sBUFF| SCALING ). You may redisplay the contents of the sBUFF using different scaling parameters without re-computing the operation that populated the scaling buffer; i.e. re-scaling the sBUFF does not alter its contents. ********************************************************** * * * PERFORMING OPERATIONS: THE MAIN EXPLOITATION MENU * * * ********************************************************** All top level interaction with REX occurrs via cascading 'popup' menus. The top level main menu appears when RMOUSE is pressed. The menu disappears when RMOUSE is released and is visible only so long as RMOUSE remains depressed. In image analysis, display area is precious. REX dispenses with useless tables of cryptic symbols that clutter the screen and whose function must be memorized. Every pixel in the REX Display is devoted to the image data being analyzed. REX' graphical user interfaces (GUIs) appear only when specifically requested and remain only as long as needed. At all other times, it is just you and the image. The top level popup menu is called the 'main menu'. It defines the top level of the 'menu cascades' that end in a command execution. A 'menu cascade' is simply a path selected through a waterfall of pop-up menu's. As you negotiate a 'menu, sub-menus to each menu field pop up and disappear instantly. Executing a command is done by smoothly sliding the mouse along a menu cascade. With a some practice this can be done very quickly and with little thought or effort. Releasing RMOUSE within the final pane of a menu cascade causes the selected operation to be performed, or an interactive processing subsystem GUI to be activated. Performing complex image transformation operations becomes a series of smooth movements, analogous to brush strokes, rather than a complex selection process involving buttons, sliders, options boxes, etc. If you do not follow the menu cascade to its end, the main menu simply disappears until RMOUSE is pressed again. Partial traversal of a menu cascade has no effect whatsoever, so you can 'explore' the function space of REX using the menu. Just be sure to release the RMOUSE button outside the menu so the function will not execute. Some menu cascades can be quite deep, but they are MUCH faster and easier to negotiate than a Christmas tree display of panels of switches, buttons, cryptic symbol tables, etc. All paths through the main menu are fully defined. The possibility of making a 'wrong' main menu selection does not exist. It is possible to perform operations that are scientifically and mathematically meaningless, but such operations may be graphically (and esthetically) interesting. It is entirely up to the user to determine what constitutes a meaningful operation. REX does not second-guess any input with the exception of operations that request massive (1 GB+) blocks of memory. For these, REX may request a confirmation before proceeding. Any operation permitted by the computer hardware is permitted by REX. This is why the REX design mirrors computer imaging hardware design. There are no conceptual stovepipes. You can do spectacularly nonsensical things with no fear of crashing your computer. The toy-like nature of REX is deliberate. REX MAIN MENU FUNCTIONS REX contains over 100 operations that are accessed via a single cascading menu. Following is a list of top-level REX functions exactly as they are encountered, top-down, on the main REX menu. Each menu entry is given, along with its sub-menus. The sub-menus are below and offset from the menu above them that activated them in a descending heirarchy. FUNCTION TARGETS: GUNS AND IMAGE COLOR PLANES In REX, a displayed image, even a grayscale image, ALWAYS consists of 3 independent color planes. In following discussions, the term 'GUNS' refers to selecting the color planes that are the target of the function among Red, Green, Blue, or RGB (RED & GRN & BLU) color planes; i.e. 'GUNS' always expands to: RGB RED GRN BLU Thus, you may apply image transforms to all three planes of a color (or B&W) image, or selectively to a single color plane. The ALPHA plane is never modified by an image transform; it is treated separately as an overlay image, a Transparency encoder, or data buffer. There are operators to copy a color plane to the ALPHA plane, and to modify or erase the ALPHA plane. Use the image calculator 'iCALC' to use ALPHA for transparency operations. REX TOP-LEVEL MAIN FUNCTIONS When the right mouse button (RMOUSE) is pressed anywhere on the REX display, the top-level main menu will appear. The menu remains visible only for as long as the mouse button remains depressed.: REX --------- AOI OPS LUT OPS PIXEL OPS BUFF OPS DISP OPS PAN / ZOOM SAVE IMAGE CALCULATOR ANCILLARY ANNOTATE LOADER EXIT EXTENSIONS Beneath every entry in the main menu, a tree of sub-menus is defined, yielding a total of over 100 image processing functions. As you move the mouse over the main menu, the next level sub-menus are instantaneously displayed. This continues through level after level of sub-menus. If the menu is in 'fast mode' releasing RMOUSE will result in the menu disappearing. In 'sticky mode' the menu will remain displayed until a selection is made by clicking in the final pane of a cascading menu, or the menu is dismissed with a mouse click OUTSIDE the menu. Sticky mode is useful if you frequently wander the mouse cursor outside the menu tree, causing it to disappear. This can be annoying. Function: AOI OPS : AREA OF INTEREST (AOI) AND CURRENT 'STATISTICAL STATE' Areas of Interest are never larger than the Display. There are two primary areas of interest at all times; the FOREGROUND AOI (FG AOI) and the BACKGROUND AOI (BG AOI). There is also a 'LIMITS AOI' that is simply a cosmetic Display boundary. The default FG AOI is the boundary of the current 'image of interest' on the display. If the image is larger than the display, the FG AOI, BG AOI and LIMITS AOI define the same area. The FG AOI defines the area within which PIXEL OPERATIONS will occur and can be actively defined, changed or moved by the user. The FG AOI determines the 'CURRENT STATISTICAL STATE' of REX. Upon completion of a 'pixel operation', the contents of the current FG AOI are automatically scanned, and histograms tabulated. Thus, the FG AOI controls both the local scope of pixel transforms, as well as statistical sampling of the result. Any change to the boundaries or location of the FG AOI also causes a new statistical tabulation of the area it defines, enabling selective analysis of statistics over image regions. Note that Color Lookup Table operations (LUT OPS) are defined by, but have no effect on, the Current Statistical State. The BG AOI is the boundary of the mapped iBUFF on the display. If the iBUFF is larger than the display, the BG AOI will form a boundary at the display window edges, otherwise it will form a boundary to the portion of the buffer mapped to the display. The LIMITS AOI defines the Display window boundary. It is primarily cosmetic. Note that the FG AOI, BG AOI and LIMITS AOI may define the same area on the display. When this happens, the FG AOI is always on top, and the BG AOI is always above the LIMITS AOI. Note that any 'area of interest' delimiter contains no data or internal state other than its position and color. AOI OPS RESTORE GUNS DEFINE DRAW AOI RECTANGLE SQUARE VISIBLE BUFF FULL VIEW 512 X 512 256 X 256 COLS,ROWS MOVE DRAG SNAP SET DRAG PREVIOUS COMPOSITE LOCAL GUNS CLONE GUNS COPY/WARP UNSCALED GUNS DRAW DESTINATION GUNS X,Y SCALE FACTORS GUNS ACCUMULATORS CROP TO ACCUM '@1' ACCUM '@2' ACCUM '@3' ACCUM '@4' PASTE FROM ACCUM '@1' GUNS ACCUM '@2' GUNS ACCUM '@3' GUNS ACCUM '@4' GUNS STATUS ACCUM '@1' : ACCUM '@4' SET FG_AOI ACCUM '@1' : ACCUM '@4' RELEASE ACCUM '@1' : ACCUM '@4' ROTATE MIRROR FLIP ROTATE 90 ROTATE 180 ROTATE -90 ANGLE CLIPPED UNCLIPPED ANTI-ALIAS OFF ON CLEAR GUNS FILL Y X X & Y CORNERS OVERLAY DESTROY ASSIGN GUNS STATUS COLOR FG AOI BG AOI LIMITS WATERMARK ACCUM '@1' GUNS : ACCUM '@4' GUNS 'RESTORE' enables the user to undo changes made to the foreground area of interest (FG_AOI) by overwriting the FG_AOI with the contents of the image buffer in memory that map to the FG_AOI. If the Display is zoomed, the data will be automatically zoomed to fit. 'DEFINE' displays a submenu giving various options for defining the FG AOI. 'DRAW AOI' enables the user to draw the AOI interactively. Simple instructions for drawing the AOI boundary will appear on the display. 'RECTANGLE' draws an AOI of arbitrary rectangular shape. 'SQUARE' defines a perfectly square AOI centered on a selected point. 'VISIBLE BUFFER' makes the FG AOI the same as the BG AOI. 'FULL VIEW' makes the FG AOI as large as the LIMITS AOI. The 'COLS, ROWS' selection pops up a dialog asking for the dimensions of the desired FG AOI. The user then drags the box of the described dimensions to the desired location. Note that 'DEFINE' only defines the boundaries of an area on the display, it has no effect on their contents. 'MOVE' enables the user to drag an existing foreground AOI from one place on the Display to another without changing its dimensions. Only the boundary is moved, the FG AOI contents are unchanged. 'DRAG' simply drags the existing AOI from one place to another using the mouse. 'SNAP' causes the existing AOI to jump to a new position that perfectly joins the edge of the previous AOI. The mouse is used to select the bordering position of the new AOI. Finally, 'SET DRAG' enables you to specify the minimum position increment when dragging. Note that for zoomed images, the drag increment is the same as the zoom. 'PREVIOUS' replaces the boundaries of the current FG_AOI with the boundaries of a previous FG_AOI. Every time you define the FG_AOI, a copy is automatically written to the 'previous' buffer. REX remembers the boundaries of up to 8 previous FG_AOIs, then overwrites the oldest boundaries. Each execution of 'PREVIOUS' re-defines the FG_AOI boundaries to the next-oldest AOI, etc. eventually cycling back to the current AOI. Only the AOI boundaries are manipulated. If you change the size of the view screen, the buffer is emptied since the new view screen may be smaller than a saved FG_AOI. 'COMPOSITE' enables user to selectively overwrite contents of the mapped image buffer with the current displayed contents of the FG AOI. LOCAL overwrites the Local, or Current iBuff. CLONE overwrites the iBuff Clone (See: BUFF OPS | CROP | CLONE). GUNS enables the user to select the R,G,B colors that are to be overwritten. Once overwritten in the iBUFF, an area cannot be restored to its original state. Note: If transformed LUTS are active AND VISIBLE, the iBUFF will be overwritten with the image as transformed by the active transform LUTS. It is important that transformed LUTS are turned off (LUTS OPS | RESET) or not visible when 'AOI OPS' is activated if this effect is not intended. 'COPY/WARP' enables an AOI to be copied from one area of the screen to another. An 'UNSCALED' copy moves data from one part of the screen to another area of the same dimensions. The other three selections enable copying the data to an area of a different size and warping the data to fit the destination. Warping will use the current ZOOM/MODE setting. Finally, 'GUNS' enables the user to select which colors to copy. 'ACCUMULATORS' accesses functions specific to REX image data accumulators. 'CROP TO' causes the contents of the current FG AOI to be copied to one of four imagery accumulators; @1, @2, @3, @4. All 4 color guns are always copied. 'CROP TO' has no effect on the displayed image. Note that the four accumulators are available for manipulation in the image calculator (iCALC) subsystem, enabling a wide range of photographic manipulation effects. There is also a CROP operation under 'BUFF OPS' for cropping areas larger than the display. 'PASTE FR' causes the contents of an imagery accumulator to be pasted to user selectable locations. The size of the contents in the image accumulator determines the size of the overwritten area. A box of this size will appear, and the user drags it to the desired location and presses LMOUSE. This can be repeated as often as desired. RMOUSE exits the operation. 'GUNS' enables the user to select which color planes to paste. 'STATUS' displays whether an accumulator is active, and gives its dimensions. 'SET FG_AOI' matches the dimensions of the FG AOI to those of the selected accumulator. The iCALC subsystem requires that accumulators must be the same dimensions as the FG_AOI (or iBuffer) to be used as data planes. If accumulator footprint is larger than the Display, a warning is issued with no action. 'RELEASE' will release the contents of an accumulator and reclaim storage. This is relevant only if dealing with huge accumulators gigabytes in size that may impact system performance. All accumulators are released when REX terminates. 'ROTATE' causes the contents of the FG AOI to be rotated. The rotation operations are self explanatory. All rotation modes except 'ANGLE' are free of artifacts resulting from rotation. If 'ANGLE' is selected, a dialog box will pop up and allow an arbitrary angle to be typed in. 'CLIPPED' means that only the contents inside the FG AOI are considered, and black 'wedges' will appear, depending on the degree of rotation. 'UNCLIPPED' attempts to rotate a sufficient area outside the FG AOI that no 'wedges' appear in the result within the FG AOI. REX uses the fastest rotation algorithm known, that uses 3 image shearing operations instead of many individual point math computations. Note that data values of a rotated buffer have been interpolated to eleminate aliasing, so subtle statistical information may be lost. You may turn anti-aliasing off by selecting ANTI-ALIASING. 'CLEAR' causes the contents of an area to be set to zero on the display. The user may selectively clear R,G or B color planes. The data in the underlying iBUFF is not lost, and a cleared area can be easily restored. 'FILL' merges the top/bottom, left/right or corners of a defined area using bilinear interpolation. This function is useful for filling voids in an image caused by scanline dropouts, noise, etc. You can also make interesting designs by joining the corners of random sized boxes in a random number field, etc. 'OVERLAY' enables the user to transfer contents of a color plane to the overlay plane, or to destroy the contents of the overlay plane. If 'CLEAR' is selected, the area in the overlay plane that maps to the current FG AOI is erased and the overlay data is lost. If 'ASSIGN' is selected, the user may selectively copy the contents of an individual color plane to the overlay plane. Note that the overlay plane is displayed as pseudocolor, so a single color plane will appear in the overlay as a multi-hued pseudocolor image determined by the overlay color lookup table (LUT). You enable/disable overlay display under the 'BUFF OPS' menu. 'STATUS' simply displays the current dimensions of the FG AOI, and its corner coordinates within the underlying iBUFF in memory. 'COLOR' enables you to change the color of the 'area of interest' boundaries. 'FG AOI' changes the color of the boundary box defining all pixel operations and histogram statistics. 'BG AOI' changes the color of the box delimiting the edges of the iBUFF in the display. 'LIMITS' changes the color of the limits of the display. A menu of colors will pop up and you make a selection. If you click RMOUSE, or click outside the menu, the selection is ignored. 'WATERMARK' is used to merge the contents of an Accumulator with an iBUFF area as a translucent overlay. The original image is visible through the Watermark. This may be done for artistic purposes, or to flag Copyrighted material at full resolution for review prior to sale. The User selects the Accumulator containing the Watermark, and the color bands to be active. The ANNOTATE utility is useful for creating Watermark content, or the Watermark may be an image file. Text should have a BLACK [zero] background. Once activated, the Watermark is written at the current mouse position with every LMOUSE button click. Click RMOUSE to exit. See also 'Transparency' under the CALCULATOR utility. Function: COLOR LOOKUP TABLE (LUT) OPERATIONS The image on the Display is determined not only by the state of the data in the underlaying Display buffer, but also by the state of the Display color lookup tables (LUTs). The values in the Display buffer serve as indexes into the display LUTs. It is the LUTs that determine actual colors rendered on the Display. For a LINEAR LUT (Default), the Display value equals the image value. Transformed LUTs remain active until the user explicitly resets the LUT via the 'LUT OPS / RESET' operation. A LUT that remains active after being 'burned- in' the iBUFF or area on the Display can be confusing if not reset. This protocol is used because a single LUT may be 'burned in' to selected areas, and this is difficult to do if the LUT is reset after each operation. LUT operations are defined by the 'Current Statistical State' as computed from the FG AOI. LUT operations DO NOT alter the Current Statistical State. Only Pixel Operations cause the Current Statistical State to be recomputed. LUT operations have no effect on the mapped iBUFF. They are instantly reversible, and may be rapidly flicked ACTIVE or NOT-ACTIVE by clicking the MIDDLEMOUSE button. LUT operations also effect the entire display indiscriminately and are NOT confined to the FG AOI. There are two sets of LUTs; the 'DEFAULT LUTs' and the 'TRANSFORM LUTs'. Each set contains 3 LUTs, one for RED, one for GREEN and one for BLUE. LUTs are manipulated independently of one another. The overlay or 'ALPHA' buffer has its own pseudocolor RGB LUTs that are manipulated under 'BUFF OPS/OVERLAY/EDIT'. Default LUTs define a linear progression from 0 to 255 for normal viewing. In reality, they are defined by the Display 'Gamma function', described below. Transform LUTs take on any value from 0-255 at any offset, usually according to a mathematical function applied to the current image statistical state. LUT operations have no spatial component; they are applied to each color/pixel independently of the state of any other color or pixel. LUT operations are instantaneous. The ability to manipulate the RGB color LUTs of a 24 bit display is known as DIRECTCOLOR. REX emulation of DIRECTCOLOR in software eleminates the need for expensive video hardware that supported this function in the past. The LUT OPERATIONS selection enables a user to define LUT transformations on an image, and to restore the LUTs to their original state. All LUT transforms may be toggled ON/OFF via MIDDLEMOUSE. Again, LUT operations are instantaneous. NOTE: REX is a 'What You See Is What You Get' system. If Transform LUTs are ACTIVE when you perform a non-LUT operation, then LUT values will be 'burned-in' before the operation is performed. If you do not want this behavior, then you reset the LUTs using 'LUT OPS | RESET' first. You can always revert a changed display to an earlier state using RESTORE from either 'DISPLAY OPS' or 'AOI OPS'. You can also re-activate a reset LUT via the 'PREVIOUS' function below. REX retains the previous 8 Transform LUTs that you can cycle through. NOTE: The CYCLE and INVERT functions will be performed on the existing state of the LUT, rather than a LINEARIZED LUT. You must first RESET the LUT if this behavior is not desired. LUT OPS RESET GUNS PREV EQUALIZE GUNS HDR MODE LOCAL GUNS GLOBAL GUNS HISTOGRAM STRETCH GUNS HISTOGRAM SPECIFY GUNS COMB 16 GUNS 8 GUNS 4 GUNS 2 GUNS INFOMETRIC ENTROPY GUNS ABSOLUTE REDUNDANCY GUNS RELATIVE REDUNDANCY GUNS CYCLE ROTATE GUNS SHIFT GUNS INVERT GUNS PREVIOUS - + ZERO GUNS INPUT/OUTPUT READ WRITE SET PATH 'RESET' causes the selected LUT to be LINEARIZED to the DEFAULT state. You may independently reset the RED, GRN or BLU luts. If 'PREV' is selected, the buffer of 8 PREVIOUS LUTS is emptied. 'HISTOGRAM EQUALIZE' performs a histogram equalization transform on the selected color gun(s) using the current histogram. Histogram equalization is a powerful image contrast enhancement technique. 'HDR MODE' stretches RGB LUTs using the same scaling modes used by the HDR scaling system (see: BUFF OPS|sBUFF|SCALING|MODE). LOCAL scaling stretches each histogram independently based upon its LOW and HIGH values. GLOBAL uses the lowest and highest value across all three RGB histograms to determine scaling range. This enables you go get a feel for HDR scaling options on non-HDR images. Note: Selecting different HDR scaling modes for LUT scaling DOES NOT modify the the state of REX scaling subsystem. 'HISTOGRAM STRETCH' activates an interactive subsystem for transforming LUTs by means of directly manipulating the displayed image histogram. A histogram is interpreted as a linear progression from 0 to 255, representing pixel counts for each intensity level. This linear progression is depicted as a straight line from the lower left to the upper right of the displayed histogram. The histogram can be manipulated by using the mouse to interactively specify alternate progressions rather than the linear one. This causes more pixel counts to be placed in some bins than in others, causing the histogram to be stretched, shifted or compressed. The LUT is modified to compress certain portions of the image range, and expand other portions of the range, enhancing contrast within that range. This enables specific ranges of intensity values to be enhanced at the expense of suppressing other ranges. This is a powerful utility best understood by experimenting with it. Basically, you can selectively stretch, compress, shift and ignore different regions of the histogram and view the corresponding image instantly without actually changing anything. 'HISTOGRAM SPECIFY' activates an interactive subsystem for specifying a desired histogram shape. The utility will then effect a transform that will make a 'best possible fit' of the current state of the histogram to the desired state. The desired histogram is specified by interactively drawing its shape directly over the displayed histogram. The transformed histogram will not exactly fit the specified histogram; it is a 'best mathematical fit' to the desired state. Again, experimentation is the best way to understand its capabilities. Knowledgable users will find this a powerful tool for specialized applications. 'COMB' causes a LUT to cycle through its entire 0 - 255 range multiple times from low -> high, rather than a single time, while never repeating a value. In other words, it 'shuffles' the LUT. The 'shuffle' value may be 16, 8, 4 or 2. This is useful mainly for very low contrast areas where it is used to 'comb' a seemingly homogeneous area for extremely subtle features. 'COMB' will turn 'busy' areas into incoherent clutter. NOTE: COMB uses the current state of the transform LUTs. Use 'RESET' if this behavior is not desird. Fractal visualization also uses COMB internally. 'INFOMETRIC' creates LUTs that convey visualizations of the information metrics of color planes, as defined in the branch of mathematics known as 'Information Theory'. 'ENTROPY' converts each intensity value into a representation of the amount of information that intensity value contributes to the total information content of that color, based on probability of occurrence. 'REDUNDANCY' yields a transform that represents the extent to which the information at each point is determined by all the OTHER points of a color. There are two ways of calculating redundancy; both are given. The RGB color planes are treated as independent images and intercorrelations between color planes are ignored in the LUT implementation (see PIXEL OPS). The 'INFOMETRIC' transforms are extremely powerful tools for revealing hidden structures in complex phenomena. They convert images into pure visualizations of their underlying 'information architecture', as mathematically defined. Information Theory has a rich scientific literature in multiple disciplines spanning decades. 'CYCLE' rotates or shifts the current state of the transform LUTs, using the mouse scroll wheel. You can also rotate the LUTs by repeatedly clicking the Left or Middle mouse buttons. There are two modes; Rotate and Shift. 'Rotate' moves the highest LUT value to the lowest or lowest LUT value to highest; depending on direction of rotation. 'Shift' simply zeros cycled LUT values and does not recover them. On exit, LUTs remain in the cycled state. NOTE: CYCLE uses the current state of the transform LUTs. 'INVERT' flips a LUT by computing (L=255-L) for every LUT value. It is directly analogous to converting an image into its photographic negative; i.e. bright areas become dark, dark become light. Note that the current state of the Transform LUT (NOT the Default LUT) is inverted. For example, you may invert an equalized LUT, entropy LUT, etc. 'RESET LUT' first to 'INVERT' using the Default LUT. NOTE: INVERT uses the current state of the transform LUTs. 'PREVIOUS' activates a previous transform LUT. Every time a new transform LUT is defined it is automatically written into the LUT archive. Up to 8 LUTs may be in the archive, after which the oldest LUT is overwritten by newer LUTs. Selecting (-) 'minus' activates older LUTs. Selecting (+) 'plus' activates newer LUTs. Either direction cycles to the beginning. 'ZERO' does just what it says; it sets all the values of a LUT to zero. It is a way to 'turn off' a color plane without erasing the actual pixels. It is a trivial transform, but might be useful under some circumstances. 'INPUT/OUTPUT' permits you to read color lookup tables stored externally as text files rather than computed 'on the fly'. This is useful when utilizing standardized enhancement operators defined externally. Similarly, you may store the current state of the REX color lookup tables by writing them as textual (human readable) information in a text file. Since the saved LUTs are written as text, you may examine/modify them using a text editor. The format for the LUT file is: # comments are indicated by a '#' in the leftmost column # the first non-comment line flags start of the named LUT # NAME='text' # flags LUT name for searches. No other text is allowed. 000 000 000 --R,G,B displayed values for R,G,B intensity level zero 000 000 000 : 000 000 000 --R,G,B displayed values for R,G,B intensity level 255 --Missing entries set zero. Entries > 255 ignored EOF # flags the End Of File. Do not omit this tag Note that LUTS are always read/written as integer triads, with values 0 - 255. The LUT file should always have the file extension *.lut'. Function: PIXEL OPERATIONS In contrast to LUT Operations, 'PIXEL OPERATIONS' perform transforms that actually change the values in the Display buffer, and recompute the 'Current Statistical State' from the FG AOI. The SCOPE of Pixel Operations is normally the FG AOI, but may be set to GLOBAL and transform the entire iBUFF in memory, no matter how huge. WARNING: DO NOT PERFORM GLOBAL PIXEL OPERATIONS ON HUGE BUFFERS IF THE DISPLAY IS SET TO FULL SCREEN. It will lock the screen and make the computer unusable until the operation terminates. Minimize the REX display, activate the function, then perform other tasks while REX runs in the background. Unlike LUT Operations, Pixel Operations are irreversible. They may, however, be undone by using the 'AOI OPS/RESTORE' operation. Included are some extremely complex functions that have deep scientific and mathematical backgrounds with extensive technical literature. It is beyond the scope of this user's guide to go into any depth regarding the theory and application of some of the advanced techniques presented here. Knowledgable users will find these tools mathe- matically accurate and very fast. Lack of such knowledge should not discourage you from playing with them. Intuition and experience often exceeds theoretical knowledge as an avenue to effectively utilizing a new technique. A child who knows nothing of vibration theory, harmonics, FFTs, number theory of tones, etc, may play the violin beautifully, while scientists with advanced knowledge in these fields cannot play a simple tune. NOTE: If Transform LUTs are active, AND VISIBLE, they will be 'burned in' prior to computing a Pixel Operation. It Transform LUTs are not visible, they are ignored. Remember, REX is a 'what you see is what you get' system. PIXEL OPS SET SCOPE FG AOI GLOBAL ONCE REPEAT STATUS B & W GUNS BURN IN LUTS GUNS PSEUDOCOLOR NORMAL LEVELS GUNS COMB CYCLES GUNS INFOMETRIC ENTROPY ABS. REDUNDANCY REL. REDUNDANCY CONVOLUTION USER SHARPEN LOW/MED/HI GUNS LAPLACIAN LOW/MED/HI GUNSS GAUSSIAN LOW/MED/HI GUNS POSTERIZE X/Y/DIAG LOW/MED/HI GUNS SOBEL MAGNITUDE/PHASE LOW/MED/HI GUNS MEXICAN HAT GUNS LAPofGAUSS GUNS MEDIAN LOW/MED/HI GUNS SWAP GUNS RED <-> GRN RED <-> BLU BLU <-> GRN WAVELET DAUBECHIES SYMMETRIC HAAR BATH BIORTHOGONAL FBI ENTROPY BIORTHOGONAL LEVEL // submenu to all wavelets above... HH|HL|LH|LL GUNS PATH GUNS USER MEAN CURVATURE DIFFUSION PLANE ITERATIONS GUNS EDGE ITERATIONS GUNS FFT FORWARD GUNS INVERSE SET FFT ORIGIN CENTER DEFAULT SCALING 1 / SQRT(X * Y) 1 / (X * Y) CANNY RUN EDGE GUNS LAPLACE GUNS ORIENT GUNS SET SIGMA K DEFAULT STATUS ADAPTIVE RUN SET SCALE ITERATIONS MODE COEFF.VAR DEFAULT STATUS FRACTAL RUN MANDELBROT JULIA : SIERPINSKI -PREVIOUS- SET ITER AREA LUT CYCLE CX/CY RANDOM 'SET SCOPE' manages the multi-scalar exploitation capabilities of REX by defining the scope of all PIXEL OPS. The scope may be either the FG AOI area on the screen (LOCAL SCOPE), or the entire iBUFF (GLOBAL SCOPE). This enables you to perform transforms on huge images of many Mb, or even Gb, without having to resort to tiling or separate batch jobs. Note that for GLOBAL SCOPE, the original image state is not recoverable except by re-loading the image file. You may specify that GLOBAL SCOPE persist once, or until reset. NOTE: On huge iBUFFs, GLOBAL SCOPE operations can take a very long time to complete. REX does not allow GLOBAL SCOPE operations when 'Full-Screen Display' is active, since it will lock the screen until the transform completes. Display mode control is in the Loader GUI under 'DISPLAY'. The standard way to run a GLOBAL operation is to use the PAN operator to fit a Global View of the entire iBUFF to the Display FG_AOI. Then exit PAN and perform a LOCAL SCOPE pixel operation on the FG_AOI until the result is as desired. Then set the SCOPE operator to GLOBAL SCOPE, and repeat the operation. The Global View on the Display will update automatically when it completes. You can also perform GLOBAL SCOPE operations in the iCALC Image Calculator system. You will greatly improve performance of a GLOBAL SCOPE operation if you disable write access to sBUFF. Otherwise, sBUFF will be updated with the HDR results of the transform, which is SIGNIFICANT processing overhead. See: 'BUFF OPS | SBUFF | ACTIVE | OFF' 'STATUS' simply pops up a panel advising the current state of the GLOBAL SCOPE operator. 'B & W' copys the contents of the color plane selected by 'GUN' to the other two color planes. The effect is to view a single color plane as a black and white image. If 'RGB' is selected, all three colors are used to compute a B&W image that most closely approximates the color image according to one of two widely accepted 'color to B&W' algorithms. 'BURN IN LUTS' does exactly what it says. It converts the actual pixel values to match the contents of the transform color lookup tables (LUTS); i.e it 'burns in' the LUT values. The LUTs are then restored to their Default State. 'PSEUDO' converts the contents of the selected color plane to a pseudocolored image using the pseudocolor palette. As with 'B & W', the contents of the other two planes are overwritten. 'GUN' selects the plane to be pseudocolored. 'COMB' causes the entire pseudocolor spectrum to be cycled by the specified number of cycles from lo -> hi. Similarly, 'SEGMENT' selects the number of PSEUDO levels. '~INFOMETRIC' converts the three RGB image bands into a grayscale image representing a visualization of the 'Information Architecture' of the bands based upon the mathematics of Information Theory. These Information Theoretical metrics of information are known as the Entropy and Redundancy. Unlike 'LUT OPS/INFOMETRICS' that compute the 'self-information' of each individual color band, and result in an enhanced color image, this transform computes the metric using the 3 RGB bands (or 4, if Alpha is included), and results in a grayscale image. There is a deep and extensive literature on Information Theory and it's applications to various disciplines. Future versions of REX will expand the metrics offered in this rich field. 'INFOMETRIC' populates the Scaling Buffer, if it is enabled. 'CONVOLUTION' provides access to powerful image convolution operators. Most of the information in an image consists of discontinuities between areas. A convolution is a spatial operator that selectively enhances spatial discontin- uities in an image; such as gradients and edges. Convolution is also used to selectively 'thin' lines in scanned line drawings, and to eleminate noise. REX provides pre-defined convolutions, as well as an interface for importing convolutions from other sources, or creating new ones. Included convolutions include 'GAUSSIAN', a smoothing operator, used to 'smear' imagery in a very controlled manner. 'LAPLACIAN' depicts the first derivative, or areas of rapid spatial change in an image. 'SHARPEN' sharpens an image by applying the LAPLACIAN operator, and adding the result to the original image. 'POSTERIZE' reduces the number of gray levels of an image, making regions more uniform while dramatically enhancing edges. The 'SOBEL' operator is another edge detection operator that gives extensive information about gradients in the image. 'MEXICAN HAT' is another commonly used convolution filter for visualizing spatial gradients. 'LoG' applies a 'Laplacian of Gaussian' operator, that is yet another simple edge detector. 'MEDIAN' is useful for removing 'speckle' noise from imagery. Finally, 'USER' activates a sub-process with its own GUI environment dedicated to processing convolutions defined interactively (or off-line) by the USER. Knowledgable users will find this an extremely powerful tool. See the 'Appendix B' for the Convolution User's Guide. 'SWAP GUNS' causes the contents of image color planes within the FG AOI to be swapped. This is an actual swap, with data from each plane overwriting the original contents. The Color Lookup Tables are not swapped. Running 'SWAP GUNS' twice using the same selection restores the image to its original state. Some image formats store RGB color images as BGR; swap the Red and Blue color planes to display the image properly. '~WAVELET' provides access to an extremely powerful methodology for visualizing image information at multiple spatial scales simultaneously. Each class of wavelets is defined by the coefficients derived from a so-called 'basis function' or 'mother wavelet'. Several are provided, including the function used by the FBI for fingerprint compression. Basis functions have different 'resolutions' determined by the number of coefficients in their filter. These are selectable. An extensive literature on wavelets exists, and knowledgable users will find these utilities possess functionality comparable to products costing hundreds of dollars. Knowledge of this advanced technology is not required to experiment with Wavelets. Artists in particular may be attracted to the myriads of beautiful, fractal-like 'bas-relief' sculptural patterns characteristic of certain wavelet transformations. Wavelets, used in conjunction with INFOMETRICS yield very interesting information regarding the spatial information architecture of imagery. Computing wavelets on segmented random number fields can yield limitless, fascinating textures of interest to graphic artists. 'WAVELET' populates the Scaling Buffer, if it is enabled. Wavelets dissect an image by passing the image through 'high pass' and 'low pass' filters at different scales. The filters are applied against the image X dimension, and Y dimension for each scale. For example, using a high pass filter against both X and Y dimensions is expressed as HH, a high pass X, and low pass Y filter is expressed as HL, etc. REX uses only Continuous wavelets. These are like discrete wavelets, except that the spatial scale of the image is not changed. An image is filtered based upon the above scheme, with the exception that only the final filtered result is viewed at full resolution. REX is unique in allowing the user to specify the path to take through the 'wavelet packet' by specifying the sequence of filters to use. For example, the user could specify: LL LL HL LH HH LL resulting in a unique path through the wavelet packet. Wavelets are a DEEP and highly mathematical subject. Some wavelets cause an image to shift relative to its original state, but REX does not support these. REX supports so-called bi-orthogonal wavelets that do not distort the result relative to the original image. Although REX supports several wavelet 'basis functions', users may want to display wavelets based on other functions. Selecting 'USER' will cause REX to solicit a filename containing user defined wavelet coefficients. The coefficients for a user defined wavelet will be read from an ASCII file that must be in following format: # # Comment block describing wavelet coefficients # {wavelet tag} # textual tag associated with a wavelet NCOFS= 12 # the number of wavelet coefficients. Any number. 0.0 0.0 0.0 0.0 0.0 # Wavelet coefficients will be read and parsed until 0.0 0.0 0.0 0.0 0.0 # 'NCOFS' coefficients have been read 0.0 0.0 {next wavelet tag} # next wavelet definition NCOFS= : '~MCD' or 'Mean Curvature Diffusion' is an advanced data smoothing / noise reduction technique based upon the PhD dissertation 'Inhomogeneous Geometric Diffusions' by A.I. El-Fallah, University of California; Davis, 1995. It is useful for removing noise and spatially segmenting regions of similar information. It also has an edge detection option similar to 'CANNY'. Results are returned as a single band image in the color gun selected. 'ITERATIONS' specifies how many iterations to compute the transform before terminating. The more iterations, the more intense the transform, and the longer the processing time involved. For high iterations, this transform can take a long time for large images. 'MCD' populates the Scaling Buffer, if it is enabled. '~FFT' indicates 'Fast Fourier Transform'. This is a powerful methodology with a deep theoretical background for visualizing the spatial interrelationships and periodic structures of imagery. The resulting visualization is the 'power spectrum' of the image. These visualizations are of use to trained researchers with the knowledge to interpret them. Drawing multi-colored, angular compositions with the annotation utility, then performing FFT often results in kaleidoscopic, fractal-like compositions of great beauty and complexity. As with wavelets, theoretical knowledge of the Fourier Transform is unnecessary to experiment with it or enjoy the beauty of the results. For those with the knowledge to interpret the results of this transform, it is a powerful visualization tool. FFT populates the Scaling Buffer, if it is enabled. Note that the inverse of the FFT is supported. See Appendix C: FOURIER TRANSFORM for more information. REX uses the same FFT source code as the Space Telescope Science Institute. 'CANNY' is a very powerful edge detector, based on the work of John F. Canny of MIT. For a detailed discussion of the theory behind this complex operator, see 'A Computational Approach to Edge Detection.', IEEE Transactions on Pattern Analysis and Machine Intelligence. Vol. 8 No 6 Nov. 1986. Canny computes 3 channels of information, and the REX implementation allows you to select output from the EDGE operator, the LAPLACIAN operator or the ORIENTATION operator for analysis. The CANNY operator takes two main parameters as input: 'Sigma' and 'K'. These values define a gaussian filter, a derivative filter and a second derivative filter that are used to compute the 3 output channels. You can specify Sigma as an absolute numeric value, or as the diameter of the Gaussian convolution kernel desired. You can experiment 'Sigma' and 'K', as long as they are within the range defined by the function. A 'Thin' flag will also make edges sharper if set. Defaults are provided. For more detailed study, refer to the original paper, or the dozens of studies on this approach. Computing the ABSOLUTE REDUNDANCY or RELATIVE REDUNDANCY of a Canny edge result provides a striking visualization of the discontinuities of an image and reveals much invisible structure. 'ADAPTIVE' is an adaptive enhancement algorithm that optimizes high contrast image display. The classic example is an image of someone in a room standing in front of a bright window. Typically, the window is oveREXposed (too bright), and the person is undeREXposed (too dark). To the limits of the data that is available in the image, the ADAPTIVE transform will darken the bright areas, and lighten the dark areas to approximate the adaptation that occurrs at the retinal level in the human visual system. There are numerous adaptive algorithms, particularly in the area of optimizing display of HDR imagery. The REX Adaptive algorithm works only for 8 bit images, but could be adapted for HDR. 'FRACTAL' activates the -very fast- REX fractal exploration subsystem. Yes, this is a toy for children and artists. You can view and zoom into fractal images to the limits of precision of 64 bit floating point math. You may then save the images or use them in compositions with other imagery. Once a fractal image has been computed you press RMOUSE to bring up a menu that offers ZOOM, BACK, LUT and CX/CY selections. ZOOM allows you to select the magnification of the next image, BACK recomputes the previous image, LUT increases the contrast of the color lookup table and CX/CY allows you to dynamically re-define parameters for fractals that use these constants. You zoom into the fractal by pressing LMOUSE and locating the zoom rectangle over the area of interest. Click LMOUSE again and the area within the rectangle will be computed to fill the screen. You repeat this as long as you like. Exit FRACTAL by pressing RMOUSE and making no selection. A popup then appears listing the parameterization of the fractal on the screen so it may be re-computed later. You may alter several parameters used in the computation of the fractals, such as the number of interations and the 'termination value'. This enables a great deal of flexibility in exploring these fascinating constructs. The REX fractal explorer is arguably one of the fastest fractal explorers available. One particularly useful trick for FRACTAL is to zoom in on an area of interest, then set 'PIXEL OPS/SCOPE' to GLOBAL and compute the '--PREVIOUS--' fractal. Then, it will compute the previous fractal, but fit it to the entire iBUFF instead of to the FG AOI. If the image buffer is huge, you get a very detailed (and very large) fractal image to play with and explore. (See 'BUFF OPS/iBUFF/CREATE' ). Fire up the fractal utility before going to bed on a 20K X 20K iBUFF and explore the resulting complex image the next day! The fractal utility serves as a reference against which naturally occurring fractals may be compared. Note that fractals are displayed as PSEUDOCOLOR and that the OVERLAY LUT is used to define the appearance of the fractals. Redefining the OVERLAY LUT will redefine the visual appearance of fractal display. Search the web for unique LUT files... 'RANDOM' randomizes the current FG AOI by simply reading it, encrypting it and writing the encrypted result back to the display. This function is, basically, an encryption visualization and is very useful for applications requiring an area containing pixels with pure random values. Many fascinating textures and interesting graphics effects can be explored by segmenting a random field using the iCALC subsystem, then subjecting the result to wavelet or convolution operators. The display of RANDOM is what would be written to an uncompressed, encrypted file, and enables you to view the actual encrypted state of an image. It is interesting that a deeply encrypted file, a highly compressed file, and a file of random numbers, are indistinguishable. Function: BUFFER OPERATIONS 'Buffer Operations' contains sub-menus that perform functions impacting the entire contents of an Image Buffer (iBUFFER), or the contents of the Scaling Buffer (sBUFFER). There are 16 selectable iBUFFs, and two scaling buffers. Image buffers are directly displayable however, since the sBUFFER consists of 32 bit floating point numbers, it can only be displayed via a scaling operation. Similarly, although an iBUFF may contain an unlimited number of images, the Scaling Buffer may contain only a single image, although it may have up to 8 bands. BUFF OPS iBUFFER sBUFFER BUFFER OPERATIONS: IMAGE BUFFER (iBUFFER and sBUFFER) This operator manages iBUFFs. Management of both RGB24 (iBUFF) and HDR Scaling (sBUFF) buffers is accomplished here. 'BUFF OPS | iBUFF' enables you to select the RGB24 buffer that is to be viewed and provides utilities that enable you to precisely manage the movement and manipulation of massive blocks of image data many times the size of a display. They also include powerful operators for tiling buffers in huge, high resolution wall or poster size datasets. The sBUFF menu is found in the section following this one. The iBUFF sub-menu is: BUFF OPS iBUFFER SELECT iBUFF iBUFF 1-4 iBUFF 5-8 iBUFF 9-12 iBUFF 13-16 // shorthand for above 4 lines is .iBuffers IMAGE SELECT STATUS DELETE RENAME OVERLAY CLEAR REDRAW EDIT LUT READ LUT RESET LUT ASSIGN GUNS ENABLE DISABLE DESTROY ROTATE MIRROR FLIP ROT 90 ROT 180 ROT -90 ROT 'angle' ANTI-ALIAS OFF ON ALIGN GUNS ANGLE CROP CLONE DRAW BOX FG_AOI DISP .iBuffers // select ibuffer 1 - 16 .accumulators // select accumulator @1 - @4 CREATE .iBuffers // select ibuffer 1 - 16 JOIN LEFT .iBuffers RIGHT .iBuffers ABOVE .iBuffers BELOW .iBuffers RESIZE SCALE X,Y STATUS .iBuffers LOAD TO .iBuffers SWAP .iBuffers DESTROY SELECT .iBuffers ALL HERE > < HERE sBUFF // see next section : 'SELECT' selects a different iBUFF to exploit. REX supports up to 16 independent iBUFFs, each of which may contain any number of selectable images. When you select a buffer, it becomes the target buffer for the image Loader where new images will be loaded (unless you change the target with 'LOAD TO'). 'IMAGE' manages images in the current iBUFF. 'SELECT' selects the 'image of interest' in the current iBUFF. The Display will center on this image and scaling, calibration and geo-astro-locational information in the ancillary display will be defined by this image. 'STATUS' will display the file path and characteristics of the 'current image of interest'. 'DELETE' will delete the 'image of interest' from the file system, after querying for a 'Y/N' confirmation. 'RENAME' will solicit a new name for the 'image of interest'. Entering a blank return will cancel the operation. 'OVERLAY' manages buffer-scope manipulation of the ALPHA / Overlay planes. 'REDRAW' turns on automatic overlay display if overlays are enabled. 'CLEAR' turns off automatic overlay display and restores obscured image contents. 'EDIT LUT' enables the user to interactively redefine the color of individual overlay planes, or render selected overlay planes transparent. 'READ LUT' enables the user to define the overlay colors from a text LUT file containing 256 colors defined as R,G,B triads coded as 3 numbers in the range 0-255. The first LUT entry must be '0,0,0',reserved for transparent, otherwise the LUT file format is identical to that for image transform luts. Note that even though the LUT file formats are identical, the values are used differently. 'RESET LUT' will cause the overlay LUT to reset to the REX default overlay colors. 'ASSIGN' writes the contents of a R,G,B color plane to the overlay plane for an entire iBUFF. 'ENABLE' enables overlay display, if ALPHA data exists. 'DISABLE' disables overlay display, but does not alter the ALPHA data. 'DESTROY' destroys the Alpha image layer in the iBUFF. 'ROTATE' rotates an entire iBUFF as a single unit. REX uses the fastest rotation algorithm known, based upon 3 'shearing' operations applied to an image. Note that if the rotation performed is not an even multiple of 90 degrees data has been interpolated to eliminate aliasing, and high-frequency (edge) information is lost. Interpolation can be turned off by selecting 'ANTI- ALIAS'. You should not perform more than a single 'interpolating' rotation on a buffer, since each rotation loses information through interpolation or aliasing and the image will become blurred. For rotations evenly divisible by 90 degrees, rotation is fully reversible with no loss of information. ROTATE disables internal image tracking for buffers containing multiple images. This is because rotation makes management of internal image coordinates impractical. Also note that ROTATE applied to GigaPixel images MAY TAKE A LONG TIME and takes A LOT OF MEMORY. NOTE: ROTATE can be used with Interpolation ON, that blurs jagged edges known as 'aliasing', or Interpolation OFF, that preserves original data values. ROTATE must be used with care on very large images, since no clipping is performed and the iBUFF is expanded to be large enough to contain the entire rotated buffer. 'ALIGN' enables an individual color bitplane to be shifted in the X,Y dimensions relative to the other color planes. The ALPHA plane may also be shifted. If the ALPHA plane is shifted, this shifts image Geo-Astro Navigation; even if there is no image ALPHA plane. ALIGN is useful for fine-tuning registration between color planes loaded as separate images, or with graphical overlays, such as maps. A sub- menu appears in which the user selects a point on the image, then the desired location of the same point on the shifted image. The shift is then performed. The user must shift the color bitplanes individually. The shift will destroy data that is shifted 'outside' the original boundaries of the buffer. To shift the position of an image on the Display as a unit, see 'DISPLAY/SHIFT'. You can undo a shift by looking at the coordinates of Shifted state, and entering their negative on the keyboard. 'RECTIF' returns the precise Angle and Distance between two points on an image. It is used prior to ALIGN to provide parameters to the ROTATE and RESIZE apps that support creation of multi-band composite images from input that may be Rotated or at a different scale to the baseline input. REX does not support image rectification beyond resizing, rotating and shifting; but it does these with great accuracy. NOTE: If the Ancillary Display is ON, ALIGN and RECTIF may use the Zoom window for precise positioning. Simply press and hold LMOUSE while moving it, then release at the precise position. The point is recorded upon release. NOTE: Precision may be greatly increased by using REPLICATE zoom mode. This makes position selection much more accurate. REX automatically compensates zoom, so that clicking anywhere within a large pixel yields the center coordinate. 'CROP' enables you to copy an area in an iBUFF to a new iBUFF, or to an image accumulator. You may also CLONE the FULL iBUFF. You can DRAW the crop area, define a crop area BOX of specific dimensions, crop the FG_AOI on the display, or crop the full DISPLAY. By cropping large areas to an accumulator, you may perform image transformations and merges using the REX 'CALCULATOR' utility. CROP is analogous to the same operation under 'AOI OPS' except the crop area is not confined to the Display area. NOTE: You cannot CROP to an existing buffer. CROP creates a new buffer that is exactly the same dimensions as the Cropped area. Use JOIN to merge contents of multiple iBUFFs. Use CALCULATOR in GLOBAL mode to merge individual bands of an accumulator into an iBUFF. 'CREATE' enables you to create an empty iBUFF by defining its dimensions. This is useful for purely creative work. NOTE: REX will decline to create an iBuff that will draw down your virtual memory (RAM + Swap) to an unstable state. 'JOIN' enables you to seamlessly join iBUFFs edge-to-edge. This is very useful. By using 'iBUFFER/ROTATE/MIRROR' (or FLIP) you can join buffers into symmetrical wallpaper images and explore various kinds of image symmetry at unlimited scale and resolution. Like textures, symmetries can become very complex and REX is an ideal research / exploration tool. JOIN stitches the current iBUFF to a selected iBUFF along an edge. Note that to join a buffer ABOVE or BELOW the current buffer, it must have the same number of COLUMNS. To join a buffer to LEFT or RIGHT of the current buffer, it must have the same number of ROWS. Upon completion of JOIN, the current buffer has been joined as directed to the selected buffer and will be much larger. The current iBUFF will also inherit the images of both buffers. Neither buffer of a 'join' is deleted, so it is up to the user to destroy buffers no longer needed. If 'join' fails because 2 buffers have incompatible dimensions, use 'resize' defining the desired X,Y dimensions. JOIN voids STATIC and CLONE iBuff modes. 'RESIZE' enables you to change the dimensions of an existing iBUFF. You may warp to a new size via X and Y scaling factors, or simply define the desired columns and rows of the new buffer. The data within the existing buffer will be warped along with the buffer dimensions. Scaling factors greater than 1.0 will increase the size of the buffer using the current ZOOM mode. Factors less than 1.0 will shrink it using Bi-Linear averaging. This is operation is useful to make buffers compatible for a JOIN operation. NOTE: Scaling factors are applied to the X and Y dimensions. The actual MEMORY to host the changed dimensions will be the SQUARE of the difference; i.e. if you DOUBLE the size of an image, its memory footprint grows by FOUR times! REX will decline to warp a buffer to a size that will draw down virtual memory resources to an unstable level. It will issue an error message and ignore the operation request. RESIZE and JOIN disable internal image tracking beyond calibration. This is because modifying dimensions of buffers makes image navigation undefined. RESIZE ignores the ALPHA (Overlay) channel, which will be all zeros in the resized iBUFF. To resize ALPHA, convert it to a B&W image, resize the image, then composite a band of the image to ALPHA. 'STATUS' displays a table listing the dimensions and number of images in a range of iBUFFs. Zero values indicate the buffer is empty. 'LOAD TO' defines the target buffer for the image loader. By default, the target buffer for image load is the CURRENT iBUFF. Here, you to change it to any iBUFF. This is equivalent to the 'SETB=' loader composition tag. Automatic buffer sequencing in the Image Loader remains active, if set. 'SWAP' causes the current iBUFF to swap positions with the selected image buffer in the array of 16 selectable iBUFFs. It also swaps the 'current' iBUFF to remain the buffer being viewed, so you can swap with an empty buffer. Only pointers are moved around, so this app is lightweight. This is for organizing iBUFFs into an organized list. Note: The target buffer to be loaded next is not changed. This enables loading imagery to a high numbered 'scratch' buffer and selectively filling in lower order buffers with SWAP. This command simply swaps a few pointers and is not compute-intensive. 'RGB/BGR' swaps the color model of the iBUFF from BLUE being stored in the low-order byte, to RED being stored in the low-order byte of a RGBA pixel. Images created on different machine architectures can create this condition. If colors in a RGB image look 'reversed', this function should correct it. 'RELEASE' releases buffer memory resources back to the system. A RELEASED BUFFER CANNOT BE RECOVERED!!! Note that REX will NEVER release the current image buffer. 'RELEASE/SELECT' will release a single, selected iBUFF. 'RELEASE/ ALL' will release all iBUFFs EXCEPT the current iBUFF. 'RELEASE/ HERE >' destroys all buffers greater-than the current buffer. 'RELEASE/ < HERE' destroys all buffers less-than the current buffer. By using 'SWAP' and 'RELEASE' you can review/select/discard many images quickly into an organized list. THE SCALING BUFFER [sBUFF] HIGH DYNAMIC RANGE BUFFER OPERATIONS: See Appendix D: sBUFF Exploitation There are two HDR Scaling Buffers; the 'Loader sBUFF' and the '~App sBUFF'. One is dedicated to the Image Loader, and one is dedicated to REX HDR Apps. Each sBUFF hosts its own Scaling Settings. The 'active' sBUFF determines the 'Inverse Scaling LUT' used to dereference Display values to original HDR data shown in the Ancillary Display. Even if the active sBUFF is empty, its scaling settings may be active. Selecting 'SCALING|STATUS' under 'BUFF OPS|sBUFF' sets the active scaling sBUFF, reflected in the Ancillary Status Display. This is useful if an ~App sBUFF display is in a FG_AOI superimposed over a Loader sBUFF HDR display on the screen. You can switch between the De-scaling LUTs for each sBUFF. Regardless of the 'Active sBUFF', each sBUFF will always use its local scaling settings to render HDR data to the Display. The Image Loader Scaling Buffer enables loading a multi-band, High Dynamic Range [HDR] image at full, floating point precision. The Exploitation Scaling Buffer is used by exploitation functions that generate HDR output; i.e. apps marked on the menu as '~App'. sBUFF contents must be scaled into an RGBA iBUFF [iBUFF], or the Foreground Area of Interest (FG_AOI) for viewing. sBUFF is limited to a single HDR image, but the image may have up to 8 bands (FFT). sBUFF stores each color plane with 32 bit, Floating Point precision. This enables full, lossless precision for all but the most exotic imaging sensors. At this time 64 bit sensors are not mainstream and their data is truncated to 32 bits Float. NOTE: When doing scaling operations on zoomed data, you should set the Zoom-Mode to REPLICATE. Otherwise you are working with interpolated values that may not even exist in the original HDR data. You can re-scale sBUFF into the same iBUFFER over and over until you have the visualization you want. However, scaling sBUFF into an empty iBUFFER makes that the new 'active' iBUFFER, and disables scaling updates to previous iBUFFERs containing scaled HDR data. This allows you to click through several iBUFFs visualized using different scaling options on the same data. Similarly, you can rescale output of a HDR ~App to the same FG_AOI repeatedly, using scaling settings other than the default settings used for initial display. Scaling is based upon image statistics, and many things can happen that corrupt the statistics of an HDR image (See EXTREMA). The scaling interface enables you to resolve such issues quickly to achieve a precision visualization. This does require practice and experience. HDR composite images loaded to sBUFF a single band at a time must be EXACTLY the same dimensions. The smallest file dimension thus dictates the size of the HDR color composite. Define a STATIC buffer the size of the smallest image and it will automatically clip images to size. FXY,COLS,ROWS,SFACT loader tags also accomplish this. 'BUFF OPS' has an 'ALIGN' function to align bands after scaling as well as support for image rectification of dissimilar imagery. Since the dynamic range of sBUFF [32 bits per color plane] greatly exceeds the dynamic range of a computer Display or human eye [8 bits / color], its huge range is selectively visualized by specifying scaling parameters to be applied to sBUFF. The scaling parameters determine the range of visible data, and the enhancement curve applied to this range. The enhancement curve [see MODE below] will enhance contrast of some regions of a range at the expense of other regions. Scaling and visualization of HDR data is the art of managing scaling mode trade-offs. NOTE: Due to the high computational and storage overhead of the sBUFF, it must be 'WRITE-ENABLED' to be accessed by REX ~Apps. This is done by selecting 'sBUFF/ACTIVATE/ON'. The default is sBUFF being write-protected. sBUFF activation can also be included in the REX startup configuration file. The Image Loader sBUFF is always active and cannot be write-protected. You may scale individual HDR color planes independently. Selecting RGB for interactive scaling will cycle through each color plane. The 'GRAY' option is for scaling single band HDR images displayed as GRAYSCALE, or for using an identical scaling setting for all 3 RGB bands. WARN: You should 'write-protect' sBUFF if running GLOBAL SCOPE transforms on huge images; unless you have a use for HDR output of a transform. The computing and temporary storage overhead of writing to sBUFF is significant for very large images. Casual REX users have no need for sBUFF and it should be OFF. BUFF_OPS iBUFF # Previous section, 8 Bit RGBA viewable buffer : sBUFF~ # High Dynamic Range [HDR] buffer; Scaling required LOAD # HDR content created by image Loader STATUS # show statistical state of sBUFF SCALING STATUS # show active scaling parameters RESET # reset HDR parameters to viewable default settings 3-SDV-MN [mean] # 3 standard deviations centered on MEAN 3-SDV-MD [median] # 3 standard deviations centered on MEDIAN FULL RNG # Full Data Range recorded in Statistics MODE LINEAR # no enhancement LOG # enhance data skewed to low range EXP # enhance data skewed to high range SINE-H # enhance low and high range of data TAN-H # enhance mid-range of data [PSEUDO] # express grayscale image as a rainbow across range # Pseudo is accessible only via Image Loader 'HDR' tag RANGE FULL # scale full extrema data range to 8 bits HIST # scale LOW and HIGH bounds from Histogram or display STD DEV # scale in Standard Deviations <- MEAN -> # scale STDEV range centered on MEAN 1 STDEV # stdev range ':' appears under mean,lo,hi,mark 2 STDEV 3 STDEV ? STDEV # clamped to actual range of data <- MEDIAN -> # scale STDEV range centered on MEDIAN : ...stdev LO -> # scale STDEV range from LOW bound : ...stdev <- HI # scale STDEV range from HI VALUE : ...stdev MARK # scale STDEV range centered on Physical Unit MARK : ...stdev PHYS UNIT # scale in Physical Units LO-HI # scale from LO to HI in Physical Units LO -> # set low bound [, scale RANGE from low bound] <- HI # set high bound [, scale RANGE from high bound] MARK # set MARK and scale RANGE centered on MARK NEW LOW # set new low bound NEW HIGH # set new high bound EXTREMA # All scaling will be clamped at Extrema bounds THIS # the present scaling bounds become Extrema RGB... HIST # select Extrema bounds from histogram RGB... CLEAR # clear Extrema; statistical sBUFF LOW, HI define bounds RGB... ARCHIVE # save, restore, swap scaling settings TOUCH # save current HDR scaling parameters RESTORE # refresh display with saved HDR scaling parameters SWAP # swap saved scaling state with HDR state and refresh SCRIPT # create Load Command Script for current image RENDER AUTOV # automatically re-render Display when scaling changes AOI # render HDR to FG AOI iBUFF # render HDR to iBUFFER iBUFF 1-4 : iBUFF 12-16 ACCUM # render HDR to accumulator ACC 1 : ACC 4 ACCESS # activate | deactivate | release this sBUFF ON # note that LOADER sBUFF is always accessible OFF RELEASE # truncate [release] huge sBUFF to free resources INPUT/OUTPUT # sBUFF direct I/O [ full sBUFF; not scaling parameters ] READ WRITE # sBUF stored in the REX internal format; see: inc/folioHdr.h SET PATH EXPLOIT # HDR sBUFF content created by HDR Exploitation apps : # functions are identical to those for LOAD above Selecting 'STATUS' will display statistical information about the contents of the sBUFFER, such as lo, hi, mean, median, mode and standard deviation. These statistics are computed automatically whenever the contents of the sBUFFER are changed. 'SCALING' manages the parameters that scale sBUFF HDR data for display. Some REX algorithms also create results with high dynamic ranges that exceed 256 graylevels. Where dynamic range is greater than 256 graylevels, the range must be compressed. Where the dynamic range is high precision with a range less than 256 graylevels, the range may be expanded. Similarly, a small subset of the full dynamic range may be of particular interest, and it is desirable to devote the full display range to this subset. The scaling utilities give the user quick access to the full dynamic range of HDR data. However, just as the PAN utility gives the user access to the full spatial range, there are trade-offs involved relating precision to coverage. Selecting 'STATUS' displays the current scaling settings. Selecting 'RESET' is used to recover a viewable visualization. It sets scaling to the Full Range, or centered on of the MEAN or MEDIAN, with a range of 3.0 standard deviations. For most images, information within 3 standard deviations of the mean|median dominates an image's visual appearance. From there you can fine-tune the scaling using RANGE. Selecting 'RANGE' enables redefining the range of data to be displayed. 'FULL' scales the entire data range defined by the Low and High extrema. '<-MEAN->' [or MEDIAN] centers the Display range on this metric. 'LO->' uses the low Extrema as the low bound and scales for the defined range of Std. Deviations from this value. '<-HI' uses the high Extrema for the high bound, and scales for the defined range from this value. '<-MARK->' uses the the mouse to select a point on the image or Histogram. Raw sensor values at this point serve as the center of the Std Dev scaling range. This optimizes scaling for a particular region of interest. 'HIST' uses the mouse to select LOW and HIGH bounds directly from the displayed Histograms. WARN: When using MARK on a zoomed image, be sure Zoom-Mode is REPLICATE. Other Zoom modes use interpolation to render a visually appealing image but these values are guesses and not hard data. Basing scaling on interpolated, zoomed values may lead to unexpected results. HIST contains no HDR values outside the range of the current scaled display. You will need to re-scale using 'DEFAULT|FULL' range to restore access the full data range. Then you iteratively 'zero-in' on the precise range of interest. There may be analysis situations where the bounds of a visualization must be precisely specified. For this reason you may also enter PHYSICAL UNIT values from the keyboard. This gives much more precise control than HIST or MARK. Selecting 'MODE' enables selecting the scaling mode. The scaling mode determines the mathematical function that maps intensity levels in the dataset to intensity levels on the display; i.e. Mode defines the 'Enhancement Curve'. 'LINEAR' mode is the simplest. Each display level is equally proportional. 'LOGARITHMIC' enhances contrast for the low end of the HDR image range. 'EXPONENTIAL' enhances contrast for the high end of the HDR image range. 'SINE-H'enhances both the low and high ends of the HDR image range. 'TAN-H' enhances the midrange of the HDR image range. 'PSEUDO' expresses the HDR image range as a rainbow [Black/Blue->Magenta]. This mode is accessible only via the image Loader 'HDR' tag, since a single HDR image band is expressed across all three [RGB] iBUFF color planes. For non-linear scaling, regions of enhanced contrast cause a sacrifice of contrast in other regions of the range. This is the trade-off of non-Linear scaling. Note: 'LUT OPS / HDR' applies the current sBUFF scaling mode and range to the current Display via a LUT transform. It does not access sBUFF, and is useful mainly to explore the scaling modes on non-HDR imagery. Using HDR on a screen of random values give a good histogram visualization. Selecting 'EXTREMA' enables you to clamp the LOW and HIGH boundaries of the range of a HDR dataset to eliminate data outliers that skew statistics. IF EXTREMA is ON, then the extrema values are treated as if they are the bounds of the dataset. 'THIS' sets EXTREMA to be the low-high bounds of the present display. 'HIST' allows selection of EXTREMA bounds directly from the Histogram display. 'CLEAR' resets EXTREMA to the statistical low-high range of the dataset. EXTREMA are defined separately for individual RGB color planes. WARN: New Scaling settings will be clamped at the Low and High bounds of Extrema. No warning is issued, and this can lead to confusing output. REX starts with scaling defaults in place, but once these defaults are changed REX retains the new settings. New HDR image files will be displayed using scaling settings for previous imagery unless new scaling settings are specified. ARCHIVE is used to save and restore the HDR scaling settings for a HDR display. Selecting TOUCH archives the current scaling settings. The initial HDR scaling is automatically Touched. RESTORE replaces current scaling settings with the Touched settings. SWAP exchanges the Touched and and current settings, without destroying either. SCRIPT creates a Loader Script (aka Command File) that will duplicate the existing HDR scaling settings and state of the HDR image display. 'RENDER' re-displays the contents of sBUFF as defined by the current sBUFF scaling settings. 'AUTOV' will cause the contents of sBUFF to redisplay automatically when scaling settings change. AUTOV has no effect if sBUFF is empty. You may select 'AOI' if the Display is larger than sBUFF. Selecting 'iBUFF' will create a new iBUFF and render sBUFF into it. The buffer selected to receive the sBUFF rendering MUST be empty, or contain a previous sBUFF rendering of exactly the same size. Selecting 'ACCUM' will zero-normalize sBUFF contents to a single-band, 32 bit signed integer User Accumulator. You multiply by a 'Precision Factor' from 1 to 1000 to preserve precision prior to integer conversion; i.e. a floating point value of 100.037 becomes 100037 as an integer, preserving precision. This HDR accumulator may then be used as an argument in the CALCULATOR function to perform precision calculations on HDR data. (see Appendix A: iCALC). Selecting 'ACCESS' activates or de-activates the sBUFFER. The sBUFFER is actually a file on disk, so writing output to it degrades performance. Also, High Dynamic Range imagery is not a mainstream use. For this reason, sBUFFER is not active by default. Selecting 'ON' will cause all sBUFFER-active REX functions [functions under 'PIXEL OPS' flagged with a '~'] to render output to the sBUFFER at full precision prior to scaling for display. You may then use the scaling operators to display and analyze sBUFFER contents. It you turn an active sBUFFER 'OFF' its contents are preserved. If sBUFFER is not active, scaled output is written to the display, but the full precision output is discarded. Like ACCUMULATORS, the contents of sBUFFER remain as defined until changed, or REX terminates. 'RELEASE' will release storage used by sBUFF and flag it as empty. This is useful to free disk space if huge-images are involved in operations. NOTE: If computing a HDR '~' Transform at GLOBAL SCOPE on a GigaPixel iBUFF and you do not need to save high-precision results, you will gain a LARGE performance benefit if you turn 'sBUFFER/ACTIVE' to 'OFF'. Selecting 'INPUT/OUTPUT' enables the user to save the current state of the sBUFF, as a file, and to re-ingest it at a later time. The files are in the simple, uncompressed format used by REX accumulators and contain statistical information for the data bands in the file. If creating a sBUFF file for injest by REX, you may omit the image statistics records following the header by setting the header value 'fStats' to zero. REX will then compute the image statistics for you when injesting the file. REX defines 8 statistics records (FFT for RGBA) but only 4 Bands [RGBA] are displayable at any time. Function: DISPLAY OPERATIONS 'Display Operations' modify, or use as a source, the entire display area of the exploitation window. The current FG AOI does not limit the scope of display operations. Note that the Display may exist in 3 simultaneous mapped states; the iBUFF internal state, the visible state in the video framebuffer, and the 'touched' state in the Touch Accumulator. DISPLAY OPS RESTORE iBUFFER TOUCHED 1 - 4 TOUCH 1 - 4 COMPOSITE LOCAL CLONE SHIFT CLEAR RESIZE DISABLE ENABLE GAMMA 'RESTORE' causes the entire Display to be refreshed. 'RESTORE/iBUFFER' refreshes the Display with the contents of the iBUFF. 'RESTORE/TOUCHED' refreshes the Display with contents of a 'Touch Accumulator'. There are 4 'Touch Accumulators'. You cannot restore from a 'Touch Accumulator' unless you manually TOUCHed the Display to save its current state to that accumulator. Active zoom level, precise iBUFFER mapping and transform LUTS are part of the saved display state. 'TOUCH' saves the current Display state to one of the 'Touch Accumulators'. If transform LUTs are active, they will be active when the accumulator contents are restored and will overwrite the current state of the transform LUTs. 'COMPOSITE' burns the current Display, exactly as it is viewed, into an image buffer. This operation is not reversible. If you select CLONE, then the Composite operation copies data from the Display to the Clone of this iBuff, and does not modify the Local, or Current, iBuff. See: BUFF OPS | CROP | CLONE. 'SHIFT' enables the user to select a point on the Display and shift the image so that the point is moved to a new location. It simply changes the mapping of the Display to the iBUFF without resort to the PAN function. This is useful for fine adjusting an image composition. Note that the Display will be overwritten with the contents of the iBUFF when shifted. 'CLEAR' erases the contents of the display. It is useful when using the display as a temporary drawing area. Contents of the iBUFF are not effected. 'RESIZE' locks/unlocks the Display size. The reason to lock the Display size is to prevent re-computing the Global View for huge buffers. A stable Display size may also be more relaxing to use. The default is for the Loader to attempt to match Display size to each Image loaded. 'DISABLE' prevents the Loader from changing the current Display size. 'ENABLE' enables the Loader to resize the Display. The Loader GUI 'Display' menu always resets to RESIZE to 'ENABLE'. 'GAMMA' is a complex topic related to the physical characteristics of display monitors and the psychophysics of the human visual system. In a nutshell, all monitors have subtle differences in how they display ranges of visual data and GAMMA controls how bright/contrasty or dark/flat an image will appear. The monitor Gamma value is set by the monitor manufacturer and is implemented in the graphics device driver by the operating system. All apps use this Gamma. But Gamma is an approximate value that represents a compromise between all ranges of visual input. With REX you can take this one step further and optimize for 'correct' visual display of complex scenes on any computer monitor. Note that GAMMA has a USER function, enabling you to experiment with gamma values. You can also apply different Gamma values to different color planes. The REX GAMMA function is implemented as a LUT transform. Default LUTs use the O/S defined Gamma. Function: PAN/ZOOM OPERATIONS Digital imagery has increased in size and resolution to the point that a computer Display can only depict a small portion of a high resolution image. For this reason, REX uses a custom-designed graphical interface that facilitates multi-scalar exploitation of Gigapixel imagery. The PAN/ZOOM subsystem enables an entire iBUFF of arbitrary size to be precisely navigated for selecting portions of that buffer to be exploited at full resolution, or even at 'zoomed' magnifications. The iBUFF can be simultaneously zoomed and panned, with transform LUTs or OVERLAYS active. There is no meaningful limit on the size of an image that can be viewed with PAN, but your system's memory and processor will determine a maximum image size that can be loaded. PAN / ZOOM PAN ZOOM MODE REPLICATION BILINEAR BICUBIC CATMULL-ROM STATUS DE-ALIAS OFF ON 1X 'PAN' controls the mapping of image data buffered in memory to the display. The image data can be magnified (zoomed) as part of this process. PAN is defined only for iBUFFs that are larger than the display. Activating PAN on a buffer smaller than the display, will activate 'ZOOM' instead. When PAN is activated, the iBUFF is subsampled sufficiently that it's entire extent is viewable on the display. This sub-sampled 'Global View' is then saved for instant retrieval. You may exit PAN with the Global View active if you wish to work at the 'Global View' scale. If not, then you PAN the image by moving the Display Frame of Reference inside the Global View. Pressing LMOUSE begins roaming the Display View in the iBUFF. Pressing LMOUSE again stops roaming. Mmouse displays the global view, and Rmouse displays the PAN menu, or exits PAN. The state of the Display upon exit is the new exploitation area. PAN ZOOM 1 X 2 X 4 X 8 X LUT TOGGLE OFF SCROLL SLOW MED FAST REVERT 'PAN/ZOOM' selects the magnification factor while roaming the iBUFF. As the magnification is increased, notice that the Display frame of reference relative to the iBUFF becomes smaller. Pressing MMOUSE during PAN causes the full resolution panned Display to be replaced with the 'Global View' for navigating the Display frame of reference within the iBUFF. If LUTs were displayed when you entered PAN, LUTs will remain active in PAN. You can turn active LUTS off and on with LUT/TOGGLE. If TOGGLE is active, then MMOUSE will toggle LUT display off/on instead of displaying the reference image. LUT/OFF turns off LUT rendering during PAN, and MMOUSE again displays the Global View. Selecting SCROLL will ask you to draw a line on the Global View. When done, turning the scroll wheel will move the view back and forth along the established path at the current zoom level. REVERT exits pan and will restore the Display to the image state when PAN was entered. You exit pan by pressing RMOUSE and releasing it outside the PAN menu. The Display will remain in the state when PAN was exited. Exiting 'PAN' with the Global View active is not an error. Note that when entering PAN for very large images, the boundary of the current Display is shown on the Global View as a location reference. Note: Changing the Display size in the image Loader, or using the mouse to drag the Exploitation window to a different size will cause the archived 'Global View' for ALL iBUFFs to be recomputed when they are accessed. This happens because the Global View is closely fitted to the current Display dimensions. Creating the Global View of a Gigapixel image is very compute intensive. If the original image is only marginally larger than the display, then PAN defaults to roaming with a magnification of 2X. You can easily change the magnification back to 1X using the PAN menu. 'ZOOM' does NOT reference the iBUFF. A moveable box will appear depicting the area that will be zoomed 2X to fill the display. Pressing LMOUSE will cause the area within the box to be zoomed. You may repeat this operation until the Maximum Zoom of 16X is reached. Pressing MMOUSE will revert the Display to the state when ZOOM was entered, but will remain in ZOOM mode. Pressing MMOUSE twice in succession will revert the Display to the original, unzoomed image, and remain in ZOOM mode. However, if the image is larger than the Display then pressing MMOUSE twice will activate PAN. Exiting PAN will then resume ZOOM. Attempting to zoom an image beyond 16X is equivalent to clicking MMOUSE. Note: If you select PAN with an iBUFF smaller than the display, it will enter ZOOM automatically after issuing a notice. A Global View cannot be zoomed. The reason is that a Global View does not map precisely to the iBUFF. If you select ZOOM on a Global View, it will message you to activate PAN instead. When viewing zoomed imagery be aware that de-referenced metrics of individual pixels may represent interpolated values and not actual data. 'ZOOM/MODE' selects the algorithm of magnification to be selected. MODE/REPLICATE magnifies imagery by simply making the pixels larger through replication. At high zoom factors, the individual pixels will be noticable as discrete objects. MODE/BILINEAR magnifies imagery by moving the pixels further apart, then using bilinear interpolation to compute a linear gradient across image voids. 'MODE/BICUBIC' computes a curved surface defined by a 4 X 4 convolution and fits interpolated values to it. 'MODE/CATMULL-ROM' is an elaboration of bicubic that uses an edge preserving 'cubic spline'. Zoomed roaming in PAN is supported only for REPLICATE or BILINEAR, since REX can compute these in realtime without resort to graphics hardware acceleration. Once PAN exits however, if BICUBIC or CATMULL-ROM zoom is active it will cause the final Display to be updated with the sharper, but MUCH more compute intensive (and slower), BICUBIC or CATMULL-ROM zoom algorithms. There may be a delay while this computation occurs. Note: If tabulating pixel values for statistical purposes, REPLICATE should be used, since other zoom modes interpolate data values. Visually, CATMULL- ROM gives the most faithful rendition of a zoomed area, but BI-LINEAR is suitable for most uses and is much faster. 'STATUS' displays the current zoom algorithm, and Display magnification factor. 'DE-ALIAS' clears up aliasing [complex artifact clutter] that can arise when a zoomed image is zoomed. This is due to complex resonances that can occur as zooming algorithms encounter their own output. DE-ALIAS works by reverting to the original un-zoomed area, then re-zooming it in a single operation. DE-ALIAS is on by default, but since aliasing artifacts may be visually interesting (!!!), you may turn it off. It remains off until turned back on. If you restore a zoomed region with 'AOI OPS|RESTORE', this will also de-alias a zoomed display. If Aliasing-Artifacts are visible in the Display, these artifacts will appear if the Display is saved to an image file. Aliasing artifacts WILL NOT APPEAR if the full iBUFF is saved to a file. This can be confusing, but it is not a Bug. Finally, ' 1 X ' is a shortcut that will instantly revert a zoomed display back to the original iBUFF resolution. Note: Changing 'ZOOM/MODE' will overwrite the current display with the zoomed contents of the iBUFF using the new zooming algorithm (if the display is currently zoomed). The current display will be lost unless 'touched'. 'BUFF OPS/RESIZE' uses the current ZOOM interpolation mode. It will warn you if you are about to perform an operation that will take a very long time. Up-sizing to a Gigapixel buffer in BICUBIC or CATMULL-ROM could take a long time. Without exception, iBUFFs are down-sized using REX hybrid biLinear averaging, since this algorithm preserves the maximum possible original image information. At high zoom factors, images will appear blurred and defocussed. This is unavoidable, since NO amount of computation can synthesize valid scientific information from the empty space between data points. Digital imaging literature contains algorithms implying 'super-resolution' of zoomed imagery, but the valid algorithms rely upon stacked and registered multiple views of the same scene over time and have very high computation requirements. There is no such thing as a 'super-resolution' zoom on a single image. Images stored in 'Lossy' image formats (such as JPEG) will yield disappointing results when zoomed due to presence of artifacts of the compression process that will be enhanced by zooming. This is not a bug in REX; in fact, artists may find lossy image compression artifacts interesting. Function: SAVE IMAGE This subsystem enables the user to save the current area of interest, or an entire iBUFF, to a file. Two output formats are supported; Portable Network Graphics (PNG) and Graphics Interchange Format (GIF). PNG is a widely supported format that supports lossless compression, and full RGBA [overlay / transparency] support. GIF enables capture of RGB images in the smallest possible data volume. There are numerous format conversion utilities on the web that will take both of these formats as input. Note: If transform LUTs are active, and visible, the transform LUTs will determine the contents of the output file, even if an entire iBUFF is being saved. REX will prompt you for the output image filename. Do NOT add an extension; that is done for you based on the image format selected. ***LOSSY COMPRESSED FORMATS*** 'Lossy' compressed formats sacrifice image precision for reduced data volume. Lossy compressed images are intended for casual viewing and presentations. The GIF image format is 'Lossy', but very compact. There is nothing inherently 'wrong' with lossy formats, but reading an input image in a lossy image format, then saving the image in a lossy format results in a cycle of unrecoverable image degradation. Since REX is fundamentally a technical and research system, it also supports the PNG image format. PNG is a lossless format that also supports the ALPHA plane. 'SAVE IMAGE' supports both. *** OVERLAY / ALPHA *** If you select RGBA [RGB + ALPHA] as the color planes to save, REX will attempt to save ALPHA plane content in addition to the RGB color planes. If there is no active ALPHA plane, REX simply saves the RGB color planes without ALPHA. If 'FG AOI' is selected as the source, or the selected format is GIF, then ALPHA is treated as an Overlay that overwrites the RGB image content. If the selected format is PNG, then the image is saved as a RGBA image. ***ENCRYPTING SAVED FILES*** The default mode for saving images is as un-encrypted files, however you may select to ENCRYPT output imagery for 'License Level 2' and above. If you loaded an encrypted image, then simply select 'CRYPTO/ON' to encrypt saved images using the same key, or select 'SET KEY' to define a new User Key. Encrypted files have the letter '#' appended to the filename (before the file extension, if present) to flag them as encrypted. See Appendix F: for more on encryption. NOTE If you change an existing encryption key when saving an image, the new key redefines the key used for decrypting images in the REX loader. If this is not desired, you must reset the key in the REX loader to its original state when loading encrypted images. WARN! If a Domain Key is active, the image will be encrypted using both the Domain Key AND the User Key. A recipient who has only the User Key will NOT be able to view the image. ********************************* *** ENCRYPTION *** *** WARNING: DATA LOSS HAZARD *** ********************************* AES encryption with a 256 bit key is impregnable to brute force exploits. If you lose or forget the key, your data is NOT recoverable. You should keep a written copy of the key, as well as an UNENCRYPTED backup copy of important data in a secure place. IMAGTEK LLC IS NOT RESPONSIBLE FOR, and CANNOT ASSIST, recovery of lost data due to crypto-key mismanagement. SAVE FILE FG AOI PNG GUNS GIF GUNS BUFFER PNG GUNS GIF GUNS CRYPTO OFF ON SET KEY SAVE KEY Function: CALCULATOR The 'CALCULATOR' subsystem (iCALC) is an extremely powerful tool for analysis and visualization guided by rigorous mathematical or logical criteria. iCALC can create tabulations and histograms of any imaginable logical relationship, and is useful for generating new images using mathematical relationships between image color planes. This is a common technique in remote sensing, where mathematical relationship between different 'bands' of imagery reveal unique signatures of the environment, such as vegetation, suspended dust, precipitation potential, etc. Results are displayed as they are computed. This utility is also useful for doing photographic merging of different image layers that have been cropped into Accumulators. With skill and some imagination, you can duplicate photographic manipulation and transparency effects of expensive graphics packages. iCALC can also be used as a creative medium, for those with the inclination to use it that way. A detailed User's Guide to the CALCULATOR subsystem is found in Appendix A. Function: ANCILLARY The ancillary display area has three components; Roam / Zoom area Histogram / Scattergram display area Pixel Statistics display area The 'ANCILLARY' subsystem controls the behavior and appearance of the ancillary display area on the right of the screen. Note that it is possible for the ancillary display to depict the internal state of the iBUFF instead of the image on the screen, enabling two simultaneous views of data at any scale. ANCILLARY MODE OFF ROAM & STATS ROAM ONLY SOURCE DISPLAY GUNS BUFFER GUNS GRAPHS HISTOGRAM COUNT GUNS PERCENT GUNS SCATTERGRAM SCALING LINEAR LOGARITHMIC EXPONENTIAL COUNTS INVLUT RAW MENU FAST STICKY LICENSE Selecting 'MODE' controls the activation and display mode of the ancillary display. 'OFF' will cause the ancillary display to disappear. Any imagery that maps to the area beneath the ancillary display will be refreshed from the Display buffer. 'ROAM & STATS' will cause the ancillary display to become active and display the 'zoom/roam' window, the histogram, and the statistics display. 'ROAM ONLY' will cause the ancillary display to become active and display only the 'zoom/roam' window. 'SOURCE' enables selection of the source of ancillary and statistical data. Data can either come from the 'DISPLAY', or from memory in the image 'BUFFER'. This enables you to examine the same area under two totally different viewing modes simultaneously. In either mode, you can select which color guns (RGB, or single R, G or B ) will be active in updating the statistical data. If a gun is not active, it does not update the statistical state of the histogram. *** NOTE *** If the data 'source' is the image 'BUFFER', be aware that histograms are updated from the iBUFF contents, NOT the Display contents. Selecting the source also controls whether to display all three guns (RGB), or a single gun rendered as grayscale, in the ancillary ROAM window. This enables you to view complex colored scenes in their individual bands to analyze the contribution of each band to the colored scene. 'GRAPHS' enables selection of the graphical displays to be viewed. At present, this is 'HISTOGRAM' and 'SCATTERGRAM'. Others may be added in the future. Selecting 'HISTOGRAM' controls the Display of the image histogram. A histogram is always maintained internally, even if it is not visually displayed. There are 256 possible color intensity values (8 bits) for each RED, GREEN or BLUE image plane. The histogram is a graphic representation of the COUNT of image pixels in the foreground area of interest (FG AOI) that occurr for each color intensity value. A histogram will appear as RED, GREEN, BLUE transparencies sharing the same area. You can select which histogram color planes to display, as well as whether to display actual pixel counts, or the percent of coverage a pixel count represents. For images where colors represent attributes, this is a powerful analysis tool. The histogram contents define the statistical 'state' of the entire image and determine the output of LUT image transformations. Histogram update defaults to 'AUTO', or an automatic update any time the image state has changed. Selecting 'MANUAL' instantly updates the histogram, but disables future automatic updates. To update the histogram, re-select 'MANUAL' when an update is desired, or select 'AUTO' to resume automatic histogram update. Note that the appearance of the histogram is dependent upon the active graph scaling mode. Select 'STATUS' to view the histogram statistics in textual format. Note also that if ANCILLARY/SOURCE is set to BUFFER, the histogram is updated from the iBUFF that maps to the image FG_AOI, not from the display. This may be confusing if you are not aware of it. All LUT operations, and several pixel operations, are defined by the current state of the histogram. Succinctly, the histogram IS the instantaneous statistical state of the exploitation environment at any point in time. Selecting 'SCATTERGRAM' displays the covariance of image color planes relative to one another. It consist of 3 combinations of 2 color components; RED/GREEN, RED/BLUE, and BLUE/GREEN. These 3 color combinations display as YELLOW, MAGENTA and AQUA, respectively. The position of the colored points on the scattergram is determined by the scaled COUNT of occurrences for the 2 color components that combine to make the displayed color. The colors coded on the X (bottom) and Y (right) axis indicate how each 'component' color's scaled COUNT contributes to the POSITION of the plotted color combination. For example, the X axis is labeled RED and GREEN. This means that color combinations containing RED or GREEN have their X position plotted by the RED or GREEN count of that combination. Similarly, color combinations containing BLUE or GREEN have their Y position plotted by the BLUE or GREEN counts of that combination. Note that GREEN is a component of two color combinations; YELLOW and AQUA. This means that for YELLOW, the scaled GREEN count gives the X position. For AQUA, the scaled GREEN count gives the Y position. Color scattergrams can be very complex and convey much abstract information about the information dynamics of an image. You can have fun experimenting with B&W images, color images and images of random noise. This will give you a feel for the abstract information dynamics of color imagery. 'SCALING' controls the scaling mode used for histogram/scattergram display. The Ancillary scaling mode will greatly impact the appearance of the histogram or scattergram. LOGARITHMIC scaling is the default scaling mode, since the number of intensity values across the Display range can vary by very large amounts. See the 'BUFF OPS|sBUFF|SCALING' (above) for an explanation of scaling modes. Note: 'Ancillary' SCALING is totally independent from HDR 'sBUFF' scaling. It controls ONLY visual histogram display. 'COUNTS' controls whether the intensity values for image pixels will be displayed as RAW integer values, or as SCALED values based on an inverse lookup table that converts R,G,B values to associated physically meaningful values. If an image with meaningful scaled intensity values has been transformed into an image where these values are no longer physically meaningful, COUNTS should be set to 'RAW'. 'MENU' controls the mode of main menu display. 'FAST' will display the menu only so long as the RIGHTMOUSE button is depressed, and the menu will disappear when it is released. 'STICKY' will cause the menu to persist after RIGHTMOUSE is released and the menu will only disappear when a mouse button is again depressed. This is strictly a user preference. 'LICENSE' displays the current status of REX licensing, including the type (Evaluation or Permanent license), Access Level, and Expiration Date. If REX is unlicensed, it displays the license order code needed to acquire a permanent license and provides a commandline to install the permanent license acquired from Imagtek. Function: ANNOTATE The 'ANNOTATE' subsystem enables the user to draw points, lines, rectangles, polygons or text directly on the displayed image. In addition, it supports plotting calibration scalebars (pseudocolor or B&W) as well as data transects (plot of RGB pixel values along a line). Text fonts, text style, text size, linewidth and foreground/background colors are all fully selectable. Annotation is used primarily for creating graphic reports based upon image analysis. It is not intended as an image 'editor' or paint program, of which many very good ones already exist. REX is primarily an analysis tool and artistic medium. Annotation to RGB Color Planes By default ANNOTATE is directed to 'RGB' where new features destructively overwrite the existing image contents seen on the display. For certain features (Scalebars), this is the only mode available. The Display is instantly recoverable via the [AOI OPS | RESTORE | RGB] app. NOTE: In 'RGB' mode the data in the underlaying iBUFF remains unchanged until 'COMPOSITE' is performed. Until then, any Display update from the buffer will erase the annotation. If you annotate to a 'Global View' image, you must save the annotated image as a file to preserve it since 'COMPOSITE' is undefined for a Global View. Graphics Annotation to the ALPHA (Overlay) Plane ANNOTATE may also be directed to write to the ALPHA (or 'OVERLAY') plane. ALPHA / Overlays exist independently of the underlaying RGB image and preserve image data from being over-written. You direct Annotation to the ALPHA plane by using the 'ANNOTATE | SET | ALPHA | TRUE' operator. If you save an image in the [.GIF] image format, the image may be loaded to the Alpha plane as an Overlay. You cannot annotate to the Alpha Plane of a zoomed image, or a GLOBAL VIEW. NOTE: Although you can annotate anywhere on the display, only annotation features that map to the iBUFF will be written to the Alpha plane. Text Annotation to the ALPHA Plane Modern Truetype text fonts cannot write directly to the Alpha plane because of font anti-aliasing [edge smoothing] which uses the full RGB color space to smooth font outlines. To Annotate text to the Alpha plane you must use the CALCULATOR app. First, create a FG AOI that delineates the desired text area. Zero the area [AREA OPS | CLEAR | RGB] and annotate RGB text into this area. Alternatively, Annotate RGB text using 'TEXT BLOCK' with default BLACK Background. Exit and open CALCULATOR. Make sure the FG AOI encloses the text area. Remove font anti-aliasing by using CALCULATOR to change every non-zero value in the text area to the Annotation Foreground Color Index : [ANNOTATE | STATUS]. Note that with anti-aliasing removed text will look fatter and more angular. For the final step, use CALCULATOR to write the Font color index to the ALPHA plane. In the example below, assume the desired Font Color Index is 255, which will display as Magenta. [REX | CALCULATOR] .(0,0,0)!255}:rgb # de-aliased text now displays as white = (255,255,255) mapped # map FG AOI to the iBUFF r:a # copy 255 in red gun to ALPHA. Any other gun also works exit # exit CALC. Text will now appear as color-index 255 [Magenta] when ALPHA is Enabled To render ALPHA visible, select: [BUFF OPS | ALPHA | ENABLE ]. To render ALPHA invisible, select: [BUFF OPS | ALPHA | CLEAR ]. To erase ALPHA in the FG AOI, select: [AOI OPS | ALPHA | DESTROY]. To erase all ALPHA in the iBUFF, select [BUFF OPS | ALPHA | DESTROY]. If 'TRANSECT' is selected in Alpha mode, the transect data is taken directly from the iBUFF rather than from the visible display. If the transect line extends outside the iBUFF, those values will be zero. When saving images, the Portable Network Graphics (PNG) image format provides full support for ALPHA overlays, including saving full iBUFFs. Other formats do not support ALPHA and are confined to displaying overlays that are pre-rendered to the display. To save the ALPHA plane, select PNG as the image format, and 'RGBA' (not RGB) as the image planes in the 'SAVE IMAGE' function. REX supports 24 bit RGB Truecolor, but ALPHA/Overlay is 8 bit pseudocolor. This limits ALPHA display to 255 colors (+ Transparent) defined by the OVERLAY LUT. Thus, features with colors not found in the OVERLAY LUT are undefined. This means the B & W and PseudoColor 'SCALEBAR' features cannot be written successfully to ALPHA. The GUI will decline to perform operations that are undefined under ALPHA mode. Foreground and Background Colors Annotation consists of using the 'SET' selection to place the annotation system in a desired graphics rendering state via selection of foreground and background colors, font and linewidth. This rendering state is then used to create the figures selected under the 'PUT' selection. The rendering state remains as configured until changed or the REX application exits. Text, lines and edges of figures are drawn using the 'foreground' color, while text background and the interior of figures is drawn using the 'background' color. To draw an empty box (or circle, ellipse, etc.) around an area, set the background color to TRANSPARENT. Likewise, for text to be drawn without a background, set background to TRANSPARENT. Otherwise, set background to the color that is to fill the interior of figures, or the backdrop for text. Transparent is the leftmost color on the colorbar displayed by SET/COLOR. Upon completion of an annotation operation, the annotation menu re-displays itself automatically, remaining in the annotation application. The main menu is reactivated by pressing RMOUSE outside the annotation menu. REX is a powerful image report composition tool, but not a photo editor. The annotation functionality below will cover most image annotation needs. ANNOTATE PUT TEXT STRING BLOCK POINT 1 : 16 LINE SIMPLE ARROW .FREEHAND .SEGMENTS FIGURE POLYGON FREEHAND SEGMENTS RECTANGLE DRAW FG AOI BG AOI SQUARE CIRCLE ELLIPSE SCALEBAR VERTICLE HORIZONTAL .B & W .COLOR TRANSECT LO-HI FULL HISTOGRAM SET COLOR FOREGROUND BACKGROUND FONT ARIAL : GERMAN LINEWIDTH 1 : 4 ALPHA TRUE FALSE DELETE ALL AREA CUT / PASTE UNSCALED DRAW DEST. X,Y SCALE COMPOSITE AREA ALL 'RGB' signals that annotation is to be performed in RGB mode by overwriting the imagery. 'OVERLAY' signals that annotation is to be written to ALPHA/overlay and that the image is to remain unchanged. 'PUT' allows the direct, interactive placement of graphics objects listed on the menu. Most are familiar and self explanatory. Simple experimentation will reward the user much more quickly than belaboring the obvious here. A few caveats... When entering a text string, move the font 'range box' to the desired location and press LMOUSE to begin typing. Terminate input by pressing the 'ENTER' key. When entering a 'text block', you must first interactively draw the box the text is to appear in. The text will then automatically scroll in the box when 'ENTER' is pressed or the text reaches the edge of the box. NOTE: In a 'text block' a trailing blank on a line of text, or a line containing a single blank, terminates input. The FOREGROUND color is the box edge and text color, the BACKGROUND color is the box interior. When entering points, a point will be drawn at the location of the cursor with each press of LMOUSE. Terminate input with RMOUSE. The numbers under 'point' indicate point size. Large points look like crosshairs. POINT is useful for indicating locational position. Note that when drawing lines, the line will not appear in the selected color until after the drawing is complete. This enables line segments to be erased or 'dragged' on the display. Line drawing mode may be 'freehand', meaning lines automatically track the cursor, or 'segment', meaning the next point on the line is entered only when LMOUSE is pressed. Points on a line are deleted by pressing MMOUSE. Line input is terminated by pressing RMOUSE. Line endpoints may be either 'simple', or terminated with an 'arrowhead'. The buffer for points on a line is periodically thinned, drawn and emptied, so it is impossible to overflow the point buffer. Once the buffer empties, you cannot delete the plotted points except via use of the DELETE menu function. Polygons are drawn exactly like lines, the only difference being that the last point on the polygon is connected to the first point when RMOUSE is pressed. Rectangles are drawn by selecting a point with LMOUSE, dragging the mouse until the box is the right size, then pressing LMOUSE again. Pressing MMOUSE signals discard of results and a repeat of the drawing process. RMOUSE terminates the operation and discards the figure. Squares are drawn by selecting the center point of the square then pressing LMOUSE. Dragging the mouse then defines the square. LMOUSE plots the square, RMOUSE discards the figure, and MMOUSE enables a retry. Circles are drawn exactly like squares; select a centerpoint and drag. Ellipses are drawn much like circles, except motion in the X or Y plane determines how flat or round the ellipse is. Scalebars are drawn exectly like rectangles. The only difference is that upon completion, the grayscale fill and border tickmarks are automatically added. Scalebars may also be pseudocolor. Transects consist of drawing a single line segment across the region of interest. Once the endpoint is selected, the user is prompted to select the region of display for the transect. Once defined, the transect display area is filled in with a histogram-like record of the R,G,B values along the line. Tick marks on the transect line, and along the edges of the transect display area, exactly correspond, enabling precise determination of locations on the transect. 'SET' selects active Text Font, Foreground Color, Background Color, Linewidth and turns ALPHA mode ON or OFF. 'DELETE' erases annotation by overwriting it with the contents of the image buffer. You can draw an area defining the area to be deleted, or you can delete all annotation visible on the display. 'CUT/PASTE' enables you to copy areas from one Display location to another. You may also warp, enlarge or shrink the selected area during copying. This function is identical to that under AOI OPS. 'COMPOSITE' burns the annotation into the RGB iBUFF, preserving it. Until this is done, updating the Display will destroy the annotation. Function: LOADER This function exits the exploitation system and activates the LOADER graphical user interface. The exploitation window is destroyed and all Display resources used by the exploitation subsystem are released. Note that the iBUFFs and scaling buffer retain their contents, as do Accumulator files and Exploitation state. This enables you to alternate seamlessly between multiple REX sessions. When you resume exploitation of a REX instance, everything is just as you left it, except for any new images loaded. Function: EXIT This function releases all system resources, closes all temporary files and terminates the REX application. The only files left behind are those explicitly saved using the 'SAVE FILE' command. Function: EXTENSIONS An important design feature of REX is the ease with which new algorithms may be integrated into the core REX framework and distributed without restriction. Developers with specialized domain knowledge in fields such as medicine, astronomy, biology, chemistry, image forensics, etc. will find that seamless integration of specialized algorithms into the REX system is so simple as to be almost trivial. Your specialized algorithms may function seamlessly within the REX exploitation framework, and you are free to redistribute (and market!) your collaborative work. Your algorithms need only read from, and write to, an image buffer, an image accumulator, the floating-point sBUFFER, or the Display via the REX API. REX takes care of the rest for you. You may define a temporary evaluation license for free evaluation of your enhanced version of REX (under your (c) Trademark) using the robust CDLT licensing mechanism, or not! See ~doc/CDLT.txt for details. Selecting 'EXTENSIONS' causes the extensions menu to overwrite the toplevel REX menu. From that point, operation within the extensions menu is performed exactly like operation within the REX toplevel menu, except all of the functions are created by you. As soon as an extension exits, everything reverts back to the standard exploitation mode. The integration is seamless. The existing 'EXTENSIONS' source code is a skeleton serving as a framework for extending the REX kernel application into specialized application domains. The source code for this function is included and demonstrates how to integrate with the REX system and CDLT license manager (or not!). Developers will be pleasantly amazed at the simplicity and absence of arcane nonsense. REX pursues a minimalist development philosophy that simplifies integration, minimizes code complexity, and uses the fastest algorithms available. Please see Appendix E: REX and Open-Source Code APPENDIX A: THE REX IMAGE CALCULATOR: iCALC If REX was limited to nothing more than running iCALC, REX would be a serious application. iCALC performs arithmetic and logical operations on each image color plane independently at 32 bits signed integer precision. It can also precisely merge different layers of RGBA images together; i.e. when composing astronomical RGBA imagery. iCALC can also perform operations exploiting the full range of High Dynamic Range (HDR) data. If the full dynamic range of a HDR image was captured in an accumulator using 'BUFF OPS | sBUFF | RENDER | ACCUM', the data in the accumulator is available at full dynamic range for processing at precisions up to 0.001. Precision beyond 0.001 is meaningless since it cannot be displayed. We refer to color planes as 'guns', such as the 'Red gun', 'Green gun' or 'Blue gun'. This antique terminology is based upon the electronic design of 20th century color video displays that used a separate electron emitter, or 'electron gun', for each color. iCALC SCOPE: DEFAULT, GLOBAL and MAPPED In Default mode, arithmetic/logical calculations executed by iCALC are applied to every point on the current Foreground Area of Interest (FG AOI) on the Display. The Display is both the source of inputs to iCALC, and the destination of results. Results are easily reversible via the UNDO operator. In GLOBAL scope, the iBUFF is the source of inputs to iCALC, and the destination of results. Every iCALC command will impact the entire iBUFF, regardless of its size. Results are not reversible using UNDO. Upon completion the Display is updated. In MAPPED scope, the FG AOI on the Display is the source of inputs to iCALC, but the iBUFF region that maps to the FG AOI is the destination of results. Results are not reversible using UNDO. Upon completion the Display is updated. Note that if the FG AOI does not map to the iBUFF, nothing will change. iCALC calculations on the FG AOI are displayed instantly, so you can observe the computation in progress. GLOBAL operations are displayed upon completion, so there will be a delay based on the size of the iBUFF. For huge images, the delay may be significant. GLOBAL mode will issue a warning for 'Full-Screen' Display mode, since it will 'screen-lock' your computer until it finishes. THE iCALC COMMAND LANGUAGE You define iCALC calculations in Reverse Polish Notation (RPN). This is a simple but powerful mode of expressing algebraic and logical operations that dispenses with the need for parentheses '( )' or an equals '=' sign. Do not be alarmed by this, because RPN is simple and can be learned by anyone in a few minutes. RPN is used because it is very efficient for sequencing interactive calculations. Any calculation specified using parentheses and an equals sign can be specified using RPN. The template for all RPN calculations in iCALC is: ( value operand operator : result ) In the above template, 'value' is the state of an RGB image plane. 'Operand' is a number (or image plane) to be applied to the 'value' in a calculation. 'Operator' defines the calculation between 'value' and 'operand' to create a result. 'Value' is only entered once, at the beginning of a calculation. If the calculation is long, the internal result cycles forward to become the 'value' modified by the next [operand operator] pair. There is no limit to the length of a calculation, however note that an Accumulator may only be referenced ONCE per calculation. RPN has no assignment operator, so iCALC uses an arbitrary operator ':' (colon) to signal end of computation and final assignment of the result to image planes. The RPN command is applied independently to every RGB point on the image and is executed left to right, re-defining 'value' at each step. The assignment operator ':' signals the end of the calculation and defines the destination(s) of the result. IMPORTANT: The original state of image RGB color planes at a point persists until the assignment operator ':' is encountered. An RPN example: 5 7 + : 12 or 5 + 7 = 12 3 9 * : 27 or 3 * 9 = 27 36 6 - : 30 or 36 - 6 = 30 G R - : RGB subtract red from green and copy result to R,G,B color bitplanes as grayscale etc. For those unfamiliar with RPN, this may look very strange. It is, in fact, very simple and will reward one minute of determined examination and thought with a full and complete understanding! Your 'hands' will quickly learn RPN and in a very short time it will require little or no thought. In the past, RPN was widely used by Hewlette-Packard in their pocket calculators before everything in the USA was dumbed down for stupid people. iCALC COMMAND SYNTAX The command template for the iCALC commandline is: gun [gun operator] ... : gun [gun gun] or gun [constant operator] ... : gun [gun gun] or constant [gun operator] ... : gun [gun gun] REMEMBER! (value operand operator : result ) ...OR... ( value operand operator operand operator operand operator... : result ) Note that most fields are optional. A calculation can be as simple as assigning one image plane to another, or to an Accumulator (see below). Every image pixel on the Display consists of a 32 bit RGBA unsigned bitfield. 'Gun' refers to selecting a single 8-bit color plane within this bitfield. Gun values may be 'R, G, B'. 'Gun' may also refer to an image accumulator; @1gun, @2gun, @3gun, @4gun; discussed below. 'Gun' always refers to its original state, unless it is the target of a result assignment after the ':' operator. Finally, we use the 'Dot Gun' [.] to refer to the entire 32 bit RGBA bitfield as a unit. 'Constant' refers to a numeric constant; i.e. a number that does not change during the calculation. All constants must be positive, numbers with a range from 0 to (2^31 - 1). Hexadecimal constants (base 16) must begin with '0X' [zero X] and have a range of 0x0 to 0xFFFFFFFF. iCALC supports RGB color triads '(RED,GRN,BLU)' as constants, where each color has a range of 0-255. Negative constants are undefined. The 'Result' operator ':' specifies how the Display is to be overwritten by the final value of the computation. Example: A result can overwrite an individual display color; ' : R', ' : G', ' : B' A result can overwrite the Display as a grayscale image by overwriting each color gun independently with the single result value; ' : RGB' A result can overwrite the Display as an unmodified 32 bit RGBA bitfield; ' : .' A result can be sent to an accumulator; ' : @1', ' : @2', etc. Note that all accumulators are 32 bits / pixel and written as a single 8 bit gun, a Dot gun, or a 32 bit signed intermediate calculation result. NOTE: RPN commands may be easier to understand if you type a space between fields. iCALC always strips commands of blanks before executing. DISPLAY ISSUES In iCALC, the Display does not change until a result is assigned to its target color gun (or guns) via the result ':' operator; i.e. the Display does NOT change internally as a computation proceeds prior to result assigment. For example: 'R' always refers to the current contents of the RED gun on the display in front of you. If GLOBAL or MAPPED scope is active, the Display does not change until the entire action has completed. Then the Display is updated from the iBUFF. If the output is to an Accumulator, the Display will not change. Note that Accumulators are files that may only be accessed linearly. For this reason, an Accumulator may only be used once in a computation but resets once the computation completes. An accumulator may not serve as both source, and destination, of a calculation. Accumulators are useful to store intermediate results at full precision prior to writing to the Display. No efficiency is gained by a long computation string over several short ones. ARITHMETIC PRECISION AND FLOATING POINT NUMBER ISSUES iCALC internal calculations utilize 32 bit signed integers. However, results for individual guns are clamped to 8 bits of precision when displayed. Negative values are undefined. Deliberate use of 'clamping' to discard ranges of a result that are of no interest is NOT an error. REsults copied to the Dot Gun or an accumulator are not clamped. Since all internal computation uses 32 bit integers, with results clamped to a range of 0-255, a meaningful question is how to perform calculations involving floating point numbers. First, you need to understand that levels of precision finer than 1/256 in a final computation are meaningless, since they cannot be displayed. The iCALC RPN language is designed to eliminate the need for 'floating point' calculations by allowing for pre-scaling of values and post- scaling of results in a single command. The motivation is SPEED, since iCALC may be called upon to perform interactive calculations on GigaPixel datasets. *** ARITHMETIC PRECISION: KEY iCALC CONCEPT *** Any floating point number can be expressed as the ratio of two integers (a / b). Therefore, any floating point number can be expressed as a scaled integer with as little loss of precision as is desired. For example, the number (3.14159265) and (314159265 / 100,000,000) are exactly the same number. Obviously, the precision that can be preserved in 32 bit integers is limited, but so is the range (0-255) of meaningful results. Levels of precision that cannot be displayed are meaningless. Basic algebra will give you all the precision that you need for valid visualizations. If you do not know basic Algebra, we cannot help you. REX is not for stupid people. iCALC is a tool to precisely visualize relative numeric relationships within a range of 0-255 per color plane; not compute tables of precise numeric values. FLOATING POINT EMULATION To emulate floating point computation, scale (multiply) the operand by a value that converts it into an integer with the desired precision before performing the computation. Then de-scale (divide) the result by a value that scales it to a meaningful display. With some elementary Algebra, you can compute a result to any precision you need for a meaningful and accurate visualization. For example, to divide a color gun by another to an arbitrary precision, multiply the gun value by a suitable constant before dividing. The constants can be selected to window a specific range of the result within the 0-255 display range, knowing that negative values will be clamped to zero, and values > 255 will be clamped to 255. As long as you are aware of clamping and use it consciously, it is not an error. The rapid response of REX, the availability of a histogram, and the 'undo' capability enable iterative, interactive selection of constants until the desired visualization is obtained. THe iCALC design philosophy is to provide the simplest possible avenue to the visible result. It may not be the most obvious avenue, but the avenue exists. iCALC is a mathematically complete package for image manipulation rather than a grab-bag of solution stovepipes. You have the freedom to make truely spectacular and visually interesting graphical mistakes using iCALC, and possibly discover something new and unexpected in the process. Some of the great scientific discoveries of history originated as 'mistakes' that were noticed and pursued. Example: Divide Green by Red with the result displayed as a grayscale image: g r / : rgb # error. massive loss of precision in visualization g 128 * r / : rgb # better. precision of visualization preserved If we simply divide green by red, we will get a blank screen because most values will be either zero or a very low number. By scaling green so that the result is a visually meaningful range, we get a much better visualization. REX is all about VISUALIZATION of relationships. Also note that to view a single band result as a grayscale image, we must send the result individually to the R, G, B guns; i.e. 'R:RGB' creates a grayscale image from the single result. HIGH DYNAMIC RANGE [HDR] ACCUMULATORS All REX accumulators are treated as 32 bit signed integers if a single band, or as an unsigned 32 bit RGBA bitfield if multi-band. HDR images in floating point format are converted to integers by multiplying them by a PRECISION the user selects when creating the accumulator. For example, to perform HDR calculations to a precision of 0.001, each data point in the accumulator is the zero- normalized original HDR value, multiplied by 1000. If the HDR data is integer in its original format, the data is normalized but any selected conversion factor during accumulator creation is ignored. Precision beyond 0.001 is meaningless, since it cannot be displayed. Note that when computing with very large numbers, overflowing the 32 Bit signed integer register will occur at 2**31 (2147483647). Although this is a very large number, overflow is an issue. Similarly, any negative result is clamped to zero. If your results appear as random gibberish or zero, a numeric overflow or negative result is suspect. This is not a bug but a computer hardware limitation. DOT GUN [ . ] ISSUES The 'DOT GUN' is a segmented, 32 bit RGBA bitfield containing all 4 RGBA color planes. For this reason, a DOT GUN cannot be assigned to a single color. Similarly, a single color cannot be assigned to a Dot Gun. For example, [R : .] and [. : R] are invalid statements. Also, you may not use the 'Dot Gun' in a logical [<, >] statement, since a 'DOT Gun' does not represent a single numeric magnitude but a segmented field of independent RGBA magnitudes. The only constant defined for use with a Dot Gun is a (R,G,B) constant triad. If the Dot Gun appears alone to the LEFT of the assignment operator ':', it always refers to a 4 band, RGBA bitfield on the Display, in the iBUFF, or residing in an accumulator (see below). If the Dot Gun appears alone to the RIGHT of the assignment operator ':', the result overwrites all 32 bits of the Display hardware for each image pixel. If the result represents 3 or 4 bands, this is a valid statement. If the result represents a single band, this operation is undefined since a single band is not equivalent to a 32 bit RGBA bitfield. In such a case, the image will appear either blue or red, depending on the Display hardware. This is not a 'bug'. REX makes no attempt to be idiot-proof; merely crash-proof. Idiots can have a lot of fun with REX. You may always assign any arithmetic result to the Dot Gun ': .', even if it makes no sense to do so. In doing so, you establish that the result represents 4 bands. For example, [R 10000 * : .] is nonsense, but may prove visually interesting to an artist. This is called 'artistic license'. Do not go there if you are doing serious work. We sacrificed some semantic rigor in the iCALC language to art, since we do not wish to constrain digital artists. This is not a design error of the language, but a design choice. You may use the language rigorously, or carelessly with abandon. This is called Freedom. You cannot crash REX using iCALC. ------------------------- OPERATORS 'Operator' refers to the type of arithmetic/logical operation to be performed. using the [value operand operator] template. iCALC supports the following rich set of operators: addition [ + ] subtraction [ - ] multiplication [ * ] division [ / ] equal to [ = ] # when a logical condition IS NOT met not equal to [ ! ] or [!=] # the result is zero. When a logical greater than [ > ] # condition IS met, there is no change greater than or equal [ >= ] less than [ < ] less than or equal [ <= ] assign if result zero [ { ] # replace zero logical result with operand ..if result non-zero [ } ] # replace non-zero logical result with operand bitshift left [ << ] bitshift right [ >> ] bitwise boolean AND [ & ] bitwise boolean OR [ | ] bitwise boolean XOR [ ^ ] # EXCLUSIVE OR [see: 2s complement below] bitwise boolean NAND [ !& ] # not AND bitwise boolean NOR [ !| ] # not OR assign result [ : ] # assign left of ':' to Display or accum ARITHMETIC ACCUMULATORS; @1, @2, @3, @4 The symbol [ @ ] refers to an image 'accumulator'. In iCALC, an accumulator is temporary storage from which values and operands can be read, or to which results of a calculation can be assigned and saved. There are only two types of accumulators: Color and Grayscale. Color accumulators always contain 32 bit, unsigned RGBA bitmasks. Grayscale accumulators are 32 bit signed integers and contain intermediate iCALC results, or a high dynamic range [HDR] grayscale image. In either case, an Accumulator has a single 32 bit integer for every image point. These are the same accumulators used by 'AOI OPS|ACCUM|CROP', 'BUFF OPS|CROP', and 'BUFF OPS| sBUFF|RENDER|ACCUM'. An accumulator can be any size. NOTE: To use an accumulator in a calculation, its dimensions must exactly match the dimensions of the FG AOI, or iBUFFER; depending on the selected mode. For GLOBAL mode the Accumulator must match the dimensions of the iBUFF. For MAPPED or Display [Default] mode, it must match the FG AOI dimensions. You can use 'AOI OPS|ACCUM|SET FG AOI' to set the FG AOI to the same dimensions as an accumulator, and drag it to the desired location. Similarly, 'BUFF OPS|CROP TO|BOX' enables you to specify the exact dimensions of either an iBUFFER, or an accumulator, to crop to; with no size limit. Photographic merging and transparency is done using accumulators that have been pre-loaded with imagery using other REX utilities, but the same rules apply. A RGBA image is written as an unsigned, 32 bits. A single band of a RGBA image, an intermediate result, or a single band of a HDR image [see sBUFF] is written as signed 32 bits. Do not confuse an Accumulator with a Scaling Buffer [sBUFF]. They are different. The Dot Gun [.] is always written as 32 bits. It always represents a RGBA color bitmask treated as a unit. Example: Copy a RGBA image to accumulator #1; . : @1 RGB color accumulator Copy a HDR result to accumulator #1: . : @1 HDR grayscale accumulator Copy the Green image planes to #1; g : @1 8 bit grayscale accumulator Accumulators enable complex calculations to be performed by storing intermediate values at full precision, and enable up to 4 images [4 Accumulators] to be imported into the calculation process. When reading a grayscale accumulator, the contents can be treated as any color in a calculation; i.e. specifying @1R or @1G or @1B will access the same grayscale image, but only 8 bits will be loaded to the designated color. Loading an accumulator as a Dot [.] gun loads 32 bits that can be treated as either a RGBA bitmask, or a HDR value to be used as operands in a calculation that will render a viewable result. When reading a color accumulator, then specifying R or B or G will access different 8 bit color planes within the bitmask. If you specify the Dot Gun '.' [ @1. ] then each pixel will be treated as a 32 bit value that is treated as either an unsigned bitmask, or HDR value, depending upon context. Example: Copy the blue colorplanes from a color accumulator; @1b : b Copy a grayscale accumulator to the blue colorplanes; @1b : b Copy a color accumulator to the RGB display; @1. : . Unlike the display, accumulators cannot be selectively overwritten. When you specify an accumulator for a result, the contents of the accumulator will be destroyed and replaced as 32 bit values for both a Dot Gun [.], or a designated color plane. So, at the semantic level, how do you know if an accumulator represents an RGBA image, a single 8 bit Grayscale image, a HDR iCALC intermediate calculation, or a HDR grayscale image? You remember. The same way you remember what any variable in a calculation represents. If necessary, keep notes. If you forget, a garbage result will remind you. You cannot crash REX using iCALC. Single band accumulators are not directly displayable as a color image and their appearance is hardware dependent; i.e they will appear as either a red image or a blue image depending on the computer graphics hardware. If '@1' is a grayscale image; '@1. : .' is undefined; appears red or blue '@1. : r' is RED. '@1. : g' is GREEN, etc. Accumulators remain unmodified (and occupy storage) until accessed or REX terminates. iCALC MODES OF OPERATION AND THEIR FLAGS iCALC supports several modes of operation. These modes are indicated by flags that are displayed on the iCALC graphical user interface. The Default Mode is for all input, and output, to be the Display FG AOI. Global: If the 'Global' flag is set, operations will effect the entire image buffer in memory and will be irreversible. Even if the iBUFF is gigabytes in size, the entire buffer will be changed. In Global mode the iBUFF is both input source, and output destination, of iCALC. Upon completion of a calculation the Display will update to the iBUFF visible. Type 'GLOBAL' to toggle this mode ON. 'GLOBAL=false' to exit. Mapped: If the 'Mapped' flag is set, operations will effect the portion of the iBUFF that maps to the current Foreground Area of Interest. If there is no mapping, nothing will change. Input source is the Display, but results are written to iBUFF. Upon completion of a calculation, the FG AOI region of the display will update to the iBUFF visible. Type 'MAPPED' to toggle this mode on. Type 'MAPPED=false' to exit. Absolute Value Mode: Subtraction can result in negative values. When 'Abs' is on, negative results are automatically converted to a positive magnitude during calculation. Positive results are unchanged. Type 'ABS' to toggle this mode on. ABS=false to turn it off. Ancil: If the ancillary Display is enabled, results of calculations auto- matically update the histogram. You can switch on the roam/zoom utility by typing 'ANCIL'. You switch it off by pressing the RightMouse button. This enables you to carefully examine iCALC results in the zoom/histogram window without exiting iCALC. ANCIL requires the ancillary display to be enabled. Undo: You can restore one or all color guns to their original state by typing 'UNDO=gun' where gun is 'rgb, r, g, b'. The contents of the image that was visible when iCALC was entered (or the Display was TOUCHED) will overwrite the Display for that gun. As a shorthand, typing 'U' equals 'UNDO=RGB' Note that the Display is updated with its most recent 'touched' state, not the iBUFF. Touch: Entering 'touch' will cause the current Display state to become the state that is recovered by the 'UNDO' command. It enables you to prevent a desired Display state from being lost while experimenting. This command does NOT update the separate 'Touch' buffers under the DISPLAY menu. The CALCULATE Display state is automatically 'Touched' upon entry, and released upon exit. AOI: Entering 'aoi' enables you to redefine the foreground area of interest (FG AOI) without exiting iCALC. This is useful for transforms such as 'red eye removal' that are localized to small areas. The FG AOI will remain as defined until it is explicitly re-defined; in iCALC or the main menu. Debug: Sometimes the results of image calculations are not intuitive and surprises may occur. 'Debug' will cause the results of the scanline center pixel of every 25th scanline to be dumped as textual integer values to the terminal from which REX was launched. This will occurr at each stage of the calculation. Type 'debug' to activate Debug. Debug=false to exit. Note that 'Debug' has two modes: 'Debug' prints pixels as RGBA decimal quads; 000,000,000,000 'XDebug' prints pixels as hexadecimal bitfields; 0X00000000 Please do not report a 'bug' in iCALC until you have verified that the results are, in fact, mathematically erroneous based on the inputs and operators using the DEBUG facility. Image arithmetic using RPN is rigorous and consistent, but not always intuitive. ARITHMETIC OPERATORS; + - * / The arithmetic operators correspond exactly to their familiar counterparts. The only difference is that arithmetic operations are performed upon image areas instead of individual numbers. Numeric operands derive from the color luminance [0-255] for selected colors at each point. The operation template is: . Arithmetic operations are performed as signed integers to a precision of 32 bits. It is important in arithmetic expressions to ensure that final results assigned to the Display fall within the range of 0 to 255 for each color gun. Results outside this range are automatically clamped to a range of 0-255 when displayed. Clamping is central to iCALC. Out of range values are not an error; just ensure that the desired visualization is within the clamped range. You may find it useful to have a pocket calculator handy when using iCALC to test ideas. Note that results assigned to an accumulator (discussed below) are never clamped but are stored at full 32 bit precision, and they MAY be negative. Clamping occurrs ONLY at the moment results are written to the display. 2s COMPLEMENT OPERATOR A missing operator is the '2s COMPLEMENT' or 'NOT' operator. This operator flips all the bits in the operand; 0s to 1s and 1s to 0s. To compute the 2's Complement of a value, simply compute the boolean 'XOR' using a full bitfield; i.e. . 0x00FFFFFF ^ : . # compute 2s complement of RGB . 0xFFFFFFFF ^ : . # compute 2s complement of RGBA G 0x0000FF00 ^ : G # compute 2s complement of GRN only BIT SHIFTING iCALC supports shifting the 32 bit value left or right by as much as 31 bits. Note that the bits 'shifted out' by the operation are lost. An invalid shift value is treated as zero and ignored. Shifting is a 'Register Shift' that discards shifted bits; NOT a 'Barrel' or 'Circular' Shift that preserves them. The sytax is: value constant << # shift is << or >> ; 1 <= constant <= 31 For example: . 8 << : . # shift the current RGB Display left 8 bits NUMERIC CONSTANTS; SIMPLE VALUE AND RGB-TRIAD Numeric constants are used for scaling input and results, or for defining ranges of interest. Numeric constants can be either decimal (base 10) or hexedecimal (base 16). The default is decimal. Hexadecimal constants must possess a leading, '0x', i.e. 0xFF for 255. Negative decimal constants are invalid. Numeric constants may define RGBA color triads; i.e. '(const,const,const)'. In such a case, each constant is constrained to a range of 0,255 and the contents of the RGB triad will overwrite all three color guns. Using a RGB triad defines the result as a 'dot gun' result. Note that RGBA color triads are the only place that constants may be concatenated. Example: Yellow consists of simultaneous display of RED and GREEN (255,255,0) Convert all pixels with 0 in the red planes to yellow. To do this, we will use the 'set-if-zero' operator to convert every pixel with a zero in the RED gun, to YELLOW. r (255,255,0) { : . // flag red = 0 as YELLOW Note that we can only assign an RGBA color result by assigning the result to the Dot '.' gun. If we assign a result to a specific gun, only the lowest 8 bits of the result are assigned. On most machines, the result will be BLUE. LOGICAL OPERATORS [=, >, >=, <, <= ] Logical operators define a logical relation between a value and its operand. Where the logical relation is True, the original color remains unchanged. Where the logical relation is False, the color at that point is set to zero. Logical operators are closely tied to use of the 'set-if-zero' [ { ] and 'set- if-non-zero' [ } ] operators discussed below. Example: Display only red pixel values equal to 200 as a grayscale image. Note that all pixels where RED is NOT 200, will be zero (black). r 200 = : rgb Display only RGB pixel values equal to (200,77,12) Note that a RGB pixel can only be expressed as a DOT gun and compared to a RGB triad constant. The result must be rendered to a Dot Gun '.'. . (200,77,12) = : . // 'dot' gun stands for RGB You can also use a COMPOUND LOGICAL OPERATION to define ranges of values. Example: Display red values > 100 and < 200 as a grayscale image r 100 > 200 < : rgb // red values > 100 and < 200 *** IMPORTANT *** Sometimes you must use accumulators to achieve a desired result since it is not always possible to achieve it with a single RPN command. Example: Display only red values < 100 AND > 200 as a grayscale image r 200 > 100 < : rgb // ERROR! result of first operation zeros ALL <= 200 r 100 < 200 > : rgb // ERROR! result of first operation zeros all >= 100 Use two commands to realize the desired result r 200 > : @1 // red values > 200 to @1; others set to zero r 100 < @1r { : rgb // red values < 100 AND > 200 displayed as grayscale or // For '{', see ZSET operators (below) r 100 < @1r | : rgb // For '|' see OR operator (below) BOOLEAN BITWISE OPERATORS; AND [&], OR [|], XOR [^], NAND [!&], NOR [!|] Boolean bitwise operations enable you to segment an image into subsets based upon relationships between individual bits in the color planes. Each bit in each color plane is treated independently. The 'truth tables' for bitwise boolean operators are: -and- -or- -xor- -nand- -nor- 1 & 1 = 1 1 | 1 = 1 1 ^ 1 = 0 1 !& 1 = 0 1 !| 1 = 0 1 & 0 = 0 1 | 0 = 1 1 ^ 0 = 1 1 !& 0 = 1 1 !| 0 = 0 0 & 0 = 0 0 | 0 = 0 0 ^ 0 = 0 0 !& 0 = 1 0 !| 0 = 1 Bitwise operators are often used with constant 'bitmasks' to segment imagery. The operation template is: . Examples: Clear least significant 4 bits of every pixel in Red gun: r 0xf0 & : r Clear most significant 4 bits of every pixel in Red gun, then scale the result to a range of 0-255: r 0x0f & 16 * : r Merge two disjoint grayscale images held in accumulators @1 and @2; 'disjoint' means that the 2 images do not overlap any histogram segments for any given color @1. @2. | : rgb Merge two grayscale images, where a range within one image is replaced by the other image. Images need not be disjoint @1. 120 > 180 < @2. { : rgb Invert all bits of Red gun: r 255 ^ : r -or- r 0xFF ^ : r Zero all Red bits that are in different state than Blue: r b & : r You could write a book on all the stuff you can do... BOOLEAN LOGICAL OPERATORS Unlike Boolean BITWISE operations, Boolean LOGICAL operations between images are undefined in iCALC. The 'set-if-zero' [ { ] and 'set-if-nonzero' [ } ] replace Boolean logical operations. SET-IF-ZERO (ZSET) [ { ] and SET-IF-NONZERO (NZSET) [ } ] operators The result of logical operations [ = != > >= < <= ] is always set zero if the logical condition is NOT satisfied. If the condition is satisfied, then the result is the original value. For example 'R 180 <=' causes all red gun pixels greater than 180 to be set to zero, and all pixels that satisfy the condition to remain unchanged. Similarly, other logical or arithmetic operations may result in zero or non-zero values. Replacement of a ZSET value with its operand depends upon whether the value is zero or non-zero. You can assign an operand to a single color gun or to all three [R,G,B] color guns based on a zero or non-zero value. This is how photo- graphic merging is done. The SET-IF-ZERO [ { ] operator converts all ZERO values of a result to its operand. The operand can be a constant, a single color gun, or a Dot gun '.' (RGBA color). Values that are not zero remain unchanged. The SET-IF-NONZERO[ } ] operator converts all NON_ZERO values of a result to its operand. The operand can be a constant, a single color gun, or a Dot gun '.' (RGBA color). Values that are zero remain zero. Note that when a RGB color triad (r,g,b) constant is used, all 3 color guns must be overwritten by the result [:] designation. In such a case, result gun assignment should be ' : .'. The operation template is Example: Assume you are viewing a RGBA image and you have another RGBA image in accumulator '@1'. You want the image in '@1' to selectively overwrite the areas where the Display RED gun is greater than 122 and less than 143; also overwriting the contents of the green and blue guns. First, create a mask in accumulator '@4' that defines the logical relation desired; R 122 > 143 < : @4 // red > 122 and red < 143 is non-zero in @4 Note that the Display is unchanged since accumulator '@4' was the target of the operation. Next, use the mask just created in '@4' to flag where to overwrite the Display with the RGBA contents of the image in accumulator @1. Note that the target gun [ : . ] specifies the current RGBA display. @4. @1. } : . // set non-zero area to RGBA contents of @4. You are done. The image in @1 now overwrites the Display for regions where the range in the Display where 122 < RED < 143. PHOTOGRAPHIC MERGING MULTIPLE HDR BANDS USING ACCUMULATORS Compositing a multi-band image from accumulators is a simple task using iCALC. This can be done for areas on the Display, or for arbitrarily large images via the 'GLOBAL' flag. Note that iCALC requires all image operands of a command to have the same X,Y dimensions; be they areas on the Display or entire buffers. First, read and scale your HDR data using the capabilities of the Scaling Buffer, sBUFF. When the B&W image on the Display is satisfactory, save it to an Accumulator. To work with an entire image of arbitrary size, use: 'BUFF OPS | iBUFF | CROP TO | ACCUM', and set the GLOBAL flag in iCALC To copy the FG_aoi area on the Display to an accumulator, use: 'AOI OPS | ACCUM | CROP TO', but not use the GLOBAL flag in iCALC. If working on an entire iBUFF, the buffer that is active when entering iCALC becomes the buffer that will contain the final composed image. Once in iCALC, you composite the other image planes into your image via the following commands. Note that 'global' flag is for global scope operations: global # use ONLY if scope is entire iBUFF @1r : r # accumulator 1 has grayscale image for RED plane @2g : g # accumulator 2 " for GREEN @3b : b # accumulator 3 " for BLUE and optionally @4a : a # accumulator 4 " for ALPHA (global scope only) The result is a RGBA color image composed of the contents of the 4 accumulators. If the color planes are not registered, see: 'BUFF OPS | iBUFF | REGISTER' to align the RGBA planes with one another. See also: 'BUFF OPS | ROTATE' and 'BUFF OPS | RESIZE' to address registration issues. PHOTOGRAPHIC MERGING VIA ALPHA TRANSPARENCY EFFECTS If an image contains an 'ALPHA' layer treated as a Transparency operator (instead of an overlay), an Alpha value of 255 means the image at that point is opaque. An Alpha value of zero means the image at that point is Transparent. An image need not contain an Alpha layer. Any image may serve as an Alpha (Transparency) layer. Transparency operations consist of a BASE image 'B', an OVERLAY image 'O', and a ALPHA image 'A' that defines the degree to which the base image 'B' will be visible through the OVERLAY image 'O'. An ALPHA of zero means the Overlay image is Transparent and the Base image is Visible. An ALPHA of 255 means the Overlay image is Opaque and the Base image is Invisible: view | Obscuring RGB image | Alpha transparency operator V Base RGB image The transparency equation is: ((A * B) + ((255-A) * O)) / 255 : result For example, assume: The 'Base' RGB image, 'B' is the currently visible image on the display. The 'Alpha' image, 'A' resides in accumulator '@1' as a single band (grayscale). The 'Overlay' RGB image, 'O' resides in RGB accumulator '@3' so, @1 is grayscale Alpha image @2 is (255 - Alpha) image // compute this once for speed @3 is Overlay RGB image The iCALC syntax to merge a RGB base, and RGB overlay, using the ALPHA plane is: 255 @1. - : @2 // @2 is (255 - Alpha) compute only once @1. R * : @4 // @4 = A * R @2. @3R * @4 + 255 / : R // merge Base and Overlay for RED @1. G * : @4 // @4 = A * GRN base @2. @3G * @4 + 255 / : G // merge Base and Overlay for GRN @1. B * : @4 // @4 = A * BLU base @2. @3B * @4 + 255 / : B // merge Base and Overlay for BLU You could also use a different ALPHA layer for each RGB color if the ALPHA image is itself an RGB image. The possibilities are limitless for using RGB images as transparency operators for merging RGB images. The use of images of clouds as transparency operators gives 'interesting' results. This opens vast possibilities to abstract digital artists. CREATING TEMPLATES FOR PHOTOGRAPHIC MERGING Merging images using logical operators is trivial. You simply designate a range in the histogram of one image that will be replaced by the other image; Example: Overwrite the red gun in the Display with the red gun in an image stored in accumulator @1 for the range 100 to 200. r 100 > 200 < @1r } : r Sometimes, things are not so simple, so you need to manually draw a template that outlines a specific area of an image that is to be replaced. You can use the ANNOTATE utility to create templates designating shapes. Simply draw an edge around a feature of interest, fill it with a color, store the result in an accumulator, then iCALC uses the template to determine where one image overwrites another. Annotate allows you to specify colors as hexadecimal numbers, giving you total control over image masking at the bit level. By selecting the color of the masks, (black [0x00000000], white [0x00FFFFFF], etc) you exercise precise spatial and logical control over image merging. Example: We want the contents of one color image to appear in an irregular area (or any geometric shape, pattern, etc.) in another image. Select the iBUFF containing the image to overwrite another image and display the image. Create a FG AOI of the desired area to copy. Note the dimensions of the AOI may not change. Copy the image into the '@1' accumulator using the AOI/CUT command. Select the iBUFF containing the image to be overwritten and display the image. Move the FG AOI over the area to be transformed. The dimensions of the AOI may not change! Activate the ANNOTATE utility to create a template. Set the foreground color of the template using SET/COLOR. Usually this will be either white or black. Note the hexadecimal value of the color using ANNOTATE/STATUS. Draw the template as a closed polygon or figure over the areas of the image that are to be replaced by the contents of accumulator '@1'. There may be one or several areas in a template. Exit ANNOTATE. You now see the areas on the image that will be replaced with the image in accumulator '@1' as colored polygons. Assume that we used the color WHITE (255,255,255) to designate the areas to overwrite. Then the follwing command will perform the operation. . (255,255,255) != @1. { : . In words, zero out all RGB pixels that equal white (255,255,255), then use the SET-IF-ZERO operator to replace all zero value pixels with the contents of accumulator '@1'. Since we use the dot '.' gun, this is done for all three color planes simultaneously. Of course, you can get much more complicated than the above, but you get the idea. You should be able to match the image composition capabilities of any other software product on the market, since all necessary primitive operations are supported. Basically, you use your mind instead of a complicated GUI crammed with stovepipe templates. USING LOGIC TO CREATE TEMPLATES Suppose you have a background that you want to selectively overwrite with another image saved in accumulator #2, but the background consists of hundreds of discrete RGB values within a range. You can dramatically lower the number of discrete values you have to deal with by compressing the range. For example: R 4 / 4 * : R # reduce number of discrete values by factor of 4 G 4 / 4 * : G B 4 / 4 * : B This will dramatically lower the number of discrete RGB values; say from hundreds to less than a dozen while still retaining the background as a distinct region. Then you can use 'mouse' to determine that the background area to be selectively overwritten has been reduced to 3 discrete RGB values: (200,166,90) (216,150,74) # the target region confined to these RGB values (190,80,220) Next, you save result as a template and restore the image to its original state . : @1 # save to accumulator @1 to use as a template undo # restore original image state Now overwrite the background with the image in accumulator #2. You set the selected background to zero, then selectively overwrite it @1. (200,166,166) != @2. { : . @1. (216,150,74) != @2. { : . @1. (190,80,220) != @2. { : . The result of the above is to selectively overwrite a background area with an image stored in an accumulator. This is a flexible approach with many uses. Note that the 'PIXEL OPS/MCD' function also reduces an image to homogeneous self-similar regions by reducing variability within regions. iCALC: CONCLUDING REMARKS One could easily write a book on the myriads of applications of iCALC in specialized analytical and creative imaging domains using its simple but complete language. There are myriads of analytical avenues possible withi the deceptively simple iCALC interface; although on occasion it may not be immediately obvious. APPENDIX B: THE IMAGE CONVOLUTION SUBSYSTEM: CONVOLVE CONVOLVE is the spatial convolution transform subsystem of REX. It provides the user with interactive access to high-performance spatial convolution operators. As with other REX utilities, entire textbooks have been written on the theory and application of image convolutions. The REX convolution system enables the user to interactively define and execute convolutions, ingest and execute pre- defined convolutions from a file, store convolution definitions to a file, and interactively analyze the results of convolutions while remaining in the CONVOLVE system. As implemented in REX, a convolution consists of convolution 'kernel', and rules for application of the kernel on the image. As with other REX utilities, convolutions may be applied selectively to RED, GREEN, BLUE or RGB image planes. A convolution kernel consists of a 2-D matrix of signed integers that is scanned across an image a single pixel at a time. The kernel values may be positive, zero or negative. For performance reasons, REX supports two types of kernels; the 'Cross Kernel' [+], and the 'Box Kernel' [X]. Each kernel has its areas of utility. The sequence of numbers in either type of kernel is always specified from top to bottom, left to right. This is also true when the kernel is read from a file. There are no exceptions. A kernel must have odd number dimensions (3X3, 5X5, etc.) but need not be square. Note that the REX implementation of CONVOLVE does not 'pollute' the results of a spatial convolution by writing the results back to the image within the spatial scope of the active convolution kernel. Results are buffered until the scope of the kernel has passed, and are only then displayed. Note also that every convolution will possess a 'border' of untransformed pixel values. This is because the convolution only replaces the center pixel of a convolution kernel. The larger the kernel, the wider the border region of unchanged values. This is normal and expected behavior and not a 'bug'. CONVOLUTION KERNELS Convolution kernels may be any size or dimension, up to a maximum of 31 on a side. A kernel need not be a perfect square, but each dimension must be an ODD number, since the center pixel must be the geometric center of the kernel. Kernels with an even number for a dimension will be rejected. Note that as the kernel size increases, the amount of computation increases geometrically. The REX convolution operator is highly optimized for speed but even so, very large kernels may take a noticable time to compute. The 'Cross Kernel' [+] consists of an array of numbers arranged in a 'Cross'. A simple example is an 'averaging' kernel: 1 1 1 1 ktype=3+3 (5 values) 1 or 1 1 1 1 1 1 1 ktype=5+5 (9 values) 1 1 etc. This convolution simply replaces the center value with the average of all values in the kernel. It is a data smoothing operator. The same convolution may be expressed with a 'Box Kernel' [X] : 1 1 1 1 1 1 ktype=3X3 (9 values) 1 1 1 or 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ktype=5X5 (25 values) 1 1 1 1 1 1 1 1 1 1 etc. Note that the 'box' kernel performs more computations covering more area of the image than a 'cross' kernel. The 'box' kernel is thus slower than a 'cross' kernel, but functions exactly the same. The 'cross' kernel is offered as a separate kernel type purely to provide a much faster computation for this and other common kernels. You can also create an variant of the 'cross' kernel, by zeroing out values in a 'box' kernel, such as: 1 0 1 0 1 0 ktype=3X3 1 0 1 or 1 0 0 0 1 0 1 0 1 0 0 0 1 0 0 ktype=5X5 0 1 0 1 0 1 0 0 0 1 etc. Kernel entries with a zero value are treated as if they do not exist. Such asymmetrical kernels may have interesting properties, but have no computational advantage over the simple 'box' kernel. Any position in a kernel may take on any value; i.e. kernels need not be symmetric, but few configurations are meaningful. Even so, the curious are free to experiment. Artists can have fun here. NOTE: Kernel values are limited to a range of -32766 to +32767. CONVOLUTION COMPUTATION Convolutions are computed by scanning a 2-D kernel across an image, 1 pixel at a time. The convolution scan is always from left to right, top to bottom. At each position within the convolution kernel, an image pixel corresponding to the position of a kernel pixel is multiplied by the contents of the kernel pixel. The result is added to a single 'convolution sum'. The 'convolution sum' is then applied algorithmically to the pixel on the image corresponding to the center position of the kernel, the kernel is moved one pixel, the convolution sum is reset to zero, and the process repeats. The convolution result does NOT take part in subsequent convolution computation. Convolution is a very compute- intensive process, but REX uses a fast algorithm. Except for Global Transforms on huge images, Convolve executes sufficiently quickly to be interactive. NOTE: ALL COMPUTATION IS PERFORMED USING INTEGERS TO 32 BIT PRECISION. SEE 'ARITHMETIC PRECISION AND FLOATING POINT NUMBER ISSUES' DISCUSSION (APPENDIX A) FOR SCALING STRATEGIES TO PRESERVE FLOATING POINT PRECISION IN CONVOLUTION CALCULATIONS. CONVOLUTION KERNELS CONTAINING FLOATING POINT VALUES CAN BE EASILY SCALED TO INTEGER-BASED KERNELS WITH NO MEANINGFUL LOSS OF PRECISION IN THE DISPLAYED RESULTS. CONTROLLING THE CONVOLUTION: 'CSUM', 'CVAL' and 'CSCALE' 'CSUM' is the variable that controls how the 'convolution sum' is treated once it has been computed. It's values may be: csum = 0 'convolution sum' is unchanged csum = 1 divide by the sum of kernel definition values (a constant) csum > 1 divide by the arbitrary constant assigned to 'CSUM' This result is the 'convolution value'. 'CVAL' is the variable that controls how the resulting 'convolution value' above is applied to the original image. Its values may be: cval = 0 replace the center image pixel with the 'convolution value' cval = 1 add the 'convolution value' to the center image pixel, cval > 1 add the 'convolution value' to the constant assigned to 'CVAL' 'CSCL' [CSCALE] is the variable that enables convolution kernels containing floating point numbers to be scaled to integers without loss of precision. 'CSCL' defines the scaling operator applied to a kernel to convert it to integer values. Its values may be: cscl = 0 no scaling cscl > 0 divide 'convolution sum' by value of 'cscl' cscl < 0 multiply 'convolution sum' by value of 'cscl' For example, if a kernel value was PI ( 3.141595 ), it would be expressed as ( 3141595 ) during the convolution, with 'CSCL = 1000000'. Note that ALL numbers of the kernel are presumed to be scaled by the same value. Note that the final results of a computation are clamped to a range of 0-255 before being written to the display. All negative values are set to zero, all positive values > 255 are set to 255. If the histogram of a convolution is badly skewed to the left or right, it means that the kernel values or scaling may need to be adjusted iteratively to achieve the desired visualization. THE CONVOLVE GUI CONVOLVE is like iCALC and the REX image loader in replacing a potentially complex GUI with a simple commandline and flag based GUI. You perform convolutions by typing commands at the commandline. There are only a few. Note that these commands set values to a state that remains until it is explicitly changed by another command. Ktyp : Specify the dimensions of a kernel and its type (Box or Cross). A flag on the CONVOLVE menu shows the state of this parameter at all times. You specify a kernel by typing in the X dimension, the kernel type, then the Y dimension. For example, a 3 by 3 'box' kernel is defined by: Ktyp=3X3 A 3 by 3 'cross' kernel is defined by: Ktyp=3+3. Note that the character 'X' separating dimensions indicates a 'box' kernel, and '+' indicates a 'cross' kernel. Once you change the dimensions or type of a kernel, you MUST define its contents with the 'Kdef' command. Kdef : Define the kernel. The size and dimensions of a kernel were defined by the 'Ktyp' command. Kdef will read the kernel contents from the command line until the kernel is filled. You may press 'Enter' as many times as required. Kernel values are read, and the kernel is filled, from left to right, top to bottom, as determined by the kernel type, dimensions and size. When the kernel has been filled, Kdef will stop soliciting input. Note that once a convolution kernel is defined, it remains unchanged until re-specified and can be executed repeatedly. Csum : This command defines what to do with the RAW convolution sum, yielding the 'convolution value'. A flag on the CONVOLVE menu shows the state of this parameter at all times. The possible values are: 0 = do nothing [default] 1 = divide the raw result by the sum of the kernel contents ~ = divide the raw result by the constant specified (+/-) '~' indicates a number other than 1 Cval : This command defines what to do with the 'convolution value'. A flag on the CONVOLVE menu shows the state of this parameter at all times. The possible values are: 0 = convolution value simply replaces center pixel [default] 1 = convolution value is added to the center pixel ~ = (convolution value + constant) replaces center pixel '~' indicates constant other than 1 Cscl : This command defines the scaling constant applied to a kernel so that floating point values may be expressed as integers, or as a simple linear scaling function. The possible values are: 0 = no scaling >0 = divide the convolution sum by the value of Cscl <0 = multiply the convolution sum by the value of Cscl Kexe : Execute the current kernel definition on the target image. If a kernel is not currently defined, an error message is issued. 'KSCALE' Note that 'Kexe' offers an optional, ancillary command 'Kscale=value'. If 'Kscale=value' follows 'Kexe' on the commandline, then the contents of the convolution kernel are multiplied by 'value' prior to computing results of a convolution. This has the effect of enhancing the contrast of the convolution and enables you to test the viewing properties of ranges of kernel values without having to recode the entire kernel. The kernel is re-scaled only for the single command qualified. Kfil : Open a kernel definition file. Only the above CONVOLVE commands may be encoded in the kernel definition file. This is useful if you are working with kernels that are too large to type in repeatedly. Ktag : If a kernel definition file is open, 'Ktag=kernelTag' will load a convolution kernel defined by the given 'kernelTag' within the file. This enables you to define many convolution kernels in a single file and selectively access them by their tags. Ksav : Save the convolution kernel definition to the indicated filename. If an existing kernel definition file is open, the kernel definition will be appended at the end of the file. Kpath: Set path to directory containing convolution kernel definition files. ANCILLARY COMMANDS Guns : Specify the color guns that are to be modified by the convolution. Guns may be R, G, B, or RGB. Each color plane is treated independently and remains as set until re-set. Undo : Overwrite the current FG AOI with the contents of the Display Buffer. This erases any convolution results currently displayed. Touch : Save current state of Display in the Display Buffer [see UNDO] Mouse : Roam and zoom the Display to analyze results of a convolution, but do not exit the convolution system. Press R MOUSE to resume. CONVOLUTION FILES A convolution file is simply a text file that defines one or more convolution kernels. The file utilizes the same commands that are presented by the GUI and the same requirements must be met. Specifying 'Ktag=' without the filename assumes the file has already been specified with an earlier 'kfil' command. So you may do something like: kfil=convolv1.ker # open convolution kernel file 'convolv1.ker' ktag=tag6 # read kernel 'tag6' kexe # execute the convolution ktag=tag2 # read kernel 'tag2' kexe # execute ktag=tagN # read kernel 'tagN' kexe kexe kexe # execute kernel 'tagN' multiple times kfil=convolv2.ker # close file, and open new kernel file 'convolv2.ker' ktag=tagA : A kernel file remains open until another file is opened, or you exit CONVOLV. The format of a convolution kernel file is very simple: # # Any line beginning with a '#' is a comment. Use to document convolutions # Note that a 'tag string:' is required, even if there is only one kernel def. # # a blank line is treated as a comment avg3x3: # text string, ending with a ':', tags this kernel ktyp=3X3 # set kernel type and dimensions kdef= 1 1 1 # define kernel.contents 1 1 1 # Note that you can list kernel values graphically 1 1 1 csum=1 # divide kernel result by sum of kernel definition cval=0 # simple replacement of center pixel with result cscl=0 # no scaling kend # end of kernel definition, OR, kexe # end kernel definition, AND immediately execute gauss16: : kend # # It is a good idea to always explicitly define 'csum' and 'cval' instead # of relying on defaults. # The active kernel remains defined until it is replaced, or CONVOLVE exits # A kernel can be repeatedly executed once it is defined # You can define as many convolutions in a single file as you like. Each one # must be immediately preceeded by a UNIQUE tag string ending with ':'. # If a tag is defined more than once, the first tag will always be used. # USING CONVOLVE As usual with REX, we have demonstrated how to use a powerful tool without providing much of a technical background on the theory and application of the tool. For CONVOLVE, the reason is simple; the theory and application of spatial image convolutions is a domain of complex and deeply mathematical scientific knowledge. We hope this tool may inspire gifted persons to study and contribute to this important field of knowledge. If interested in image convolution, any decent book on image processing will get you started. You should be able to sit with the book in front of you, key in the kernels, and view results identical to those in the book. From there, you can use your imagination. REX is about using your imagination in an environment where there are no boundaries. Users interested in convolutions may also be interested in the Fourier Transform capabilities of REX, since they are related. FFT is used for many similar operations to convolutions, but usually in a more advanced context. CONVOLVE is one of the few systems on REX that requires specialized knowledge to use productively. There is a vast realm of convolution operators that can be applied to images. Fields such as artificial vision, feature analysis and extraction, etc. are heavily involved with convolution operators. The 'hard coded' REX convolutions (sharpen, Gaussian, etc.) use the same code as CONVOLVE, but simply bypass the GUI. Persons in possession of specialized knowledge can quickly utilize CONVOLVE as a powerful, high performance research tool. A large scientific literature exists on convolution operations applied to image processing and CONVOLV makes an excellent 'hands on' laboratory for such study. If you are interested in CONVOLV, you probably want to look at 'PIXEL OPS/FFT' (Fast Fourier Transform) as well. APPENDIX C: FOURIER TRANSFORM SUPPORT NOTE: The FFT implementation used by REX is the same code used by Space Telescope Science Institute (STSCI) and other astronomical research organizations. It was selected because it is compact, very fast, and only requires that the dimensions of an image be an even number. Full source code for this FFT implementation is provided, ensuring compatibility between REX and external FFT processing. We cannot guarantee consistent FFT results using any other FFT code. REX only supports 32 bit Float FFT (Magnitude and Phase) at this time. 64 bit may be supported in the future. An 8-Bit visualization space makes 64 Bit precision superfluous. Once you have computed the FFT of an image to the sBUFF, you can use the REX scaling subsystem to analyze the FFT. You may also compute the inverse-FFT and use the scaling system to analyze the original image in unexpected detail. The uses of the FFT are too many and varied for a single implementation to encompass them all. REX enables you to compute the FFT of an image and store it as a floating-point, full precision file in 'Scaling Accumulator' format. Similarly, REX will ingest a user created FFT file in the same format, permitting computation of the INVERSE FFT and visualization of the results. A trivial test is to compute the FFT of an area, export the FFT as a file; then ingest the file directly into the scaling buffer and compute the INVERSE FFT. Note that the INVERSE FFT result should identical to the original image when properly scaled. A typical scenario might involve exporting the FFT of an image, performing a convolution on the FFT dataset (deblurring, motion compensation, etc.), then importing the transformed FFT back into REX for INVERSE FFT computation and exploitation. FFT's are stored as multi-band images, with a 'real' magnitude band, and an 'imaginary' phase band existing for each color band. The maximum number of bands that can exist in a FFT file are 8 bands, 2 for each channel (i.e. RGBA). A 'grayscale' FFT image will consist of 2 bands. No other number of bands is supported for FFT. The real and imaginary bands are stored in 'Area Interleaved' mode. This means that all Magnitude bands will appear before the Phase bands. scans 1-N band 1 (red) REAL (magnitude) scans 1-N band 2 (green) REAL (magnitude) scans 1-N band 3 (blue) REAL (magnitude) scans 1-N band 1 (red) IMAGINARY (phase) scans 1-N band 2 (green) IMAGINARY (phase) scans 1-N band 3 (blue) IMAGINARY (phase) Individual image pixels should be 32 bit IEEE floating point numbers for both real and imaginary bands. Double precision (64 bit) numbers are converted to 32 bit floating point internally because they do not provide any increase in visualization precision relative to the cost of storage and implementation. In any final analysis, the human eye can only perceive 8 bits of precision in any color. 64 bits/band FFT or HDR for image analysis is precision overkill. REX will ingest 64 bit HDR data, but truncates the data to 32 bit precision. Enhancement of REX to support 64 Bit HDR precision is straightforward if there is a preceived need. The issue is memory and disk storage on the host machine. APPENDIX D: High Dynamic Range (HDR) Imagery and the sBUFF The human visual system can distinguish a tonal range of about 256 intensities, or 8 bits quantization, of grayscale or primary color. Scientific and medical imagery may support much larger quantizations that exceed visual sensitivity. Ten bit (range 0-1023) and even twelve bit (range 0-4095) imagery is not uncommon. Sensors for scientific research may have a quantization of sixteen bits (range 0- 65535), or even much higher. For color images, each RED, GREEN, BLUE, ALPHA plane may be deeply quantized, yielding images with vastly greater information density than can be perceived across the full range. Such imagery captures subtle tonal information that is invisible if not selectively scaled into a range that the eye can distinguish. For example, an image with 12 bits of quantization may appear homogeneous if the entire range is scaled to 8 bits of quantization, yet may reveal complex structures when selected subsets of the range are scaled to 8 bits. Exploitation of HDR imagery consists of selecting the most interesting or relevant subsets of the full tonal range to visualize. The visualization of a subset of the dynamic range of deeply quantized imagery is done using Scaling Operations (See: BUFF OPS|sBUFF|SCALING). Scaling defines the subset of the dynamic range of a HDR image to display within the 8 bit range of intensities that we can see. You may selectively scale RED, GREEN, BLUE, ALPHA image planes independently. The REX image loader always loads HDR imagery into an sBUFF at its full tonal range. REX then provides utilities to rapidly explore different subsets of this tonal range interactively, without having to re-load the original data. Spectral Range Segmentation Spectral Range Segmentation consists of selecting low value, high value, and scaling mode (default is 'Linear Mode') for visualizing a subset of the dynamic range of a deeply quantized image. For example, if an image has a dynamic range of 0-1023, we may decide to view the range from 480 to 820 because features of interest occupy this range. Note that this range must be 'scaled' to 256 [0-255] distinct values for actual display, by compressing the selected range to 8 bits. Such spectral compression results in some loss of contrast, but not nearly so much as compressing the entire dynamic range for viewing. It is also possible to select a range of less than 256 distinct values to view. In such a case, the selected range is 'stretched' across the full range of 256, resulting in 'contrast enhancement'. Finally, we can select a range of exactly 256 intensity levels, and view the selected 'spectral interval' at actual sensor quantization starting at the specified offset. Scaling less than 256 intensity levels across the full 8 bit range results in contrast enhancement. SCALING OF HDR IMAGERY AND HDR RANGE SELECTION Full precision HDR data is maintained in a Scaling Accumulator (sBUFF). This is never modified until overwritten by another HDR dataset. This enables the user to interactively explore scaling options without having to reload data. There are two sBUFF's; the Image Loader sBUFF, and the Exploitation-App sBUFF. Each sBUFF hosts its own scaling settings. Selecting a sBUFF selects the source of the HDR Data to be scaled by the Scaling Subsystem. If the Scaling parameters are not based on the statistics of the selected sBUFF, you will get strange results. Note: Scaling settings have no influence on the load of HDR data into the system. HDR data is always loaded at full spectral resolution. HDR imagery introduces a new dimension of analysis that can be confusing at first; especially for multi-band (color) imagery. Coordinating the spectral range of different bands via scaling options to render an image that is a 'reasonable' data visualization is an art requiring skills acquired only by experience. Some images may compound HDR complexity by having pathological statistics. An HDR image may be 'framed' in a field of values of no relevance to the image data, but these values skew image statistics and distort the scaled visualization. In such a case, the user must interactively select the actual range of valid image data values for a useful visualization. REX enables the user to work interactively from the HDR image data Histogram display to do this. REX default HDR scaling uses an initial 'first guess' based upon image statistics (RGB, linear, centered on statistical Median, range 3 Standard Deviations). This works well for deep-space images of galaxies, etc. For planetary surfaces, a better first guess is (RGB, linear, full). You can enter scaling via Image Loader Tags (described below). You refine scaling interactively using the HDR Histogram Interface. NOTE: Once default HDR settings are modified by the user, they remain in the new state until changed. It is simple to reset scaling to default values. INVERSE LUTS AND DESCALING TO ORIGINAL SENSOR VALUES REX implements Inverse Lookup Tables [Inverse LUTs] that instantly de-scale displayed HDR values to a close approximation of the original sensor values. REX displays de-scaled values in the color RGB histogram display. By moving the cursor over the image or histogram, REX instantly displays corresponding sensor values and their frequency of occurrence as the cursor moves. This information allows you to interactively fine-tune scaling to precise ranges that maximize contrast and accuracy by directly working off the color RGB histogram. Unfortunately, multiple HDR sensor luminance intensities often scale to a single RGB Display intensity due to the reduced Display luminance range. These collisions are mathematically unavoidable. REX Inverse LUTs display the AVERAGE HDR sensor luminance that scaled to each RGB color. This is why the values entered for the scaling range may not be exactly reflected in the Inverse LUT display. It is mathematically impossible to scale a HDR range of values into a smaller visual display range without such HDR collisions within the reduced range. However, as the selected range of HDR data approaches the range of the Display, the accuracy of sensor values displayed by the inverse LUT will more closely approximate the original. This is analogous to the loss of spatial resolution when a very large image is resized to fit a Display that is smaller than the image. Note: If viewing a ZOOMED Display, many values on the screen may be interpolated to create a visually smooth image. These values are not meaningful for the purpose of de-scaling image points to their original values. For this reason use REPLICATE zoom mode if de-scaling points on a zoomed image. REPLICATE mode does not use interpolation, but simply replicates original values to expand the image on the Display. This creates aliasing [jagged tiled appearance] at large zooms. In some datasets, the LOW value may be a negative number due to sensor calibration. This is not an error and will scale and display normally. HDR DATA NOISE AND CORRUPTION HDR data is often the output of a complex telemetry pipeline that may introduce noise and data corruption. Floating point NaN faults [Not A Number] are common in legacy HDR astronomical imagery. You may also encounter malfunctioning sensors and variable or spurrious output over specific ranges. Or the image may be 'composed' into a frame of irrelevant data values. For this reason the statistics of some HDR data sets may be pathological, and automatic-scaling will not render a useful display. The data is still viewable; the scaling simply needs to be artfully refined interactively. EXTREMA HDR data may possess 'outlier' values that contribute little information to an image, but dramatically extend the LOW and HIGH statistical boundaries. The cause may be sensor noise, or an HDR image cropped inside a null background. In either case, precious Visualization Range is wasted. Your HDR image has outliers if the 'full range' histogram has 'dead zones' at the low and / or high end. You can use the EXTREMA function under SCALING to 'clamp' the LOW and HIGH ends of the data range. These Extrema are then treated as if they define the data bounds of HDR scaling operations. Clamping outliers can have dramatic effect on scaling. EXTREMA settings do not change the original image statistics, since the original HDR image is never modified. Selecting the bounds of a scaling operation is a crucial and exacting step. Normal datasets with tight histograms may use EXTREMA to 'lock-in' visualization bounds and explore sub-regions within it. EXTREMA is an optional, convenience function for HDR scaling. SCALING AND COMPOSING MULTI-BAND HDR IMAGERY INTO COLOR COMPOSITE IMAGES There are two HDR Scaling Accumulators [sBUFF]. One sBUFF is dedicated to the image Loader, and another sBUFF to image Exploitation apps that generate HDR output. Each hosts its own scaling settings for rendering a viewable image. Each sBUFF may contain only a single image, but that image may consist of up to 8 'Bands' of image data. [FFT real/imaginary bands for RGBA] If the image is read as a HDR 'data-cube' loaded in a single operation, then the Scaling Accumulator contains all the image bands after a single load operation. You may also compose color HDR images into an sBUFF a single B&W band at a time using the loader 'GUN' tag. Bands may be composed in any order. HDR composite images composed of individual bands may not always be perfectly aligned or even the same scale. Use the FXY, COLS, ROWS, SFACT loader tags to specify the exact footprint of each image layer in the composite. Once scaling to a viewable image is achieved, use the 'BUFF OPS | iBUFF | ALIGN' operator to precisely align the RGB color planes after scaling. For rotation and scale issues, see 'Image Rectification' below. NOTE: The HDR 'PSEUDO' [Pseudocolor] scaling operator is accessible only from the image loader. It expresses a single band Grayscale HDR image as a rainbow applied across the defined HDR dynamic range, with Black/Blue=Low thru Magenta=High. Attempting to apply PSEUDO to a multi-band image is an error. NOTE: Loaded HDR bands must all have EXACTLY the same X,Y dimensions in the sBUFF. This means that the dimensions of the smallest HDR area loaded defines the dimensions of the HDR composite. The easiest way to do this is to use the STATIC loader tag to define a static iBUFF, and load the smallest image first to define the static dimensions. All image loads to a static image buffer will be automatically cropped to the static buffer size. You can use the DUMPH (Dump Header) loader tag to display image dimensions. NOTE: Unscaled HDR data cannot be ALIGNED or RECTIFIED. These operations may only occur after sBUFF HDR data has been scaled into an iBUFFER. This means that each re-scaling operation on sBUFF contents will require a re-alignment in the iBUFFER if data in sBUFF is not already precisely aligned. Use Loader FXY, COLS and ROWS tags to align HDR data in the sBUFF. REX HDR EXPLOITATION OPERATORS An sBUFF can also be configured as a source/destination for REX exploitation apps that compute HDR output. REX HDR operators are flagged with a '~' symbol on the menu. Note that REX HDR ~apps will perform normally even if sBUFF is write- protected; however, you will not be able to analyze ~app output using different scaling settings. The REX Image Loader always has 'write' access to sBUFF, and cannot be blocked. IMAGE RECTIFICATION FOR MULTI-BAND COLOR COMPOSITING AND PANORAMAS Multiple B&W HDR images may be merged into a color-composite image, or RGBA images may be stitched together into Panoramas. This requires that images be perfectly aligned relative to one another in a process called image Rectification. Images must be acquired from the same point location for Rectification to be possible. If the imagery is HDR, the first step in Rectification is to scale the image data into iBUFFs in a manner that optimally visualizes the desired information in each image. REX cannot rectify raw HDR data directly. 'BUFF OPS|ALIGN|RECTIF' provides precise information on the Rotation and Scale of different image components of a color-composite or panorama relative to one another. You use this information as input to image resize and rotation operators to match scale and orientation for creating color-composites or panoramas. Rectification consists of altering the Scale, and / or Rotation of an image to match the geometry of a 'base image'. Scale is determined by measuring the precise Distance between points on two images to be Rectified. If the Distance measurement differs significantly, it is used by 'BUFF OPS|RESIZE' to adjust the scale of one image component relative to another. The image resize factor is simply the ratio of the two distance measurements. IF the distance between points is nearly identical, no resize is needed. Rotation is determined by measuring the precise angle between points on two images. If this angle differs significantly, the difference between angles is used by 'BUFF OPS|ROTATE' to rotate one image relative to the other. You will need to use 'BUFF OPS|CROP' to clip the rotated image to compatible dimensions of the non- rotated base-image. If the angles are nearly identical, no rotation is needed. Rectified images must be exactly the same dimensions to be used in a color composite image. See 'SCALING AND COMPOSING...' above. For an IMAGE PANORAMA, Rectified images must share a common dimension to be Tiled together; either COLS for images tiled Vertically, or ROWS for images tiled Horizontally. For Color-Composite images from B&W layers, use 'BUFF OPS|ALIGN' to fine-tune the final RGB alignment by shifting image RGB planes relative to one another in an iBUFFER. Note that while shifting, you can press and hold the L-MOUSE button down while moving it for very pecise, zoomed positioning. R-MOUSE always exits any operation. Using REPLICATE zoom mode aids accuracy during this procedure. VARIABLE IMAGE SLEWING A DIFFICULT RGBA COMPOSITING PROBLEM AND SOLUTION Sometimes, the ALIGN operation used to composite multiple bands only aligns bands over an limited area of the image, with error increasing with distance. The reason is that different bands of astronomical imagery acquired by space telescopes using very long exposures may be slewed differently across portions of an image. This is an artifact of the finite resolution of station-keeping guidance systems on the spacecraft during long exposures. The result is that only sub-areas will ALIGN and it is impossible to composite bands in a single operation. One solution is an image-wide network of control points over the image bands that projects each band to a common mathematical surface. Defining this control network is a long and exacting process. Also, it introduces interpolation error. The REX solution is to divide the image into a mosaic of smaller sub-areas, or tiles, within which images ALIGN. Each tile is then aligned independently. You make the tiles as small as necessary for alignment to be true within their bounds. REX supports Tiling utilities that maintain seamless alignment along Tile boundaries. The procedure to do this is to size the Display so a multiple of Display Tiles will exactly (or closely) span the iBuffer. Next, create a Foreground Area of Interest (FG AOI) so a multiple will EXACTLY span the Display. Next, you make a CLONE of the iBuffer (BUFF OPS | CLONE). The iBuff Clone may be the target of the tiled Align/Composite operations. You tile the FG AOI across the Display, and tile the Display across the iBuffer. At each step, you ALIGN image bands within the FG AOI tile, then Composite the result to the Cloned iBuff. When a full Display has been aligned in this manner, you Tile the Display to the next position in the iBuff. When finished, the Clone iBUFF will contain a Composite color image with positional error no greater that that within any individual tile. In this way you can build a flawless composite image from multiple bands with variable internal image slew. This procedure can be done rapidly and has the advantage of avoiding introduction of interpolated error. Of course, the above does not correct image slew in the base image. But you only need a single mapping operation to project the composite image to a mathematical surface. You use a similar procedure to COMPOSITE any data to a Clone iBuff. Generally it is best to work from images slightly larger than the desired final size, so that 'edge-issues' can be cropped away. Also, when Rectifying scientific imagery involving Rotation, it is best to turn off Rotation 'De-aliasing' to preserve original information in rotated imagery. EXPLOITING HDR DATA USING REX IMAGE CALCULATOR REX supports an image CALCULATOR for exploiting image bands mathematically. As an advanced feature, REX supports composition of RGBA color images directly from raw HDR imagery via the REX Image Calculator (iCALC) utility. It does this by treating the sBUFFER as an Accumulator with 32 bits of spectral precision per image plane. HDR data may then be directly manipulated by the REX Image Calculator (iCALC) system. See:'BUFF OPS|sBUFF|RENDER|ACCUM'. Note that this requires the user to be aware of the dynamic range of the data in the sBUFFER. Using iCALC to mathematically manipulate raw HDR data gives the finest possible control over interactive visualization of multiple HDR bands. See Appendix A: iCALC User Guide. IMAGES WITH MORE THAN 3 BANDS; MULTISPECTRAL AND HYPERSPECTRAL The physiology of the human eye has three types of color receptors in the retina lining the back of the eyeball; red, green and blue. Each receptor is sensitive to a range of wavelengths that correspond to each color. Images with three spectral bands (Red,Green,Blue) are called 'Color' images when the spectral range for each R,G,B band approximates the natural sensitivity of the human eye. When spectral information outside the human visual range is presented, the resulting image is referred to as 'false-color' or as a 'multi-spectral image'. The magic of a computer Display is that it enables ranges of radiation that are invisible to the human eye to be rendered in a spectral range that we can see. Multi- spectral imagery [aka false-color] enables detailed analysis of spectral regions far outside human sensitivity, such as heat, radio waves, or even Ultra-Violet, X-Ray and Gamma-Ray. Multispectral images may have more than three bands. So-called 'hyperspectral imagery' may consist of hundreds of bands of data acquired at different spectral wavelengths. In astronomy, the spectral analysis of stars uses high-resolution images of their spectra, where the point image of a star is diffused into a visualization the wavelengths of radiation being emitted. For multispectral imagery the user may select 1 band to view as a grayscale image or 3 spectral bands to view as a falsecolor image (with a possible extra band loaded as Alpha). For such 'multi-spectral' images, the user must specify the bands to be loaded via the 'BAND=' Loader Tag. The bands will be loaded into the R,G,B,A color-planes in the order specified. A 4 band image is always assumed to be RGB with an Alpha band. The Alpha band may simply be another data layer swapped in and out of the RGB visual space, an Overlay, or a Transparency layer. If you wish to view more than 3 bands+Alpha of image data simultaneously, some sort of pre-processing of the imagery that collapses multiple bands into a single band must be done. Such 'Principle Components' algorithms are an ongoing area of advanced mathematical research. GOOGLE the term for more info. As long as Principle Components output is in a format REX can read, REX can be used for its analysis. Some multi-band images are stored with each spectral band in a separate file. In such cases, each band is simply treated as a grayscale image loaded to a separate color plane, and care is taken to ensure that the bands stay spatially aligned or 'registered' when loaded. The result is a color image. REX has a utility to align color planes interactively 'BUFF OPS | ALIGN'. Multiband images stored in a single file must interleave the colors in some fashion. Multiband images may be interleaved in 3 possible INTERLEAVE formats: PIXEL INTERLEAVED : the image bands are interleaved at the pixel level, i.e. R0,G0,B0, R1,G1,B1, R2,G2,B2, ... Rn,Gn,Bn SCAN INTERLEAVED : the image bands are interleaved at the scanline level i.e. RED scanline 0 GRN scanline 0 BLU scanline 0 RED scanline 1 GRN scanline 1 BLU scanline 1 : AREA INTERLEAVED : the image bands are present as full images, in sequence, i.e. RED image area scanlines 0-N GRN image area scanlines 0-N BLU image area scanlines 0-N The above schemes may be extended to any number of bands, in which case RED,GRN, BLU become Band1, Band2, Band3, etc. Normally, the image interleave is automatically determined based on the image format (.gif, .jpg, .tif, .fits, etc.). APPENDIX E: SOFTWARE DEVELOPERS: REX COLLABORATIVE DEVELOPMENT LICENSING TECHNOLOGY (CDLT) REX provides a powerful, highly advanced, 'anvil reliable' image exploitation platform and a simple framework for creating specialized derivative works that extend REX capabilities. You can improve REX with your innovative algorithms, and sell your improved version of REX using the robust CDLT licensing control mechanism. Alternatively, you can give away your improved version of REX for free with unlimited distribution, or use it exclusively within your group. The CDLT Licensing Process CDLT enables you to purchase a 'kernel license' from a CDLT application developer on behalf of a customer for your derivative work. You add a secret code in the kernel license order that controls access to your improvements via the CDLT API, then convey the license for your enhanced derivative work to your customer at any price you choose. Since every license is encrypted and unique to its hosting system, your intellectual property is secure. After a simple installation process taking seconds, licensing is fully transparent to the user. You profit from collaborative development with the kernel application developer without surrendering your intellectual property. You may also open-source your work, and use CDLT as a platform for sharing your code ideas via REX. CDLT licensing places no restrictions on copying and installation of CDLT code that you modify or create to enhance REX. You can give it away for free, or not. Legal Issues: GNU General Public License (GPL) *** REX USES NO 'GNU GPL' SOURCE CODE. EVER. *** Open source code that is distributed under the coercive and Communist 'GNU GPL' license imposes punitive restrictions on software developers. Under terms of the GPL, any application that uses a GPL component is considered a 'derivative work' of the GPL, and its copyright is hijacked under GPL licensing. The GPL license is a Marxist, legal Frankenstein that raises complex and absurd legal issues. To date these issues are unresolved, so GPL zealots resort to Lawfare attacks. Imagtek firmly believes that the GNU GPL is a farce of legally invalid overreach based upon magical thinking. Still, our courts have become a farce and few have the time or resources to bother with subsidized GNU GPL litigation risk. The REX kernel application is forensically clean of GNU GPL code contamination. *** USE OF GNU GPL SOURCE CODE IN DERIVATIVE WORKS *** The GNU GPL is a dangerous, network crawling, Marxist klepto-algorithm. GNU GPL source code may only be used under very specific circumstances. The GNU GPL states: "...this license (the GPL) and its terms, do not apply to those sections (not using GPL code) when you distribute them as separate works." CDLT (c) Licensing dictates, as a condition of use, that a collaborative work exists only as a legally separate and distinct work from the REX kernel application it is built upon. REX hosting a collaborative work is no different than an operating system hosting an application. This means you may distribute a REX collaborative work that uses GNU GPL licensed source code, if the work is distributed as an executable, and CDLT components are distributed only as a library in object form callable via the rexLib (c) API. You may NOT under any circumstance mix GNU GPL source code in the same distribution as CDLT source code. You may NOT distribute GNU GPL source code in a CDLT licensed distribution. Please see the CDLT License for more in-depth information on this complex and absurd issue. The best policy is to unconditionally avoid GNU GPL licensed code. APPENDIX F: REX ENCRYPTION AND CRYPTO-KEY MANAGEMENT REX encryption capabilities require a Level-2, or greater, license level. A Level-1 license WILL NOT enable encryption, and fully complies with any legal restrictions that prohibit private use of encryption technology. The entire CDLT licensing system must be disabled via a complex and criminal binary editing exploit to enable encryption if it is not purchased. You should not purchase encryption capability if private encryption is illegal where you live. Any encryption scheme that modifies the original file size by a single byte, or is not an EXACT duplicate of the original when decrypted, is worthless. REX encryption is 'industrial strength', based upon the well established Advanced Encryption Standard (AES-256) and Password Based Key Definition Function (PBKDF2) standard implementations. Ad Hoc implementations of encryption are not secure. It takes a great deal of peer-reviewed research over a long period of time to establish industry standards that can withstand professional exploits. The REX encryption subsystem is as robust and secure as any in the marketplace and fully complies with the US Government FIPS-197 standard. The US government uses AES-256 encryption to secure TOP SECRET data and crucial financial and physical infrastructure information. There are many research papers exploring AES Encryption and exploits against this technology on the web. Despite much hype about Quantum computers defeating encryption, such technology is decades away with many uncertainties remaining. Note that any encryption system is no more secure than its keys. User key management is the cornerstone of secure systems. Keeping key management simple is the cornerstone of User Key management. Complexity of human systems can always be exploited. Real exploits against an encryption system always target human actors and key management, since the computation and analytical resources to 'brute force' a 256 bit key are prohibitive and impractical. Humans always get careless, most are naive, and it just takes one. It is an error to believe that encryption beyond 256 Bits with more complex key management is more 'secure'. Key management complexity introduces vulnerability to man-in-the-middle attacks, or attacks exploiting user carelessness during complex key management. People hacking encryption systems are security and intelligence professionals with backgrounds in Psyops. Most people using such systems on a daily basis, are not. REX directly supports 'Secure Compartmentalized Information' natively via encryption. This is done via two keys; a 'User Key' that is used to encrypt data, and an optional 'Domain Key' that is used to encrypt the 'User Key'. A User Key will only decrpt data that was encrypted under the Domain of its 'Domain Key'. Thus, as long as the Domain Key is managed separately and securely, you can send User Keys via insecure networks and still maintain secure access to Compartmentalized Information. Secure encryption is seamlessly built into REX, so encrypted files are treated exactly the same as unencrypted files once the encryption system is initialized. Users may directly exploit deeply encrypted imagery in mainstream, compressed image formats in a single operation using REX. REX encryption uses the Advanced Encryption Standard (AES) cipher with a 256 bit encryption key in Cipher Block Chaining (CBC) mode, with a key-derived 128 bit CBC initialization vector. AES-256 is widely regarded as one of the most secure crypto algorithms in existence. An uncompromised 256 bit key is secure for any forseeable technology. Crypto using more than 256 bits is overkill and remains vulnerable to 'man in the middle' key-intercept exploits. Using the AES-256 algorithm, data remains fully encrypted if even a single bit of the 256 bit key is wrong. There is no detectable deterioration of encryption as the key is approximated. REX comes with a separate batch encryption package called 'crypTool' for encrypting/decrypting large numbers of files under control of a script, or for decrypting REX encrypted files for 3rd party image viewing software. 'CrypTool' DOES NOT AND WILL NEVER require a license to decrypt files. Your data will never be hostage to any sort of licensing issue. 'BACK DOORS' A 'back door' is undisclosed engineering in a system that enables third parties to insert and access secretly encoded information. To test a system for a back door, run 'sha256sum' on a test file. Note the code and the EXACT file size. Then encrypt the file. Note that the size of the two files is EXACTLY the same. An encrypted file that is not exactly the same size as the original has implemented a 'back door', or is some sort of a joke. Next, decrypt the file, and run 'sha256sum' on the result. If the codes are identical, it is impossible that a 'back door' is encoded. If the 'sha256sum' codes differ, even if the file size is identical, a 'back door' encoded the key into the encrypted dataset. It is algorithmically trivial to invisibly encode the key into a dataset after encryption, and to retrieve the key from the encrypted dataset. But it is impossible to do so undetected by the above procedure. REX encryption has no 'back door'. Test it as described above. DECORRELATION AND BRUTE FORCE EXPLOITS There exists a single effective brute-force exploit against encrypted datasets. You can compute the 'exclusive-OR' of an unencrypted image against an encrypted copy of the same image comparing known patterns at known offsets in the data. You simply run the encryption algorithm backwards from known patterns to derive the key. Yes, this is complicated and a lot of work, but Intelligence agencies have vast resources. The common approach to defeat this exploit is to encrypt the data twice, using two different keys or even two different encryption algorithms. This is complicated, annoying, and slow. REX encryption defeats this exploit via 'Decorrelation'; i.e. encrypting the POSITION of data, as well as its content. For any given offset in a message, or spatial coordinate within an image; its corresponding position within a REX encrypted dataset is a random and constantly changing positive or negative offset with a large range from any position. Storing data in encrypted compressed image formats, without specifying a file format extension, adds yet another layer of security since there exist many compression algorithms and implementations. REX does not use the file extension to determine the format of data in mainstream formats. REX is useful for research in encryption visualization via the RANDOM (image randomizing) function in the exploitation system. RANDOM simply encrypts what is on the display, then re-displays the result. It is exactly what would be written to an uncompressed, encrypted file. It is also as pure a set of random numbers for research purposes as can be computed. That was the primary purpose for REX encryption; access to pure random numbers for mathematical investigations of chaos and information theory. The rest just fell out of that. USER KEY and DOMAIN [or BASE] KEY The REX crypto scheme utilizes two 256 bit keys; a Domain Key, and a User Key. The Domain Key is optional and is used to compartmentalize information into Domains. User Keys can access only information within a Domain to which they have been granted access with a Domain key. A User Key that will access information within one Domain is incapable of accessing information within a different Domain. The Domain Key is optional and is irrelevant for most users. Choosing a 'good' password based key > 8 characters provides ample security. Defining a Domain key is for extreme high-security data compartmentalization across Domains of larger organizations. If a dataset has been encrypted with both a Domain Key, and a User Key, then the User Key can be sent over insecure channels to those with authority to access the dataset via possession of the Domain key. As long as the Domain Key remains secure, intercepting a User Key does not compromise encryption. Crypto-key management systems much more complex than this exist, but it is debatable whether they are more secure. When it comes to encryption key management, complexity increases human fallibility, which increases risk. DEFINING THE OPTIONAL DOMAIN KEY REX provides the option to define the Domain Key when you first specify the User Key. The Domain Key may be specified as a password, or a 256 bit binary number that foils advanced 'password guessing' hacker toolkits. A binary number is specified as a 64 character hexadecimal number (i.e. '0x' followed by 64 hex characters [0-9, A-F]). The Domain Key persists until REX terminates. Attempts to re-define a Domain Key within a REX session are ignored. However, the User Key may be re-defined as many times as you like. SECURITY NOTE! Manage the 'User', and 'Domain' keys completely separately. This creates a formidable barrier to known crypto exploits. The greatest danger to encryption is not a brute force exploit, but a key intercept exploit over a network via hacking into your user account, personal device, or tricking you into divulging useful information. Encryption is only as secure as the systems the keys are stored on, and the people who have access to the systems. Never store a User Key and Domain Key on the same system or device! Never relay them from or to the same email account or telephone number. Any personal device or system containing a key must itself be protected by a robust password. If someone refers even indirectly to secure information over insecure channels, terminate communication. These four simple rules will greatly enhance security. Be aware that if you have access to valuable or sensitive information, you are a target of professionals who will seek access to it and resort to devious, long-term PsyOps to gain trust. SPECIFYING ENCRYPTION KEYS Keys can be variable length, expressed as either a 'text string', or a hexadecimal number; i.e. 'thisIsAkey' or '0X -- 64 hex characters --' All Keys must ALWAYS be bounded by single quotes. To use a quote ['] as a character in a key, it must be preceeded by a Backslash [\]; Note that [\\] is interpreted as [\] if you want to use it as an active part of a key. KEY=' string ' specifies a User Key. DKEY=' string ' or '0x0123 -64 chars- DEF' If using a hexadecimal number for DKEY, you may keep it on a Flash-drive: DKEY=F'/media/usbDisk/myKeys/BaseKeyFilename.txt' Images Encrypted by Third Party AES Software...? REX supports the strongest encryption mode of the AES standard, augmented by proprietary Decorrelation technology. It is beyond the scope of REX to support other AES modes and keylengths, or AES datasets encrypted by other vendors. REX will decrypt images that were encrypted by REX, or by the Imagtek LLC 'crypTool' utility. No other encryption formats are supported. CRYPTOOL REX provides a standalone batch encryption utility 'crypTool' for batch use to encrypt large numbers of images to the REX implementation, or to enable REX encrypted imagery to be decrypted for use on other systems. DECRYPTING data using cryptool does NOT, and will NEVER, require a license. Your encrypted data will never be hostage to a software license. ENCRYPTING data using crypTool DOES require a Level-2 license. FINAL WORD: SOFTWARE BUGS imagtek@imagtek.com REX consists of almost 100,000 lines of source code written over a period of decades. REX is stable in testing, and the code has been written with security from 'fuzzing' attacks and deliberate buffer overflows in mind. Unexpected results are not necessarily bugs in the software. Please do not report a bug until you have thoroughly researched what you are doing and are confident there is an error. You might be correct! We promptly and rigorously investigate all bugs. REX supports mainstream image formats, but some image formats define specialized and little-used extensions that REX does not support. There are simply too many. Legacy FITS format files in particular are prone to load failure. This is because geniuses decided to create 'extensions' and 'exceptions' to the format standard for each 'mission'. This requires custom FITS software and teams of 'mission support' programmers. This is not a bug in REX. If REX ever core-dumps that is certainly a bug and we want to know about it!!! For sure. We think those are all gone, but you never know...