Thread Locked This thread is locked - replies are not allowed.



Permlink Replies: 356 - Pages: 24 [ Previous | 1 ... 10 11 12 13 14 15 16 | Next ] - Last Post: 18-Nov-2017 16:56 Last Post By: davidekholm Threads: [ Previous | Next ]
jGromit

Posts: 33,156
Registered: 31-Jan-2006
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 12:14   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
1) If jAlbum detects the presense of a variable matching the "themeImageSizeName" skin property, for instance "themeImageSize", it activates generation of theme images.

Simpler: two skins properties, supportsThemeImages and separateThemeImages. If the first is false, the theme image display in the folder panel vanishes completely. No user confusion, trying to use a panel object that is inactive. If the first is true, but the second is false, you can't drop an image on the theme image display, but you can use the cropping slider. If both are true, you can drop an image and crop it.

7) The theme image is scaled and cropped to fit within "themeImageSize".

This gives me heartburn. We have core-defined image bounds and thumbnail bounds, but now all of a sudden, the skin is tasked with setting bounds. That means, among other things, that the skin has to create a way to input these. If it's a combobox like the other bounds, the skin has to validate the input, to make sure to filter out invalid entries like 1080xMydog. If it's a couple of spinners, the skin has to use a StateMonitor to generate the needed variable.

But the tools to do this are already present in jAlbum. Just add another image bound selector to Images, just like the other two. If the skin wants to suggest good sizes, use hints.jap, which is exactly what skins do for the image and thumbnail bounds. Use the entered bounds to set the aspect ratio of the cropping selector.

And if supportsThemeImages is false, dim out the bounds selector.

In short, why should this core function be moved to the skins? Instead, the skins that are already taking inputs like the height of the theme image need to remove those settings. Just use the jAlbum core's theme image bounds. If they're 2000x150, and the skin wants a fixed height for the theme image, well then, it's 150px. If the skin can handle a variable height (miserable to try to implement, BTW), let it suggest bounds like 2000x500.

Even the way Tiger is doing it now (as I understand it - I may be misreading this) is a bit bone-headed. You choose a maximum page width, which controls the thumbnail layout. But the theme image is full viewport width, so that number isn't really suitable as a cropping bound for it. On a large monitor, you'll get a theme image that's been scaled to 1080px wide (actually, it appears to be using 1200px), but stretched to something like 2500px, and it looks lousy. There have already been a couple of posts about it - users want to be able to set the scaling bounds for theme images, just as they can set the bounds for other images.

...we already have closeupPath....

Too bad about that one. ;)

The other aspects of this all sound good.
AndreWolff

Posts: 2,126
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 12:43   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
AndreWolff wrote:
David, why is folderImageSize a skin variable?

It is much more flexible if you define this as a jAlbum core variable, which can be set in a textbox on your new folder panel.
This allows a user to define the size of the theme image per folder.

I understand... Well I admit it's intuitive to have such a setting close to the theme image selectors, but ...

David I like to summarize the advantages of an implementation of the Theme image size on your new folder panel:

  • The most important advantage: the user gets the possibility to define the theme image differently for each folder. I think that is not possible if the dimensions are asked in the skin code, because you can’t save the dimensions per folder.
  • Is is easy for the users: the same UI for all skins and all relevant parameters are grouped together.
  • You get the most reliable (validation-) code, because it is coded by you.
  • Less work for the skin developers and an easy interface for the skins, so it can easy be implemented in all skins.
  • If the crop focus tool shows a bad result, you can adapt the theme image size in the same panel to get it better.
  • Converting images is a typical core function, so all parameters involved with this function should be defined in the jAlbum core. There was no good core implementation of the creation of theme images available in the past, so a number of skins made there own implementation. It is now the time to correct this and give all skins the same possibilities in an easy way.

Edited by: AndreWolff on 04-Nov-2017 12:58

Edited by: AndreWolff on 04-Nov-2017 13:09
AndreWolff

Posts: 2,126
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 12:47   in response to: jGromit in response to: jGromit
jGromit wrote:
This gives me heartburn. We have core-defined image bounds and thumbnail bounds, but now all of a sudden, the skin is tasked with setting bounds. That means, among other things, that the skin has to create a way to input these. If it's a combobox like the other bounds, the skin has to validate the input, to make sure to filter out invalid entries like 1080xMydog. If it's a couple of spinners, the skin has to use a StateMonitor to generate the needed variable.

But the tools to do this are already present in jAlbum. Just add another image bound selector to Images, just like the other two. If the skin wants to suggest good sizes, use hints.jap, which is exactly what skins do for the image and thumbnail bounds. Use the entered bounds to set the aspect ratio of the cropping selector.

And if supportsThemeImages is false, dim out the bounds selector.

In short, why should this core function be moved to the skins? Instead, the skins that are already taking inputs like the height of the theme image need to remove those settings. Just use the jAlbum core's theme image bounds. If they're 2000x150, and the skin wants a fixed height for the theme image, well then, it's 150px. If the skin can handle a variable height (miserable to try to implement, BTW), let it suggest bounds like 2000x500.

Another argument to implement the image size dimensions on the new folder panel!
davidekholm

Posts: 21,445
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 18:31   in response to: AndreWolff in response to: AndreWolff
AndreWolff wrote:
There is already a skin variable: separateThemeImage=true is that not sufficient to activate the generation?

No, that flag simply tells that the skin supports a theme image that is different to the image used to represent the folder.

Yes, but a size definition on your new panel would be appreciated!

Some (or all?) skins will probably only care about an aspect ratio or height and let the width be taken from the image bounds width. For those skins, asking for the theme image width is confusing.
davidekholm

Posts: 21,445
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 18:42   in response to: davidekholm in response to: davidekholm
I don't think it's desired to let users select custom theme image sizes on a per-folder basis. We have ONE bounds setting for slide images and thumbnails. Having per-folder bounds sounds fancy but also means that users will have to make changes for every folder if they decide they want different bounds.

Please consider my idea to simply put a "Theme image height" or "Theme image ratio" under Settings->Images, and let jAlbum use Image bounds along with this ratio and the xWeight and yWeight variables to calculate the crop region.
AndreWolff

Posts: 2,126
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 19:13   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
For those skins, asking for the theme image width is confusing.
It is OK for me if it is only possible to define the height or aspect ratio below the theme image area on the folder panel.
I think that is a more logical place as on Settings->Images tab because he sees the effect immediately in the selected image and as said earlier a user can create the best theme image for each folder.
But you are the boss!
jGromit

Posts: 33,156
Registered: 31-Jan-2006
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 19:41   in response to: jGromit in response to: jGromit
jGromit wrote:
Instead, the skins that are already taking inputs like the height of the theme image need to remove those settings. Just use the jAlbum core's theme image bounds. If they're 2000x150, and the skin wants a fixed height for the theme image, well then, it's 150px.

I take part of this back. Because HTML/CSS handle background images differently from regular images, there might be a case for specifying one height for a title bar, but a different vertical image bound for the theme image.

A couple of quickly-slapped-together demo's that illustrate the point. Bring these two up your browser, and switch between tabs. Yes, they look different. But what's more important is how the theme image behaves when you narrow or widen the browser window. With the second demo, where the theme image is strictly cropped, the lunar rover is always the same size - it's just the sides of the image that get cut off. In fact, on a phone, the lunar rover disappears to the left. Not so with the first demo.

https://jgromit.jalbum.net/tidemo1

https://jgromit.jalbum.net/tidemo2

In short, a user might prefer one behavior over the other, and the only way to achieve that is to allow theme image bounds that may differ from the theme image display height on the page.

Edited by: jGromit on 05-Nov-2017 07:03, to fix typo in link
davidekholm

Posts: 21,445
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 20:16   in response to: jGromit in response to: jGromit
Should we simply have two boolean skin properties: hasThemeImages and separateThemeImage and let each skin do the rest? Scaling and cropping is rather easy to do with the CropFilter and AlbumImage API and JAlbumUtilities.isDirty is a convenient way to figure out if the image needs processing or not.
AndreWolff

Posts: 2,126
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 04-Nov-2017 20:33   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
Should we simply have two boolean skin properties: hasThemeImages and separateThemeImage and let each skin do the rest? Scaling and cropping is rather easy to do with the CropFilter and AlbumImage API and JAlbumUtilities.isDirty is a convenient way to figure out if the image needs processing or not.
I don’t understand this change: Every skin should invent the wheel again and duplicate the code which belongs to the core?
I disagree!
AndreWolff

Posts: 2,126
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 05-Nov-2017 09:17   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
I don't think it's desired to let users select custom theme image sizes on a per-folder basis. We have ONE bounds setting for slide images and thumbnails. Having per-folder bounds sounds fancy but also means that users will have to make changes for every folder if they decide they want different bounds.
What about this to get the best of both worlds:

Put a "Theme image height" or "Theme image ratio" under the Theme image box on a folder panel.
Add,on the panel of the top folder (level 0) only, a check-mark “Use this for all folders”.
If this check-mark is set the "Theme image height" or "Theme image ratio" fields on the other folder panels are disabled or even absent.

What do you think?

Please consider my idea to simply put a "Theme image height" or "Theme image ratio" under Settings->Images, and let jAlbum use Image bounds along with this ratio and the xWeight and yWeight variables to calculate the crop region.
If you put a "Theme image height" or "Theme image ratio" under Settings->Images, it is also visible for skins which do not use theme images (bad user interface) and with skins using a theme image, the users have to swich between two panels to define the theme image settings.

Edited by: AndreWolff on 05-Nov-2017 09:39
AndreWolff

Posts: 2,126
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 05-Nov-2017 10:07   in response to: jGromit in response to: jGromit
jGromit wrote:
A couple of quickly-slapped-together demo's that illustrate the point. Bring these two up your browser, and switch between tabs. Yes, they look different. But what's more important is how the theme image behaves when you narrow or widen the browser window. With the second demo, where the theme image is strictly cropped, the lunar rover is always the same size - it's just the sides of the image that get cut off. In fact, on a phone, the lunar rover disappears to the left. Not so with the first demo.

https://jgromit.jalbum.net/tidemo1

https://jgromit.jalbum.net/tidemo2

In short, a user might prefer one behavior over the other, and the only way to achieve that is to allow theme image bounds that may differ from the theme image display height on the page.

There is an easy solution for this problem: do use the theme image as a normal image with a width in % and a possible max-width in pixels instead as using it as a background image. I use that in my PhotoSwipe skin, see this example.

BTW1: Your first link contains an error, it has been corrected in my quote.

BTW2: Nice that the next version of your skin gets swipe support!

BTW3: Tip: use swipeup / swipedown on a slide page to go back to the index page.

Edited by: AndreWolff on 05-Nov-2017 10:18
jGromit

Posts: 33,156
Registered: 31-Jan-2006
Re: jAlbum 14.2 beta for testing
Posted: 05-Nov-2017 13:54   in response to: AndreWolff in response to: AndreWolff
AndreWolff wrote:
BTW1: Your first link contains an error, it has been corrected in my quote.

Fixed.

BTW2: Nice that the next version of your skin gets swipe support!

The current version of Gromit has swipe support, as have the prior six versions.
davidekholm

Posts: 21,445
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 07-Nov-2017 16:42   in response to: jGromit in response to: jGromit
Hi everyone. b12 is out. Run the installers again. It has a new image reading library ( TwelveMonkeys ) that provides more robust JPEG image reading and far faster CMYK JPEG reading. I also use it for scaling images using the Blackman Sinc algorithm. To try this scaling, go to Settings->Images and set Quality to Medium and switch off "Use hardware accelerated scaling when possible" under the Advanced tab. I find that the Blackman Sinc algorithm even outperforms the Smooth scaling, although it's slower than the combination of Smooth and hardware accelerated scaling. Here are two sample images. The 1:st is scaled with Smooth, and the second with the Blackman Sinc algorithm (Medium quality and no hardware acceleration)

Sample images: Pay attention to the thin, almost vertical cable!

Smooth:


Blackman Sinc (Medium and no hw scaling):


So, if this new algorithm is the best, why not replace smooth? I might, but I don't want to touch it until you can confirm that it outperforms Smooth with all sample images you throw at it. If I replace Smooth with it, it will also be slower than Smooth is today and that's perhaps not desirable. The way I'm using the Blackman Sinc algorithm now is a quality vs speed tradeoff where I first scale really large images quickly to half the size while loading them and then apply the Blackman Sinc scaling for the final scaling. Even though this approach may produce worse results than Smooth (which will load full sized images and scale them smoothly), it at least produces better results for this sample image.
jGromit

Posts: 33,156
Registered: 31-Jan-2006
Re: jAlbum 14.2 beta for testing
Posted: 07-Nov-2017 17:36   in response to: davidekholm in response to: davidekholm
Quick tests with some challenging images (sailboat rigging, for example), and some more ordinary material, and the results with Blackman Sinc on Medium are always at least as good as the regular method on Smooth (HW scaling off in both cases), and sometimes ever so slightly better. Not a dramatic difference, but detectable in some cases.
davidekholm

Posts: 21,445
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 07-Nov-2017 18:25   in response to: jGromit in response to: jGromit
jGromit wrote:
Quick tests with some challenging images (sailboat rigging, for example), and some more ordinary material, and the results with Blackman Sinc on Medium are always at least as good as the regular method on Smooth (HW scaling off in both cases), and sometimes ever so slightly better. Not a dramatic difference, but detectable in some cases.

Thanks for testing. Do you have images with really high frequencies in? Like a football goal from a distance? Those could show up better with Smooth, especially if the target image is, say at least 3 times less wide or high than the source image.
Legend
Forum admins
Helpful Answer
Correct Answer

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