The Documentation of OpenCV mentions that "the returned image (by cvRetrieveFrame) should not be released or modified by the user" ...
Link: http://opencv.willowgarage.com/documentation/c/highgui_reading_and_writing_images_and_video.html#retrieveframe
I am trying to debug my code, which involves the following steps:
Retrieve frame from video using cvRetrieveFrame()
Do some processing on the frame
output results
My instinct says that something is wrong with cvRetrieveFrame() because if I manually input frames using cvLoadImage, the program works fine. But I am not getting same results while using cvRetrieveFrame().
Since the documentation mentions such a restriction, any reason for such a restriction ? And, any alternatives ?
Have a great day
Before you call this function, you should have used another function which is cvGrabFrame() in order to be able to use the mentioned function, which you can use it for doing any necessary processing on the frame (such as the decompression stage in
the codec) and then return an IplImage* pointer that points to another internal buff er
(so do not rely on this image, because it will be overwritten the next time you call
cvGrabFrame()).
Related
My Anchor program spits out an error that looks like: custom program error 0xa2. What does this mean? Where can I learn what this error means?
This is Error: 162: 8 byte discriminator did not match what was expected.
That means anchor was expecting an account's data to start with a certain 8 bytes, but it didn't.
That could be because you passed in the wrong kind of account (so the first 8 bytes were totally wrong), or maybe because you're trying to use zero_copy and haven't actually written those bytes yet (need to use #[account(zero)] before you've run .load_init())
It also can happen if you're trying to reference an account from a program that wasn't originally written in Anchor, and now you're rewriting it in Anchor. You might need to write some custom serialization logic for this.
Is it possible to generate CAN protocol errors with CANoe?
Tried searching for it but the word "CAN" is not really search friendly.
If you mean disturbing CAN frames, generate error frames then consider trying Vector interface VH6501 - https://vector.com/vi_vh6501_en.html
It's successor of deprecated product named CANstress. Integrates seamlessly with CANoe/CAPL.
yes, you can create error frame in CANoe. use IG block and select special frame option in IG configuration. then press send now button to transmit.
Yes, CAN protocol errors can be generated with CANoe. A detailed example can be found here under Online Vector Help in CANoe (by clicking the help symbol in the CANoe tool): CAPL Functions » CAN » on errorFrame
I'm using Direct2D to render my user interface.
What I would like is to be more easily able to profile my ui rendering (since I'm using several panels using Graphics debugger is a bit cumbersome).
Since I know that Direct2D uses a Direct3D device (exactly d3d11 device using 10_0 feature level) under the hood, I'd like to know if it is possible to retrieve either a ID310Device or ID3D11Device instance from ID2D1RenderTarget or ID2D1Factory object.
In that case I would easily be able to attach a timestamp query on the BeginDraw/EndDraw calls.
I tried several QueryInterface calls, but none of them have been sucessful so far.
An interesting undocumented secret is that any ID2D1RenderTarget you get from ID2D1Factory will also be an ID2D1DeviceContext (it seems to be intentional from what I've gathered, just accidentally undocumented?). Just call IUnknown::QueryInterface() to snag it. From there you can toy around with methods like GetDevice() and GetTarget(). If you can get the target then you may be able to weasel your way to obtaining the IDXGISurface which supports IDXGIDeviceSubObject::GetDevice() https://msdn.microsoft.com/en-us/library/windows/desktop/bb174529(v=vs.85).aspx (I haven't verified this part)
And in Win10 it looks like ID2D1Device2 gives you precisely what you want: GetDxgiDevice() https://msdn.microsoft.com/en-us/library/windows/desktop/dn917489(v=vs.85).aspx . So in that case, your ID2D1RenderTarget is cast to an ID2D1DeviceContext via IUnknown::QueryInterface(), and then you get an ID2D1Device via ID2D1DeviceContext::GetDevice() and then cast it to an ID2D1Device2 via another call to IUnknown::QueryInterface().
I found several ways to load an image and use it as a texture. All examples I found use texImage2D. But according to the docs this method is some what deprecated. Two alternatives stood out to me: texImage2DUntyped or texImage2DTyped. The untyped version can be fed with an ImageElement for the pixel data but I don't know what values I should pass in for the other parameters?
Because I'd like to abstract the html stuff from the actual gl rendering code I'd like a way, I can load the image and pass the data to the rendering code. I think texImage2DTyped would be good here, but I can't find an example how to load an image as TypedData. And again, what are the possible values for the other parameters?
TL:DR: Is there an example for texImage2DUntyped?
There is an open ticket for the documentation issue:
https://code.google.com/p/dart/issues/detail?id=16195
By the way, I'm using both texImage2DTyped and texImage2DImage here:
https://code.google.com/p/negentropia/source/browse/wwwroot/dart/texture.dart
texImage2DTyped --> takes data from a Uint8List
texImage2DImage --> takes data from a ImageElement
I am using the Datalogics library 9.1 and I am trying to embed an OutputIntent in a PDF I am creating so that it will be compliant with PDFA-1B.
I'm using PdDocColorConvertEmbedOutputIntent to do so and the function call is succeeding. The intent is getting in there, I can see it in Adobe Preflight. But certain PDFA verifiers still do not like what I'm creating.
I think it may be because the PDFA/s I create with this method have an outputIntent with a subtype of "GTS_PDFX" (as shown in Preflight). I believe it needs to be "GTS_PDFA". I see nowhere to specify the subtype of the output intent in the PdDocColorConvertEmbedOutputIntent parameters. This meethod seems to automatically choose the "GTS_PDFX" subtype and not allow me to choose anything else.
Basically, I'm just reading an ICC profile into pBuffer from a file, creating the profile and embedding it as below.
AC_Profile profile = NULL;
ACMakeBufferProfile(&profile,pBuffer,nSize);
PDDocColorConvertEmbedOutputIntent(m_pDoc,profile);
Am I missing something?
The 9.1 API and early versions of the 10 API have no parameter to supply to PdDocColorConvertEmbedOutputIntent () to specify the subtype. At the time of creation there was only one subtype "GTS_PDFX" and was hard coded into the API.
Manipulation at the COS layer will be necessary to affect a change to the subtype.