Having just run into yet another example of why the current scheme is a mess, it's time to revisit this, with the benefit of a couple more years' experience.
I think there's a relatively straightforward way to clear up the "path" issues in jAlbum, a way that would require only one change to (some) existing skins, but will allow newer, modified skins to offer more flexibility to the user. I believe the key to it is to separate the image linking choices from the video linking choices, since the requirements are so different. Linking to original images is not uncommon, but linking to original videos is, I suspect, a different matter entirely (original videos are often either in the wrong format, or they're much too large for web use, or both).
First, the Pages tab might end up looking like this dummied-up example:
Why not just two checkboxes in each category, Processed and Original? Because that would allow the user to choose neither, and I'm not sure what a skin would do in that case! "Make me an album, but with no visual content!"
The choices for Images are, in effect, pretty much what we have now - scaled only, originals, originals via scaled - but relabeled (a side benefit - the word "processed" also conveys the idea that in addition to scaling, things like filters are applied to images). So, the existing imageLinking API doesn't have to be changed.
For Videos, we would have a new videoLinking API, parallel to the image choices. To avoid confusion, new constant values would be needed - maybe LINK_PROCESSED, LINK_ORIGINAL_VIDS, and LINK_ORIGINAL_VIDS_VIA_PROCESSED. An old skin won't be confused by this - it simply won't be looking at the value of videoLinking. The existing values never made sense for videos anyway, so a skin would not have been checking those, either - for example, LINK_ORIGINALS meant nothing with regard to a video, so no skin should be looking for it.
Next, where to put the videos? If the choice is Processed or Both, the processed mp4 lands in slides, as it does now. If the choice is Original or Both, the original, untouched video gets copied to the root. Same as images.
Second, paths. No change at all to imagePath. Regardless of linking, it points to the image to be used on the album page - scaled (in slides) or original (in the root).
For images, originalPath would be exactly as it is today. If linking is to scaled only or to originals only, it's void. It's non-void only if the original image is being included along with the scaled image.
For videos, videoPath would be like imagePath for images. Regardless of linking, it points to the video to be used on the album page - processed (in slides) or original (in the root).
For videos, originalPath would be just like images. If linking is to processed only or to originals only, it's void. It's non-void only if the original video is being included along with the processed video.
Video poster images should still land in slides, with imagePath pointing to them. In effect, there is no "original" version of that poster image anyway.
For individual objects, the Include original and Use original context menu choices would simply mirror the album-wide choices, above, as they do today for images. They just need to be extended to videos.
For other types of album objects, like a PDF, nothing changes at all.
With this setup, a modified skin can offer things like using a processed video on the slide page, but with a download link to the original, full-sized monster, or to the original in another format, like WMV. But an unmodified skin should still work just fine.
Skins might want to add things like a download button for an included original video, for example, but that can wait, with no harm done in the meantime.
This still leaves one messy area, and that involves reprocessing of videos that have already been processed by jAlbum. The Do not re-encode option is a strange little beast. I've actually used it as a way to have my original MP4 used in the album without reprocessing, but under this new scheme, the Original (album level) or Use original (object level) choices would take care of that. The only remaining use is to avoid having videos reprocessed when Make All is chosen, or when the video settings are changed.
The Make All option should probably be split into two - a user might want to reprocess all the images, but leave the videos alone. There's also the question of what to do if the user changes the video settings - does he really want jAlbum to reprocess all the videos that have already been processed? Does he need to mark all of the already-processed videos with Do not re-encode? I'm not sure how all of that shakes out, but it's a problem right now, even if nothing is changed.
Having just run into yet another example of why the current scheme is a mess....
For reference: https://jalbum.net/forum/thread.jspa?threadID=55362. This is the kind of tangled web we keep running into. It's as if jAlbum took the wrong turn at a roundabout many miles back, and has been bushwacking down rutted jeep trails ever since, trying to reach its destination by striking out cross-country. Maybe it's time to go back to the roundabout, and get on the right road.