with the marker detection example (https://github.com/googlesamples/tango-examples-c/tree/master/cpp_marker_detection_example) I tried to detect AR Tags with id's higher than 16.
For that, I generated Alvar markers using http://wiki.ros.org/ar_track_alvar. (I have read these tags are Alvar in a comment in the google example source code). Is the SDK fixed to detect maximum only 16 ids (4bits)? If yes Does someone know if this will change in the future?
I am not interested in QR codes, since they don't seem to be robustly detected from perspective angles.
Related
I'd like to visualize a geojson file in the EPSG:4326 coordinate reference system using D3.js version 3. I'm aware it's better to use the newest version, but alas I'm restricted because of old software that doesn't support higher versions.
I wrote this code: https://bl.ocks.org/FrieseWoudloper/141945ce346639013ac1ced8e4c071b7
In the resulting output there is an SVG element with paths, but I don't see it. I think I have the translate and scale arguments wrong, but I don't know how to determine the right values. Could you please give me any directions on how to fix this?
Dose cobalt support youtube 360 video(Spherical Video)? If yes, how it's been implemented, is there any document for it? Does it need the platform to do extra things to support it?
Almost. There is still some small remaining work that prevents this from being a simple yes, but the vast bulk of the work is done and has been shown to function.
A document will soon be appearing in the source tree explaining all this, but here is a preview...
In order to support spherical video, a platform will have to support decode-to-texture, introduced in Starboard API version 4. Cobalt will choose between punch-out and decode-to-texture when creating an SbPlayer, based on whether a mesh transform has been applied to the video tag. In decode-to-texture mode, every frame, the video texture will then be queried from the player, and rendered into the UI graphics plane with the current transform applied.
We've encountered a strange problem on newer laptops using built-in graphic cards.
In order to draw true-type fonts we obtain the glyph outlines using wglUseFontOutlines and then draw them with in glRenderMode(GL_FEEDBACK).
Afterwards we parse the feedback buffer. This has worked for many years.
Now we have a problem with glyphs containing holes (only on platforms with built-in graphic cards):
wglUseFontOutlines works perfectly. If we just draw the returned display lists, everything is fine. However, the token stream generated with GL_FEEDBACK is corrupt. The debugger shows nothing unusual, all functions return with success and the parsing itself works fine too. It is really the binary data generated by GL_FEEDBACK mode, which is wrong.
Has anyone else encountered this problem?
And is there an alternative way to obtain outlines and fillings for true type fonts on Windows?
I'm just guessing into the blue here: The GL_SELECT and GL_FEEDBACK rendering modes were usually not supported by widespread GPU driver OpenGL implementations. Only a handful graphics cards from the previous century actually did support these rendering modes. Hence you would almost always fall back into a software implementation when using those modes.
However given modern GPU's vastly more flexible feedback mechanisms, the latest drivers could actually try to implement those rendering modes using GPU features (somewhat weird, because those modi have been removed from modern OpenGL profiles). Anyway, this could be the reason why you're experiencing these problems.
In order to draw true-type fonts we obtain the glyph outlines using wglUseFontOutlines and then draw them with in glRenderMode(GL_FEEDBACK). Afterwards we parse the feedback buffer.
That's a cool Rube-Goldberg machine. Why don't you simply cut the middleman and obtain the glyph outlines directly using the appropriate Windows GDI functions (GetGlyphOutline) for this? This is what wglUseFontOutlines is using internally anyway.
I am working on a project, which is Android app that uses camera to capture a photo of some ticket and does OCR recognition for only a part of it. I have no previous experience in image processing, but I know it must be some kind of tricky way, because Android applications have small RAM limits.
I have not enough reputation points to post images so I give URLs to it.
Below, I attach image before any processing:
My aim is to automatically detect these lines of (---) and crop it so that final image look like this one:
What's more - it's important to stay open-source and do it without sending photo to some external image processing service.
You can try using Hough Transform to find the lines. OpenCV has a implementation that is open source and works on Android.
HoughLineP is a very efficient Version of the HoughTransform to find Line Segments.
Olena is definitely the way to go!. It's a generic image processing library, but the interesting part is an module that's called Scribo.
Scribo will do document analysis on the picture to extract text and/or image regions, and optionally send text regions to tesseract for recognition.
Being feasible for Android or not is something that I couldn't tell. I've tried it on OSX and Linux systems and it shows great potential.
I am writing a DLL that needs to do some work in Cuda 3.2 and some work in OpenGL. OpenGL will render some grayscale images that my Cuda code needs to read in and modify, and then give back to OpenGL as a texture. I believe I need to create PBOs to do that. I have done some basic OpenGL stuff before but never worked with extensions, and that's where my problem is - I've been searching for 2 days and so far haven't been able to find a working example, despite wading through pages and pages of code. None of the samples I've tried work (and I'm sure my vid card will support it, being a GTX470)
Some specific questions:
1. I installed the nvidia opengl sdk. Should I be using glew.h and wglew.h to access the extensions?
2. My DLL does not have any UI - do I need to create a hidden window or is there an easier way to create an off-screen rendering context?
3. Can I create a grayscale PBO by using GL_RED_8UI format? Will both cuda and gl be happy with that? I read the opengl interop section in the cuda programming manual and it said GL_RGBA_8UI was only usable by pixel shaders because it was an OpenGL 3.0 feature, but I didn't know if that applied to a 1-channel format. 1 channel float would also work for my purposes.
4. I thought this would be fairly easy to do - does it really require hundreds of lines of code?
Edit:
I have code to create an OpenGL context attached to a HBITMAP. Should I create a bitmap-rendering context and then try to attach a PBO to that? Or will that slow me down by also rendering to CPU memory? Is it better to create an invisible window and attach the PBO to that? Also, does the pixel format of my PBO have to match the window/bitmap? What about the dimensions?
Thanks,
Alex
There's actually an example of how to use OpenGL and CUDA together. Look at the SimpleGL example.
You may want to take a look at this example:
https://github.com/nvpro-samples/gl_cuda_interop_pingpong_st