hi,
i am trying to make a patch involving a live camera on PD 0.49.0 (64bit) with Gem 0.94_pre1 (64bit) on a windows 7/64bit machine.
so far everything works alright, but i can't set the camera resolution !
unfortunately the default resolution is 160x120, which is pretty useless. so far i found no way to change that resolution, the "dimen" message does nothing and setting width/height via the props method also doesn't work.
now here's another strange thing: with PD 0.48 and Gem 0.93 (both 32bit), when i opened the camera dialog (with the "dialog" message to [pix_video]), 2 windows opened: 1 for the camera driver settings (brightness, contrast, exposure etc.) and 1 for the resolution.
so with the fomer (32bit) version of Gem i COULD set the camera resolution to the desired dimension.
however, sending "dialog" to [pix_video] in the 64bit version described above, i only get 1 window, the one with the driver properties (which btw i can also set via the "props" method)
can anybody help me in this regard ? is there a workaround to manually set the camera's resolution ?
unfortunately i need the 64bit version of Gem because of the amount of RAM i need (i record video frames over some peroid of time, and the 32bit version is limited for my needs). plus the 32bit version doesn't work (i already reported that to the list)
thanks for any hints
best
oliver
On 3/5/19 6:33 PM, oliver wrote:
thanks for any hints
i've created a ticket at [228]. i've also did a bit of **totally untested** hacking, that might make the "dimen" message work.
if you can't compile yourself, you can try and "download" the build-artifacts from our CI [5487].
fgmdsar IOhannes
[228] https://bugs.gem.iem.at/228 [5487] https://git.iem.at/pd/Gem/-/jobs/5487
IOhannes m zmölnig wrote:
On 3/5/19 6:33 PM, oliver wrote:
thanks for any hints
i've created a ticket at [228]. i've also did a bit of **totally untested** hacking, that might make the "dimen" message work.
nope, sorry !
============================================================ PD 0.49(64bit) / Windows 7 (64bit) / Gem ver: 0.94.git v0.94 ============================================================
with the latest windows Gem from deken [pix_video] now doesn't work at all anymore. on opening its helppatch the console just says:
[pix_video]: no video backends found!
and no camera is captured.
also [pix_image] is now fully defunct, not even .rgb files can't be opened anymore.
also using your latest snapshot (as you suggested) didn't help.
just for the record:
with GEM: ver: 0.94.git v0.94_pre1
- [pix_video] did "somehow" work, but dimen could not be set
PD-console says: [pix_video]: backend #0='VFW' : vfw dv iidc analog [pix_video]: backend #1='VIDS' : videoInput [pix_video]: backend #2='decklink' <--- DISABLED
- [pix_image] could only load .rgb files, no .jpg or .tif
best
oliver
On 3/31/19 10:24 AM, oliver wrote:
IOhannes m zmölnig wrote:
On 3/5/19 6:33 PM, oliver wrote:
thanks for any hints
i've created a ticket at [228]. i've also did a bit of **totally untested** hacking, that might make the "dimen" message work.
nope, sorry !
============================================================ PD 0.49(64bit) / Windows 7 (64bit) / Gem ver: 0.94.git v0.94 ============================================================
with the latest windows Gem from deken [pix_video] now doesn't work at all anymore. on opening its helppatch the console just says:
[pix_video]: no video backends found!
i also got this, but...
and no camera is captured.
... capturing nevertheless works (in my recent test builds)
i'm sure i tested it before uploading the 0.94 release.
what's the experience of others?
also: i finally got around to testing my new code on a Win10 VM, and i am happy to report that it does work as expected (that is: i can now change the resolution of the captured video). only resolutions that the camera supports are supported though (so there's now additional rescaling involved).
my new builds also seem to work for 32bit Pd (without crashing), but only when started from an MSYS2 shell (and *not* when starting Pd the usual way).
gfmards IOhannes
On 4/3/2019 3:17 PM, IOhannes m zmölnig wrote:
my new builds also seem to work for 32bit Pd (without crashing), but only when started from an MSYS2 shell (and*not* when starting Pd the usual way).
There might be some needed DLL in "C:\msys64\mingw32\bin".
Check Gem.dll with http://www.dependencywalker.com/.
There will be a long list of un-finded dlls, but is safe to ignore the ones "win-api-*****"
:)
Mensaje telepatico asistido por maquinas.
On 4/5/19 2:43 AM, Lucas Cordiviola wrote:
On 4/3/2019 3:17 PM, IOhannes m zmölnig wrote:
my new builds also seem to work for 32bit Pd (without crashing), but only when started from an MSYS2 shell (and*not* when starting Pd the usual way).
There might be some needed DLL in "C:\msys64\mingw32\bin".
Check Gem.dll with http://www.dependencywalker.com/.
There will be a long list of un-finded dlls, but is safe to ignore the ones "win-api-*****"
i did do that prior to posting here, and didn't find anything (yet).
gmadsr IOhannes
On 4/7/2019 4:17 PM, IOhannes m zmölnig wrote:
i did do that prior to posting here, and didn't find anything (yet).
hmm,
Check for reddish color modules. This is an 32bit pd.dll loading a 64bit libwinpthread-1.dll (inline attach):
[image attach]
Also if you find something wrong and you fixed it, do another scan. i.e if you place some dll that was missing/wrong scan again as this new dll may have other new dependencies.
A.dll calls B.dll and B.dll now is calling C.dll. You didn't know about C.dll on your first scan.
:)
Mensaje telepatico asistido por maquinas.
-
IOhannes m zmölnig -
Lucas Cordiviola -
oliver