ah, looks nice. I was constantly searching for the options, like in which of the categories they were. So this certainly helps even though its just cosmetical. ^^

Cool. Good thing you like extra work since there looks to be some style regression at least. It's usually the case with Qt that small things go off between platforms, but more so across major versions of Qt.

Keep in mind some functionality on Windows isn't there in the Linux version, like alias resolutions, so those dialogs need to be converted separately. The control panel is a modular implementation that reuses much of the previous UI code so it shouldn't be too bad.

arnoo wrote on 2023-05-30, 21:59:

I've finally got to try and build some Windows binaries 😀

Hello,

thank you for the great work 😀 I just tested the version 2.7.0 on VisionRGB E2s on Windows 10 PC and it works great.

A few bugs I have observed:

1. If I activate the ECO mode, the older versions remembered it and when started again, the ECO was already active. With 2.7.0 it is not.
2. When I select 16-bit or 15-bit color depth in the input menu, the application crashes. "Error: OpenCV reported an error in file..\vcs\src\scaler\scaler.cpp on line 129" (not that I ever use these modes 😁)

And one tip for future improvement:

1. it would be great if the VCS can remember what channel was active on the last run and automatically select it on the next startup. My capture card has 2 channels and I have to switch to channel 2 most of the time.

Thanks.

havli wrote on 2023-07-01, 07:41:

1. it would be great if the VCS can remember what channel was active on the last run and automatically select it on the next startup. My capture card has 2 channels and I have to switch to channel 2 most of the time.

For the time being you can use the command-line option "-i 2". There should also be the shortcut Shift+1/2, if it hasn't been removed.

I tried the windows binaries of v2.6.1 and v.2.7.0 and both don't work with my VisionRGB-PRO1. Is that card not supported anymore or is this some other problem? The v2.6.0 binary I got from the original repo works.

They fail with the error message that RGBGetInputInfoW can't be found (I can make a githbut issue, just wanted to check if I missed that card being deprecated).

I assume it's built against a newer version of the Datapath RGBEasy API that doesn't support the PRO.

I tried the windows binaries of v2.6.1 and v.2.7.0 and both don't work with my VisionRGB-PRO1

Sorry about that. As vvbee correctly guessed, I used the latest RGBEasy SDK from Datapath, not realizing it was not supporting the same set of cards as the older ones.
(I'm still trying to wrap my head around the relations between RGB SDK versions, driver versions, and supported cards.)

I'd like to fix that for the next release, but unfortunately, it looks like Datapath just removed all legacy downloads from their website 🙁
Google still has the link for the driver, but it goes to a page that does not exist anymore on Datapath website.

If you still have them, could you and vvbee send me the driver package you're using?
(I'm not sure I would distribute those binaries as-is, but at least I could investigate, and see what can be done.)
Edit: was able to find the old driver package from a trusted source, see next post.

Internet Archive's Wayback Machine has delivered once more, and I was able to find the old drivers from a years-old capture of Datapath site. I'll see if I can use those to create a build that works with the old cards.

@happy: if you're interested in testing the next release with your hardware, could you comment on this issue on Github (https://github.com/arnoo-sel/vcs/issues/7), and I'll be in touch once I've got a tentative build targeting the old drivers?
Thanks!

arnoo wrote on 2023-07-02, 18:12:

Internet Archive's Wayback Machine has delivered once more, and I was able to find the old drivers from a years-old capture of Datapath site. I'll see if I can use those to create a build that works with the old cards.

@happy: if you're interested in testing the next release with your hardware, could you comment on this issue on Github (https://github.com/arnoo-sel/vcs/issues/7), and I'll be in touch once I've got a tentative build targeting the old drivers?
Thanks!

I also checked the Wayback machine and luckily the links to the actual files also still work on datapath's website. I'm uploading everything I can still download to the Internet Archive right now.

Here's the link to archived VisionRGB software and drivers: https://archive.org/details/vrgbpro
(this is probably the same as you just downloaded)

Someone else uploaded this before but an older version of it.
I'll download and archive the rest of the legacy software. You never know

I will comment on the gitbhub issue 👍

vvbee wrote on 2023-07-01, 17:22:

For the time being you can use the command-line option "-i 2". There should also be the shortcut Shift+1/2, if it hasn't been removed.

Thank you for the tip, I will try that.

Also got a feature request:

Currently there is an option for scaler output which includes optional padding.
However it would also be great if there was an outpot option which allowed for cropping. I found that the Voodoo 3 card adds black borders. Basically inflating 640 x 480 to 656 x 494, and at least some of that comes in the form of black borders. So it would be great if this could be cropped.

There's a cropping filter, that should do it.

vvbee wrote on 2023-07-03, 16:41:

There's a cropping filter, that should do it.

Thanks, tested, but I guess there is a bug.
You can see it in this video:

https://youtu.be/d4vr6I5VbTQ

What I got here is a 640*480 picture which the Voodoo outputs as 656x494, adding 8 Pixels left and right as well as 14 at the top.
These I then cop with the "Crop" option. Taking the 640x480 resolution out of that, which then goes into the output scaler which is supposed to do nothing (the cropped 640x480 should stay at 640x480). (Actually I want to use the output later on to add 10 pixels to bottom and top, so that I can properly scale it in OBS, but I guess thats irrelevant here). However you can clearly see in the picture that either the Crop or the scaler does something bad. The font becomes unreadable.
I am still running version 260 as the new versions didnt fix any bugs or added new features yet which I'd use.

At a glance I'm not so sure it's a bug. I think you should instead manually force the input resolution to 640 x 480. Filters manipulate pixels but don't resize frames, if you blow up the cropped region then you still have 656 x 494 going into the output scaler.

vvbee wrote on 2023-07-04, 22:06:

At a glance I'm not so sure it's a bug. I think you should instead manually force the input resolution to 640 x 480. Filters manipulate pixels but don't resize frames, if you blow up the cropped region then you still have 656 x 494 going into the output scaler.

If I understand you correctly that would mean 656 x 494 stays 656 x 494, just that the borders set up are being replaced by "emptyness", which on recording would be black.
But that is not the case. And you can see that in the recording. You can see there that the black border is gone.
I also tested to output as 656 x 494 - but the result is, that the black borders are cropped away, and then the remaining 640x 480 picture is actually made bigger to 656x494 WITHOUT the black borders.

So essentially no matter what you do, you will end up with a screwed picture once you start to use the cropping.

Ah, and forcing the resolution wouldnt really work either. This adds an additional black bar at the bottom + introduces tons of other problems similar to what I mentioned before with the 720x400 vs 320x200 split. which need 2 different presets, and two different processing pipelines.

There actually was a regression in the cropper in that the null scaler would still blow up the region rather than mask it with borders. You'd be using a non-null scaler though so this would have no bearing. If you crop to 1 x 1 with a non-null scaler you're supposed to get a single-color 656 x 494 image, otherwise a single non-masked pixel in a 656 x 494 image, so what you're describing sounds normal. I don't know what you mean by unreadable font since I didn't see anything egregious skimming the video, I assume you're just getting a crusty image from the fact that you end up upscaling and downscaling with mismatched resolutions and nearest sampling.

If forcing the input resolution doesn't work then basically that's the best the capture hardware can offer. I've captured the Voodoo in DOS and Windows using the VisionRGB-E and/or PRO and remember it being alright as far as these things go.

I am not sure if the issue is clear.
With cropping the picture of 656 x 494 is correctly cropped as in the cropped sections are moved away. Essentially making it into a 640 x 480 picture.
How would you output the picture then to not lose quality? If you output as 656 x 494 , you would stretch the cropped image of 640x480 up to 656 x 494 (I confirmed that). So what you do instead is output the remaining 640 x 480 as 640 x 480. But then some filter/scaler is applied even though it shouldnt be necessary.
The issue is clearly visible in every font you can see in the video. But just an example I took a screenshot of the most obvious one.

It is definitely not about the harware. The issue is how the software handles that. If I output the uncropped picture, everything is fine. I will then just need to crop via OBS. Cropping via VCS is essentially broken.

Uncropped:

Cropped (black border is gone, font is screwed, the "Daten werden" is missing some pixels at the bottom, similar effects with every font during the video):

Kordanor wrote on 2023-07-05, 08:38:

How would you output the picture then to not lose quality?

I'd force the capture resolution or adjust settings on the source, since 656 x 494 says bad input. Basically forget about the cropping filter, it's not the tool for this.

The screenshot looks like destructive scaling with nearest sampling, which your settings were asking for from what I saw. It also looks like the capture isn't clean since there's some phase-like ghosting and color smearing. The Voodoo has crap image quality but I don't think all of it is that.

vvbee wrote on 2023-07-05, 17:31:

Kordanor wrote on 2023-07-05, 08:38:

How would you output the picture then to not lose quality?

I'd force the capture resolution or adjust settings on the source, since 656 x 494 says bad input. Basically forget about the cropping filter, it's not the tool for this.

The screenshot looks like destructive scaling with nearest sampling, which your settings were asking for from what I saw. It also looks like the capture isn't clean since there's some phase-like ghosting and color smearing. The Voodoo has crap image quality but I don't think all of it is that.

Well, then my request stays the same: Would like to have a cropping feature.

In the end its about versatility and automaic adjustment. I dont want to readjust in the program for every different resolution I go to.

What do I mean with that?

Let's say I have 3 Resolutions:
320x200
640x480
656x494

And no matter what is currently on screen the output should be perfectly scaled.
So the current process is:

320x200 is naturally coming in as 720x400. That needs to be scaled down in VCS to 320x200. Unfortunatly multiple scaling is not possible. So it needs to output this. So I need to scale this in OBS, to fix the aspect ratio, I scale it to 1280x1000 (x4 / x5)

640x480 this resolution is still broken in VCS. You manually need to readjust the preset, otherwise it doesnt apply (see my video from months ago). To capture it in the same process with OBS I am adding panning 10 Pixels on top and bottom. That way I can just multiply with x2 x2 to end up at 1280 x 1000 which goes into the same window as 320x200

Now with 656 x 494 that is breaking again. Fortunately 656 x 494 does not have the bug 640x480 has, but I dont have a process to crop it. Logically it would need to be scaled x2 x2 as 640x480

So the only resolution I see as workaround for now is to adding black borders to everything else instead, which can then be cropped via OBS the same way:

656 x 494 has "natural" black borders of 8 left, 8 right, 14 top. In order to use it in the same process as everything else, I would now need to add additional padding of 6 pixels top, 20 pixels bottom, 2 pixels left, 2 pixels right. VCS outputs it as 640x480 in the center on a black canvas of 660 x 520.
OBS will "stretch" (pixel doubling) this to 1320 x 1040. And then crop some of the black border which is now (natural + artificial, both multiplied): 20 left, 20 right, 20 top, 20 bottom, resulting in the intended 1280 x 1000 image (with the intended 20px upper and lower padding I need)

All the other output would need to be adjusted as well in VCS, so I can make it work in OBS.

640x480 would now basically need to be made as "broken" as the 656 x 494 resolution by artificially adding the 8 left, 8 right 14 top, to make the canvas look the same, so that it can be processed the same way.
Essentially adding a padding of (10 left, 10 right, 20 top, 20 bottom), outputting it as the same 640x480 picture in the center on a black canvas of 660 x 520 like the 656 x 494 source resolution got.

720x400 is scaled down in VCS to 320x200, and then receives padding of 5 left 5 right, 4 top, 4 bottom. So it would be output as a 320x200 picture on a black canvas of 330x208.
Again, OBS will "stretch" (pixel doubling) this to 1320x1040, which in this case is x4 and x5. And then it will crop the (completely aritificially added border) of 20 left, 20 right, 20 top, 20 bottom. resulting in the intended image of 1280 x 1000

So the lack of the padding removal essentially means that I now need to add the padding on all other resolutions so that the VCS output can be processed the same way. which is the most important thing here. In a stream you dont want to tell everyone "wait, give me 3 minutes! let me re-adjust all the settings manually, so we can open the world map".

With that workaround it's possible...but certainly not the most elegant way. A crop feature would make it much less complicated.

And as mentioned before, my two other requests:
-fixing the 640x480 bug (it always needs manual intervention)
-have multiple scalers in one pipeline (that way you can guarantee that VCS already outputs the perfect picture no matter what, without the need to properly scale it in OBS)