Forums  ›  Cheetah  ›  Bug Reports
 

Photo extensions for ads, groups, etc.

 

Odd. I see it in the css as you pointed out, but at least on my site, it's not being applied to anything.

 Well actually it does! When I added my one-line hack for the Random photos, they were very blurry. I can't recall how I discovered the offending code, but when I removed it everything came good. I'll do a Dolphin search and see if I can track it down.

 

 

Anyhow. It's not a blur that is being added, it's a gradient transparency that only covers the bottom part of the cover block. . . . .

 I think we're talking about different things. I still using the transparency on my covers, but the blur does something different.  Oddly, it doesn't seem to affect the default cover or the graphic for Member Four in my demo. The blur does however seriously affect the images in my random image hack. With it activated, the images are very blurred! When it's removed, they're super sharp.

I'm referring to a code snippet in  templates/base/css/profile_view.css Lines 35 - 41 approx.

div.sys-profile-cover-bg-l1.sys-pcb-thumbnail {
    -webkit-filter: blur(3px);
    -moz-filter: blur(3px);
    -o-filter: blur(3px);
    -ms-filter: blur(3px);
    filter: blur(3px);
}

I'm not quite sure why this snippet even appears, but everything works fine for me if I isolate it.

 

 

 

 Odd. I see it in the css as you pointed out, but at least on my site, it's not being applied to anything. I am going to remove that from the css. It does not need to be there.

 

Anyhow. It's not a blur that is being added, it's a gradient transparency that only covers the bottom part of the cover block. . . . .

 I think we're talking about different things. I still using the transparency on my covers, but the blur does something different.  Oddly, it doesn't seem to affect the default cover or the graphic for Member Four in my demo. The blur does however seriously affect the images in my random image hack. With it activated, the images are very blurred! When it's removed, they're super sharp.

I'm referring to a code snippet in  templates/base/css/profile_view.css Lines 35 - 41 approx.

div.sys-profile-cover-bg-l1.sys-pcb-thumbnail {
    -webkit-filter: blur(3px);
    -moz-filter: blur(3px);
    -o-filter: blur(3px);
    -ms-filter: blur(3px);
    filter: blur(3px);
}

I'm not quite sure why this snippet even appears, but everything works fine for me if I isolate it.

 

 

 

 

I am going to improve that as well. It's a pain in the ass.

 You got it in one! If the people who run a site find it difficult, what about the 70 year old who just wants to do a bit of social networking? When I was doing program design way back in the 80's, my tutor always insisted "Things must always flow in a natural progression. People make choices before they think." How right he was.

 

In the old regular uploader, the original was saved and could be displayed when going to view the photo; 

I agree with many of the points Geek_Girl has raised. Cover photos are actually a rarity. On the sites I'm involved with, hardly anyone bothers to change the static photo, thus the reason for me developing the Random Cover hack.

I agree that there could be a separate folder inside or outside the photos module for both Profile Photos and Cover photos. Neither of these need to appear on the timeline or outline when updated, but that's what currently happens.

It would be nice if the Crop module under development was able to do this for cover photos:

1. Bypass the Photos module resizer and save the graphic in the proper size format. 1100 x 300 or whatever.
2. Place it in the correct folder so that the "Change Cover" option can find it.
3. Delete the original. Who needs any original, because browsers resize them if they're too big  anyway.

It would be lovely if the same thing applied to Profile Pics:

1. Save to a separate dedicated folder
2. When Profile Pic is selected, force a square crop 300 x 300
3. Delete the original

All remaining photos:

Delete the original. As stated, browsers resize large originals anyway and it stops people from pinching hi res graphics.

 

 

 

 

Yep! I love the tool, but dammed if I could find an easy way to get the graphic to be my cover. I already have a folder for covers and the only solution I could see was to download it and upload it. Yeck! No problems, these are things that will no doubt sort themselves  out.

Yea. If it's in the covers album you would go to organize photos and drag it to the first position. If it's not in that album you would have to move it.

I am going to improve that as well. It's a pain in the ass.

Yep! I love the tool, but dammed if I could find an easy way to get the graphic to be my cover. I already have a folder for covers and the only solution I could see was to download it and upload it. Yeck! No problems, these are things that will no doubt sort themselves  out.

Yes, that new cropping tool is pretty nifty.  Good work.

In the old regular uploader, the original was saved and could be displayed when going to view the photo; a button view original would open up the original photo in a new window/tab on the browser.  If the hmtl5 uploader is not actually saving the original image then the only point to it is to keep the original format and I really don't see a need for saving the original just for having a .png image when the uploader converts it to .jpg.  Instead of using the photo module for uploading the cover photo, why not a simple uploader with built in resize to the width of the cover block?  I don't really like the way a photo album is used to just hold the cover image and what happens if the user removes that album? I accidentally removed one of the built in albums awhile back and had to recreate it.  I see the cover image as a separate thing away from the regular photo albums; much like avatars are separate.  We don't have an avatar photo album; avatars are stored in the avatar module and are viewed when you go to the account/dashboard and choose avatar.  I think that approach would work well for the cover image.  Most people will only have one or two cover images; no real need to use the photo module for the cover image.

Yes, i would like your hack.

Anyhow. It's not a blur that is being added, it's a gradient transparency that only covers the bottom part of the cover block, but yes, i agree, removing it does make the cover look better and i most likely will for the next version of cheetah.

However, on your demo, profiles 2 and 3 are using stock photos, and all of them appear to be at least 1118px wide or higher. Those ones look good. On profile 4 there is a cover that was uploaded, thus the site resized it, and it's width is not 1118px wide. It's 750px wide. So that one is getting stretched. I don't like that. I know the photo would look better if it was a higher resolution.

So i am going to leave it up to the end user if they want to modify their sites to delete the original photo. I will rewrite cheetah to use the original image for the cover, and if it does not exists then will use the 750px one which is the next one down if the original does not exist. Currently cheetah uses the 750px image as the cover by default. But that's not how it should be for the covers. Especially if the original is available.

And i have to agree. The original cropper sucked. My new one is much more powerful. This site is using the new cropper if you want to check it out.

Hi all, I've been away from Cheetah and Dolphin for a while, but I've been dropping in on the forum.

I raised the subject of the Image cropper in an old forum post or my suggestions for an upgraded photos module. I'm not sure about the HTML5 uploader which I think I've been using, but as I have a small volume server, I've recoded the photos module to:

  • Create smaller thumbnails
  • Delete the original after the upload is completed
  • Set the compression to 80% which seems to be the industry standard.

    Via admin I've set the image size to 700px high/wide which is perfect in my opinion.

The downside of deleting the master image is that the Cropper wouldn't work. As it was pretty useless in that it only did square crops for profile pics I wasn't concerned.

I did a paper which I sent to Boonex about the automatic cropping of cover photos  because it took a chunk from the vertical center of the photo. In the case of a decent female portrait being used for the profile,  the cover only showed her boobs.

I don't think an enlarged photo for the cover is such a bad idea. Cheetah already adds a forced blur to the cover and this is why you may be thinking the photos look bad. If you remove the blur, things may look a whole lot better. I've removed it and my cover pics can look spectacular.

At this point of time, may I suggest you add my cover photo module/hack as part of the next release? It has so many benefits, it only requires the change of one (1) line of code and I think the members will love it. The only other requirement is for Cheetah or the Admin to add a folder of stock cover photo graphics and all is done.

How the module (hack) works:

Currently every profile has the same cover graphic until a member changes it. Most probably don't care. With my hack, the member's profile shows a different cover graphic every time they, or a visitor accesses their profile page. If it's a site about bees, the cover graphics could be a selection of bee photos which the script chooses at random. I currently have 30 photos, but you can have as few or as many as you want. Site admins can replace the stock photos with ease.

The random photos continue to appear as long as the member doesn't upload their own graphic. As soon as they do, that graphic will always appear as their cover.

What I like about the hack is that the random photos only come into play if a member has a profile photo. If they don't, a  preselected cover graphic will appear. I currently use the standard EVO graphic, but it can be anything.

All that for a small code change on a single line. It's yours for the asking Deano.

You can see the demo here: Just visit each of the members profiles to see how it works. There are only four.

 

Click Here for the Demo

 

I thought i should mention this as i am working on a new image cropper and ran into what might be a possible problem.

Turns out neither cheetah or dolphin actually keeps the original image, at least not when uploaded via the html5 uploader. Given that i have removed the regular uploader from cheetah, the html5 uploader would be used anyway.

When using that uploader, the original image is resized to the maximum setting specified by the Width for photo resizing in browser setting in the photo module. So even if you uploaded a massive 4K photo. 4096 x2160 or 8K 7680 x 4320 it would be reduced in size to that setting which the default is 2048.

So it turns out the original is not actually the original after all unless the old regular uploader is used.

Reason deleting the original is a problem is the profile cover. Per the default page width settings the cover needs to be at least 1118px wide other wise it gets stretched to fit. And stretched images look like crap.

So instead of deleting the original, i recommend that the Width for photo resizing in browser setting be set no lower than the page width your site is set to use. This will reduce those massive 4k and 8k photos down to a predetermined size.

Anyhow, i will have to deal with issue in my cropper because i have built in a aspect ratio into my cropper that is sized for the cover photo, and if the original is not available, the next one down would be stretched to fit and it would look like crap.

 

@Geek_Girl should already know this, but for anyone interested in reducing hard disk usage, there are a couple of things you can do to seriously save server space without Google throwing a spanner in the works by introducing a new photo format. 

When you, or a member uploads a file to the site, the photos module makes several copies, one for the main photo in an album and several for thumbnails used throughout the site. The photos which your members will view can be resized in the Photos module settings. I've set mine to 700 wide or 700 high and that seems to be fine on all platforms. There are other settings you can also change to reduce server space and make your site look different. Firstly, you can easily change the size of the thumbnails and that will significantly reduce the demand on your hard disk. In my opinion it also makes the site look better. Secondly, you can set the rate of compression which currently defaults to 85%. As 80% seems to be the industry standard, I set my sites to 80% and that also saves a lot more disk space.

The biggest saving of all is to delete the original photo from the server as soon as the photos have been uploaded and converted. Cheetah currently keeps a copy of the original photo and as far as I know it's not compressed. If a member posts 10 by 3 meg photos, all ten are saved on the server along with all the copies. "Why?" you may ask? Well, Cheetah has a rudimentary crop facility (Square Photos only, possibly to create avatars.) The original photo is used for the crop so as to give the best possible quality. Then there's an option when you're looking at a photo to View the Original. In most instances, the user will see little or no difference, because all browsers reduce photos to fit the screen anyway.

I've written a tutorial showing how to make all the above changes, but it's currently for Dolphin. I'll work on it over the weekend and convert it to work with Cheetah. Somewhere amongst all the earlier discussions about Cheetah, I prepared a suggestion for the photos module and I think I asked Deano to consider the "Delete Original" feature as being an option admins could select. If that's not the case, it's in a yet to be published paper requesting changes to the Crop facility. All in good time, but you can certainly make all the above changes and save heaps of server disk space immediately. One warning, it will only do it for new photos. You'll need to resize previously posted thumbnails and delete the original photos manually.

Yes, I don't know how widespread support is.  However, if the compression is good and you don't lose quality, then it helps to save drive space.  PNG is good but the file size isn't so good.  WebP may be one of those things that never really catches on.  The other thing is that the smaller the file, the less bandwidth it uses and the faster it loads to the page.  Here is a list of browser support 

this was posted oct 12 2020

Which web browsers natively support WebP?

Webmasters interested in improving site performance can easily create optimized WebP alternatives for their current images, and serve them on a targeted basis to browsers that support WebP.

  • WebP lossy support
    • Google Chrome (desktop) 17+
    • Google Chrome for Android version 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 11.10+
    • Native web browser, Android 4.0+ (ICS)
  • WebP lossy, lossless & alpha support
    • Google Chrome (desktop) 23+
    • Google Chrome for Android version 25+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 12.10+
    • Native web browser, Android 4.2+ (JB-MR1)
    • Pale Moon 26+
  • WebP Animation support
    • Google Chrome (desktop and Android) 32+
    • Microsoft Edge 18+
    • Firefox 65+
    • Opera 19+

Ok, the photo module is using the html5 uploader by default which supports these formats.

jpg
jpeg
png
webp
gif
svg

And apparently ignores the file extension setting in the photos module which seems only the regular uploader uses which i removed from this site and from the main cheetah distro. I did not even realize the html5 uploader ignored those file extensions.

Still does not explain the issue in the other modules.

Great, more stupid dolphin quirks i need to fix.


 

I just tried it on my Dolphin site and it worked there as well. Not so in the Groups module. No warnings, it just didn't appear.

 

My last post may not be too helpful because I probably didn't read the original question correctly. I was able to upload and view a .webp photo in a private album on this site and I suspect Cheetah converted it to a JPG.  That surprised me a bit because the discussions I could find on the Internet say you need a codec to convert the files. It also seems the files in their native format can't be seen by all browsers which is an interesting huge step backwards.  

What makes it even more interesting is this:  Although Cheetah's photo module converts the photos to JPG, do other third party modules? When I tried uploading the the photo to Modzzz's Answers module on this site, the photo never appeared. Thus I'm inclined to believe that Modzzz and possibly others, allow uploads and storage of certain photos in the file's native format. If you were to allow .webp files to be uploaded in this manner, people viewing a Cheetah site may not be able to see the photos because of the browser they use. 

If you ask me, it's just a ploy to force people to convert to Chrome, or use a third-party extension on their browser. Thus it may be best to ignore this format for the time being, as we do with TIFF and other obscure formats?

In all fairness, JPG does a pretty good job at 80% compression and it's only purists who need this kind of stuff. maybe it will be the format of the future, but maybe not.

@Geek_Girl, I realise people may wish to upload files in this format, but they also try uploading lots of other weird stuff and where does one draw the line?

Hmm, i will have to look into that as the upload should have been rejected. the webp file extension is not listed in the allowed files even in the photos module.

And based on info here, https://caniuse.com/webp the webp extension is supported by all current modern browsers except safari.

Also, php does have the needed functions to convert webp files.

My last post may not be too helpful because I probably didn't read the original question correctly. I was able to upload and view a .webp photo in a private album on this site and I suspect Cheetah converted it to a JPG.  That surprised me a bit because the discussions I could find on the Internet say you need a codec to convert the files. It also seems the files in their native format can't be seen by all browsers which is an interesting huge step backwards.  

What makes it even more interesting is this:  Although Cheetah's photo module converts the photos to JPG, do other third party modules? When I tried uploading the the photo to Modzzz's Answers module on this site, the photo never appeared. Thus I'm inclined to believe that Modzzz and possibly others, allow uploads and storage of certain photos in the file's native format. If you were to allow .webp files to be uploaded in this manner, people viewing a Cheetah site may not be able to see the photos because of the browser they use. 

If you ask me, it's just a ploy to force people to convert to Chrome, or use a third-party extension on their browser. Thus it may be best to ignore this format for the time being, as we do with TIFF and other obscure formats?

In all fairness, JPG does a pretty good job at 80% compression and it's only purists who need this kind of stuff. maybe it will be the format of the future, but maybe not.

@Geek_Girl, I realise people may wish to upload files in this format, but they also try uploading lots of other weird stuff and where does one draw the line?

I recall playing with this oneday. Maybe this will help:

/modules/photos/install.sql

('[db_prefix]_allowed_exts', 'jpg jpeg png gif', @iKatID, 'Allowed extensions', 'digit', '', '', 3, ''),

/modules/photos/chphotosuploader.php

                switch($aSize[2]) {

                    case IMAGETYPE_JPEG: $sExtension = '.jpg'; break;

                    case IMAGETYPE_GIF:  $sExtension = '.gif'; break;

                    case IMAGETYPE_PNG:  $sExtension = '.png'; break;

                    default:

                        @unlink($sTempFileName);

                        return false;

Considering the module does not have settings for this, and it seems similar modules that use a similar form layout for the adding of new items such as many of the modules from modzzz that started as a clone of one of the dolphin modules. Such as the answers and tutorials modules on this site also do not have their own image format settings.

So i am guessing that they must be hard coded somewhere and betting they are restricted to GIF, JPG and PNG.

I will look into it when i have some time. Considering many third party modules also use the global file handling classes from the inc folder, i would have to make that a global setting somewhere, other wise i could end up breaking 3'rd party modules.

But i have to locate where those extensions are checked first before i can do anything with it. So i will add it to my todo list.

This is not really a bug as such but thought this would be the best location to post.  Testing on the beta 1.1.0 I see that the ads module; and I am guessing photos in groups, etc, would not allow me to upload the webp extensions.  I thought the allowed extensions would be controlled by the photo module settings but adding webp as an allowable extension in photos settings still would not allow me to add a webp photo in the ads module.  Are the allowable photo extensions in the ads module hard coded?  If it is hard coded; then either each module with photo uploads should have an allowable extensions for photos, or, it could be a global setting, or just the allowable extensions as listed in the photo module.

I don't know the extend that sites are using webp images; it is a new compression from Google; royalty free, that is suppose to have lossless images at greater compression rates than the current lossless formats.

Forums  ›  Cheetah  ›  Bug Reports