Previewing images in zip files

[ze1]

Would it be possible to preview files inside a zip file? The site already shows you which images are inside a zip file, but that's not as helpful as previewing the images. Even a thumbnail would be good enough to decide whether downloading a zip file is worth it.
It's a lot of trouble having to download a zip file, unzipping the files and organizing everything to make sure you don't mix up files when you're not even sure if the zip has what you're looking for.

[Petie]

It's a lot of trouble having to download a zip file, unzipping the files and organizing everything to make sure you don't mix up files when you're not even sure if the zip has what you're looking for.

This is exactly why what you're asking for can't (or, more to the point, won't) be done. In order to provide live previews of zip contents, those zip files would have to be unzipped on the fly or we'd have to store those previews elsewhere. Either way, it's not feasible. This is one of many reasons why I strongly dislike zips for all but the most necessary purposes (like a collection of 4K backgrounds or something). In almost all cases, content should be submitted as a sheet.

[Raccoon Sam]

Both, client-side and server-side unzipping is possible with Javascript but what the most efficient/doable method is is beyond me.
It's a legitimate usability concern, but I think the question "can zip files be previewed" isn't as relevant as "how should we do it?" Even if we can manage to unzip the contents online with zero strain onto the server, what then? A slideshow-type image viewer? Low-res thumbnails generated (every time) for easy scouring-through? What about models? They're zipped too; could they be unzipped on-the-fly as well and previewed?

It's an interesting question for sure and the implementation interests me.

[Petie]

Client-side unzipping, even if we could get it working, isn't really an option as it required downloading the entire zip for every page load.

I've looked into this pretty extensively before - it's not something I'm just dismissing for no reason. I still think the best solution is to stop using zips outside of extremely limited circumstances but I'm happy to consider other options. The issue I'm having is that it's hard to get a straight answer whether or not a zip needs to be extracted to use some of these functions. Reading the file list, for instance, does not appear to require unzipping it. This function would, on the surface, appears to be able to grab data from a zip file but I can't tell if that requires extracting the specified file or not.

And, like you said, how exactly do we even display this data if we can get it out of the zip without creating a massive issue for the server? Some of these archives have hundreds or thousands of files so it's not as simple as just displaying some thumbnails on the page.

[DemoCrew19]

I do believe there is a way to do that on a Chromebook, but only after you download the file. This might not be what your looking for, but it might help since you don't have to waste the time and storage on the computer. I have to agree with Petie with disliking zip files, it is so annoying...

[Simpsons Dumper]

@Petie Would working with tarballs be easier or require less resources for showing previews or do you think it wouldn't make any real difference?

[Petie]

Tarballs on their own don't offer compression (not that it makes a big difference when we're dealing with images) but more importantly, are not as user-friendly. Zips are supported on basically every OS out of the box and require no specialized software or know-how to use. It's the same reason we disallowed RAR and 7z files a long time ago - the user experience is important here and we want to make the content we host available with as few hoops to jump through as possible.

[TGE]

Having to manually cut out the images from a sheet is unnecessarily time consuming, and definitely seems like a band aid fix that aids previewing on the site but hurts actual practical usability.

[Petie]

Having to manually cut out the images from a sheet is unnecessarily time consuming, and definitely seems like a band aid fix that aids previewing on the site but hurts actual practical usability.

I've heard this thrown around all the time and it's always because the person saying it is inexperienced or doesn't know how to work with sheets. Sheets are not a band aid that makes previewing easier and nothing else. They're used in nearly every game, from indie to AAA, that uses sprites as they're the most efficient way to store the individual sprites and access them as needed. I don't have experience creating games so I can't go into the process that's used in any depth but the reality is, sheets are the right way to do this.

[Simpsons Dumper]

Hmm. I find that sheets are fine for sprites that are all of the same size since anyone who is going to use them in a project probably knows how to write a script to extract them as separate files or to find someone else's despriter tool, but when it comes to mixed-size sprites it seems not to good as, unless I'm being dumb and missing something, it then becomes a manual process.

So this is easy to work with: https://www.spriters-resource.com/ninten...eet/93824/

and this is not: https://www.spriters-resource.com/ds_dsi...eet/27561/

Being able to preview images in zips would be good, as for large images such as those profile pictures it makes more sense to have them as separate files, and for mixed-size sprites it almost seems a necessity. After despriting the Switch profile pictures, I had 8.9MB of files, down from 9.6MB (granted, ignoring the early revision picture and everything to the right of it). But we do still have the problem as to how to deal with it all.

Perhaps a simple way would be for the server to extract the archives and to keep a copy of the unextracted images. These could easily be served to web browsers as previews. I doubt it would increase CPU resources and whatnot by much since the bulk of it would be a one-time thing during upload, but disk space usage would be doubled. I kind of imagine that's the last thing you want unless you don't pay much at all for it.

And then there's extracting the images on the fly which would be better but probably use more resources.

Or maybe you could even only store the images separately, with no archives at all, then zip them up when a user wants to download them. I'm not familiar with the methods of doing this though, and if temporary disk storage would be required or if it could be done completely on the fly like the gzip compression for nearly all webpages is. But it appears to be what cloud storage services do when you download multiple files, so it's at least feasible.

But running the website for years and all you've probably already had this discussion or at least thought about it quite a bit. So sorry if I've just wasted your time.

[Petie]

No need to apologize. Providing suggestions, even if they have already been thought of and tested (which they have, in this case), is never unappreciated. There really isn't a good way to handle on-the-fly zips though.

[Kuro-chan]

As Petie points out, even a client-side zip handler still requires grabbing the zip just to look at, defeating the purpose of such a tool that would involve plenty of coding and no real advantage.

With my site, I have zip files that have thousands of image files (some as high as 3,000+), requiring a decent-size sample image to show off what is hiding in the zip. Often the sample image has several dozen to show off what is hiding in the folder, but with most of them being button-size (120-160 x 40-100 range), that is a very possible thing to do. On this site, given the .zip files are (based on my impression) for massive images, this would not be practical.

Really, I doubt there is a good option for this other than just grabbing the .zip and looking through it yourself. :/