|
Post by PostmasterGS on May 31, 2020 4:02:52 GMT
OK. I just uploaded an update (v1.21) to fix a few issues folks have identified with v1.20. Available for download here. Here's what changed: 1. File Naming — Changed file naming convention for images output using the "Batch from Image" / "Extract to File" process. This is the one process where the file naming is completely automated (meaning it doesn't come from the input file, and doesn't present the user with an opportunity to change it). In previous versions, the file naming always started at "1" and worked up from there. If files from previous runs were in the output folder, they could be overwritten if they hadn't been renamed after output. With v1.21, the app looks for the highest, all-numeric filename in the output folder, then starts the new file naming one digit higher. So, for example, if you're batch processing a scan containing 4 stamps, and the output folder contains the following: 1.jpg 2c.jpg 5.jpg 122C.jpg 234.jpg 246b.jpg The program would find the purely numeric filenames in the output folder: 1.jpg 5.jpg 234.jpg Identify the highest value: 234.jpg And iterate from there. So the four images output would be named: 235.jpg 236.jpg 237.jpg 238.jpg This should prevent inadvertent overwriting of images outputted during previous runs. 2. Initial Window Size — Reduced the default window size, both in height and width. This was to accommodate those who have lower screen resolutions, and who found that the initial window was wrapping off the screen. To accommodate the reduction in height, the Single-Image Load and Save buttons were shrunk and are now side-by-side instead of stacked. 3. Added Additional Reprocess/Recalculate Triggers — With v1.20, a Reprocess/Recalculate could be triggered by typing a new value in the text boxes and hitting Enter. With v1.21, a Reprocess/Recalculate will now also be triggered when Tabbing out of the text boxes or clicking out of the text boxes onto another text box or slider. 4. Bug Fix — There were a couple stray instances where the window would resize itself automatically. I think I got the last of them removed, so if you resize the window, it should stay resized. As usual, if you find any bugs or have any requests for additions/changes, please let me know.
|
|
|
Post by sherro on May 31, 2020 4:07:18 GMT
I fixed it. I uninstalled and reinstalled. It looks like I made an error and downloaded the 32-bit version instead of the 64-bit. The 64-bit works. Now all Ihave to do is figure it out!
|
|
|
Post by PostmasterGS on May 31, 2020 10:37:48 GMT
Sorry to drop new versions this close together, but I had to fix a bug. So, here's v1.22In v1.21, I introduced a new automated filenaming for when you are doing batch processing using the "Batch from Image" / "Extract to File" process. In doing so, I failed to account for prefixes and suffixes. In v1.22, if not using a prefix or suffix, it works as before. It simply finds the highest all-numeral filename, and iterates up from there. If using a prefix and/or a suffix, it checks to see if the filename already exists, and if so, it adds a "-X" to the filename, with X starting at 2 and running upward as necessary to achieve a unique filename. I think for the next major version, I'm going to try to include addition options to customize the auto-naming so you have a lot more control over it.
|
|
|
Post by PostmasterGS on Jun 5, 2020 4:00:54 GMT
StampFix v1.25 is now available here. OK. This will probably be the last update for a while, unless someone finds a bug or gives me a new feature request. This was a major, major update to the underlying code. This was done primarily to (1) increase the accuracy when using Batch from Image, and (2) add Drag & Drop. Here's a short description of what's changed: 1. Added a reset button at bottom left. This will reinstate the app to the state it was in when you loaded it, including reloading your default settings and clearing the workspace. 2. Re-worked the bounding box detection in the Batch from Image function. This should dramatically decrease the false boxes, and reduce the need to weed them out before processing. The screenshots below show the same image loaded in v1.22 (top) and v1.25 (bottom) with the same settings. 3. Added Drag & Drop. This change opens up a host of options for you. For Batch from Folder and Batch from Files processing, you can drag files or folders into the window, and they're automatically processed and saved. For Singles and Batch from Image, dragging a file into the window will load it as before, just without clicking the button to select a file. However, there's a new button at top left that will allow you to bypass opening the files in the window, and instead process and save them directly to file. 4. Added auto-detection of files. With this change, the app attempts to detect black background vs. white, and whether the image is a single or multiple. It then processes as appropriate. This allows you to drag and drop an entire folder with mixed content, and have it all processed at once automatically. This should allow folks who scan lots of multiples to simply drag them all into the window at once, and process them all in one run. If you have any questions about the new features, or anyone finds any bugs, or has any additional suggestions for features, please let me know. YouTube video demo is here.
|
|
|
Post by PostmasterGS on Jun 5, 2020 14:10:58 GMT
On re-reading my v1.25 post, I realized I didn't spell out the Drag & Drop as clearly as I should have, and I know people don't always watch the demo video (seriously, watch the video!). So, here are a few animations showing how it works. Single ImagesSingle image, opening to screen ("Drag/Drop Direct to Save" toggle at top left OFF) Single image, saving directly to file ("Drag/Drop to Save" toggle at top left ON) Batch from ImageBatch from Image, opening to screen ("Drag/Drop Direct to Save" toggle at top left OFF) Batch from Image, saving directly to file ("Drag/Drop to Save" toggle at top left ON) Batch from Folder ("Drag/Drop to Save" toggle at top left is irrelevant) Batch from Files ("Drag/Drop to Save" toggle at top left is irrelevant)
|
|
JeffS
Member
Posts: 2,607
What I collect: Oranges Philately, US Slogan Cancels, Cape of Good Hope Triangulars, and Texas poster stamps and cinderellas
|
Post by JeffS on Jun 5, 2020 18:12:35 GMT
That's all quite impressive, but I've failed to understand it's purpose. Seriously.
|
|
khj
Member
Posts: 1,467
|
Post by khj on Jun 5, 2020 18:38:23 GMT
The program allows you to process large batches of stamp images. In the past, when you wanted stamps with uniform borders and lined up nicely (not slightly tilted), you would have to spend a lot of time lining them up to a reference edge or rotating them individually, then cropping the borders manually. OK if only a dozen or so pics, but takes forever if hundreds of pics. For my own files, I could care less, but if I'm going to present the image (or for exhibit or to sell professionally), it looks a lot cleaner. There are some programs that do this, but they either only work for specific type of scanners, or are not as flexible (or designed for stamps) as StampFix.
With StampFix, I can just slap the stamps on the scanner bed (although I still very roughly line them up), and let StampFix do the work.
The v1.25 update works really well for me, so I've removed my fall-back v1.11 that I had kept using.
In the future, it would be nice if SF would support metatags to maintain the dpi info. Right now, any new file saved will default to my screen dpi (96) even though the scan is actually 600dpi -- no resolution is lost, but any program that opens it thinks it is 96dpi and will open it up several times larger than it really is. I never thought this would be a problem until I sent some stamp images for a book project and they asked why I was sending 96dpi images. But I'm grateful for what has been provided.
|
|
JeffS
Member
Posts: 2,607
What I collect: Oranges Philately, US Slogan Cancels, Cape of Good Hope Triangulars, and Texas poster stamps and cinderellas
|
Post by JeffS on Jun 5, 2020 19:00:05 GMT
|
|
|
Post by PostmasterGS on Jun 6, 2020 0:34:01 GMT
khj, This is my white whale... I got it working for PNG input files, but JPG input files are proving to be a challenge. There's not the same level of consistency in the format of JPG metadata, so being able to write code that will extract it is a nightmare. Glad 1.25 is working for you. Let mw know if you have any problems, questions, or suggestions.
|
|
khj
Member
Posts: 1,467
|
Post by khj on Jun 6, 2020 3:51:45 GMT
I'm very happy with v1.25! I've really enjoyed watching and supporting the development since the early days. I still have the v1.01 installer as a keepsake!
Don't worry about the jpg metadata problem. Some of the other software produced by professional programmers have the same issue. While there are online sites that will convert metadata, and also software that will do it, I would rather not go that route for various reasons.
You won't believe my current workaround when I must have proper dpi metadata. I keep a small 600dpi jpg file with the proper dpi metadata as a template, and simply copy the PMGS processed image into that template file! When I save it, it keeps the 600dpi metadata!
Anyway, thanks again! Well done!
|
|
|
Post by PostmasterGS on Jun 6, 2020 4:05:59 GMT
khj, In the past two weeks, I spent about 40 hours working nothing but the JPG issue and made absolutely zero progress. I put it down and went to work on the drag and drop and algorithm changes for v1.25. Re-attacked the JPG issue this morning, and I think I’m making progress. It’s funny how often it’s just a matter of finding the right sample on the Internet.
|
|
khj
Member
Posts: 1,467
|
Post by khj on Jun 6, 2020 5:21:08 GMT
I'm sorry, it wasn't my intention for you to spend a lot of time on it, but certainly appreciated. The workaround I'm currently using also works for bmp or any format. As long as I'm not copying the image into a new file, programs such as MS Paint will keep the old dpi metadata of the template file. If I copy into a new file and save, MS Paint will save the dpi of my monitor as the metadata, ignoring the original dpi of what I was pasting in.
|
|
|
Post by PostmasterGS on Jun 6, 2020 5:29:30 GMT
khj, It wasn’t just you. That was the most commonly requested fix.
|
|
|
Post by PostmasterGS on Jun 6, 2020 7:23:23 GMT
As expected in light of how extensive the v1.25 changes were, a quick bug fix -- v1.26. Three fixes with this version: 1. Tweaked the auto-detect function. The auto-detect feature allows the app to process images with single stamps or multiple stamps in the same run, auto-detecting how many stamps are in the image. The accuracy of the auto-detection is very dependent on the accuracy of the threshold setting used in the Batch for Image processing. This setting... My recommendation would be to get this setting where it works well for your particular background color, then save it as the default, since that sidebar isn't visible by default when you first open the app. It only appears when you load a Batch Image. 2. Fixed a bug that was causing the occasional extra period in the filenames (Ex. MiNr-1..png). 3. Got the JPG/JPEG metadata working. The DPI of your JPG/JPEG input files should now get transferred over to the output files, with one caveat. There are two different metadata formats for JPG/JPEG, and they are not compatible. Some programs use one, some use the other. Some photo processing programs change the structure of the metadata in an attempt to be readable in both formats. If your image is straight off the scanner, it should work. If the metadata of the input file has been damaged by some other program before running through StampFix, the DPI might not get transferred, because StampFix relies on the metadata being in a specific format in order to find the DPI of the input file. If you find that it's not working on your JPG/JPEG file, please save the input and output files so you can send them to me for testing, and note where the files came from (scanner, camera, photo editing software, etc.)
|
|
khj
Member
Posts: 1,467
|
Post by khj on Jun 6, 2020 8:30:24 GMT
So far, I've only been able to retain the original 600dpi metadata from processing a single image jpg to a cropped single image jpg.
Results:
bmp batch file to bmp individual image files = new image files do not retain original 600dpi, metadata says 96dpi bmp batch file to jpg individual image files = new image files do not retain original 600dpi, metadata says 96dpi jpg batch file to jpg individual image files = new image files do not retain original 600dpi, metadata says 96dpi
bmp single image file to jpg = new image files do not retain original 600dpi, metadata says 96dpi jpg single image batch file to jpg = new image files does retain original 600dpi
|
|
|
Post by PostmasterGS on Jun 6, 2020 8:52:13 GMT
khj, At the moment, it can do PNG and JPG/JPEG inputs, not BMP. Can you send me the JPG file you were using for input on this run, because I haven't been able to replicate the problem.
|
|
|
Post by PostmasterGS on Jun 6, 2020 9:13:26 GMT
khj, Send me a BMP while you're at it.
|
|
khj
Member
Posts: 1,467
|
Post by khj on Jun 6, 2020 9:46:15 GMT
|
|
cjoprey
Member
Scanning stamps for my website...
Posts: 1,443
What I collect: Belgium (predominantly), British Commonwealth (older ones), WW (whatever comes my way...)
|
Post by cjoprey on Jun 6, 2020 11:23:17 GMT
This is great progress PostmasterGS - thanks! I'll do some testing as well as I traditionally scan jpg at 600dpi and convert to png on output... I normally use paint.net to fix it as it's resize dialog supports manually rewriting the DPI to any value...
|
|
brightonpete
Departed
Rest in Peace
On a hike at Goodrich-Loomis
Posts: 5,110
|
Post by brightonpete on Jun 6, 2020 19:21:21 GMT
It took me a while, but I managed to scan a bunch of stamps & have Stamp Fix save them individually. I either had 700 images or none. I used no covering paper, my fave green paper, but then clued in that black is needed. Voilá! But one stamp, no matter what I did, came out as a bisect! I had to join the two parts together to make one full stamp.
No matter, it makes scanning a bunch a lot easier. The hardest part now is re-naming them to their individual dates. The stamp in question was for yesterday! Oh well... there's always next year!
|
|
|
Post by PostmasterGS on Jun 6, 2020 21:47:33 GMT
brightonpete, Can you send me the scan that kept coming out as a bisect? postmaster -at- the name of my website.
|
|
brightonpete
Departed
Rest in Peace
On a hike at Goodrich-Loomis
Posts: 5,110
|
Post by brightonpete on Jun 7, 2020 1:32:16 GMT
I altered one with the other. I'll scan again, but watch - it'll come out perfect, making a liar of me!
|
|
brightonpete
Departed
Rest in Peace
On a hike at Goodrich-Loomis
Posts: 5,110
|
Post by brightonpete on Jun 7, 2020 1:54:58 GMT
PostmasterGS: of course when I replicated what I did, it still made up two parts for the stamp. But on changing the threshold number in smaller increments, it worked just as advertised! Sorry to get you all excited about a bum stamp!
|
|
|
Post by PostmasterGS on Jun 18, 2020 0:27:11 GMT
I've just posted a new version with a minor update — v1.29, available here. The change is one that's not obvious, so I would encourage you to watch the demo video linked/embedded at the bottom of this post. A user on one of the forums was having difficulty with a particular image, and upon examining it, I realized that an old issue was still causing problems, so i decided to fix it. When I first implemented the "Batch from Image" feature in v1.11, I noticed that, on occasion, the threshold setting required to get the green boxes correct didn't always produce the best results when the app then went to rotate and crop the individual stamps. I never fixed it because it appeared to be only a minor inconvenience. As it turns out, it wasn't all that minor to folks with lighter colored black backgrounds. For example (all images except the animated one, click to enlarge): Here is the image the user sent me. Notice that with a threshold of 100, the green box isn't drawn correctly for the green stamp in the bottom row. To get the green box drawn correctly, I had to change the threshold to 75. Though a threshold setting of 75 got the green boxes drawn correctly, when I went to the Edit Individually screen to preview the output, the rotate/crop produced really bad results. To fix this, I had to apply a threshold adjustment of 100 to all the stamps on the Edit Individually screen, Apply, then Reprocess. The only other way around this was to export the images, then re-run them through the app using a Batch from Folder/File process, applying the 100 threshold at that point. Bottom line, the best threshold setting to draw the green boxes wasn't the best threshold setting for the processing of the individual stamps, and it was forcing the user to take a couple extra steps to get a good result. So, with v1.29, I added a second threshold setting to the Batch from Image process, so now there's a setting for drawing the boxes, and a separate setting for processing the individual stamps. The threshold setting at the top right still controls the drawing of the green boxes. The new setting, entitled Fine Tuning Threshold, is the threshold applied when the app processes the individual stamps. For those who weren't getting accurate results using the Batch from Image process, I hope this will improve your results and/or save you a few steps. A few additional notes: 1. I removed the Recalculate button on the Batch from Image sidebar. I needed the real estate for the new setting, and a recalculate is already automatically performed every time you change a setting, so it was somewhat extraneous. 2. I had not planned on releasing a new version until I got the metadata working for BMPs and TIFs, but that looks like it may be a while. The BMPs are kicking my butt. One additional request -- if you are having difficulty getting a good result from an image, please, PLEASE, PLEASE!!!!, save the original image and send it to me. The only way I can continue improving the app is getting feedback on what's not working. The solution may just be sending you the correct settings, but it may also be fixing a problem (like this one) with the app. Demo video for v1.29 is here or hopefully embedded below.
|
|
stainlessb
Member
qaStaHvIS yIn 'ej chep
Posts: 4,643
What I collect: currently focused on most of western Europe, much of which is spent on France, Belgium, Germany and Great Britain Queen Victoria
Member is Online
|
Post by stainlessb on Jun 18, 2020 0:42:59 GMT
First PostmasterGS , let me say thank you for this as it is a true timesaver. I have noticed one difference between the GUI of the newer versions. When I save- it used to show my folders, and when I selected one it showed the files within, so it was easy to grab the previously named file , whereas now (Unless I am missing something)- I have to re-enter the filke name this is not an issue with bulk images as 1,2,3,4,.... works fine, but often individual i am naming specific to the stamp. Is there away to turn that view back on? BTW I am on a MAC thanks!!! (this is not a complaint, just a question) Stan
|
|
|
Post by PostmasterGS on Jun 18, 2020 3:05:51 GMT
stainlessb , Here's what I see on my Mac. When I go to save an individual image, sometimes I get the small naming dialog. Not sure why I sometimes get this and sometimes don't. It's a MacOS thing. If I click the little down arrow next to the folder ("Desktop" in the above image), it takes me to the Mac's full save dialog screen. This is the screen I usually get immediately on hitting Save. Again, not sure why I sometimes get this and sometimes don't. It's a MacOS thing. From there, I can click on any filename to quickly select it as the new filename, with the file extension from the selectbox at the bottom of that dialog box.
|
|
stainlessb
Member
qaStaHvIS yIn 'ej chep
Posts: 4,643
What I collect: currently focused on most of western Europe, much of which is spent on France, Belgium, Germany and Great Britain Queen Victoria
Member is Online
|
Post by stainlessb on Jun 18, 2020 14:04:25 GMT
Thanks! (I'm a creature of habit!)
|
|
|
Post by PostmasterGS on Jun 21, 2020 6:25:54 GMT
I just uploaded an update — v1.30. This version fixes two minor bugs: 1. Fixed occasional graphical corruption on the main screen when the app first loads. 2. With certain computer configurations, there was an issue with the app not "releasing" the last image file created during batch processing, leading to you being unable to rename the file, etc., because the image was showing as still in use by StampFix. As usual, download is here.
|
|
|
Post by PostmasterGS on Jun 21, 2020 13:03:01 GMT
Sorry to push out another update so soon after the last one, but I added another new feature. v1.31 available here. This version adds a button at the top left with a target icon. Clicking this button will minimize the StampFix window and open a small window that can be used as a target for drag and drop. Click to enlargeThe target window is resizable, though if you make it too small it becomes a tough target. Whatever you drop in that window will be processed with the current settings from the main StampFix window, even though it's minimized. On a Mac, closing the target window reinstates the StampFix window. On a PC, you have to manually maximize the main StampFix window from the taskbar.
|
|
|
Post by PostmasterGS on Aug 9, 2020 9:28:05 GMT
I’ve just uploaded a new version - v1.34. The changes in this version are minor, and mostly a result of user requests, so please keep the feedback coming. 1. Rearranged left sidebar — as I add features, I occasionally have to rearrange things to make room, since I’m limited in how tall I can make the app before it causes problems for those with lower screen resolutions. I moved all of the settings in the left sidebar to a single spot. Originally, they were split among Single, Batch, and Both areas, but with the addition of the Drag & Drop feature, there really isn’t much of a distinction anymore, and almost all settings are used in one way of another in both Single and Batch processing. 2. Changed the Save dialog box behavior — previously, when you clicked “Save” (now “Save As”) to save a file, the OS inserted a default filename (not sure what it was on PC, on Mac it was “Untitled”) and the file extension defaulted to .JPG. The filename in the “Save As” box will now default to the input file’s filename, and the filename will default to that of the input file. This does increase the risk of overwriting the original, but it will help those who like to slightly modify the original filename, as they won’t have to remember what it was. For example, the filename in this demo was Scan.png. 3. Added an option to enable or disable filename overwrite protection — Several versions ago, I changed the save behavior to prevent overwriting of the filename when doing batch folder/file processing or dragging/dropping straight to file. The app would automatically add a “-X” (with X being an iterating number) suffix to the original filename to prevent overwriting. With this version, I’ve made that optional by adding a checkbox entitled Prevent overwrite of original input files. With this enabled/checked, the filenames are iterated to prevent overwriting: With this disabled/unchecked, the original files are overwritten (a couple of the thumbnails were slow to update in this gif — that's an operating system issue): Note that this DOES NOT apply to Batch Image processing, since that function has to generate new filenames anyway, and it doesn’t affect overwriting if you’re clicking the Save As button and entering a filename there, as that overrides everything. 4. Bug fixes — fixed a startup bug on certain Windows configurations, and a bug that was causing files to not get released properly after processing. As usual, downloads are available here.
|
|