Topic: PNG Not Being Copied to hi-res Directory

I discovered yesterday that, when an album is being generated, a .PNG image is not copied to the "hi-res" sub-directory of a gallery's destination.

I made a two-image -- one PNG, one JPG -- gallery this morning, to verify this. See:

http://www.billanddot.com/JPG-vs-PNG-Test/

This is on a Mac, running Sierra 10.12.6, with the latest versions of Juicebox Pro and jAlbum.

I did a search of this issue, and came up empty. And if I should've posted this on the jAlbum forum, i.e., if this problem is specific to jAlbum's use of the Juicebox skin, er, um, my apologies.

Cheers,

Bill P.

Re: PNG Not Being Copied to hi-res Directory

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.

Removed ability to include hi-res images (doesn't seem to be used)

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.

Re: PNG Not Being Copied to hi-res Directory

Steven:

Thanks for your prompt and thorough reply.

Per the https://jalbum.net/forum/thread.jspa?messageID=318904 thread, here's some info for you:

- My filetypes.xml was properly configured, per the second post.

Per the fourth post:

- Settings > Pages, Copy originals if needed: already checked.

- Settings > Advanced > General, Exclude new images by default: already unchecked.

- Include xmp metadata in generated images: was checked, but I just unchecked it, and generated a new gallery. I didn't upload it to my server, but I did look at the generated folder on the Mac, and the PNG image was properly added to the hi-res folder. So that did the trick.

- Settings > Images > Advanced, Force JPEG writing: unchecked the entire time.

Which brings me to a follow-up question: should I care about "Include xmp metadata in generated images" setting?

That is, all these settings that you were talking about are ones that I just left at their default, haven't concerned myself with them, and so forth.

Additionally, that PNG file that I discovered was missing in my non-test gallery yesterday: I just copied the original PNG to the hi-res directory on the server. That took care of the problem, of course, and I can't recall messing with anything but JPG files in 100 or so galleries that I've put up.

Thus, is unchecking "Include xmp metadata in generated images" something that will have any side-effects that I should worry about?

Thanks again,

Bill P.

Re: PNG Not Being Copied to hi-res Directory

- Include xmp metadata in generated images: was checked, but I just unchecked it, and generated a new gallery. I didn't upload it to my server, but I did look at the generated folder on the Mac, and the PNG image was properly added to the hi-res folder. So that did the trick.

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).

Thus, is unchecking "Include xmp metadata in generated images" something that will have any side-effects that I should worry about?

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.

Re: PNG Not Being Copied to hi-res Directory

Steven:

Thanks again for the explanation, and for your time.

I'll just leave things as is: leave the "Include metadata" checked, but continue my usual practice of working only with JPG files.

Thanks,

Bill P.

Re: PNG Not Being Copied to hi-res Directory

You're welcome!