If the files are in the File Manager, they should be easy to find and delete. Open the File Manager and set the number of images per page to '500' and hit 'Search'. Then sort the list by size by clicking on the 'Size' heading and the large images will appear at the top of the list.

As to your questions... I doubt they are slowing the site down and I know of no way to find out if an image is actively used in the site.

View a page in the developer console and look at the resources tab. That will tell you what is used on the page.

Large files will only slow the site down if they are actually used. Even then, re-sized files are kept, so c5 making a resized version of a large file will only happen once.

Otherwise large files just waste space, not time.

PS, my Front End Uploader addon includes a resizer. This acts after the upload, but before the file is saved, so for a monster image the upload will take time, the resizing will take some time (not massive compared to the upload), but only the re-sized file will actually be saved into c5.

@johnthefish... I've been dealing for years with people who just hook their camera up to their computer and try to upload huge photos leading to timeout errors and support calls. In your work with file uploads have you been successful at re-sizing on the client before uploading? I've successfully used this but not in the C5 environment:

http://www.plupload.com

On my personal agenda for Front End Uploader is resizing before upload, drag/drop, multi-upload and other stuff that is possible with html5. However, all that will not be coming soon. I need to get a lot of other work completed first.

I'm really trying to avoid going page by page to find unused images.

Surely there must be some method to determine if an image is in use -- whether in the C5 interface (ideal) or in the database?

I would imagine some database pointer is set when an image is added to a page. Is there a specific x-link table that tracks used images?

I looked at that but it's not that simple. Pages are collections of blocks and the blocks are the things that contain the images so it's not the pages you are interested in looking at but the blocks on approved page versions. Given the number of different blocks that can contain images and the fact that these blocks are free to name their database fields any name they choose, I'm not sure you could construct an SQL query to find them all. As far as I can see, there is no table that maps images to pages.

Someone else with more experience can 'school' me if I'm wrong.

In Remo's book he gives a development example of a Job that checks for broken links. Such a job could presumably be modified to check for pictures over a certain size.

Another possibility would be to upload re-sized pictures to replace the existing big pictures.

Yet another possibility would be to backup database and files, delete the big pictures from the filer manager, then quickly scan through pages looking for missing pictures. (Or revert if too many are missing)

EDIT - some info that may be useful for any code based solution: If the site is in c5.6+, the image helper leaves an _fXXX on the end of any image it has resized, where XXX is the fID. So providing the essential bit of info needed to back-trace a scaled image from the rendered page to the original file.

Sounds like an opportunity for an add-on...

Thanks for your help, all great ideas.

+1 for something that could tell which files in the file manager are being used in the site. One site in particular I'm thinking about has about 300 pages and they've all gone through changes over the life of the site. I just know there are a ton of old images in the file manager that could be culled.

Uhg, I know this probably just poor management on our part, but are there any settings or something we can do to prevent the file manager from being visually cluttered and adding unneeded weight to server space/backups?
I just spent an hour cleaning out images and trying to figure out if they were used and why there were duplicates. One example: I had multiple images that all had the exact same name. I believe the image had to be re-tweaked multiple times over a week or 2 and just kept getting uploaded without searching for the older one and deleting it. I am used to Windows not allowing same names in a folder, so at first it was confusing seeing the same name and image thumbnail as I scrolled. I was able to eliminate the copies by matching the image path in the site to the right image file. I then had to go through dozens of other images one at a time to see if they were even being used then deleted with my fingers crossed. My client has a local news block that will not be archived, so old news will be deleted. How are we going to organize/separate these images used on the news pages from the site's images in file manager? I can see now, after a year there will 100's of temporary images mixed in with the site's permanent ones.
Is this just remembering careful image management?
Do any of you guys have any tips on properly using the file manager so it works for us, not us working for it?
Thanks!

Solving this problem should earn someone a Nobel Peace prize.

I use a program called FastStone Photo Resizer:

http://www.faststone.org/FSResizerDetail.htm...

Highly capable and it lets me set a myriad of variables, destination folders, borders, watermarks. etc. Download it for free and check it out.

I've posted an approach that would do that a while ago on the beta forum (finding unused files)http://www.concrete5.org/developers/beta/beta_discussion/removing-u...

We don't all have access to the beta forum. Could you summarize your hypothesis?

Sure!
Scanning the site to find all images in use is a tedious thing and won't work perfectly in every situation. Think of some "tool" that gets called by an AJAX script - scanning that is rather tricky.

Instead I suggested that we need some kind of "file manager registration" - every add-on (block, attribute etc.) that uses files has to register itself as a "consumer".

With blocks, there's already something we could use. Check this:https://github.com/concrete5/concrete5/blob/master/web/concrete/core...
This is used when a block is exported into an XML file but could in theory also be used to see if a file is in use. We'd basically have to scan all blocks to see if $btExportFileColumns is defined - if it is, we'd have to scan the table and so on...

Sounds feasible but isn't the real reason we need this functionality is to be able to know what images in files/1234/2345/3456... are NOT needed? How do we find files that have been orphaned by the deletion of the parent block or if a version of the file is no longer linked to by any block?

I guess my explanation was bad, but my solution would help you with that!

Right now you have no clue which add-on uses files and thus we need some kind of registration. When deleting a file we'd know where to check for any usages..