Hello:
Remembering that if one wishes to maintain the Geo-referencing info which IIUC is inside the Geo-TIFF *.TIF file as well as in its associated *.TFW file after editing, one should
first export a backup copy of that Geo-referencing info with GIS utility:
https://www.google.com/#q=fsdeveloper GaryGB geoTIFF Geo-TIFF world file
This
Geo-referencing info must be restored to the Geo-TIFF and associated *.TFW world file after editing if the Geo-TIFF(s) are intended to be used with the FS SDK features allowing internal reading of such Geo-referencing info when processing / compiling scenery content.
http://www.fsdeveloper.com/forum/threads/photoscenery-how-much-overlap.425814/
Also, when creating textures to be overlapped on the ground in FS, IMHO, one might wish to consider how the FS terrain rendering engine draws the texture tiles on the ground in FS at run time, which AFAIK is:
* Left to Right (West to East)
...
then:
* Top to Bottom (North to South)
...
or generally (AFAIK, in all versions of FS):
Top Left to Bottom Right (NW to SE)
NOTE: In the case of Effect (*.Fx) textures, or textures mapped to other content utilizing *.DDS file formats used by recent versions of FS, because the texture image is vertically "flipped" for optimal performance processing via the Windows DirectX graphics sub-system used by FS, some have implemented a 'different' system of describing the FS texture pixel numbering / "texture draw direction" scheme.
Regardless of ones "
texture draw direction" reference scheme, one may wish to explore the method of arranging overlaps of textures for use in custom terrain land class textures and/or ground polys etc. so that they accommodate:
*
1-pixel overlap on the X direction aka Left to Right (NW to NE)
...and:
*
1-pixel overlap on the Y direction aka Top to Bottom (North to South)
AFAIK, FS SDK Resample for all versions Fs2Kx and FSX already does this to avoid gaps in overlapping terrain texture tiles.
By keeping the overlap to only 1-pixel on each X and Y axis, with draped mesh-clinging terrain land class textures (default or custom photo-real), there is still a risk for "blue silvers" of un-textured gaps in terrain at run time when terrain elevations make abrupt and steep changes in slope, so use of multiple LODs in mesh files was also implemented.
FYI: An interesting aspect of how FS SDK resample implements the 1-pixel overlap on both the X+Y directions can be seen when zooming in on *.BMP textures
for adjacent tiles ...in the default MSFS 2004 scenery for Oshkosh (included in FSX at):
[FSX install path]\Scenery\Cities\OshKosh\texture\
Careful examination of these textures at a high zoom level in FS SDK ImageTool shows that
rather than simply using the FSX resample method of an additional blend mask channel or external blend mask file when overlapping and blending edges of overlapping textures,
FS2Kx Resample utilized a clever method of
slightly changing color values for the pixels in rows which are to be overlapped, effectively achieving a blend which is potentially "better" for performance than the blend achieved using a discrete blend mask method.
Note also that
these photo-real aerial image tiles are DXT1 with NO Alpha channel (thus no monochrome / gray scale gradient transparency blending).
This legacy method (which still displays in FSX) when used for
smaller coverage areas ...may, IMHO, effectively put less demand on the FS rendering engine than using more recent SDK discrete Blend methods of FSX / P3D.
Why:
Because as Phil Taylor of ACES said, "
Transparency is computationally expensive" to the FS rendering engine.
ACES' caveats regarding total number of tiles using transparency to blend FS ground textures rendered at run time:
http://msdn.microsoft.com/en-us/library/cc707102.aspx
The 'gotcha' is that FS2Kx default or custom photo-real land class tiles utilize (
many ?) discrete 256 x 256 pixel files which may impact the vulnerability of FSX run time rendering loop performance to (
initial but temporary ?) delays imputed by FSX data loader sub-system fibers used for file I/O.
BTW: The effects of using (RGB ?) colors as a means of achieving blending effects for various aspects of terrain scenery processing (
ex: with water
masks as a means of blending aerial imagery with FSX default water) ... is alluded to by "
Maurizio G" (aka "Maurizio Giorgi" ?) ...author of several excellent freeware AussieX photo-real sceneries, and the payware Orbx FTX
Canberra Cityscape:
"
converting the water mask to gray scale you loose a lot of functions.... depending on the colour you use to draw the polygons, you have a different effect. For instance with a blue you hole the mask and FSX textures will be displayed. Using cyan you obtain a blend with FSX textures and your photoreal. For the water, using a red, you maintain the photoreal under.... very useful to obtain tropical see [sea ?] or sand sea. Using a green, the classic FSX sea will be displayed. And, with this same mask, you can obtain also the night lights, colouring with a specific magenta, all in the same mask.
Try these suggestions and you will remain surprised how this system is powerful...."
http://aussiex.org/forum/index.php?...cenery-tutorial-using-maps2bgl-program/page-4
...
and:
"
Basically, if you want to maintain the photoreal water, placing the water above the photoreal texture, you have to paint your watermask in red. Using the green, instead, FSX standard water will come out. Using the yellow, just near the coast, this creates water above the photoreal, preventing that some FSX texture comes out along the coast. To show you the system, I put an example of water mask."
[Original image web link is dead]
"This system is more powerful than using a monochromatic mask, because each colour has a different feature. The blue, drawn in the land area, creates an hole in the mask, and in this zone FSX textures will be shown. You could use it where there is vegetation, for instance, and you will have the autogen without making it. The cyan is used instead to make a transition. In the cyan area, FSX textures will be fused with the photoreal, smoothly. This is the technique I use. The photoreal tiles have to be corrected in their colours, otherwise the scenery won't look good. Use the contrast mask if the tile seems a little unfocused, to improve the image. The chromatic tendency of the pic have to be also corrected. Often, the satellite imagery tends a lot to blue or to red, due to a wrong white balance. Try, changing the different colours [with an image open in a graphics editor ?] to correct this tendency. You can make reference to an area that you know it's [is supposed to be ?] white. With the counterdrop [eye dropper color tool ?] click on it and see what is effectively this colour. If it's not really white, the colour balance is wrong."
http://aussiex.org/forum/index.php?/topic/2831-my-project/
NOTE: Maurizio G further explains these concepts of color-based masking / blending near the end of his excellent full tutorial document with example illustrations:
"
TUTORIAL_FOR_THE_PHOTOREAL_SCENERY_CREATION"
cfile7.uf.tistory.com/attach/183178384F1F957D0C6A94
"
WORKING WITH THE MASK
This will be your main work, the real job that requires your time. You will edit the created mask with a graphic program like Photoshop or Paint shop pro. More sophisticated is the program you use, better it will be, because you need to adjust the colours of the native bitmap and also to redraw some parts, for instance the airports, that almost never fit with your photoreal layer.
So, assuming that you are using Photoshop, that I advise, open it and load the native bitmap and the mask created too.
In this way:
[Original image web link is dead]
As you can see, this type of mask, reproduces exactly the native texture, in colours inverted, and in this way you can colour it properly when you need, taking as reference the native bitmap. But you will make it later.
Now it’s important to change the colours of the native bitmap, because the satellite images, like those you shot with a camera, almost always are unbalanced in their colours. I am a professional video producer and I know well these things.
You could use, for first the automatic levels function of the Photoshop to correct the image, but you will see that it’s not enough, you have to correct it manually, managing each of the 3 colours RGB. This is left to your taste (keep in mind that you should correct all the tiles of your scenery in the same way, otherwise it will have visible differences).
The tip I can give is to try to remove the chromatic tendence that images have…. Too much blue, or sometimes too much green, depends on the colour of the image.
Then adjust the brightness and the contrast. Use moderately the colour saturation because it affects a lot your image and you risk to make it unnatural. Save your changes.
It’s ok, you are going fine. Now it’s time to work with the mask. Here I show an example of a compiled mask.
The basic system is that using different colours on the mask, this will create different results on your sceneries.
The blue pratically holes the photoreal texture allowing to show what FSX normally shows…. The areas coloured in blue are full of trees, so here in your final scenery it will be displayed the FSX trees, and obviously also his terrain.
The yellow creates instead the FSX water and in this case you can see a river coloured in yellow. Naturally it depends on the native colour of the photoreal bitmap, but almost always you will obtain a dirty blue for the water with this colour. An animated water, obviously, with reflexes too.
If you would use instead a red for the water, this will maintain the photoreal colour….. so, if in the native image the water is green, then you will have a green water in your scenery. This means that using the red, you will maintain the photoreal colour. In the image I used also a dirty green for another river, and with this colour you make more dirty the FSX water. You can experiment your favourite tone of colour. Basically, use the yellow where the native bitmap image shows a very dark river or sea, use instead the red when the native image has beautiful and real colours. If you use a red when a river is too dark, the water won’t come out, you wouldn’t see the animation and neither the reflection.
The magenta (the darker in the image) is used instead to create the night lights. Where you draw this colour, your scenery will show the lights here.So you will colour where you have an area with houses or in some country fields, if you like some lights here too. Easy, aren’t you?
As ultimate, cyan is used to create the transitions between your scenery and FSX scenery, so that you can reduce the differences. Pratically this colour creates a fusion between FSX and your photoreal scenery. You will use it at the boundaries of your sceneries, along all the borders you have to fuse.
Well, I give you an example of the colours I use and what kind of functions they have with this colour palette:
[Original image web link is dead]
It’s important to know that for the night lights the magenta must be only this, otherwise nothing will be show…. This is a little secret I give you, after a lot of experiments….. This magic colour is in values:
H 313
S 99
B 99
R 252
G 2
B 198"
NOTE: I have a 'hunch' which I have not yet had time to test, which speculates that there may be a comparable routine in FS SDK ImageTool used for terrain texture overlaps (found in the obscure 'Help info' for ImageTool under "Terrain" and "Border" keywords) ...which may be useable for processing textures to be used for overlapping terrain textures.
http://www.fsdeveloper.com/forum/th...s-follow-a-size-guideline.431618/#post-685850
PS: An interesting discussion on using (RGB ?) component colors as a means of achieving blending effects:
http://softwarebydefault.com/2013/03/10/bitmap-blending/
Perhaps another graphics program other than Resample and/or ImageTool might be identified that uses component colors (derived from the source pixel colors and
not a gray scale "color" shade for a gradient "alpha" transparency) which can implement "feathered" and "color balanced" blending of (
ex: 1024 x 1024 pixel) images larger than the FS2Kx SDK resample TGA / BMP file output of 256 x 256 tile ...may be more appropriate for the bigger / higher resolution terrain tiles / ground-poly textures used in FSX / P3D ?
I'm not familiar with PhotoShop, but perhaps someone here may know if any of these blend options do what I'm describing above to "
feather" and "
color balance" adjacent images being used for a "
mosaic" ?
http://www.dummies.com/how-to/content/blend-modes-in-adobe-cs5-illustrator.html
http://www.exelisvis.com/docs/MosaicImages.html
I'm still curious: has anyone here tested the ImageTool options to process textures using Terrain / Border options ?
[
EDITED]
THIS JUST IN (...thanks, Google !):
Perhaps this (freeware)
OSGEO - OSSIM "
ImageLinker" GIS-based GUI workflow might be an easier method of creating a "mosaic" of tiled textures ...
complete with retained Geo-referencing for one's Geo-TIFFs:
"
Example Histogram Matching with DOQs
This example will take four Digital Ortho Quads that have different levels of brightness and contrast and mosaic them together into a tonally balanced mosaic using histogram matching"
http://download.osgeo.org/ossim/tutorials/pdfs/Histogram.pdf
ftp://ftp.remotesensing.org/ossim/tutorials/pdfs/ImageLinker_Tutorial.pdf
http://trac.osgeo.org/ossim/wiki/Tutorials/ImageLinker
http://www.geofemengineering.it/GeofemEngineering/Blog/Voci/2010/3/15_OSGEO_-_Live_-_DVD_-_"running_imagelinker".html
"
Histogram VCE Example Demonstrating the Visual Chain Editor Version 1.0
Overview - Histogram Matching with VCE
This tutorial will use that project as a starting point to demonstrate some of the capabilities of the visual chain editor and connectable objects in OSSIM.
The Visual Chain Editor (VCE) exists as a separate environment in the ImageLinker program.
The VCE allows the user to construct, inspect, and manipulate custom image processing chains through direct interaction with the image objects."
http://download.osgeo.org/ossim/tutorials/pdfs/HistogramVCE.pdf
...
See also:
http://download.osgeo.org/ossim/tutorials/pdfs/
ftp://ftp.remotesensing.org/livedvd/doc-dev/quickstart/ossim_quickstart.html
http://www.osgeo.org/home
[
END_EDIT]
Hope this info helps !
GaryGB