I’m trying to use vvvv.packs.image with DX11, first time I’ve pulled it out in a while.
Latest versions of both packs (vvvv.packs.image x64 version updated 4 days ago. DX11 pack v1.1 x64) on beta35.8_x64.
I can’t seem to get AsImage (DX11.2D) to work.
Could be my hardware, it’s an intel GPU on a NUC. Wondering if it works for anyone else?
Here’s what the AsImage helppatch shows me. Nil output from info node.
TTY Renderer logs this error
00:16:08 ERR : System.Exception in VVVV.CV.Core: Image not allocated, can’t access internal data
Stacktrace:
at VVVV.CV.Core.ImageBase.get_Data() in C:\dev\dhmd_Vogel_x64\vvvv_50alpha35.8_x64\packs\VVVV.Packs.Image\src\core\Image\ImageBase.cs:line 99
at VVVV.CV.Core.ImageUtils.CopyImage(IntPtr source, CVImage target) in C:\dev\dhmd_Vogel_x64\vvvv_50alpha35.8_x64\packs\VVVV.Packs.Image\src\core\Utilities\ImageUtils.cs:line 386
at VVVV.CV.Core.CVImage.SetPixels(IntPtr rawData) in C:\dev\dhmd_Vogel_x64\vvvv_50alpha35.8_x64\packs\VVVV.Packs.Image\src\core\Image\CVImage.cs:line 131
at VVVV.CV.Nodes.AsImageDX11Instance.Process(DX11Resource`1 input, DX11RenderContext context) in C:\dev\dhmd_Vogel_x64\vvvv_50alpha35.8_x64\packs\VVVV.Packs.Image\src\nodes\plugins\Image\DX11\src\AsImageDX11Instance.cs:line 106
at VVVV.CV.Nodes.AsImageDX11Node.Evaluate(Int32 SpreadMax) in C:\dev\dhmd_Vogel_x64\vvvv_50alpha35.8_x64\packs\VVVV.Packs.Image\src\nodes\plugins\Image\DX11\src\AsImageDX11Node.cs:line 59
Actually I just tested AsImage (Ex9.texture) and that’s not working either. Its internal status pin gives an error ‘The type initializer for ‘Emgu.CV.CvInvoke’ threw an exception.’
00:04:55 - : AsDesktop: 1920 x 1080
00:04:55 - : \\.\DISPLAY1 AsDesktop Refresh Rate: 60
00:04:55 * : couldn't connect pins of nodes IOBox (Node) and %VVVV%\packs\VVVV.Packs.Image\nodes\modules\Image\OpenCV\GridView (Transform).v4p.
00:04:55 * : couldn't connect pins of nodes Quad (DX11.Layer) and Renderer (DX11).
00:04:55 ERR : System.NullReferenceException in VVVV.Nodes.CV.DX11: Riferimento a un oggetto non impostato su un'istanza di oggetto.
Stacktrace:
in VVVV.CV.Nodes.AsImageDX11Instance.Process(DX11Resource`1 input, DX11RenderContext context) in C:\dev\dhmd_Vogel_x64\vvvv_50alpha35.8_x64\packs\VVVV.Packs.Image\src\nodes\plugins\Image\DX11\src\AsImageDX11Instance.cs:riga 96
in VVVV.CV.Nodes.AsImageDX11Node.Evaluate(Int32 SpreadMax) in C:\dev\dhmd_Vogel_x64\vvvv_50alpha35.8_x64\packs\VVVV.Packs.Image\src\nodes\plugins\Image\DX11\src\AsImageDX11Node.cs:riga 59
00:04:57 * : couldn't disconnect pins of nodes Quad (DX11.Layer) and Renderer (DX11).
what’s the type of the texture? (texture info node)
which imagepack download did you use?
does it help when having a preview after the renderer? what does the info node state?
does rightclick fix the asImage node?
@sebl
Type of texture: that’s the helppatch of AsImage DX11 Texture 2d.
Imagepack: the one you posted (latest x64 from…): only way I could have got my hands on it. Version.info says 0.2.0.
Preview: put a preview node for each renderer, no it doesn’t help.
Info node: what info node you’re referring to? The one in helppatch has only four output pins (shown in picture). Also consistent with info out of dx11 renderer.
Alt + rightclick: did nothing.
Edit: the card is nvidia. May not have most latest driver, 385.41.
Edit 2: There’s definitely something wrong: if, with AsImage helppatch opened, I use taskbar to close (rightclick on icon, then click on close), vvvv pops up an exception.
So I think there’s a few different things going on.
I’ve now got access to my main pc with an Nvidia card. (But I’ve lost access to the NUC with the intel card, so I’ll send more info when I’ve got that back next week).
//Issue 1
DX11 to DX9 conversion through AsImage results in corrupted DX9 output.
This only seems to take effect on particular X resolutions. Here’s a GIF, notice that when X = 128 or 160 it’s ok but at values in between it’s screwy. Patch also attached.
Possibly you just shouldn’t use Image pack for DX11 to DX9 conversion but because the AsImage(DX11) helppatch has a DX9 output renderer more people may see this bug than necessary…
//Issue 2
Color channels mixed up
There’s some weird behaviour when you change the format of the incoming texture.
First off when you have an invalid incoming texture type (Eg R16G16B16A16_Float) you get an error in TTY and the output of AsImage freezes. However If you have a static input image (as per the helppatch) and you aren’t looking at TTY it’s not immediately obvious anything is wrong. A red node or an ‘error’ or ‘status’ output pin on AsImage would be better failure behaviour.
Here’s my results from different input texture formats.
R8G8B8A8_UNorm - wrong colours. Note this is the default format for many DX11 renderers on my system.
R8G8B8A8_UNorm_SRGB - also wrong colours but different to previous
R8G8B8A8_Uint - very wrong colours, in fact DX11 preview even doesn’t like this one.
R8G8B8A8_SNorm - invalid format, output freezes
R8G8B8A8_SInt - invalid format, output freezes
I’m not going to do all of them. If we just stick with a few of the _Float and _UNorm
R32G32B32A32_Float - correct colours
R32G32B32_Float - correct colours
R16G16B16A16_Float - invalid format, output freezes
R16G16B16A16_UNorm - invalid format, output freezes
//Issue 3
Nil AsImage object. This is the problem I had from my first post that I can’t recreate on this hardware. I will provide more info on this when I can.
I’d point out that if, in colour bug patch, you go directly from R32G32B32A32_Float to B8G8R8A8_UNorm or …X8_UNorm, although the result is as expected, the format out of Info (CV.Image) remains RGBA32F.
Switching from “invalid” (renderer freezing) format to B8R8G8A8_UNorm wouldn’t unfreeze the renderer: only R32G32B32A32_Float and some of the R(32|16|8)_(UInt|Unorm|etc) would do the magic.
this is a specific problem when working with GPU textures. some drivers/devices handle image size in certain block sizes. so they make a bigger buffer to store the image than the width actually is. this has performance reasons. if the width and the backing storage does’t match the image must be copied line by line. also pixel size has to be taken into account.
this case is probably not 100% correct. so for now just make sure you use a compatible width or try to find the bug, the code is not overly complicated…
Since I was working on an small PC (HP prodesk with i5 CPU) with a intel graphic card, I found something related to @tobyk 's inital post. Just to complete this thread.
I wasn’t able to allocate the Image of CV.Image of the latest VVVV.Packs.Image with current 50beta36_x64. So as suggested in the inofficial thread here, I just put a 64bit nvcuda.dll into its corresponding folder (actually the one I found on the link that @Grandchild provided. Thanks).
