Because 1.) You are experiencing persistent and unrequested filetype association changes and 2.) Both third-party software and Mac OS system utilities are being set--again, without request and persistently--as first-responder applications for major filetypes, I therefore believe you have a corrupted Launch Services database. (While there is a known issue with Adobe CC2017 being the cause of .pdf files opening in Photoshop rather than in Preview.app, this does not explain the behavior of Grab doing the same to .jpg files.)
[NOTE: The following paragraphs are taken from The Eclectic Light Co. site. I include them here to provide a backup set of instructions for attempting a solution should the link die, but I recommend visiting the actual site if possible.]
There is no simple way to rebuild your Launch Service database, unless you have a utility such as OnyX which includes this as a feature. Restarting in Safe mode (with the Shift key held) flushes quite a few caches, but does not touch the Launch Services database. Even if someone were to tell you where to find the files, you cannot just trash them.
The tool which maintains the Launch Services database is lsregister, which is tucked away in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support.
It has no man page, but typing /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -h in Terminal will return its usage information.
To reset the Launch Services database, you should use its -kill option. You want this to be applied through a recursive directory scan, so also need the -r option. It’s wise to watch its progress in verbose mode (-v option), and you need to specify the domains to which this will apply. Generally, the command advised is:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain u -domain s -domain l -v
to which some add the option to scan default locations to seed the database, -seed.
There are some issues with that command as given. It covers three domains – system, local, and user – which makes it very extensive, perhaps more so than is required. It also uses a different syntax from that given for the command in Sierra 10.12.6. Instead, I suggest that you try in the first instance
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -apps u
That should do the trick. If it doesn’t, then widen the domains with
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -apps u,s,l
and finally try
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -all u,s,l
which should wipe everything from the database.
It is also not impossible that you find you have to use the older syntax with
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -v -domain u
The snag with resetting the Launch Services database is that your Mac will take time to gradually rebuild it, during which its functions will run much slower. After a while, though, it will have been rebuilt, and the right app should be associated with each document type.
As to
how the database was corrupted, there are dozens of ways. Here's an example involving a recent cause (not necessarily related to yours):
Firefox version corrupts MacOS file association database.
