Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dariusz Piatkowski

Pages: 1 ... 34 35 [36] 37 38 ... 89
526
Applications / Re: PMView - colour vibrancy gone after save?
« on: November 16, 2020, 02:37:53 pm »
I reached out to Peter Nielsen - the author of PMView - regarding this. We exchanged a couple of emails, I researched the different formats in parallel to understand this better. In the end, I felt like Peter's final email pretty much summed up the issue very nicely. I asked him to OK me posting his response to the list here, he agreed.

Quote
Subject: Re: PMView - image colour vibrancy gone after save
To: Dariusz Piatkowski
From: Peter Nielsen
Date: Sun, 15 Nov 2020 14:20:55 -0500

Hi Dariusz,

PNG can use a palette (color lookup table) or true color values. In 8-bit mode, a 256 entry palette will be used. GIF always uses a palette, even for gray scale images.

JPEG can only use true color values. You need to read an article or technical paper to understand how it works, but in short, the procedure affects pixel data and reduces information.

Images with sharp contrast (like computer generated images) are generally not suited for JPEG because you will see artifacts because of the lossy algorith,. Also, even more important if you don't have many colors: JPEG is always true color (24 bits for each pixel), it does not have a palette. If you have an image with 256 colors, it can be stored in 8 bits per pixel. If you only have 8 colors, you only need 3 bits per pixel, etc. PNG and GIF may produce smaller images than JPEG in this case, while keeping the image unaltered.

>So am I understanding correctly that due to JPEG's algorithm and compression processing, the colours >eventually arrived at are the post-compression values and therefore this is why they do NOT match those >of the originals?

Yes. The JPEG algorithm is *extremely* unsuitable for computer generated images with "on/off contrast". This is where the algorithm performs the worst. JPEG is good for photographic images but should generally be avoided for any computer generated data.

>Is this taking place because the original used so few colours to start off with?

No. It's because of the sharp pixel-to-pixel contrast in the data. If I recall correctly, JPEG stores data in 8x8 blocks. If you resize the file by 8 times, and then save as JPEG you can expect a better looking result.

Thanks,

Peter

I am satisfied with this explanation, the key there being the extremely small number of colours in the sample images I encountered the issue with.

Thanks everyone,
-Dariusz

527
Networking / Re: Dual Network adapters
« on: November 15, 2020, 04:43:59 am »
So this one is an oldie, but maybe a goodie too???  :o

I'm bringing it back from the "dead" b/c a newer version of motherboard is heading my way (nuthin' fancy, just a small upgrade to SATA3 and maybe this platform will finally allow me to run the 6 cores of my Phenom X6 CPU?).

Anyways, that board has dual NICs. Both of them are RealTek chipsets, supposed to be exactly the same stuff I'm running on my board right now. So from a drivers' side of things, it may be a good-news story, aka plug-it in and run!

Therefore, I am curious how one could take advantage of such a configuration?

Specifically, I now have that 1Gig fibre feed into my house, OS/2 shows a pretty decent 820 Mbit/s throughput rate on average when I test (speedtest script).

1st idea is to setup one NIC of all WAN traffic, while the 2nd serves the LAN only...either way, I do not have much traffic on either one, so I'm not sure if the effort and added complexity is worth it?

If not, how would one split up the OS/2 tcpip traffic to take advantage of the two ports?

528
Networking / Re: patched AFINETK.SYS: anyone willing to test ?
« on: November 15, 2020, 02:57:04 am »
Hi Lars,

Well, I tried patching the original AFINETK.SYS driver with the udpated fix.pat, however, this is what i get:

Code: [Select]
[G:\mptn\protocol]\os2\patch fix.pat
Patching fix.pat

End of file is at E5C
Enter the hexadecimal offset of patch:

So I'm thinking something is off because the 1st fix did not require this.

I took a look at the fix.pat contents and compared NEW to OLD and there are some differences in the layout, but i'm not sure whether this is related to applying multiple patches or not?

EDIT
====
Hmm...as they say, RTFM everyone...I forgot the "/A" patch.exe command line option...yikes (blushing)!

529
Programming / Re: ODBC VX-Rexx/DBExpert
« on: November 14, 2020, 07:05:52 pm »
It looks like it's flat-out not expecting to see the JOIN in the first place...that feels like a syntax parsing error.

I spent a few years writing Oracle database code, so I'm curious if with this SQL dialect you could skip the 'INNER JOIN' and just go right to WHERE clause and rely on implicit JOIN given the matching of foreign and primary keys?

530
Applications / PMView - colour vibrancy gone after save?
« on: November 14, 2020, 06:53:09 pm »
This one is hard to illustrate since saving the as-is image will clearly strip the "vibrancy" off of it...LOL, but for the sake of comparisong I've attached the JPEG and PNG images or the same content (CPU monitor).

But here is what I'm seeing: capturing any images on my machine with PMView 3.82 (which I believe is the latest version) shows a perfectly matching colour intensity to the original image. However, saving it and re-openning now shows a much more toned down image. The vibrancy is gone.

This only happens with JPEG format (even if but using 100% quality), saving in GIF or PNG does not show this behaviour.

Has anyone seen this?

531
Networking / Re: patched AFINETK.SYS: anyone willing to test ?
« on: November 14, 2020, 06:19:44 pm »
Lars,

I have patched the driver and re-booted, still using the current version of my NIC driver. Once I have a few days of runtime on this baseline configuration I will move to test the MMRE drivers.

For what it's worth for anyone else attempting to do this, the RPM/YUM install has it's own version of patch.exe in /usr/bin, so when patching this driver make sure you call \os2\patch.exe directly, otherwise you'll get an error message from the patch utility.

Oh, one remark, although it may not be relevant give how long it's been since I actually tested my fibre 1G connection speed: firing up my speedtest python script now shows a noticable steady spike in the CPU core utilization, basically about 50-60% across all CPU cores. I do not recall this being the case in the past, but honestly unless I re-boot with the un-patched AFAINETK.SYS and re-test I cannot confirm. Anyways, I'll get that tested during the next re-boot.

EDIT: Added the screenshot of CPU spikes: two separate tests, show the individual spike groups

532
Web applications / Re: QT5 simplebrowser
« on: November 13, 2020, 11:59:13 pm »
Just answered my own question...there is an updated highmem RPM package out there...

Hello Dimitriy,

...The new highmem fixes some nasty bug in DosRead on JFS which hangs the system if an app tries to load a few hundred megabytes in one go. It's available in the exp repo as RPM now BTW. And you should NOT mark LIBCN0.DLL or LIBCX0.DLL for loading high — it will break virtually everything on your system...

Current 1.0.0 release is available in highmem-1.0.1-1.oc00.pentium4, will you continue with those updates as well, or will highmem.exe transition to the RPM package...OR...did you mean to say that the new highmem.exe is available as highmem-1.0.x-1.oc00.pentium4 RPM package on the EXP repo?

Sorry, may seem silly, but better to clarify as opposed to assuming anything. I suspect you meant the updated highmem RPM package as opposed to rolling it into the base RPM RPM package.

533
Web applications / Re: QT5 simplebrowser
« on: November 13, 2020, 11:08:24 pm »
Hello Dimitriy,

...The new highmem fixes some nasty bug in DosRead on JFS which hangs the system if an app tries to load a few hundred megabytes in one go. It's available in the exp repo as RPM now BTW. And you should NOT mark LIBCN0.DLL or LIBCX0.DLL for loading high — it will break virtually everything on your system...

Current 1.0.0 release is available in highmem-1.0.1-1.oc00.pentium4, will you continue with those updates as well, or will highmem.exe transition to the RPM package...OR...did you mean to say that the new highmem.exe is available as highmem-1.0.x-1.oc00.pentium4 RPM package on the EXP repo?

Sorry, may seem silly, but better to clarify as opposed to assuming anything. I suspect you meant the updated highmem RPM package as opposed to rolling it into the base RPM RPM package.

534
Programming / Re: ODBC VX-Rexx/DBExpert
« on: November 13, 2020, 10:57:28 pm »
...You mentioned that your odbcadm.exe does nothing. Doesn't it even bring up the dialog window where you can define databases etc.?

Well, I have nothing populated in the window and when I select 'Drivers' button that 'Installed ODBC Drivers' pop-up is empty as well, and there is no ability to add anything there. Further on, none of the other buttons work, so selecting HELP does not actually bring up any help screen. Therefore, I suspect that my install is only paritially correctly installed. Quite honestly I have no idea how it got here in the first place...lol

535
Programming / Re: ODBC VX-Rexx/DBExpert
« on: November 13, 2020, 06:06:33 pm »
Hi Per,

...Does anyone know where I can obtain fully working ODBC drivers ?

This probably isn't the answer you are looking for, but G:\OS2\APPS\BIN\ODBCADM.EXE appears to be an ODBC Administration utility. On my machine it does nothing, simply because no such connections are defined. Beyond this though, I wonder if some of the database packaged may in fact contain such drivers?

536
Networking / Re: patched AFINETK.SYS: anyone willing to test ?
« on: November 10, 2020, 08:04:53 pm »
Lars!

...Seems like if you restrict your system to one core that then the traps in AFINETK.SYS go away. At least that is what someone reported to me.

OK, I'll test this later tonight, although the TRAPs I did see weren't always immediate, so the full test-cycle might take a few days.

In the meantime, given the above reference and what you documented in the patch itself, what is being changed in the driver:

Code: [Select]
...
replace call to _indcomplete16 with _indcomplete
...

What I'm wondering is as follows: is the patch attempting to serialize the processing and thus potentially avoid any sort of SMP problems from creeping up?

Thanks!

537
Networking / Re: patched AFINETK.SYS: anyone willing to test ?
« on: November 09, 2020, 06:13:24 pm »
Hey Lars,

Sent you a PM.

Yeah, I'd like to take a stab at this. I used to run the MMRE drivers for my RealTek NIC, but once I moved to fibre I discovered that they would trap and the trap always was in the AFINETK.SYS driver. So while the R8169 driver appears to work fine, it is good for only this particular hardware combination I have at the moment.

thanks,
-Dariusz

538
Programming / Re: REXX - how to kill a process?
« on: November 05, 2020, 02:12:21 am »
Hi Doug,

Try PKILL.EXE. It seems to be included in ArcaOS, and only needs the program name, not a PID.

Yup, I got this one on my machine already, but I really wanted to do this through REXX (if anything, it's a bit a learning experience). I'll pursue Remy's suggestion.

540
Programming / REXX - how to kill a process?
« on: November 04, 2020, 05:15:20 pm »
So I need to kill a process given a particular flag being set.

I figured this would be easy in REXX, and most likley would rely on a suitable API call or a built-in function. However, no such thing has been found (REXX newbie here, so take it easy... ;))

But, I did start looking at RXU library, indeed, I can see that I could use:

dosrc = RxQProcStatus(stemname [,flags])

to get the equivalent of PSTAT result.

From there I could fish out the matching record for a particular module (an EXE in my case) and once I have the PID I could call:

killrc = RxKillProcess(pid [, action])

But all this still seems a little convoluted, I mean is there no simpler way to kill a process than having to point to it by a PID? Yes, I understand the reason for this, but if I have a single instantiation of a particular EXE I know that killing it by module name is just fine.

Any suggestions where to look next?

Oh, sure, I could call one of the utilities that do this, but I was hoping to push my REXX "boundaries" a tad and see how this could be implemented, any suggestions?

Thanks!

Pages: 1 ... 34 35 [36] 37 38 ... 89