I have a python-fu script, which is mostly working. It scans a layer looking for a color, rectangular selects contiguous areas of that color, copies the portion of image in another layer covered by that selection, and saves it to a separate file. All good.
Now the rectangular select has to be cleared, so that it won't be selected again as part of some other set, and the scan starts over so that it can find the next contiguous rectangular block to save.
Unfortunately, I can see the scan traverse the area that's been cleared, and the debug output shows that it still thinks the color is there. Despite the fact that I can see the area is transparent. So, I must be missing a step that tells gimp to update.
I thought I had it with the following:
pdb.gimp_edit_clear(layer)
pdb.gimp_drawable_update(layer,0,0,width,height)
gimp_edit_clear does clear the selection in the layer I'm searching -- I see that happen -- but the gimp_drawable_update doesn't seem to do anything, because when the loop progresses over the spot that's been cleared, it reports that the old color is still there.
What am I missing?
The problem was not with the clear, but with my understanding of what it did. I thought it erased the area reverting it to the natural color of an originally transparent area which is RGBA(0,0,0,0). That's what GIMP reports when you ask for the color of a pixel in a fresh transparent layer.
'Clear' doesn't actually remove the color, it just sets the transparency to 100%. So if the original color had been "fully visible white" RGBA(1,1,1,1), it just turns it to "invisible white" RGBA(1,1,1,0).
I had misunderstood RGBA(0,0,0,0) as "transparent", when it's really "invisible black".
So, when my scan started again, it was still seeing 'white', albeit 'invisible white'. Now, instead of using 'clear', I do a fill with the background color, which I've deliberately set to "invisible black".
Related
I've been trying to work on a small hobby project that involves plotting players' positions from a game onto a heatmap, to see where the most active areas are at various points in time.
I'm a bit new to OpenCV and its tools, but I've managed to successfully run some text matching and extraction on the scoreboard and timers in the game, now trying to take the characters' positions from the in-game minimap.
It looks like this, which is the biggest resolution image I'm able to get with (about 185x185):
I'm trying to obtain the positions of only two things: the characters (big circles) and "wards", which are represented by these icons:
So given the assets to them, I thought that because there was too much "noise" in the source image, I'd try to subtract the background of in game minimap from its image, and then try to pattern match the original character and ward image with the resulting image together (which is meant to be the minimap, minus its background). But that didn't even get close to working as you can see:
> >
Even if that did work, I wouldn't be really sure how to handle cases where the icons are partially covering each other, or how I could obtain the positions of those little ward markers.
I'd really appreciate some help, as I've been searching the Internet and banging my head for a few days and haven't gotten anywhere. I've tried a bunch of difference techniques, read guides and articles, and tried a few GUI tools to experiment with but haven't gotten any closer to a method to work this out.
Please help me with what techniques I could or should be using instead, to get the locations of all the characters and wards.
I'm not an OpenCV user, but I can speak to some general problems.
First and foremost, you goofed in subtracting the background map. It appears that you did a straight, arithmetic subtraction of the map's RGB values. For instance, the blue-team icons in the lower-left corner are roughly #99FFFF, and you're subtracting the grayish background of maybe #D0D0FF. This leaves you with #002F00, a very dark green.
Also note that you're subtracting the original map, not the part that shows. Paths beyond view are shaded, but you appear to subtract the original value.
What you need to subtract is a masked background. Unfortunately, building that mask means that you have to find the icons. Masking won't work well at this stage.
Back to the subtraction: don't just blindly subtract. Rather, look for a match in hue. When you find a hue match, simply set that pixel to 0. You have two special cases to watch: icons on the background of their own colour, especially for the blue team. In this case, you need to define the region boundaries.
Start from a pixel that's an exact match to the original background. It won't be shaded, since all such problem pixels are in plain sight of an icon. Expand from that pixel so long as you have the exact match to the original background colour. That will give you the region you can blank out.
Your next problem is to identify icons. You should now have a map with only icons, many of which are fully revealed. Those are easy matches; identify and subtract them, one key icon at a time.
You now have a map of partial icons. Switch the match algorithm: a key icon is now a match to either the exact color, or to black (indicating it was previously covered). Iterate until you have no more matches.
This does still leave you with one problem: an icon that no longer has enough pixels showing to identify. These will be icons that were either entirely covered, or covered except for a small portion that is not unique, such as a few pixels of a red circular border.
For this, a general approach is to keep track of game progress to a small extent: from an earlier time, you know where the icon used to be. Track each icon as a software object. If other icons cover it, assume it's still there until you discover otherwise.
This will handle most cases. You'll still have some problems with minions or sensors that get shot out from underneath a legend's icon, but I trust that your heat map application is not so fragile as to take modelling damage from that situation. The legend will move soon enough, revealing the small item's death. A moving minion isn't covered by a legend for long; they don't move with the same intelligence.
At present I'm generating a chart based on a bunch of user-selected options, and this is rendered on the server to generate a png output file. The generated png chart is then displayed on the user's system, over an underlying system background.
Where the plotBackgroundColor of the chart has some opacity, the user's underlying system background will of course show through, and will influence how the chart appears.
That's all fine, because the user has complete control over both the highcharts plotBackgroundColor and the system background colour.
But now I want to generate a chart that is "free standing", with a solid background colour (no opacity) which represents exactly how the chart appears when over the system background. That way, I can display that chart on any system, to give a true picture of what the user is seeing, regardless of the system background colour in the target device.
I do have access to the user's system background colour (it's either a bitmap, or I can just extract the "dominant" colour somehow and use that as a solid colour instead if it's easier).
So using the concept of layers, this would be like merging the highcharts plotBackgroundColor with a solid colour that represents the system background colour, and using that as plotBackgroundColor instead.
Or maybe there's a way to change an underlying background "browser" colour that is used in the highcharts renderer, independent of plotBackgroundColor?
I'm sure this must be possible somehow?
One way of doing this, and it's what I'm doing until someone posts a better answer, is just to manually combine each backgroundColor value with the underlying system canvas colour, using the method described at https://stackoverflow.com/a/10782314/4070848. This is basically just laying one colour over the other, and using an algorithm to determine the combined colour based on the respective opacities and rgb values.
I check whether the backgroundColor is a plain colour or a linear/radial gradient, and if the latter then I combine each of the stop colours separately with the underlying colour and reconstruct the gradient based on the merged stop colours.
Seems to work OK, but maybe there's an off-the-shelf method, or maybe someone can tell me how to do it better...!
I have an Image of a landscape which i need to fill with different colors.
When i select colors from palette and start scrubbing on any particular part, only that part should get the color even if by mistake i take my finger outside of that image part.
So basically i need to detect which part of image have i tapped so that only that part takes the color.
I am developing this app in Cocos2dx, but any help in logic would be a good point to start.
Here is an example of what i want.
Note : I know i could achieve this by taking separate images and then detecting touches, but that increases the app size by alot of MB's.
I guess user will be able to draw only on white part of the image.
If above is true, what i want you to do is, in your touchesMoved method, check if any black color (non white) pixel is present between previous touch point and current touch point.
If there is no such black pixel, then draw it else dont draw it.
Please be kind, I'm new to this....
I have an application that I'm developing where I need to take a PNG image, which has a transparency layer, and treat another color (I'm thinking of using RGB( 1, 1, 1 ), since it's so close to pure black that I can hard-code it) as a separate transparency layer. The reason for this is that I have a background image sitting behind the PNG image that I would like to still display as my sprite gets filled (by adding a progress bar to the sprite), and I only want the portions of the sprite that aren't of the given color to reflect the color fill of the progress bar. In this way, I can avoid having to deal with vector computations for the outline of the image within the sprite, flood the area outside of the discernable image with my new "transparent" color, and be on my merry way.
I've tried using shaders, but they seem to be less than helpful.
There is no way that I know of due to Open GL not allowing you to do it. You will either have to modify the pixel data manually or write a shader (Which you hav already done ).
I'm drawing some cars. They're Bitmap's, loaded from PNG's in the library. I need to be able to color the cars-- red ones and green ones and blue ones, whatever. However, when you paint the car green, the tires should stay black, and the windows stay window-color.
I know of two ways to handle this, neither one of which makes me happy. First, I could have two bitmaps for each car; one underneath for the body color, and one on top for detail bits. The underneath bitmap gets its transform.colorTransform set to turn the white car-body into whatever color I need. Not great, because I end up with twice as many Bitmap's running around on screen at runtime.
Second, I could programmatically search-and-replace "white" with "car-body" color when I load the bitmap for each car. Not great either, because the amount of memory I take up multiplies by however many colors I need.
What I would LIKE would be a way to say "draw this Bitmap with JUST THE WHITE PARTS turned into this other color" at runtime. Is there anything like this available? I will be less than surprised if the answer is "no," but I figure it's worth asking.
You might have answered the question yourself.
I think your first approach would need only two transparent images: one with pixels of the parts that need to change colour, one with the rest of the image. You will use colorTransform or ColorMatrix filter by case. It might even work with having the pixels the need the colour change covered with Sprite with a flat colour set on overlay ?
The downside would be that you will need to create a 'colour map'/set of pixels to replace for each different item that will need colour replacement.
For the second approach:
You might isolate the areas using something like threshold().
For speed, you might want either to store the indices of the pixels you need to replace in an Vector.<int> object that could be used in conjuction with BitmapData's getVector() method. (You would loop once to fetch the pixel indices that need to be replaced)
Since you will use the same image(same dimensions) to fill the same content with a different colour, you'll always loop through the same pixels. Also keep in mind that you will gain a bit of speed by using lock() before your loop to setPixel() and unlock() after the loop.
Alternatively you could use Pixel Bender and try some green screen/background subtraction techniques. It should be fast and wouldn't delay the execution of the rest of your as3 code as Pixel Bender code runs in it's own thread.
Also check out Lee's Pixel Bender subtraction technique too.
Although it's a bit old now, you can use some knowledge from #Quasimondo's article too.
HTH
I'm a little confused where you see the difference between your second approach and the one you would like to have. You can go over your loaded bitmap pixel by pixel and read out the color. If it turns out to be white replace it with another color. I do not see occurence of multiplied memory consumption.
You might want to try my selective color transform: http://www.quasimondo.com/archives/000614.php - it's from 2006, so some parts of it could probably be replaced by a pixel bender filter now.
Why not just load the pieces separately, perform the color transform on the one you want to change, then do a BitmapData.copyPixels() with the result? The blit routine runs in machine code, so is wicked fast. Doing it pixel by pixel in ActionScript would be glacially slow in comparison.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/BitmapData.html#copyPixels()