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



Permlink Replies: 100 - Pages: 7 [ Previous | 1 2 3 4 5 6 | Next ] - Last Post: 7 May 21, 13:30 Last Post By: davidekholm
davidekholm

Posts: 3,903
Registered: 18-Oct-2002
Re: WebP support in next major version
Posted: 29 Mar 21, 23:51   in response to: JeffTucker in response to: JeffTucker
JeffTucker wrote:
CAUTION!!

There's a bug in this beta that louses up the casing on image file extensions. It's confusing .JPG with .jpg. Made a mess of my demo site, and I'm still sorting my way through the disaster. I may have to remake and re-upload all of it. :(


How do you mean?
JeffTucker

Posts: 7,932
Registered: 31-Jan-2006
Re: WebP support in next major version
Posted: 30 Mar 21, 00:14   in response to: davidekholm in response to: davidekholm
Total Validator to the rescue - it found the broken links, so I was able narrow it down to just nine of the demo albums, not all of them. Some quick deletion, regeneration with 23.2.8, and re-uploading, and my site seems to be stable again.

Now that the dust has settled, I'll reinstall the core for 23.3b2 and do some testing - back in a bit....
JeffTucker

Posts: 7,932
Registered: 31-Jan-2006
Re: WebP support in next major version
Posted: 30 Mar 21, 00:24   in response to: JeffTucker in response to: JeffTucker
OK, found it. If you have an image called DSC_1234.JPG, the slide and thumbnail that are generated are DSC_1234.jpg. OK in Windows, which is case-insensitive, but once uploaded, you're doomed.

ETA: If you're starting with a fresh project, it also uses lower case for the thumbPath and imagePath, so there's no error. But if you're dealing with an existing project, you're in trouble because some images are not being regenerated, while others are. It quickly becomes a tangled mess.
davidekholm

Posts: 3,903
Registered: 18-Oct-2002
Re: WebP support in next major version
Posted: 9 Apr 21, 21:57   in response to: JeffTucker in response to: JeffTucker
Ok, now I get it. jAlbum has historically respected the casing (.JPG vs .jpg) of existing images when writing the generated ones, but since I added webp support in the last beta it always writes JPEGS as ".jpg". I've now fixed this in the updated beta file.
JeffTucker

Posts: 7,932
Registered: 31-Jan-2006
Re: WebP support in next major version
Posted: 9 Apr 21, 22:15   in response to: davidekholm in response to: davidekholm
Always writing lower case would be fine if there were no existing projects. ;)

The b3 core appears to fix the problem - the extension casing of the original image is being respected. I've done some "flopping around" between writing JPG and writing WEBP, with a mix of cases, and it looks like it's getting it right every time.

But it's probably something to keep in mind if any users suddenly start reporting "broken" thumbnail or slide image links.
davidekholm

Posts: 3,903
Registered: 18-Oct-2002
Re: WebP support in next major version
Posted: 9 Apr 21, 22:27   in response to: JeffTucker in response to: JeffTucker
Good.
JeffTucker

Posts: 7,932
Registered: 31-Jan-2006
Re: WebP support in next major version
Posted: 9 Apr 21, 22:34   in response to: davidekholm in response to: davidekholm
The only exception is in this instance:

  • Original image is mydog.WEBP
  • jAlbum is set to Write webp
  • The output image is slides/mydog.webp
  • But if Use original is chosen, the output image is (root)/mydog.WEBP

This is not a problem because existing projects shouldn't have any WEBP images in the slides directory - support for webp is new to this version. But I have the nagging feeling that always respecting the original casing would be safer.
davidekholm

Posts: 3,903
Registered: 18-Oct-2002
Re: WebP support in next major version
Posted: 9 Apr 21, 22:46   in response to: JeffTucker in response to: JeffTucker
I agree. In either case this shouldn't be a problem as we haven't been generating webp images before.
ctwist

Posts: 645
Registered: 27-Sep-2003
Re: WebP support in next major version
Posted: 23 Apr 21, 20:39   in response to: davidekholm in response to: davidekholm
Which variable or method provides the "Write WebP images" setting?
davidekholm

Posts: 3,903
Registered: 18-Oct-2002
Re: WebP support in next major version
Posted: 26 Apr 21, 23:34   in response to: ctwist in response to: ctwist
ctwist wrote:
Which variable or method provides the "Write WebP images" setting?

It's an API call: engine.setWriteWebP(true), or put in a project file: writeWebP=true
ctwist

Posts: 645
Registered: 27-Sep-2003
Re: WebP support in next major version
Posted: 27 Apr 21, 18:33   in response to: davidekholm in response to: davidekholm
For gif files, engine.getTargetName() returns a file name with suffix png. Is this intentional?
RobM

Posts: 3,781
Registered: 4-Aug-2006
Re: WebP support in next major version
Posted: 27 Apr 21, 19:35   in response to: ctwist in response to: ctwist
Gif images are normally converted to png, unless Settings/Images/Force jpeg is selected.
ctwist

Posts: 645
Registered: 27-Sep-2003
Re: WebP support in next major version
Posted: 27 Apr 21, 20:44   in response to: RobM in response to: RobM
I think that option is to retain animation in the gif.

However, webp supports animation, so doesn't it make sense to always convert gifs to webp if the "webp" option is selected?
RobM

Posts: 3,781
Registered: 4-Aug-2006
Re: WebP support in next major version
Posted: 27 Apr 21, 21:09   in response to: ctwist in response to: ctwist
ctwist wrote:
I think that option is to retain animation in the gif.

However, webp supports animation, so doesn't it make sense to always convert gifs to webp if the "webp" option is selected?

I didn't realise webp supported animation. Still, the option for firing jpegs probably needs updating now.
JeffTucker

Posts: 7,932
Registered: 31-Jan-2006
Re: WebP support in next major version
Posted: 27 Apr 21, 22:08   in response to: RobM in response to: RobM
Lots of confusion here. Let's try to sort it out....

I believe jAlbum converts GIF to PNG because the image processor it uses can't output GIF's.

The conversion from an animated GIF to PNG does not produce an animated PNG. The animation is lost.

In all of my skins, I make the assumption that if a user has included a GIF, it's an animated GIF, and he wants to preserve the animation. So, I simply force them to be tagged as Use original. I know this violates my long-standing principle: Don't do me any 'favors.' But in this case I think it's warranted.

So should the jAlbum core do the same, and just use the original GIF for the slide page, no matter what? (Not for the thumbnails, however - GIF is a bitmap format, so the image files tend to be quite large for their dimensions.) One downside - this would mean that GIF's are never pumped through image processing, which means no resizing (not a big deal, since GIF's are almost invariably smaller than the image bounds), but also no cropping, no watermarking, no logo, etc., etc.

Pick your poison.
Legend
Forum admins
Helpful Answer
Correct Answer

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