but I add one other action: save to file.Remember that by default, SC *always* saves the screenshot to a file (in it's screenshot directory). You can drag and drop files from the main window thumbnail panel to any other directory or select them and copy/move them wherever you want. There is even a special "Move To" menu on the toolbar to make it easy to move screenshots to your favorite locations (you can customize this set of locations).
The different working methods of different people, when they are working with images could perhaps sometimes be impossible to accommodate in the one tool - e.g., (say) ScreenshotCaptor.
It is important that one's tools assist one to develop working methods that are optimised to be as efficient as possible
, because where such methods will generally involve repetitive manual (and potentially error-prone) process steps which all take time
, there will always be the potential to be a time-bandit.
Thus, the object should ideally be to minimise the time taken in each process step.
This seems to be especially true where working with images and image tools is involved, as the accumulated time taken (in manual process steps) can sometimes be significant. One frequent/repetitive manual decision/step that can be easily automated is the action: save to file.
Through an extended process of trial-and-error, I have pretty much achieved some kind of "Nirvana" in this regard, through the use of CHS
(Clipboard Help & Spell) - i.e., CHS has to be always running
to achieve this.
My screenshot captures are variously made using 4 methods:
- OneNote (ON) Screen-clipping tool: - using the hotkey Shift+Win+S, images are automatically saved into the default ON Notebook and to CHS as .PNG files.
- Screenshot Captor (SC): - images are saved automatically to the default SC image saves directory as .PNG files and to CHS as .PNG files.
- Windows System screen captures: prt sc (captures the full screen) and alt+prt sc (captures the top/active window only) - images are saved automatically only to CHS as .PNG files.
- Xbox Windows game screenshot and audio-video capture tool: - images (screenshots) are typically saved automatically to the default directory C:\Users\[UserID]\Videos\Captures\ as .PNG files. (I don't use this capture tool very often.)
So, I know where any screenshot captures and duplicates
of same will have gone to.
If I want to make some changes to any of these images, they will usually be of the form:
The interesting thing for me was that:
- Make significant edits: this I will usually do using SC (from experience, there's nothing better nor more efficient for my purposes).
- Make minor edits: e.g., resize to a preferred standard size, or remove red-eye, or sharpen an image (say, if it is a bit fuzzy or has text in the image); these I will invariably do using Irfanview (from experience, there's nothing better nor more efficient for my purposes).
the first 3 - and my most frequently-used - methods, are, therefore, each leaving a duplicate image copy
in the CHS
- (a) those images are stored by CHS as external (to the database) .PNG files, and
- (b) the full PATH to each image file is given as metadata in the text Tab of the relevant CHS image clip.
So what I did was make these settings in CHS Options | Image Capture
* External Image Viewer
(optional): set to Irfanview.
* External Image Editor
: set to SC.
In the process of writing this post, I took a screenshot (using the ON clipping tool) of the little Xbox Windows game screenshot and audio-video capture tool
that pops up for a few seconds when the user presses Win+G
(you need to do that to capture "game" shots in method 4
I then took a screenshot of that Xbox tool as it appears in the CHS main window, and proceeded to edit it in situ
, using SC to illustrate what can be done:
(click to expand the image)Post-capture pop-up dialog - Stays on top (cannot be minimized)
Clicking on the two icons means that making and saving changes with either/both Irfanview or SC is the matter of a few seconds. The filename of the image file being edited is not an issue at this point.
I can then select the Tab to copy the text PATH-filename (metadata) of this particular now edited
clip image, so as to insert it into the image filename text field for this post on the DC Forum.
Sure, everything can be improved, but, as it stands, it probably couldn't be a much easier or trouble-free process.
Any unwanted duplicate files can be deleted from the default ON Notebook or other folders where they have been also captured, or - in the case of ON - if the images contain text, then maybe retained in ON so that the text can be automatically OCRed and become part of my searchable notes data in ON.
The edited image in CHS often becomes the "primary" image, and I retain it with relevant added text (metadata), so as to be able to easily find it later.Comment:
As a potential area for improvement, I have played around with how to set the default SC images folder to be the same as the one that can be set as being dynamically assigned as the default working folder (Years, Months) for CHS (which could be a useful idea from the point of view of consolidation and ease of organisation). But this is currently not feasible. The workaround would be to have them both use the same, single folder, but this would probably tend to accumulate a lot
of image files in a single folder, over time, and which would become slow-as-molasses to load and search in Explorer, the more files it held. So this workaround is not really a good idea.
To this end (consolidation and ease of organisation), it would thus seem useful to consider:
- (a) Whether SC could somehow be set to intelligently and automatically be consistent with or follow/sync to the smarter CHS folder structure - which latter can be set in CHS to automatically break down the folders into years, and months within years - thus keeping individual folders at a more efficient/manageable size.
- (b) Whether CHS could be set to scan for any image files in its directories, and - if those images (names/hashes) are not already in its database - then add them as clips (flagged as orphans, for user intervention) to its database, using the file metadata as at present, so that orphan image files do not persist/accumulate undiscovered in the CHS directories as can happen at present. CHS could thus augment the very good image file management capability of Irfanview (which I had not needed to refer to, above) for better managing/rationalising the clip image file populations in its database.