Discussion Forums

Hi,

I have a number of rotated ECW aerial photos that I am rendering using the Map Engine. Because they are rotated there are large areas of black space at the edges of the photos.

Is there a way when rendering the ECW files to make the black areas a different colour - or even better, transparent?

I understand that ECW/JPEG2000 files can not support the alpha channel in usual RGBA files?

Thanks in advance.

Dave

David,

Can you used the following method to render to ECW file:

imageLayer.GreenTranslation = 0;
imageLayer.RedTranslation = 0;
imageLayer.BlueTranslation = 0;
imageLayer.Transparency = value(0-255);

you can set the Transparency value between 0-255, 0 represents the maxium transparent, 255 represents the minium transparent.

Thanks,

Thanks for the response.

Unfortunately the transparency value works on the whole image.

I have looked at a couple of ways to do with image attributes:

- setting the color key to black sets all black colours to transparent

imgLyr.ImageAttributes.SetColorKey(Color.Black, Color.Black)

Unfortunately the colours nearer the aerial image are not exactly black. So I tried the colormap object:

imgLyr.ImageAttributes = New System.Drawing.Imaging.ImageAttributes()
            Dim cMap As New System.Drawing.Imaging.ColorMap()
            Dim list As New Generic.List(Of System.Drawing.Imaging.ColorMap)()
            cMap.OldColor = Color.Black
            cMap.NewColor = Color.Transparent
            list.Add(cMap)
            cMap = New System.Drawing.Imaging.ColorMap()
            cMap.OldColor = System.Drawing.Color.FromArgb(255, 1, 1, 1)
            cMap.NewColor = Color.Transparent
            list.Add(cMap)
            cMap = New System.Drawing.Imaging.ColorMap()
            cMap.OldColor = System.Drawing.Color.FromArgb(255, 2, 2, 2)
            cMap.NewColor = Color.Transparent
            list.Add(cMap)
            cMap = New System.Drawing.Imaging.ColorMap()
            cMap.OldColor = System.Drawing.Color.FromArgb(255, 3, 3, 3)
            cMap.NewColor = Color.Transparent
            list.Add(cMap)

            imgLyr.ImageAttributes.SetRemapTable(list.ToArray())

This allowed me to set multiple colours to make transparent but didn't seem to work either as there was still 'almost black' edging to the aerial. the other problem is that therse methods make the same colour within the aerial image transparent as well - so shadows to trees have transparent sections.

Any further help in this would be much appreciated.

I don't think there is a clear cut solution for your ECW once it has been created. You can mess around with the ImageAttribute and get some enhancements in the displaying of the image layer but the real solution is at the creation of the ECW. You should contact your data provider of the ECWs and ask for other images without black margins. Another solution would be to use an Image Processing software such as ERDAS that could handle those operations to certain degree of removing black margins.

Hi Val and Scott,

I refer to your replies to this question by David and thank you both for your suggestions.

The individual rotated aerial images with black borders are georectified images being generated with ERDAS Imagine using their ECW plu-in. We haven't found a way to produce these ECW's with a transparent edge. We tried changing the black background to a colour not found in most of the images. This simply converted all black pixels both on the edge and the throughout the image to the new nominated colour.

Between either ERDAS or Thinkgeo this is a very important issue for us to resolve and is a potential showstopper as the ability to make the margins of rotated images transparent so they can be overlaid over an existing mosaic is a requirement of a number of our customers. Because of the large original image size (372MB per image), using ECW (1/15th of the size) is very important for performance.

With upwards of 5,000 aerial photos being captured per day we wish to be able to render processed images in two ways :

a) As ortho photo mosacis ideally with the black margin around the mosaic made transparent. These mosaics are produced some weeks after the image capture. This is not crucial but would be fixed if there was a solution to b).

b) By displaying either one or more individual georectified images within the selected extent. These individual images have an overlap of >50% and are rendered as an overlay on top of an existing ortho photo mosaic along with other map layers and are available immediately following the image capture. With overlapping images, the black margin of each rotated image makes a mish mash of the display and it is not possible to see how the georectified images line up with each other and over the underlying mosaic as the black margin of each individual rotated image blocks out part of the underlying image or mosaic.

I assume this functionality would be generally useful to others as well as a feature which enables near real time access to georectified aerial imagery (ie in emergencies) without the need or delay involved in producing ortho photo mosaics.

If this problem could be solved by Think Geo, ideally the requirement would be to make transparent only contiguous black pixels from the external margin of the image, as opposed to all black pixels.

We did have some hope when reading the forum thread : http://gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/1/aft/458/afv/topic/Default.aspx that this might be relatively simply fixed as were the similar issues raised in that thread. We are also pursing this problem with ERDAS but would be very grateful if Thinkgeo could help us come up with a simple solution.

Thanks again

David Wright

I also looked at your ECW in Global Mapper and I could not find a way to display transparent the margin. When I think logically about this problem, I don’t think that any viewer can guess that the black margin should be treated as a margin. It does not know that it is not part of the displayed area or part of just a margin. That leads me to my original thought that the ECW needs to be created differently or modified later on using some imaging software. This is beyond the scope of a developer tool such as Map Suite. I am not an expert in Imaging but I would think that it would have to be determined what pixels are part of the margin and change their RGB value to transparent. I am not very familiar with ERDAS but I would check with their support to see if you can for example select manually the pixels to change their value or do something like that. I really don't think we can do much on our side.

Hi Val,

Thanks for looking at this and discussing it with me to try and find a solution which I appreciate. As discussed, to solve this problem I expect we are going to have to work at it from both the ERDASS end and the ThinkGeo end.

One possible approach we have established at the ERDASS end is to adjust all black pixel values in the source TIFF image by 1 (ie from rgb value 0,0,0 to 0,0,1 or 1,1,1), then georeference (rotate) the image to it's correct orientation and then export it as an ECW with a background with rgb values of 0,0,0. This would mean no other pixels in the image would be rgb 0,0,0. We can then use the ThinkGeo API to render all rgb pixels with a value of 0,0,0 as being transparent without punching holes in the photo itself. Visually pixels with an rgb value of 0,0,1 or 1,1,1 are essentially black anyway.

However this poses a massive processing task at the ERDASS end and I assume will limit performance at the ThinkGeo End as the whole image is being assessed for pixel values of 0,0,0 as opposed to just the margin.

Our desire therefore is to find a solution from the ThinkGeo end which applies as a much smaller image is being rendered as opposed to being a massive processing task at the ERDASS end with very large source images (up to 372MB in size each * several thousand a day).

An approach we are wondering if you can consider is whether during the rendering of several stacked images you can floodfill or paint all contiguous or neighbouring pixels as transparent starting from the edge, top left corner or from all four corners pixels of each individual image, as opposed to searching across all pixels in the image. As the border is probably less than 20% of the image this could have a significant impact on processing time.

An example of how this is done in the open source, command line image processing software program "ImageMagick" http://www.imagemagick.org is shown in the following command line, I have adapted this from the second usage example listed at url http://www.imagemagick.org/Usage/color/#opaque under "Floodfil" :

convert ImageIn.jpg -bordercolor "rgb(0,0,0)" -border 1x1 -background "rgb(0,0,0)" ^
-flatten -fuzz 3% -draw "fill none matte 0,0 floodfill" -shave 1x1 ImageOut.png

Broken down, the syntax of this is :

1. Read ImageIn.jpg
2. Add border 1 pixel wide with a background colour of black (ie rgb 0,0,0)
3. Using a variance of 3%, floodfill the image from pixel xy coordinate 0,0 (ie the top left) with a value of "none" (ie transparent)
4. Shave off the border that was 1 pixel wide added previously
5. Save the image as a png. (in our case we wish to save the final image as a JPG)

The effect of this which is important with the image example we have provided you with is :

a) the pixel corners of the original photo when rotated can be on the very edge of the final image, thus a flood fill operation of contiguous pixels of the same value (or within a 3% range) will stop and only make transparent the top left corner of the image.

b) the ability to vary the pixel colour of rgb 0,0,0 by say 3% is necessary as there is some leakage of colour from the rotated image into the black margin during the compression to ECW. Unfortunately this results in black skuff on the outside of the image referred to in the example by David above.

If it was possible to use the Think geo API to floodfill all contiguous neighboring pixels (within a range of say 3%), from the corner of the image, this may mean we can avoid the massive processing task at the ERDASS end referred to above.

A further approach which would reduce the readwrite time of the command line above would be to use the pixel width and height of the image to determine the top right, bottom right and bottom left pixel x,x coordinate value and floodfill all pixels from each corner within say a 3% range of rgb 0,0,0. This would obviate the need (and time) to undertake the step of drawing a 1 pixel width border, filling it with rgb value 0,0,0 and then deleting it when finished as in the above command line example. This may also be important to avoid in case it affects the actual geolocation of the image. Also our images do not always have a black margin on all corners. If the colour of any corner pixel was found to be not rgb 0,0,0 then it would simply be skipped, thus reducing processing time further before moving onto the next corner.

The only downside with this approach is where there are contiguous black pixels within the rotated photo that join up with the margin on the outside of the photo. For example a "Black River" or black shadow on the edge of the photo within the image. For this reason we may need to process all the pixels on the ERDASS end, however I am assuming there could still be a substantial saving of processing time on the ThinkGeo end if it only makes transparent the outer edge as opposed to the whole image.

Would be grateful for your comments or any suggestions you can come up with.

Regards

David

David (david Wright i mean - since we are both called david this is getting a little confusing!),
A couple of points:
1 - JPEGS cannot be made transparent. Only when merged throught eh GDI+ graphic object can you make some of the pixels transprent

2 - you could bleed in from the edge for the processing but I don't see the need. When the aerial image is viewed using the MapSuite Engine the GDI+ engine can easily make a number of colours transparent within the image - an by image I mean the final rendered map image no the original.
The bleeding effect is the problem. If ERDAS can make sure the border of the aerial is exactly black - and no other pixel in the image exactly black - then processing will be very fast. This is because the vast amount of processing is really done by the ERMapper ECW component that passes a image for the extent to the mapsuite engine.

Is there no way to switch off antialiasing within ERDAS - to stop the bleeding from the aerial?

Regards,

Dave

Hi Dave J,

Thanks for the points.

Re point 1. This whole issue is based around the fact that JPEGS (and variant ECWs) cannot be made transparent which has signficant advantage in speed but limitations in display.

Re Point 2. The bleeding issue is part of the problem we are seaking to address on the ERDAS end which seems to be occuring during compression to the ECW rather than during the rotation.

Per the post above, it seems likely that the only approach which makes sense at this stage is to offset all black pixels in the original photo by 1 prior to rotation and and also to ensure the margin once rotated is pure black once exported as an ECW. Then using the GDI+ graphic object render pure black as transparent as one rather than tackling each stacked image. As mentioned however the original size of each photo is 372 MB and multiplied by 5,000 or more a day and it is a significant requirement of hardware, storage and processing requirement to do the black offset. If there was a solution to this once the ECW had been created that would be ideal but appears unlikely.

Cheers

David

Using the SetColorKey function of ImageAttributes, setting the range from 0,0,0 to 5,5,5 in RGB value, I could get rid of most of the black margin without affecting the image itself.

I hope this helps a little bit. I hope that with ERDAS, a more elegant solution can be found. Thank you.

Dim imageLayer As New ImageLayer("...\ortho_l_sept_14__001619.ecw")

Dim ImagAttr As New ImageAttributes()
ImagAttr.SetColorKey(Color.FromArgb(0, 0, 0), Color.FromArgb(5, 5, 5))
imageLayer.ImageAttributes = ImagAttr

map1.ImageLayers.Add(imageLayer)

Hi Val,

Thanks for the code to set a range for the SetColourKey. This will be helpful however still will result in transparency within the rotated image of the original photo where the colours in the range exist.

I still suspect however, per the other' David's comments, the best result and performance will be obtained if we can offset black in the original image by 1 before rotation and then make the background (ie Margin) entirely black. We can then render black in the endire image as transparent rather than trying to find a solution to make the margins of individual images transparent.

However we have confirmed the bleeding is taking place during conversion to ecw rather during the rotation. We are seeking to address this with ERDAS. If we can solve this at least we have a solution, even if it requires extra processing.

Cheers

David

Good luck with manipulating the images with ERDAS. If there is anything else we can do at our end, let us know.