I am trying to use a premade stage from an old game as my background. Its resolution is 4864 x 184. I've tried every setting in graphics options and any other related settings. I think its related to the texture page size but I can't find any information on how to change the size.
Thanks for any replies.
But it is not the best solution in the case. I would recommend to spilt the background into smaller pieces (two 2048*184 and one 768*184) because otherwise it may not work on some old hardware.
Related
I am trying to find a way to specify some antialiasing settings in three.js/WebGL to try and improve the results.
The thing is that with the exact same code, if I load a model on a Retina Display, the antialiasing works quite fine (even if I move it to my non-retina external monitor afterwards), but it's all pixelated if I load it first on a non-retina screen.
Here is a screenshot (both on Chrome, both displayed on a retina display). Left was loaded on a non-retina, right on a retina: https://i.imgur.com/krNavZU.png
What I get from this is that three.js somehow uses the pixel density when initializing the antialiasing. Is there anyway to tweak this so that I can force it to something better?
Thanks a lot in advance for your help :)
Side note: For the record, it seems that the antialiasing works much better on Firefox as well, anyone knows why?
Just in case someone is looking to do the same kind of tweaking I was trying, I'll answer my own question.
Based on WaclawJasper's comment, I found some documentation in Three.js related to my issue. From http://threejs.org/docs/#Reference/Renderers/WebGLRenderer:
.setPixelRatio ( value )
Sets device pixel ratio. This is usually used for HiDPI device to prevent blurring output canvas.
I was using renderer.setPixelRatio( window.devicePixelRatio ); in my initialization, which was the reason why the rendering was depending on where the page was first loaded.
Related to the antialiasing, I now artificially raise the pixel density using renderer.setPixelRatio(2); on non-retina screens. This results in a much more effective antialiasing, at the cost of increased computation.
I want to remove background and get deer as a foreground image.
This is my source image captured by trail camera:
This is what I want to get. This output image can be a binary image or RGB.
I worked on it and try many methods to get solution but every time it failed at specific point. So please first understand what is my exact problem.
Image are captured by a trail camera and camera is motion detector. when deer come in front of camera it capture image.
Scene mode change with respect to weather changing or day and night etc. So I can't use frame difference or some thing like this.
Segmentation may be not work correctly because Foreground (deer) and Background have same color in many cases.
If anyone still have any ambiguity in my question then please first ask me to clear and then answer, it will be appreciated.
Thanks in advance.
Here's what I would do:
As was commented to your question, you can detect the dear and then perform grabcut to segment it from the picture.
To detect the dear, I would couple a classifier with a sliding window approach. That would mean that you'll have a classifier that given a patch (can be a large patch) in the image, output's a score of how much that patch is similar to a dear. The sliding window approach means that you loop on the window size and then loop on the window location. For each position of the window in the image, you should apply the classifier on that window and get a score of how much that window "looks like" a dear. Once you've done that, threshold all the scores to get the "best windows", i.e. the windows that are most similar to a dear. The rational behind this is that if we a dear is present at some location in the image, the classifier will output a high score at all windows that are close/overlap with the actual dear location. We would like to merge all that locations to a single location. That can be done by applying the functions groupRectangles from OpenCV:
http://docs.opencv.org/modules/objdetect/doc/cascade_classification.html#grouprectangles
Take a look at some face detection example from OpenCV, it basically does the same (sliding window + classifier) where the classifier is a Haar cascade.
Now, I didn't mention what that "dear classifier" can be. You can use HOG+SVM (which are both included in OpenCV) or use a much powerful approach of running a deep convulutional neural network (deep CNN). Luckily, you don't need to train a deep CNN. You can use the following packages with their "off the shelf" ImageNet networks (which are very powerful and might even be able to identify a dear without further training):
Decaf- which can be used only for research purposes:
https://github.com/UCB-ICSI-Vision-Group/decaf-release/
Or Caffe - which is BSD licensed:
http://caffe.berkeleyvision.org/
There are other packages of which you can read about here:
http://deeplearning.net/software_links/
The most common ones are Theano, Cuda ConvNet's and OverFeat (but that's really opinion based, you should chose the best package from the list that I linked to).
The "off the shelf" ImageNet network were trained on roughly 10M images from 1000 categories. If those categories contain "dear", that you can just use them as is. If not, you can use them to extract features (as a 4096 dimensional vector in the case of Decaf) and train a classifier on positive and negative images to build a "dear classifier".
Now, once you detected the dear, meaning you have a bounding box around it, you can apply grabcut:
http://docs.opencv.org/trunk/doc/py_tutorials/py_imgproc/py_grabcut/py_grabcut.html
You'll need an initial scribble on the dear to perform grabcu. You can just take a horizontal line in the middle of the bounding box and hope that it will be on the dear's torso. More elaborate approaches would be to find the symmetry axis of the dear and use that as a scribble, but you would have to google, research an implement some method to extract symmetry axis from the image.
That's about it. Not straightforward, but so is the problem.
Please let me know if you have any questions.
Try OpenCV Background Substraction with Mixture of Gaussians models. They should be adaptable enough for your scenes. Of course, the final performance will depend on the scenario, but it is worth trying.
Since you just want to separate the background from the foreground I think you do not need to recognize the deer. You need to recognize an object in motion in the scene. You just need to separate what is static in a significant interval of time (background) from what is not static: the deer.
There are algorithms that combine multiple frames from the same scene in order to determine the background, like THIS ONE.
You mentioned that the scene mode changes with respect to weather changing or day and night considering photos of different deers.
You could implement a solution when motion is detected, instead of taking a single photo, it could take a few ones with some interval of time.
This interval has to be long as to get the deer in different positions or out of the scene and at the same time short enough to not be much affected by scene variations. Perhaps you need to deal with some brightness variation, but I think it is feasible to determine the background using these frames and finally segment the deer in the "motion frame".
So I'm making a game with my group on processing for a project and we all have different computers. The problem is we built the game on one computer, however at this point we have realized the the (1200,800) size we used does not work on our professors computer. Unfortunately we have hard coded thousands of values to fit on this resolution. Is there any way to make it fit on all computers?
From my own research I found you can use screen.width and screen.height in order to get the size of the screen, I set the game window to about half the screen size. However all the images I had loaded for background and stuff are 1200x800 So I am unsure how to go about modifying ALL of my pictures (backgrounds), and hard values.
Is there anyway to fix this without having to go manually change the 1000's of hard values? (Yes I am fully aware how bad it is I hard coded the numbers).
Any help would be greatly appreciated. As mentioned in title, the language is processing.
As I'm sure you have learned your lesson about hard-coding numbers, I won't say anything about it :)
You may have heard of embedding a processing PApplet inside a traditional java JFrame or similar. If you are okay with scaling the image that your PApplet draws (ie it draws it at the resolution that you've coded, and then the resulting image is scaled up or down to match the screen), then you could embed your papplet in a frame, capture the papplet's output to an image, scale the image, then draw it to the screen. A quick googling yielded this SO question. It may make your game look funny if the resolutions are too different, but this is a quick and dirty way. It's possible that you'll want to have this done in a separate thread, as suggested here.
Having said that, I do not recommend it. One of the best thing (IMO) of Processing is not having to mess directly with AWT/Swing. It's also a messy kludge and the "right thing to do" is just to go back and change the hard-coded numbers to variables. For your images, you can use PImage's resize(). You say your code is several hundred lines long, but in reality that isn't a huge amount-- the best thing to do is just to suck it up and be unhappy for a few hours. Good luck!
On the left is the original PNG and on the right are versions reduced to roughly half the original size using width and height.
Why does the resized image look so fuzzy in Firefox? Is there anything I can do about it without changing the image file? The fuzziness is particular annoying if the image contains large amounts of math or text.
I know this is late, but you can trick firefox into rendering the image better by applying a oh-so-slight rotation. I tried to translate() the image to get the same effect... to no avail.
CSS
.image-scale-hack {
transform: rotate( .0001deg );
}
Javascript
if( "MozAppearance" in document.documentElement.style ) {
$('.logo img').addClass('image-scale-hack');
}
I avoid browser sniffs at all cost. I borrowed this sniff from yepnope.js and I don't feel bad about it.
Also noteworthy, this same trick can be used to force sub-pixel image rendering in both webkit and firefox. This is useful for very slow animations - best explained by example:
http://jsfiddle.net/ryanwheale/xkxwN/
There is a longstanding bug ticket filed in Bugzilla related to Firefox image downscaling. You might like to keep an eye on the ticket to track its eventual resolution or contribute a patch yourself if you feel able to.
The best workaround is to use the transform CSS property to apply a tiny rotation to the problem image and force sub-pixel rendering, as detailed in Ryan Wheale's answer.
The image-rendering documentation linked from the Firefox blurs an image when scaled through css or inline style answer which Su' referenced includes instructions for using image-rendering:optimizeQuality (which corrected the issue in my testing on FF4) - example:
I think your answer is in the link from above https://developer.mozilla.org/En/CSS/Image-rendering:
'Currently auto and optimizeQuality are equal by default, both result in bilinear resampling.'
'default value IE8+: bicubic (high quality)'
Next see:
http://www.codinghorror.com/blog/2007/07/better-image-resizing.html
'When making an image smaller, use bicubic, which has a natural sharpening effect. You want to emphasize the data that remains in the new, smaller image after discarding all that extra detail from the original image.'
I can think of a couple of possible workarounds, but neither are simple:
Resize the image on the server. Either serve it up at half size, and allow Firefox to scale it up to full (which presumably it will be ok at), or have different URLs for the different sizes of image.
You may be able to make this work in the browser with plugins (but the example I found doesn't actually do what you need, so I've removed it).
TL;DR: Image scaling is not likely to be fixed soon. About anywhere.
Longer version:
Eris Brasseur has a page that deals nicely with the broader question "Why is just about any image scaling software so bad?"
http://www.ericbrasseur.org/gamma.html
Since W3C's position on this matter is roughly that it's better to have an incorrect but equally incorrect implementation everywhere, they shun any proper dealing with Gamma (which would complicate matters slightly). Thus anyone accustomed to web standards is likely to continue ignoring Gamma, leading to the effects described by Eric and in this thread. This ensures that even downscaling is far from being well-defined, as Jeff Atwood puts it in an Article linked in another answer.
In such an environment, methods like Lanczos thrive whose claim to fame is mostly that they perform quite well even if implemented incorrectly.
In other words, browsers are the software equivalent of McDonald's burgers, and that fact will stay. Its implications need not, but the odds are skewed.
Now (2017) the bug is closed 2 years ago. A short Test:
FF, 50%:
FF, 25%:
A workaround for this issue is just to resize the original image with an image editor to the desired size and to use the image as it is, without defining it's width and height in the style sheet.
I m, on a daily basis creating web pages. My preferred development screen resolution is: 1600x1200 but what is yours?
And do you use any other plug-ins?
I use window re sizer 1.0 for Firefox. But are there better options?
In my opinion, if you're using a window resizer, you're already on top of the game. I try to aim for pages that work well on a 1024x768 screen, accounting for scrollbars and toolbars and whatnot. It may be worth resizing your screen to 1024x768 (or whatever the minimum is that you support) every once in a while just to fully understand that user experience, but in general the window resizer keeps you aware enough.
I disagree - fixed size layouts are just fine. In fact, Stackoverflow.com uses a fixed size layout, as do a great many professional sites out there. The reason? Predictability.
A few things:
Never have horizontal scroll bars
Try to avoid vertical scroll bars when it's reasonable to do so
Remember, AJAX and other newer technologies can help you save space on your page with popups and other niceties.
My 2 cents,
-Doug
It shouldn't matter - design your web pages to be flexible and fluid such that they degrade gracefully on any reasonable screen resolution. Cater for mobile devices with very minimal screen space and massive displays.
I develop with a 2x1440x900 setup, but I leave Firefox as a window at 1024x768 using Web Developer Toolbar.
The dual monitor setup is really useful when you have the code on one screen and Firefox on the other.
I wouldn't go over 800x600. However, ideally your layout is not fixed to a screen size, and can resize and still look right.
I stick with 1024x768. It's usually big enough for what you need to display, and not everyone is quite to 1600x1200 yet. Maybe in a few years. I'd stick with a smaller display...that way it may force you to be more design conscience.
Two screens are invaluable regardless of screen size. One screen to run your editor, and one screen to run your browser. It's amazing how much smoother development becomes.
With my stats showing 1024x768 as my users' dominant resolution, I certainly wouldn't go below that. Beyond that, I agree with, apparently, everyone else here that fixed size layouts are just a bad idea, and your design should adapt to render context.
For the love of Pete don't use pixel sized fonts. Use em or pt sizing instead.
It all really depends on what kind of page you are designing. I would try to design with the ability for the page to scale in mind. There is nothing I hate more than having to zoom in a page that was designed for 800x600 on a 1920x1200 display.
I think the best advice given here is just to try it at different resolutions instead of your native one, and try to make it look good at a variety of sizes.