BGLDEC - A resample BGL DECompressor

Hey Sean.... Marcus from waaaay back. Remember simwestCONTROL? :D ha! Glad to see you are still in flightsim. Just released my first product. Two more are about to drop.
 
Hi Theisomizer,

first a great thank for this new release, it's a great work opening amazing possibility !!!

working on an elevation sample, I have detected some strange think into .inf file generated with RAW files (.bin)

My sample file is a 16bits elevation Geotiff. Here is a raw view in QGIS before any work & conversion:
sample01.jpg

Details and geolocalisation data are stored into a .tfw file. here it is:
Code:
0.0000091084
0.0000000000
0.0000000000
-0.0000091084
-61.2346257144
14.8993192805
Step 1: Geotiff -> BGL with resample.exe from FSX SDK

I use this .inf file for resampling for FSX BGL format:
Code:
[Source]
Type = GeoTIFF
Layer = Elevation
Channel_BlendMask = 2.0
SourceDir = E:\MNT compil decompil Test\
SourceFile = Image.tif
GCS = WGS84
nCols = 8954
nRows = 9641
nBands = 1
PixelIsPoint = 1
SamplingMethod = Gaussian
SampleType = SINT16
XDIM = 0.0000091084
YDIM = 0.0000091084
ULXMAP = -61.2346257144
ULYMap = 14.8993192805

[Destination]
DestDir = E:\MNT compil decompil Test\out\
DestBaseFileName = MNT_test
UseSourceDimensions = 1
DestFileType = BGL
LOD = Auto
Step 2: BGL -> RAW (.bin) with BGLdec 0.9.4

Here is the .inf file generated by BGLdec 0.9.4 from this .bgl:
Code:
[Source]
Type = MultiSource
NumberOfSources = 2

[Source1]
Type = Raw
Layer = Elevation
Channel_BlendMask = 2.0
SourceDir = E:\MNT compil decompil Test\out\
SourceFile = DEM-17-32430-27343.bin
GCS = WGS84
nCols = 6145
nRows = 8449
nBands = 8449
PixelIsPoint = 1
SamplingMethod = Gaussian
BandLayout = BIL
ByteOrder = Intel
SampleType = UINT8
XDIM = 0.021887
YDIM = 0.021887
ULXMAP = -61.237793
ULYMap = 14.900208

[Source2]
Type = Raw
Layer = None
SourceDir = E:\MNT compil decompil Test\out\
SourceFile = DEM-17-32430-27343-MASK.bin
GCS = WGS84
nCols = 6145
nRows = 8449
nBands = 8449
PixelIsPoint = 1
SamplingMethod = Gaussian
BandLayout = BIL
ByteOrder = Intel
SampleType = UINT8
XDIM = 0.021887
YDIM = 0.021887
ULXMAP = -61.237793
ULYMap = 14.900208

[Destination]
DestDir = E:\MNT compil decompil Test\out\
DestBaseFileName = DEM-17-32430-27343
UseSourceDimensions = 1
Step 3: Create a .hdr file to get this raw file readable by QGIS

In order to watch the Raw file (.bin) into Qgis I create manualy a .hdr file from this .inf file, here it is:
Code:
BYTEORDER I
LAYOUT BIL
NROWS 8449
NCOLS 6145
NBANDS 8449
NBITS 8
ULXMAP -61.237793
ULYMAP 14.900208
XDIM 0.021887
YDIM 0.021887
Into Qgis the binary file look like a stripped black square wit hlot of artefact...

I have to change some value into the .hdr file to get it work better:
NBANDS 8449 -> NBANDS 1
NBITS 8 -> 16

sample01_out_of_binary_before_correction.jpg


not bad but there are still two problems:
- the image that should be more square (EPSG:4326) seems to be streched verticaly.
- Lat/Long boundaries dimensions are completely disproportionate -> I have figured at top left corner with a Red square the bounds of my original geotiff dimensions.

After a lot of manualy "try and error" step, I could fit pretty much to my Geotiff boundaries if I change:
XDIM 0.021887 to -> XDIM 0.0000143046
And
YDIM 0.021887 to -> YDIM 0.0000107285
sample01_out_of_binary_after_correction.jpg


to sum up here is my final .hdr file:
Code:
BYTEORDER I
LAYOUT BIL
NROWS 8449
NCOLS 6145
NBANDS 1
NBITS 16
ULXMAP -61.237793
ULYMAP 14.900208
XDIM 0.0000143046
YDIM 0.0000107285
I Hope it could help you ;-)

just one or two more remark :
- could you add the possibility to change the default "nodata" value (black color for RGB imagerie and 0 value for elevation) which for now create a black outline around the Image to fit FSX Level boundaries. Or another possibility it's to add an alpha band to keep this part transparent.

thank you for all your hard work

Vogel

edit:
XDIM and YDIM should be easily calculated from QMID Level width and height no ?
XDIM = QMID width / nCols
YDIM = QMID height / nRows
right ?

edit2:
yes that was it !
XDIM = (QMID max longitude - QMID min longitude) / nCols
YDIM = (QMID max latitude - QMID min latitude) / nRows

and for my sample: calculation allows to be a little more accurate than "try & error" ;)
XDIM 0.000014302786818551668022782
YDIM 0.000010727566224553201562315
 
Last edited:
Hi @Vogel, sorry for the delayed reply.

Would it be possible to share via DM or similar your BGL file with me? I am revamping bgldec and can take a look. Thanks
 
Hey there,

While working with worldlc.bgl from FSX I've found out that binary output has bytes set to 00 where they shouldn't be.
For example, the bitmap for QMID(7,0,0) is all ice, but the binary, instead of being full of 7A (122 in decimal, for Ice), has some bytes set to 00. I thought it was some sort of row separation, but the grids are allegedly 257x257 which is the resolution of the bitmap AND the size of the binary output, so something is definitely off. Both my tool and BGLViewer from @Patrick Germain decompress that QMID grid as full 7A.

Also, I was working with some FSX default .dem files which no other tool can really decompress and what I've noticed is that the output of the decompression doesn't seem to match all the existing TRQ1 records from the .bgl file. For example, dem0502.bgl seems to have TerrainElevation from QMID level 4 up to 11, yet the tool only outputs levels 4 to 8 and there's some missing grids even within those.

Perhaps I'm doing something wrong, but I've checked the documentation and while there is some mention of LOD settings, it appears they no longer exist in the latest versions.
 
Hey there,

While working with worldlc.bgl from FSX I've found out that binary output has bytes set to 00 where they shouldn't be.
For example, the bitmap for QMID(7,0,0) is all ice, but the binary, instead of being full of 7A (122 in decimal, for Ice), has some bytes set to 00. I thought it was some sort of row separation, but the grids are allegedly 257x257 which is the resolution of the bitmap AND the size of the binary output, so something is definitely off. Both my tool and BGLViewer from @Patrick Germain decompress that QMID grid as full 7A.

Also, I was working with some FSX default .dem files which no other tool can really decompress and what I've noticed is that the output of the decompression doesn't seem to match all the existing TRQ1 records from the .bgl file. For example, dem0502.bgl seems to have TerrainElevation from QMID level 4 up to 11, yet the tool only outputs levels 4 to 8 and there's some missing grids even within those.

Perhaps I'm doing something wrong, but I've checked the documentation and while there is some mention of LOD settings, it appears they no longer exist in the latest versions.
The DEM data and the landclass data is PTC encoded via different algorithms depending on the non null data. Have you been using BGLDEC? Is dem0502.bgl you are having issues with BGLDEC? Can you post your QMID and output? Thanks
 
Last edited:
While working with worldlc.bgl from FSX I've found out that binary output has bytes set to 00 where they shouldn't be.
For example, the bitmap for QMID(7,0,0) is all ice, but the binary, instead of being full of 7A (122 in decimal, for Ice), has some bytes set to 00. I thought it was some sort of row separation, but the grids are allegedly 257x257 which is the resolution of the bitmap AND the size of the binary output, so something is definitely off. Both my tool and BGLViewer from @Patrick Germain decompress that QMID grid as full 7A.

Also, I was working with some FSX default .dem files which no other tool can really decompress and what I've noticed is that the output of the decompression doesn't seem to match all the existing TRQ1 records from the .bgl file. For example, dem0502.bgl seems to have TerrainElevation from QMID level 4 up to 11, yet the tool only outputs levels 4 to 8 and there's some missing grids even within those.
Hi Rafael,

Thanks for bringing this up, and both issues have been identified. The latter has already been fixed in a more recent build yet to be published, it was an issue with stitch cells that started with null data due to a full missing data mask in the top left cell. I hadn't noticed the former as I am usually testing in stitch mode. That is happening for pointispixel types (257X257). For some background, when the image is stitched together it will only blit 256X256 for all interior chunks, with only the final row and column blitting a single extra pixel per. This is mathematically correct, as the final size of the image is 256^n + 1, not 257^n. This extra column /row can be viewed as forming the final bottom right vertices and edges binding the pixel array, and the data is used for blending the edge of an LOD patch with the next neighboring higher or lower LOD (which is coplanar to the 1st vertex of that patch in the y dimension). What happened is that in adding that logic for the stitch code, I broke the individual tiles mode, and the final 257th column is being written as 0. I can fix this, I just need to think of how to do it in a way that won't break the stitch functionality.

The DEM data and the landclass data is PTC encoded via different algorithms depending on the non null data. Have you been using BGLDEC? Is dem0502.bgl you are having issues with BGLDEC? Can you post your QMID and output? Thanks
Thankfully this is not a decompression problem, just how the output is being rendered to a file. FYI, the 8 bit raster types (everything except for DEM and Aerial) are not encoded in PTC and only every use the delta, bitpack, and LZ permutations. This is because PTC does not specify a single channel 8 bit compression mode, and even if one was to customize the algorithm to add it I imagine you would probably get lousy results. That sort of data lends itself better to a standard dictionary coder than the entropy + transform of an image coder.

Standby for an update.

Thanks,
Sean
 
Last edited:
Top