Small program to build a Jpeg from a Jpeg tiles, using a GUI a Windows environment. These tiles are accessed from an online source as Jpeg tiles from a TilePic file, which are accessible through a web based 'getpic' script. The parameters for the TilePic file and online location are read from an online XML or JSON file.

Small program to build a Jpeg from a Jpeg tiles, using either a GUI or CLI in a Windows environment. These tiles can be either local or online files, e.g. Jpeg tiles from a TilePic file, accessible through the (web based) 'getpic' script.

“TilePic is a file format developed by the Berkeley Digital Library
Project that is designed to store tiled data of arbitrary type in a
hierarchical, indexed format in order to provide fast retrieval. This format
was influenced by the Kodak FlashPix format and is based in part on the
GridPix format developed by the Tertiary Disk Project at UC Berkeley.”

/*
* All of the numeric data, including the "magic number" are stored
* in the file most-significant byte first.
*
* file size field description
* byte in
* offset bytes
*
* 0 4 magic magic number == "TPC\n"
* 4 4 headerSize size of file header in bytes (40)
* 8 4 imageWidth width (x) of largest image in base units
* 12 4 imageHeight height (y) of largest image in base units
* 16 4 tileWidth width of lowest tiles in base units
* 20 4 tileHeight height of lowest tiles in base units
* 24 4 nTiles number of tiles stored in the file
* 28 2 nLayers number of layers of tiles
* 30 2 scale scale factor between layers (typically 2)
* 32 4 attribSize size of space used to store attributes
* 36 4 nAttribs number of attributes stored in file
* 40 (nTiles+1)*4 (tileIndex) offsets of the start of each tile in order
* followed by offset of start of attributes
* 44+nTiles*4 tileIndex[0]-(44+nTiles*4) [optional filler]
* tileIndex[0] tileIndex[1]-tileIndex[0] data for tile "1"
* tileIndex[1] tileIndex[2]-tileIndex[1] data for tile "2"
* ...
* tileIndex[tileNo-1] tileIndex[tileNo]-tileIndex[tileNo-1]
* data for tile "tileNo"
* tileIndex[tileNo] attribSize null separated attribute data
*
* Note: There may optionally be uninterpreted filler data between
* the end of the header and the start of the first tile. Applications
* are neither required to interpret nor pass on this information. This
* space may exist to align the start of the tile data on a sector
* boundary, but applications should not count on such alignment.
*
* The tile data is stored contiguously and in order from the first to last
* tile. The tiles are numbered 1 to tileNo, starting with the upperleft
* tile in the smallest layer and proceeding across, then down, then to the
* next larger layer. So for example, if the image size is 1011x765 and
* the tilesize is 256x256 and the scale is 2, and there are four layers,
* the tile order would be:
*
* scaled
* layer size scale
*
* layer 1: 1 127x96 8x
*
* layer 2: 2 253x192 4x
*
* layer 3: 3 4 506x383 2x
* 5 6
*
* layer 4: 7 8 9 10 1011x765 1x
* 11 12 13 14
* 15 16 17 18
*
* Note that the layer sizes are rounded up to the nearest integer.
*
* The data to be tiled may be raster or vector data. The tiling is done
* in more or less the same way with slight differences. In each case,
* there is a base unit of dimension whose type and scale is not important
* to the tiling process (although that information can be stored as text
* attributes for application processing).
*
* For raster data, the base unit corresponds to one cell of the lowest layer
* (highest resolution) data. For image data this would be a single pixel.
* Higher layers are assumed to represent aggregations or inteprolations of
* the lower levels with each level aggregating cells in scale^2 chunks.
* For example, if the lowest layer was a black and white scanned image,
* the higher levels might be grayscale images of increasing depth. Or, if
* the bottom layer was a color image, the upper layers could use color
* averaging or median color to pick the colors for higher layers. The
* exact aggregation function used is not constrained or specified by the
* tilepic format except that rate of aggregation must match the specified
* scale factor. It is even possible for the tile data format to change
* from one level to another, for example with the bottom layer tiles
* being GIFs, while higher layers are JPEGs. It is up to the application
* to keep track of and deal with these issues
*
* For vector data, the tiling works in a similar fashion except that the
* scale units do not change as you rise through the hierarchy. Instead,
* the tile sizes change by the scale factor with each layer to cover
* more "ground units" at each layer while the level of detail drops.
* So, if the tiles were to hold vector data of rivers and coastlines,
* the level of detail might decrease as you move towards higher layers.
* Similarly if it held city data, the smaller cities might be omitted
* as you zoom out. Or for stellar data, the dimmer stars and galaxies
* might be omitted as you zoom out.
*
* The TilePics format neither specifies nor cares what format the tile
* data is in. That is left up to the application to determine.
* Similarly it does not specify whether partial tiles (on the right and
* bottom edges) are padded to the full tile size or truncated to the
* minimum number or rows and columns required. Thus either the
* application must know these conventions, or (preferably) the tile data
* should include sufficient header information to determine its storage
* format and size.
*
* The last tile is immediately followed in the file by the attribute
* data. The attributes are stored as contigous null-terminated ASCII-7
* or modified UTF-8 (UNICODE) strings of the form:
*
* name1=value1\0name2=value2\0...nameN=valueN\0
*
* Each "name=value" substring including the last one is terminated by
* a single null character. (There should be exactly nAttribs nulls in
* the attribSize bytes used to store the attributes.) If UNICODE
* strings are used, they should be encoded with the same modified UTF-8
* encoding used by Java such that embedded nulls in the value strings
* are stored as 0xc0 0x80. Only 16-bit Unicode values are supported
* as for Java. Attributes are for use by the applications and are
* uninterpreted within the basic format.
*
* TilePic files cannot be larger than 4GB in size due to the use of
* 32-bit unsigned integers as file offsets. However some systems cannot
* handle files larger than 1GB or 2GB, so files larger than 1GB may
* not be portable anyways. For datasets larger than 1GB or for data which
* is extensively mosaiced, we recommend considering using the TileSource
* data tiling approach instead.
*/