SnipSVG saving over the PNG I'm annotating

[bwofficer]

I opened a PNG in SnipSVG to annotate it (specifically, to add number tags). Once I added the number tags, I saved it as an SVG. However SnipSVG seems to have also resaved the original PNG file, as I can see from the file time stamp. What am I doing wrong?

Even worse, in resaving the original PNG SnipSVG seems to have removed important print resolution info from the PNG header. Luckily I had a backup of the original PNG and I compared the two using a PNG field inspector app. The original PNG had an IHDR field (or chunk to use PNG spec terminology) specifying the width and height in pixels, but it also had a pHYs field that specified the print resolution (in pixels per metre, of all things!). The PNG file that SnipSVG overwrote the original with lacks that pHYs field, so if anyone resuses the illustration in a different authoring environment (Word, for example) the authoring app doesn't know how big to draw the illustration on the page. Is this intentional behaviour, or am I doing something wrong?

Regards,
Bruce

[Tim Green]

Hi Bruce,

This isn't a known issue and I don't think it's possible for SnipSVG to save without you actively saving. It definitely doesn't have an autosave feature -- when you exit the program without saving (either directly or from the tray if it's been minimized there instead of exiting) you will be prompted to save and can cancel. My guess is that you accidentally hit CTRL+S before saving as SVG.

I'm passing this on to our developers for checking what you report about the PNG header. There probably won't be a response on this before the beginning of next week though. For the time being I recommend saving immediately in your target format or with another name before you start editing on files like these.

[Tim Green]

Update: The dev team confirms that SnipSVG physically cannot save automatically so you must have saved accidentally. On the headers: This is intentional. Only necessary data is included and any extraneous and possibly privacy-compromising data is removed from the header when the file is saved. This ensures that PNG and JPG files saved by SnipSVG never contain any personal data.

Our developers comment as following on the "print resolution": The "print resolution" is not necessary for pixel-based formats. A PNG contains pixels, and the pixels determine the native size directly. Anything other than that is scaled up or down and that needs to be a decision on a case-by-case basis. Programs shouldn't need to rely on information like that for a pixel-based format. The intended size is only relevant for vector-based formats like SVG, where it is included because there are no pixels to determine the "native size" of the image -- and even there the relevance is low, because the decision on how large to display the image is almost always external to the image anyway.

[bwofficer]

Thank you for your reply, Tim.

With regards to saving, what I was trying to do was to open a PNG (created with a different app) in SnipSVG, annotate it with callouts in SnipSVG, then save the resulting annotated image as an SVG in the same folder as the original PNG but without overwriting the original PNG. As I'm completely new to SnipSVG it's quite possible that I saved things in the wrong way, so I'll try again and see if I get the same result.

[Alexander Halser]

Hi Bruce,
The "IHDR" header entries in the PNG are of course written by SnipSVG, otherwise the PNG file would become a junk of dead data. Additional header information is generally stripped. These are so called EXIF headers, often present in JPEG files, but sometimes in PNG as well. They contain meta data that is not required to decode and display the image, something like camera model, software version, user name, light conditions, geolocation, date and time when the picture was taken and the rotation of the image. Sometimes they include a size information in inch or centimeters as well.

When opening a JPEG or PNG, SnipSVG reads the EXIF headers (in particular: to auto-rotate an image correctly, in case it has a rotation specified). But it never saves the headers. When embedding the data inside an SVG, nobody needs that and it might contain private data that you are not even aware about, and which you don't want to publish. So we strip that data in general, which we consider a feature, not a bug.

You might notice this only, when you open a JPEG/PNG and save it again in this format. In this case, the EXIF headers are gone and for most of the header entries, this is a good thing, because you don't want to publish private information. This one entry with optional metric information is collateral damage in that case. But this information is not required anyway. A PNG or JPEG is defined by its pixel size, which is in the IHDR header of the file format. The additional scaling information in centimeter or inch is not relevant - or should not be. If a software relies on that instead of trying to fit the pixel size into a publishing space, then this software has a problem in the first place.

[bwofficer]

Hi Alexander and Tim,
Thank you for your replies.

EXIF headers (in particular: to auto-rotate an image correctly, in case it has a rotation specified). But it never saves the headers. When embedding the data inside an SVG, nobody needs that and it might contain private data that you are not even aware about, and which you don't want to publish. So we strip that data in general, which we consider a feature, not a bug.

I understand now. I hadn't thought of that. My primary output is a printed paper document, so I don't generally think about confidential metadata. The end reader only sees what's been printed onto the paper page, after all. I guess it's different for people who publish to the web or to electronically distributed PDFs.

But this information is not required anyway. A PNG or JPEG is defined by its pixel size, which is in the IHDR header of the file format. The additional scaling information in centimeter or inch is not relevant - or should not be. If a software relies on that instead of trying to fit the pixel size into a publishing space, then this software has a problem in the first place.

My main concerns are ensuring the line widths of the numbered callout pointers and of the highlight boxes are consistent in all the illustrations throughout a document when it's printed out onto paper, and also that any raster elements of the document are at a sufficient dpi to print crisply. I might decide that:

• All numbered callout pointers will be 0.5mm thick when printed out on paper;
• All red outline boxes used to highlight parts of an image will be 1mm thick when printed out on paper;
• All raster elements will be sized so that they are at 200dpi when placed on the page at their intended physical width.

Up until now I've resampled all PNGs to 200dpi at their intended physical width before adding annotations, then assumed that on ppi info saved in the metadata means the image will import into the document at that intended physical width without the document author needing to be told explicitly how large to make the imported illustration on the page. As you are saying that SnipSVG intentionally strips this info out, I'll need to use a different method to ensure the illustrator and author both know the intended physical size and stick to it - and a method that still works even when the illustration is reused elsewhere. My first thought is to include it in the file name e.g. ControlPanel_PW150mm.svg or something like that, where PW stands for Image Physical Width. I guess that would work.

Regards,
Bruce

[Tim Green]

My main concerns are ensuring the line widths of the numbered callout pointers

If you're saving as SVG the pointers are SVG elements and size controlled within the SVG and relative to the main SVG, so the issue does not arise there. The only PNG data would be your original PNG image, which is embedded inside the SVG.

Up until now I've resampled all PNGs to 200dpi

DPI is meaningless and irrelevant for bitmap images like PNG or JPEG. The only relevant data is the number of pixels, and that is a physical attribute.

[brionnacrooks50]

To avoid it, you could try saving the SVG with a different name or location to keep the original PNG intact.

[Alexander Halser]

assumed that on ppi info saved in the metadata means the image will import into the document at that intended physical width without the document author needing to be told explicitly how large to make the imported illustration on the page

I suggest to include the PPI into the file name. This tells every print professional what they need to know about the intended physical size. When you resample the original PNG for 200 ppi, an image with 1000 pixels width is simply five inch in print, height proportional. A " (200ppi)" in the file name is a crystal clear message and nobody has to guess if the PPI value in the EXIF header is indeed correct or actually wrong, because it has been carried over by an amateur user, blissfully oblivious to those settings.