I'm fairly sure that this is a core jAlbum issue (rather than a Juicebox issue or even a 'Juicebox skin for jAlbum' issue).
All image handling and resizing is handled by jAlbum itself (rather than the Juicebox skin). The skin just points towards whatever images jAlbum makes available after the source images have been processed.

Heres's some background to what goes on behind the scenes...

If you look at the skin's 'config.htt' file, you'll see that the linkURL (the URL which is opened when the 'Open Image' button is clicked) is defined as follows:

linkURL="<ja:if exists="targetURL">${targetURL}</ja:if><ja:else><ja:if exists="originalPath">${originalPath}</ja:if><ja:else>${contentPath}</ja:else></ja:else>"

Essentially, if the Album Object being processed has a targetURL (an internal jAlbum variable) associated with it, then this indicates that the Album Object is a Web Location (see notes below) and the targetURL will be used.
If the Album Object does not have a targetURL associated with it but does have an originalPath (another jAlbum variable), then the originalPath will be used. The actual file that originalPath points to will vary depending on the 'Pages' tab settings. For a description of originalPath (and all other jAlbum variables), please see the Variables support page.
If the Album Object does not have an originalPath associated with it, then the contentPath (yet another jAlbum variable, this time referring to just the image itself) will be used.

The logic above allows for the use of Web Locations. Web Locations are something that jAlbum introduced in v14 (please see the jAlbum Release Notes) to allow the use of links alongside images. This is perhaps more useful in skins other that Juicebox but Juicebox can still make use of Web Locations.
If you add a Web Location to a project, then Juicebox will display the Web Location's representing image (make sure you add one in the jAlbum interface) and will use the Web Location itself as the gallery's linkURL (for the 'Open Image' button).
If the current Album Object is an image rather than a Web Location, then the Juicebox skin will basically just use the highest resolution version of the image made available by jAlbum.

Unfortunately, I am note sure why there is no 'hi-res' version of your PNG file (or why jAlbum's originalPath for this Album Object leads to a non-existent file). The fact that an originalPath exists (pointing to 'hi-res/Test-PNG.png') suggests that there should be a PNG file in the hi-res folder but that there has been a problem whilst copying or generating it.

I've found this jAlbum forum thread which seems to describe your problem ("png images are not scaling or generating hi-res images even though 'Link to hi-res* via scaled images' is selected"). Hopefully jGromit's suggestions will help for your own scenario as they seem to have done for the original poster.

I hope this points you in the right direction.

Incidentally, jAlbum plans to remove the ability to create 'hi-res' images in v14.2.
Check out the changelog for v14.2 in this forum thread.

If you move to jAlbum 14.2, then your best bet to retain a second, larger set of images (for the 'Open Image' button) would be to include the originals by selecting both "Link to originals via scaled images" and "Copy originals if needed" on jAlbum's 'Pages' tab.

Fingers crossed that the solution to your problem lies in this forum thread.

I'm glad you've found the cause of your problem, although deselecting the "Include xmp metadata in generated images" checkbox should not prevent an image from being processed and placed into the 'hi-res' output folder.
As the relevant post is already in jAlbum's 'Bug reports' sub-forum and the problem you reported is clearly the same as that of the original poster, I would normally suggest that you bump the post (it's not that old) and add your own notes to make your voice heard and to let the jAlbum developers know that there is at least one other user who is affected by the problem.
However, as the jAlbum team are removing the ability to generate 'hi-res' images in the next version of their program, I think it is highly unlikely that they will spend time and resources fixing a bug relating to a feature that will not be around for very much longer so there's probably very little you can do other than deselecting the "Include xmp metadata in generated images" checkbox (or adding you PNG files manually to the 'hi-res' folder after album creation).

Deselecting the "Include xmp metadata in generated images" checkbox just means that there will be no embedded data (at least not in XMP format) in the album images.
If all you want to do is display your images in a gallery, then there will be no functional problems at all.
However, some people might prefer their images to contain metadata (such as a copyright message and/or information about the image) but this has no effect on the visual quality of the images in the gallery or the functionality of the gallery itself.