This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 24 - Pages: 2 [ 1 2 | Next ] - Last Post: 29-Apr-2016 18:54 Last Post By: AndreWolff
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Proposed Change to Video Handling (and some related matters)
Posted: 23-Apr-2016 13:49
 
  Click to reply to this thread Reply
First, please forgive the length of this, but it's a complicated subject. We've kicked this around in one form or another for a few years, now. This is my best shot at a proposed structure that I think would solve a lot of difficulties that users are having, while also curing some inherently irrational behavior in the current release.

I'll trot this out in several chunks, which will make it easier to digest (I hope). Some of it is "inside baseball," of concern only to skin developers, but the net results should be of some importance to users. In particular, this scheme would allow you to do things like having jAlbum process a video for use in your album, while still allowing a site visitor to download a much larger, original, hi-def version of that video, which is something you can't do now.
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 23-Apr-2016 13:50   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
Step one: Get rid of hi-res images. As discussed elsewhere, these have outlived their usefulness, and are now just an unnecessary complication. To avoid breaking skins, hiResPath should always be void, and engine.getImageLinking() should never equal LinkHiResViaScaled. If a skin developer wants to make other image resolutions available, beyond scaled and original, he can do it himself - iterate through the album objects, create an output directory to contain the images, and pump them through the image processor.

Step two: Replace the Pages tab with the following:



Step three: Images would be handled as they are now. If you start with mydog.jpg and choose Scaled images, the image is scaled and you get outputDirectory/slides/mydog.jpg. If you choose Original images, the image is copied, untouched, to outputDirectory/mydog.jpg. If you choose Scaled images and also check Include originals, you get both.

Videos would be handled exactly the same way. If you start with mydog.wmv and choose Processed videos, you get outputDirectory/slides/mydog.mp4. If you choose Original videos, you get outputDirectory/mydog.wmv (and if the skin can't handle a WMV, that's your problem). If you choose Processed videos and also check Include originals, you get both. In either case, you also get outputDirectory/slides/mydog.jpg, which is the poster image for the video.
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 23-Apr-2016 13:52   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
Step four: For every object, there would be two context menu options - Use original and Include original. The first option says, "Whatever choice I've made on Pages, use the original image or video in the album for just this object." This takes care of the situation in which you've got 10 videos, but want jAlbum to process only 8 or 9 of them, and to use the provided video untouched for the other 1 or 2. For images, this also provides a way to deal with animated GIF's that are mixed in an album with JPG's - just tell jAlbum to use the originals for these objects. The second choice says, "Include the original for just this object," so the skin can offer it for download. The Use original option would be new - the Include original option is already in jAlbum (though not for videos).

Step five: Now, let's talk about variables. Most of this doesn't actually change.

  • imagePath always points to the image to be used in the album, whether scaled or original.
  • videoPath always points to the video to be used in the album, whether processed or original.
  • originalPath points to the original image or video (in the root of the output directory), no matter which option has caused that original to be sitting in the output directory. It's defined if the user has chosen to use original images/videos in the album, whether on the Pages tab or by choosing the Use original object-level option, or if the user has chosen Include originals on Pages or Include original for this object. Otherwise, it's void.

For a skin developer, this means that he can simply use imagePath and videoPath to build his pages. For an optional download link, or button to open the object in a new window, just check for originalPath not being void.
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 23-Apr-2016 13:53   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
Step six: So what gets broken? Well, there are going to be some video files in two places in the output, necessitating some manual cleanup. Tough to get around this one, but that's just too bad.

Where the real breakage will occur is with skins that are using originalPath to point to a video, rather than videoPath. There's no way around this, but let's face it, when jAlbum takes an 80MB WMV and produces a 20MB MP4 with it, there's nothing "original" about that MP4!

We're talking about a grand total of 21 skins that need to be patched. That sounds like a lot until you realize that they're all coming from only a handful of developers: RobM, AndreWolff, drmikey, sascharasler, pierrem, mrag, Dschuwi, ctwist, Laza, and me. And the patches are minimal - I think I could take care of my skins in under 30 minutes. You're really talking only about replacing originalPath with videoPath. If the skin also offers a "download the original" option, it requires a bit more tinkering.

Only a couple of those developers are problematic, since they're not active (Sascha and Pierre), but if they're unwilling to take care of it, patching their skins should be an easy task for the current intern.

There's also the question of whether some skins are explicitly checking the old "linking options" to decide how things should be handled. If a skin wants to know if there are originals, for example, it can just check for a void originalPath. But if the skin is actually checking engine.getImageLinking(), it will fail if that method is gone, or if it returns a null. Perhaps the core should use the new options to generate that value. So if, for example, the user has chosen the Scaled images radio button and also checked Include originals, that's the equivalent of Link to originals via scaled images. I think I'd prefer some new variables, with getImageLinking() deprecated, but whatever works is OK.
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 23-Apr-2016 13:54   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
Step seven: This still leaves one messy area, and that involves reprocessing of videos that have already been processed by jAlbum, i.e., not preprocessed by the user, who should then just choose Use original. 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.

Finally, "The Holy Roman Empire was neither holy, nor Roman, nor an empire." Discuss.
RobM

Posts: 3,260
Registered: 4-Aug-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 23-Apr-2016 14:30   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
Personally, I think it is sometimes worth breaking things if the end result is better, like a surgeon rebreaking a bone to set it correctly. It is painful, but after the initial shock things are much better.

Things are already 'broken' such as, especially with 'responsive' skins, the concept of rows and columns. All you can be sure about with those settings is that after row*col images you get another index page, you certainly can't assume you will get a grid of images row long by col wide.

Variables have confusing, for skin developers (me anyway), names. originalPath is not the path to the original in the project, but to a copy, maybe, of the 'original' in the album output folder.

Carpe diem, bite the bullet, in for a penny...
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 23-Apr-2016 14:44   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
RobM wrote:
Variables have confusing, for skin developers (me anyway), names. originalPath is not the path to the original in the project, but to a copy, maybe, of the 'original' in the album output folder.

Currently for videos, it's neither of those things! It's the path to a processed version of the original video that may not even be in the same format.
AndreWolff

Posts: 1,871
Registered: 14-Dec-2007
Re: Proposed Change to Video Handling (and some related matters)
Posted: 26-Apr-2016 08:59   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
jGromit wrote:
Step one: Get rid of hi-res images.
The hi-res images have noting to do with the video handling, so I don't understand why that has to be removed. I agree with you that the current contents of the hi-res folder is pretty useless, because the image bounds are always 2048x2048.

A real good solution is to create a new panel for the hi-res images where the user can define for the hi-res images the image bounds, the quality and the sharpness. If you add on the same panel a check-mark 'Copy originals', you can also save the originals to this directory cleaning up the mess in the output directory if originals are copied.

And if you are going to implement the proposed changes, please remove the originals from the output directory and store them in a new Originals directory.
If a skin developer wants to make other image resolutions available, beyond scaled and original, he can do it himself - iterate through the album objects, create an output directory to contain the images, and pump them through the image processor.
I am against this, why should several skin developers do this? It has nothing to do with the skin and it is confusing for users changing skins. It is much better to implement this in the jAlbum core program!
AndreWolff

Posts: 1,871
Registered: 14-Dec-2007
Re: Proposed Change to Video Handling (and some related matters)
Posted: 27-Apr-2016 08:50   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
Attachment TableType.PNG (18.7 KB)
RobM wrote:
Things are already 'broken' such as, especially with 'responsive' skins, the concept of rows and columns. All you can be sure about with those settings is that after row*col images you get another index page, you certainly can't assume you will get a grid of images row long by col wide.
That depends on the skin and the selected parameters in the skin: the Slide Show 4 skin and the PhotoSwipe skin are both responsive skins and if you choose for an elastic table, see enclosed screenshot, you get a table of size row*col on all devices.
But indeed if you select option 'Table with variable # thumbnails / row', the contents of row and col is ignored.

It would be a good idea if the Columns and Rows fields in panel 'Thumbnails layout' could be disabled by the skin code!
davidekholm

Posts: 3,683
Registered: 18-Oct-2002
Re: Proposed Change to Video Handling (and some related matters)
Posted: 28-Apr-2016 14:37   in response to: AndreWolff in response to: AndreWolff
 
  Click to reply to this thread Reply
Thank you for your input. I'm inclined to follow jGromit's recommendations, and to also stuff originals in an "originals" sub folder. There is one UI thing I don't get though. Why not just have two checkboxes for images and two checkboxes for videos saying "Use originals" and "Use processed" respectively? Why the need for radio buttons + a checkbox that's grayed-out if you select one of the options?
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 28-Apr-2016 14:46   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
Thank you for your input. I'm inclined to follow jGromit's recommendations, and to also stuff originals in an "originals" sub folder. There is one UI thing I don't get though. Why not just have two checkboxes for images and two checkboxes for videos saying "Use originals" and "Use processed" respectively? Why the need for radio buttons + a checkbox that's grayed-out if you select one of the options?

The radio button is there because either you're going to display the scaled images in the album slide pages, or you're going to display the originals. You can't display both. Currently, you can't click both Link to scaled-down images only and Link to originals, right?

But then you also need to replicate the current Link to orginals via scaled images. I'm trying to preserve the option of having the scaled images or processed videos in the album pages, but also including the original images or videos for download. Currently, you can't do that with videos at all.

I also want that ability for just one object, along with the ability to have the album use the original for just one object.
davidekholm

Posts: 3,683
Registered: 18-Oct-2002
Re: Proposed Change to Video Handling (and some related matters)
Posted: 28-Apr-2016 14:51   in response to: jGromit in response to: jGromit
 
  Click to reply to this thread Reply
Isn't it more intuitive to select both "Use processed" and "Use original" if you want to emulate "Link to originals via scaled images" ?

As there is no option to include neither processed or scaled, the user interface could check one of the options if the user deselects the other. jAlbum could of course also allow the creation of albums containing thumbnails only...
jGromit

Posts: 7,711
Registered: 31-Jan-2006
Re: Proposed Change to Video Handling (and some related matters)
Posted: 28-Apr-2016 15:03   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
I guess you could just have two checkboxes: Scaled images and Original images. If the user checks the first, but not the second, he gets the scaled image in slides, and that's what shows on the slide page. If he checks the second, but not the first, he gets the untouched original in the root, and that's what shows on the slide page. If he checks both, he gets both versions, with the scaled image on the slide page and the original available for download.

If he checks neither, he gets a seriously broken album. My NoPages skin offers a "thumbnails only" option, but it doesn't do any page generation at all, so it works. But I don't know of any skin that currently knows what to do on the index page if there's no imagePath.

And with that scheme, the object-level choices that I've proposed are a little more confusing, I think. There's a real distinction between using an image or video, and including an image or video. Using means, "This is what's going to be shown on the slide page." Including means, "This will be available for download."
AndreWolff

Posts: 1,871
Registered: 14-Dec-2007
Re: Proposed Change to Video Handling (and some related matters)
Posted: 28-Apr-2016 15:09   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
Why not just have two checkboxes for images and two checkboxes for videos saying "Use originals" and "Use processed" respectively? Why the need for radio buttons + a checkbox that's grayed-out if you select one of the options?
I think nobody except jGromit understand the meaning of check-box 'Copy original images and videos if needed', so to keep it simple don't implement that.

The check box 'Include original images' is required in case you select 'Scaled images' and still like to download the original images.

I don't think we need the check box 'Include original videos', because I don't think anybody will download video's.

I strongly support the use of the radio buttons!

I have no idea who likes to generate an album with only thumbnails, but if you insist to implement that, add it via a 3th radio button 'No images'.
But if you do this. all skins using images do have a problem: What should be done if an album creator selects that option?

I think also the proposed changes will give compatibility problems:

Suppose you implement this in version 3.x In the beta phase of version 3.x you should convince all skin developers to make the required changes in the skins. I have my doubts whether all skins can be converted in time for version 3.x.
And if all skins are converted, they can no longer be used in versions before 3.x, so do you give all users a free of charge update to version 3.x?

Edited by: AndreWolff on 28-Apr-2016 18:52
davidekholm

Posts: 3,683
Registered: 18-Oct-2002
Re: Proposed Change to Video Handling (and some related matters)
Posted: 29-Apr-2016 10:36   in response to: AndreWolff in response to: AndreWolff
 
  Click to reply to this thread Reply
I don't intend to make changes that radically breaks compatibility. What we're discussing here is mainly to provide a more intuitive user interface and allow symmetrical handling of both videos and images.
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums