Messages

1

Screenshot Captor / Re: Request JPG Caption Metadata CR/LF not just LF

« on: July 30, 2020, 07:09 AM »

Yes, that works in Nikon's ViewNX 2, as well as continuing to work in Jeffrey's Image Metadata Viewer.

For these settings:


ViewNX 2:


Jeffrey Friedl's Image Metadata Viewer:


BUT, for %datetime% we're still seeing " , " separator:


Thank you very much for the improvement!

2

Screenshot Captor / Re: Request JPG Caption Metadata CR/LF not just LF

« on: July 30, 2020, 06:17 AM »

Can you try the new beta and see if the CRLF issue is fixed:
Download beta version (4.39.0 BETA) from here (or portable).

-mouser (July 29, 2020, 02:14 AM)

Sure will, I'll let you know soon.

3

Screenshot Captor / Re: Request JPG Caption Metadata CR/LF not just LF

« on: July 16, 2020, 06:26 PM »

Shouldn't be a problem.  Note you can also set your own custom date format.

-mouser (July 16, 2020, 12:51 PM)

Yes, I know, but I don't know where you got the " , " thing, that makes no sense at all, and I think it might "rub users the wrong way". And there isn't a way to insert a CR character, which two of my photo-editing programs need to see.

I look forward to testing out a new version with these changes, and will report ASAP upon release.

Thanks!

4

Screenshot Captor / Request JPG Caption Metadata CR/LF not just LF

« on: July 16, 2020, 06:11 AM »

Currently SC separates multiple items in the Caption/Description written to the metadata by LF characters only (x0A). That doesn't play well with all photo editing software, for example from Nikon's ViewNX 2:



In the photo editing process it's one more step needed. I must go into the tags/metadata and replace the LF characters with CR/LF pairs, and then it looks like this:



I request that the separate items that need to go in the metadata be separated by CR/LF pairs (x0D x0A) and not just LF (x0A). Hopefully this can be done one way or another, as it is additional work for every capture to properly separate these items.

BTW, I'm using Preferences:
Advanced Tweaking > Image File Format > Default Image File Format: JPG
The Basics > File Naming > New Screenshot File Template > Automatically generate comment/note for each capture:
  %filename%
  %datetime%
  %windowtitle%
  %scrapetext%

In addition, the "space comma space" sequence between the date and time should be replaced with just a space! Then it would look like this:



Jesse, if these changes could be made then I would give this feature 5/5 stars!

5

Screenshot Captor / Re: JPG Bogus Metadata Replication to Subsequent Captures

« on: July 16, 2020, 03:35 AM »

Can you try this quick beta 4.39 version to see if it solves the problem:
    Setup exe version

-mouser (July 14, 2020, 10:54 PM)

Yes, I tested beta 4.39. You squashed that bug and swept it under the rug )))

I could not find the critter in three quick tests:
1) SC used to view/focus on a screenshot that had bogus metadata replicated from previous shots, shot another screenshot.
2) SC used to view/focus on IMG_0168.jpg (given as example 2 in my original post), shot another screenshot.
3) ViewNX 2 used to edit the Description on a capture, SC used to view/focus on it, shot another screenshot.

In all cases tested so far the caption is as it should be, no replicated metadata from previously viewed capture.

Next time I swing by where I was born I'll hunt you up and I'll buy you a beer )))

6

Screenshot Captor / Re: JPG Bogus Metadata Replication to Subsequent Captures

« on: July 14, 2020, 11:18 PM »

I use JPG as the default format because I'm a photographer and I need the ability to add a lot of different metadata items to the photos in order to be able to organize and search my collection of 500,000 images. PNG may be better for screenshots, but I use a variety of images with SC, and so I prefer to stick with JPG.

Yes, I found with an exhaustive search that the bug had not been reported yet. That is typical for me, I find flaws where very few other people usually go, using features and capabilities beyond the basic.

I need time to test your beta 4.39 version. It may be a day or two before I get back to you. If you find out anything in the meanwhile, please let me know.

7

Screenshot Captor / Re: JPG Bogus Metadata Replication to Subsequent Captures

« on: July 14, 2020, 10:39 PM »

1. I understand you to be saying that after you view an image file with meta data added from a non-SC source (like a camera photo or meta data editor), then NEW screen captures by SC carry over the meta data from the viewed file, instead of getting good new meta data (caption) that they should have from a new capture.

-mouser (July 14, 2020, 10:32 PM)

YES, that is what is happening. Usually when this happens I'm not just viewing them with SC, I'm also editing them to add graphics. But I've reduced it down to the fact that all you have to do is view it, then make another capture.

2. Is it also the case that SC does some bad changing of the metadata of other files that you view, modify, and save?  Or is it only ever that NEW captures get the meta data from the last viewed non-SC file?

-mouser (July 14, 2020, 10:32 PM)

There may be such behavior, but I haven't isolated it. That is, it could be happening (there's a lot of metadata in a typical image) but I haven't noticed it change the metadata. For example, I can focus SC on an image file and add graphics to the image, save that as another version, and the metadata appears to be as from the original file. But as it has been a long time since I needed to do this, I don't know. Further testing would be needed.

However, the question is mute: all images viewed and edited with SC that have more than the basic metadata that SC inserts will cause SC to replicate that metadata to subsequent captures (until a "clean" image is viewed or focused on with SC).

8

Screenshot Captor / JPG Bogus Metadata Replication to Subsequent Captures

« on: July 14, 2020, 09:41 PM »

This bug happens when SC is used to view or was focused on an image that has metadata from a camera or a photo editing program and another JPG capture is made.

Preferences:
Advanced Tweaking > Image File Format > Default Image File Format: JPG
The Basics > File Naming > New Screenshot File Template > Automatically generate comment/note for each capture:
  %filename%
  %datetime%
  %windowtitle%
  %scrapetext%
  Note that the comment/note can be disabled completely and the bug persists, i.e. subsequent captures after viewing or focusing on an image with metadata have bogus replicated metadata.

The bug is persistant, in that once there is a Screenshot made that picks up this bogus metadata it will be replicated to all future captures by virtue of the fact that each of these are the last focused or viewed Screenshot (see below).

The bug is multi-platform (observed on Win7x64, Win7x86 and XP SP3).

The bug is multi-version, observed with SC versions 3.08.01, 4.15.0, 4.16.1, 4.29.0 and 4.36.2.

You can use Jeffrey Friedl’s Image Metadata Viewer to see the metadata for these examples or your own tests: http://exif.regex.info/exif.cgi

In my examples I use Nikon's ViewNX 2 to view and manipulate the image metadata.

Example #1
1) Make a "clean" capture file, here's my example and the metadata:
 
 
  Note that SC has inserted the caption as desired and set in Preferences
2) Use a photo editing program to replace the metadata Description created by SC in the "clean" capture made above with another Description, here's the result and the metadata:
 
 
3) View that image with SC and take another capture, here's my result and the metadata:
 
 
Note that the new capture has picked up the Description from the previous capture, and that the screenshot of the ViewNX 2 metadata also has bogus metadata replicated from the photo-edited file. SC fails to write the caption as desired and set in Preferences and defaults to writing metadata from the last viewed file, over and over again.

Example #2
There is nothing special about this photo, it is straight from an Apple iPhone 11 Pro Max:
 
1) Copy this image to the folder where captures are made OR navigate to the folder where it resides using SC: View it with SC
2) Immediately take another capture: screenshot or scan, it does not matter
3) Examine the metadata of the subsequent capture and note that it includes the metadata from the iPhone image (Date Shot, Camera Info, Exposure)
For those that might be afraid of what Apple is doing with the metadata in the files the iPhone produces: I've observed this bug in SC with JPGs created by a Nikon D300s and an Android phone. I've also observed it with JPGs created by photo editing softwares Nikon ViewNX 2 and Adobe Photoshop.

Workarounds
1) Use SC to view a "clean" JPG with metadata that at most was placed there by SC itself. Subsequent captures have proper metadata. A photo editing program can be used to remove all metadata from an image, I use ViewNX 2 > Ctl-E (Convert Files) > "Remove camera setting information" and "Remove XMP/IPTC information".
2) Empty the default folder where screenshots are made (Advanced Tweaking > My Favorites > Favorite directories > Startup directory), exit SC and restart it. Subsequent captures have proper metadata.
As long as SC is not used to view or edit a camera photo with metadata or a screenshot with the bogus metadata it functions correctly.

I use SC to add graphics to photos I've shot with a camera, so this bug has been a "big pain in the butt." It took me close to two years before I realized specifically when/how/where/why this bogus metadata replication starts. Although I know now the extra steps needed to avoid it, the bug should be fixed.

Thank you for any information you can give me concerning this issue.

9

Screenshot Captor / Re: Default save folder and Auto Move

« on: July 13, 2020, 05:17 PM »

Jesse, I was born in Champaign, IL, so I am sure I can help your thinking )))

First of all, Auto Move should not be disabled and should always apply to the default capture folder. I use SC sometimes to move around, and am bewildered when I find Auto Move is no longer working.

At the very least, I think that whenever SC is started it should start at the default capture folder, and not where it was the last time it was used. This will help reduce the confusion and mess that is caused when new screenshots or scans go into some folder where I've focused SC, as by the time SC is restarted (in my case at reboot) that location is no longer important.

It has been an annoyance to me when I've edited files in other folders with SC and then later took a screenshot to find it was put in that other folder. I've had to mentally remember, countless times, that if I move to another folder I MUST REMEMBER to move back to the default folder for subsequent use. This has actually caused me to be hesitant to use many of the navigation features of your program because just looking around changes where the captures go! If it is any help, in my opinion, new screenshots don't need to go wherever the program is focused, as I don't use the program to create screenshots in other folders than the default folder. I use it save or manipulate images in other folders, but not to create new ones in other folders. So the default folder is where I want new screenshots or scans to go, and from there I may navigate elsewhere only to manipulate or save images.

I vote for "moving around to subfolders would not have any effect on where new captures are saved." But as for the separate issue "what should happen if you are in a different folder and a new capture is made" I would vote for a new capture leaving the current folder and going to the new capture in the default location. You can spruce that up for people who want to put screenshots in all sorts of different places with a configuration option to disable the default screenshot directory which is always used for new captures. In conjunction with that Auto Move should always apply to one directory only (specified on that configuration page).

I hope this helps.

10

Screenshot Captor / Re: Default save folder and Auto Move

« on: July 13, 2020, 04:25 PM »

I'm also interested in a fix for this problem.

Having the application's default working folder (as opposed to the current working folder) and auto move preferences changed every time the user performs a "Save As..." is really annoying behavior.

-SamPe (July 06, 2020, 02:41 PM)

I have also been mystified and annoyed by this behavior. It seems that the SC architecture needs a paradigm shift. It also looks like nothing is going to change )))