I am currently working on a program that preforms techniques such as image segmentation along with a few others. However I have the task ahead of me of filling a segmented area (this will be a blank area) based on its surrounding pixels.
This is a lot like what photoshop likes to call content aware fill, however me being only one person am wondering the best way I could approach this type task. Also how I should start to think about getting something, obviously not as technical and robust, but similar in some sense to work.
I am not currently aware of any classes that may help with something like this but any help on this would be greatly appreciated.
You are after Inpainting. There are many ways to do it, and an Inpainting survey by BertalmÃo, Caselles, Masnou, Sapiro - 2011, presents lots of results and references about them.
Around here you will also find sample results using the technique, for instance at https://stackoverflow.com/a/13666082/1832154 you will see one together with http://www.cc.gatech.edu/~sooraj/inpainting/ that gives a complete implementation. At https://stackoverflow.com/a/14295915/1832154 you can see another sample result, together with a simplistic reference to a different inpainting method.
Related
Greeting, wise ones!
I am trying to make a generator for pictures like this one. My idea is to make 2 patterns (vertical lines and horizontal lines). After that, I need to make vertical lines only appear "within" the letter but go a bit beyound if they don't intersect a horizontal line. Same for horizontal line, just for being "outside" the letter.
To perform this I need to know, which pixels are "within" letters of the text() object and which are not. This is the only thing, that I can't get my head around. Any ideas on how to implement this?
(If you have a simpler idea of how to make this generator, I'll happily read about them as well, I'm not too sure that mine is the best)
TL;DR: solution
So, initially, I was doing it in Java Processing and was thinking in terms of points and "if" conditions. I couldn't get any meaningful help and abandoned the problem, doing the thing by hand.
However, later I encountered a problem with detecting if a point is within a polygon in Unity and found a solution that includes the concept of raycasting. It's easily implemented in Unity but will require some extra work in something like Java Processing. In any case, this is an excellent answer to my question. I hope it helps anyone who encounters a similar problem.
Explanation:
EDIT3: MASSIVE CLEAN UP as this was not clearly explained.
I'm trying to build up a 2D level out of tiles and entities. Where the entities are for example trees that can be cut. I need to store the data (how many chops are left for example) for each entity. I want them to have a more dynamic position (doubles) and a more dynamic sprite-width and height. My tiles are 32x32 pixels whilst my trees are not going to be one tile but a sprite with greater height than width.
I want objects that are closer to the top of the level to be drawn before the other objects. In this case a character behind the tree will cannot be rendered in or in front of the tree. This case also applies to other objects of the same kind (like trees).
I think it might be too inefficient to loop through the entities and calculate each entity's position since there may be a LOT of entites in the level.
As I've done some research I found that certain libraries allow the storage of both the object and it's position in a MAP (BiMap in google's Guava).
Questions:
Is this an inefficient manner.. but are there some changes that can
be applied to make the rendering more efficient (if so, what could be
optimized)?
Or is this an inefficient manner to render the entities and is
there a better way (if so, what other methods are there in Java)?
Or is there something else that I haven't listed?
EDIT2: I looked through the link I've posted in the edit below.
It seems that Google's Guava (I think that's all correct) has BiMaps. Is there an equivalent to this in regular Java? Otherwise Google's Library will probably be able to fix this for me. But I'd rather not install such a huge library for this one interface.
At last:
It's very much possible that the answer has been right in front of my nose here on StackOverflow or somewhere else on the internet. I've tried my best searching but found nothing.
If you've got any suggestions for search queries or any relevant links that might be of use to me I would appriciate it if you'd post them in the comments.
Thanks for taking the time to read through this/helping me ;)
EDIT:
I have looked at; Efficient mapping of game entity positions in Java .
I think it's narrowly related to this question. But I think it's just not what I'm looking for. I am going to look through the second answer very closely since that might be able to solve this for me.. but I'm not sure.
SOLUTION
The solution is to have an array, arraylist or another manner to keep track of your entities. Every tick/update you'll take all the object's Y coordinates and store them in another array/arraylist/map/other with the same size as where the entities are stored in. On every equivalent position to the entity you'll store it's Y. Then you'll order it with another loop or using http://www.leepoint.net/notes-java/data/arrays/70sorting.html .
Then when rendering:
for(int i = 0; i < entityArray.length; i++)
entityArray[i].render();
Off course you'll render it more efficiently by rendering only whats on or near your screen.
But that's basically how one does this in 2D top-view/front-view.
In my own 2d game attempts I come up with the following solution:
use an enum to specify different types of objects in game and give them priorities (sample order: grass, rivers, trees, critters, characters, clouds, birds, GUI)
make all visual objects implement interface which allows for getting this DrawPriority enum
use a sorted implementation of list with comparator based on the enum
use the list to draw all elements
That way the order computing is not very expensive, because it is done only on Visual Object insertion (which is in my case done while loading a level).
.. And since you will already using a comparator, do a x/y comparison when the enum priority values are the same. This should solve your y-order draw problem.
I'm working on a sketch search engine that correlates whatever someone's sketching with a picture in the database (the db is just about 40 pictures now). I'm doing this mostly for fun so I'm not that well-versed in computer imaging techniques.
First of all, are there any rules of thumb on how one should create histograms (bin sizes, ranges, etc)? I'm using some histogram code found at http://www.scribd.com/doc/6194304/Histograms (but ported to JavaCV). Sometimes I get good results, sometimes I get bad results, most of the time I get "meh" results. I've been experimenting a TON with bin sizes and ranges and I'm wondering if comparing higher dimensional histograms may be the answer here.
Second of all, it seems that black makes a very strong presence in my current histogram setup (even a black dot shifts the entire result set). Should this be expected? Or did I screw something up? Example:
And after the dot:
Note how I'm already getting pictures of "earthrise" as "close" matches.
I'm also wondering what methods I should use for blob or feature analysis. I think that stuff like SURF may be overkill because I only want to broadly compare blobs, not accurately map templates. Is there any way I can compare the edges after being passed through a Canny filter? (Low complexity if possible):
For example, here, I want the two smiley faces to be at the top because the needle smiley "blob" is more closely related to the smily face shape than to a bunch of passion fruit or a galaxy.
Phew long question. If you want to try out the engine for yourself, go to http://skrch.dvt.name/ (shameless plug, I know, I know -- only works in FF/Chrome/Safari). Maybe more experienced computer vision people can make suggestions based on results. Oh, I'm using the CV_COMP_BHATTACHARYYA distance when comparing histograms (it seemed that it gave the best results although chi-square isn't bad either).
Is there a background ?
IS it significant ?
Maybe you need to look at whether there is a user-supplied background or not.
then you "just" need to have 2 histogram per db entry, one with bg, one without.
That'll stop earthrise looking like an apple with a dot.
for basic bg separation, try a canny, then taking "outside" and removing it from a copy of the original.
I saw this video, and I am really curious how it was performed. Does anyone have any ideas? My intuition is that he scraped pixels from the screen (one per 'box'), and then fed that into some program to determine the next move.
Is scraping pixel-by-pixel the way to do this, or is there a better way? I am looking to do something similar with either Java or Python.
Thanks
Probably that's the most reliable way. There are ways to inspect what is happening inside a process - looking directly at its internal state and memory - but they are platform-specific and very prone to misbehaving because your dealing with a slightly different version of something - that includes a different flash version as well as a different version of the app. Those methods are more often used for "trainers" for exe games, where there's typically only one or two versions of the executable to worry about.
Lots of screen shots, comparing, figuring out reliable indicator pixels seems the way to go - plus keeping track of what you expect to happen, of course. When the app is running, it should work from a screenshot at a time (hopefully ensuring a consistent picture, with no half-updated views) and then test the minimum number of pixels needed using (perhaps) a decision tree.
There are ways to automate construction of efficient decision trees, but it's probably easier to do it manually based on comparing screen shots. In this case, since Tetris normally creates all new pieces at the same position, with a 1:1 relationship between colour and shape, you can probably determine the shape and position of a new piece from a single pixel colour - so "decision tree" is probably the wrong term, really, in this case - though there are other things the bot needs to read from the screen.
What's more interesting is the logic to actually make gameplay decisions, since that bot clearly isn't just slotting every piece into the most immediately obvious position, but deliberately aiming to create opportunities to clear 3 or 4 rows at a time.
Yes, i think he scanned the pixels. Actually it should be very simple because you only need to scan the new shape for each move. With that information you can locally calculate the grid and further use it for your AI calculations.
This is a subjective question as I want to gauge if it's worth me moaning at my co-workers for doing something which I find utterly detestable.
The issue is that a bunch of my co-workers will truncate method calls to fit a width. We all use widescreen laptops that can handle large resolutions (mine is 1920x1200) and when it comes to debugging and reading code I find it much easier to read one line method calls as opposed to multiple line calls.
Here's an example of a method (how I would like it):
IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class, param1, param2, param3);
(I do hate really long interface/class names as well :)
It seems that this doesn't render well on StackOverflow, but I think most of you know what I mean. Anyway, some of the other devs do the following.
IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class,
param1,
param2,
param3);
Which is the easier to read at the end of the day for you and would I be unreasonable in asking them to use the first of the two (as it is part of our standard)?
I find the first example more readable in general, though if it is longer than some predefined limit (120 characters, for me), I would break the lines:
IReallyLongInterfaceName instanceOfInterfaceName =
OurContainer.retrieveClass(IReallyLongInterfaceName.class,
param1, param2, param3);
Maybe you should have as part of your standard build process some sort of checkstyle plugin which checks for exactly that kind of thing? If you've agreed the standard with your co-workers it seems reasonable to ask them to keep to it.
I personally find the second of the two options the more readable, but that's just because I don't have a widescreen monitor ;)
If its exlicitly stated in the companies coding standard that method one is the correct method then by all means moan at them, after all they are not adhering to the company standards.
If its not exlicitly stated then I guess now would be a good time to get it into the standard.
One thing to be aware of though, if you are using an IDE with autoformatting is that it may take it upon itself to reformat the methods to style 2 when its run.
So even if everyone is writing to style 1, it may not end up looking like that when they are finished with it.
and like Phil, I find method 2 much more readable, since you can see everything you need to see without having to scroll your eyes sideways :)
I prefer the second example. Even though you may have widescreen laptops, you might not always have windows full screen, or in your IDE you may have a lot of other panels around the main coding area that reduce the available width for displaying code.
If the line can't fit without scrolling, then vertical scrolling is preferable to horizontal scrolling. Since we read left-to-right, horizontal scrolling would mean moving backwards and forwards all the time.
I prefer one parameter per line to Avi's suggestion, which is arbitrary to me. If you spread the parameters over multiple lines but have several on each line, it makes it more difficult to find particular parameters when reading the code.
I prefer option #2, as well. The issue isn't just how it looks on screen (and if I had 1920 horizontal pixels, I'd have a lot more docked windows), it's how it looks if I need to print it and read it. Long lines will print terribly out of most IDEs, whereas lines broken by an author with the intent to improve legibility will print well.
Another point is general legibility. There's a reason magazines and newspapers are printed in columns -- generally, readability of text (particularly text on-screen) is improved by shorter lines and better layout/formatting.
I think 80 might be overly arbitrary, but I'm using 10pt Consolas, and I seem to be able to get about 100 characters per line on a standard 8.5" printed page.
Now at the end of the day, this is a holy war. Maybe not as bad as where to put your curly braces, but it's up there. I've given you my preference, but the real question goes back to you: What's your company's standard? It sounds to me like they've standardized on option #2, which means for the sake of the team, you should probably adapt to them.
I prefer option 2, but optionally with comments for parameters where the variable name is not obvious. When you have a function call that is asking for a bunch of parameters, it can be pretty hard for reviewers to tell what the code is doing.
So, I generally code like this if there are more than 3 parameters to a given function:
applyEncryptionParameters(key,
certificate,
0, // strength - set to 0 to accept default for platform
algorithm);