This might not be an easy task to achieve (and I do not know of anyone who has done this).

You could certainly use the Juicebox-Pro API to detect when the last image in the gallery has been reached and then run whatever custom JavaScript code you like.

var jb = new juicebox({
    containerId: "juicebox-container"
});
jb.onInitComplete = function() {
    var count = jb.getImageCount();
    jb.onImageChange = function(e) {
        if (e.id === count) {
            alert('Last image in gallery has been reached.');
        }
    };
};

You'd just need to change the JavaScript alert for a command to load your next gallery page, for example:

window.location.href = 'https://www.example.com/index.html';

Unfortunately, there is no API method to check (or track) the current AutoPlay status so that only way to detect if AutoPlay is on or off is to check if the 'jb-status-playing' CSS class is present on the 'jb-bb-button-auto-play' CSS class.

var jb = new juicebox({
    autoPlayOnLoad: "TRUE",
    containerId: "juicebox-container",
    showAutoPlayButton: "TRUE"
});
jb.onInitComplete = function() {
    var count = jb.getImageCount();
    jb.onImageChange = function(e) {
        if (e.id === count && $('.jb-bb-btn-auto-play').first().hasClass('jb-status-playing')) {
            alert('Last image in gallery has been reached via AutoPlay.');
        }
    };
};

You could then add a delay (ideally the same as the Juicebox-Pro displayTime value) to allow the last image to be seen before loading the next gallery.

var jb = new juicebox({
    autoPlayOnLoad: "TRUE",
    containerId: "juicebox-container",
    showAutoPlayButton: "TRUE"
});
jb.onInitComplete = function() {
    var count = jb.getImageCount();
    jb.onImageChange = function(e) {
        if (e.id === count && $('.jb-bb-btn-auto-play').first().hasClass('jb-status-playing')) {
            window.setTimeout(function() {
                alert('Last image in gallery has been reached and 5000ms have elapsed.');
            }, 5000);
        }
    };
};

There might be some further pitfalls to avoid and tweaking to do but I hope that this points you in the right direction.

I think both your questions are related to each other (at least by the root cause).

The main difference between your 'JBGallery.html' page and your 'JBGallery1/index.html' page is that your 'JBGallery1/index.html' page locks the viewport (with the following line of code):

<meta name="viewport" id="jb-viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1, maximum-scale=1, user-scalable=0" />

... whereas your 'JBGallery.html' page does not.

This results in the gallery being expanded from the Splash Page differently on the two embedding pages.
From 'JBGallery.html', the gallery is expanded on a new page of its own.
From 'JBGallery1/index.html', because the viewport is locked, the gallery is expanded on top of the embedding page.
(Please see the Expand Gallery Behavior support section for details.)

This explains the difference between the two pages but not why the galleries expand with different layouts.
Unfortunately, the problem seems to be due to a known bug (whereby the page that the gallery is expanded into has a bearing on how the gallery is displayed) that the developers are aware of but have not yet been able to fix.

Until the bug is fixed, possible workarounds are as follows:
(1) Set showSmallThumbsOnLoad="FALSE" (in JuiceboxBuilder-Pro's 'Customize -> Thumbnails' section).
... or:
(2) Remove the viewport lock from your gallery pages.

I have sent a further note to the developers regarding this problem.
Thank you for reporting the problem and apologies for any inconvenience caused.
Hopefully one of my suggested workarounds will work for you until the bug is fixed.

You can make the caption area's background fully transparent by setting the Opacity to '0' for both the Caption Back Color and the Caption Back Top Color (in JuiceboxBuilder-Pro's 'Customize -> Color' section).

If manually editing your gallery's 'config.xml' file, set captionBackColor="rgba(0,0,0,0)" and captionBackTopColor="rgba(0,0,0,0)".

Please note that Juicebox-Pro uses only one captionBackColor and captionBackTopColor gallery-wide so the values you set will be used in both Small Screen Mode and Large Screen Mode.

captionBackTopColor is actually the only configuration option which has different default values for Large Screen Mode (rgba(0,0,0,0)) and Small Screen Mode (rgba(0,0,0,0.3)) so if you do not change captionBackTopColor in JuiceboxBuilder-Pro's interface, a captionBackTopColor value will not be written to the gallery's configuration file and the two default values will be used (which, when combined with the default value for captionBackColor, gives a gradient background in Large Screen Mode and a solid background in Small Screen Mode).

If you want to ensure that a single captionBackTopColor is used in both screen modes, then change its color or opacity slightly from its default value. This will ensure that a captionBackTopColor entry is written to the gallery's 'config.xml' file and the chosen value will be used in both Large Screen Mode and Small Screen Mode. Then, to remove the gradient, set captionTopColor to exactly the same color and opacity as you've used for captionBackTopColor.

I've tried playing with backgroundColor and expandedBackgroundColor settings in a config.xml file, but only the latter is having any effect. No matter what setting I choose for backgroundColor (such as "rgba(153,153,0,1)"), the background remains black. What might I be doing wrong?

EDIT:  I have now added your Javascript code for autoplaying multiple galleries. It appears to work fine, after making one adjustment; I had to choose a delay time that was 200ms less than the gallery display time in order to stop the 'AutoPlay OFF' message from appearing on my Windows PC screen (though it still pops up on Android/iOS). Once again, many thanks for your help in making this possible.

One further enhancement to this process would be for the autoplay of multiple galleries to be initiated by the user clicking the Autoplay button while on the last image of the current gallery. At present, clicking the button in that situation briefly turns on Autoplay, but it is then automatically turned off.

All is now clear. I'd never previously noticed that my embedding code also included a backgroundColor setting.

Up to now, all of my configuration tweaks have been done via the config.xml file. Are there any advantages to doing this via the embedding code instead?

I agree that using config.xml is the most convenient approach.

I have since discovered that it is better to set enableLooping="TRUE" when autoplaying multiple galleries. This suppresses the 'AutoPlay OFF' message and thus makes it unnecessary to tweak the delay time. Your Javascript code for jumping to the next gallery takes precedence over looping back through the current gallery.

After manually stepping through a gallery, with enableLooping="FALSE", clicking the Autoplay button on the final image will have no useful effect. With enableLooping="TRUE", it will start to replay the current gallery. In both cases, I would really prefer it to trigger a jump to my next gallery, but after checking out the API options I doubt if this is possible, so I have taken the option of always jumping to the next gallery by removing the jb-status-playing condition from your Javascript code. Have I missed another way of handling this?

Note that my current set of six associated image galleries can now be found here:
http://www.southamptoninternationalexhi … index.html.

Once again, you have provided an excellent solution to my requirement  :)

Given that the user has been operating in manual mode before clicking the Autoplay button there didn't seem much need for a serious delay before switching to the next gallery, so I reduced that from 5000ms to 500ms. Other than that, and replacing your alert with my window.location.href command, no other changes were needed.

Are such things as .jb-bb-btn-auto-play').click(function() and your CSS class details (e.g. .jb-bb-btn-auto-play').first().hasClass('jb-status-playing')) documented anywhere on the Juicebox website?

No. Such modifications (using internal CSS classes and custom JavaScript) are not officially supported (but you can use them at your own risk).
We support the use of the available Config Options and make available the Juicebox-Pro API, but even the API has limited official support, as noted on the API's support page:

Sometimes, users request things that are just not possible using the available Config Options and/or the API.
I'm happy to try to provide a solution if I can but sometimes the solution requires some custom code (CSS and/or JavaScript).
Such modifications are not officially supported as there are far too many possible permutations to document/list and using such modifications can often result in unforeseen and unwanted knock-on problems.
One small and seemingly easy request may snowball out of control into a complex coding mess and it's much safer to stick to the available Configuration Options where possible. If you modify a gallery beyond what is possible with the Config Options, Juicebox will have no knowledge of the modifications and this can quite often cause problems (when Juicebox expects something to happen or a gallery element to be in a certain location and this is not the case due to the modifications).
Also, I really have no greater insight into the inner CSS classes of Juicebox than you do.
I just have to rifle through the 'theme.css' file and use my browser's developer tools to try to figure out how to achieve something (like the code I've posted above).
Having said that, you are certainly free to do whatever you like with Juicebox and your web pages (within the Terms of Use and without modifying the 'juicebox.js' JavaScript source code) but just remember that, if you go beyond the Config Options, then you might run into problems that can be difficult to overcome.