Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding feedback to the UI #5

Open
kornelski opened this issue Jul 24, 2014 · 3 comments
Open

Adding feedback to the UI #5

kornelski opened this issue Jul 24, 2014 · 3 comments

Comments

@kornelski
Copy link
Contributor

  • Compression could start in a background thread immediately as the window is open. This could make perceived save time much shorter.
  • If compression is done immediately, then we can show expected file size right in the window.
  • For small images the speed setting may not be very important. Instead of a manual setting I suggest either adjusting speed automatically (e.g. if image is 2000*2000px or larger) or showing the control only when the image is large.
  • Metadata could be broken down into textual and color data. Some users may want to embed authorship information, but not color profiles.
  • Have a visual selector for interlacing (the icons in the mockup could be improved still) to make this option clearer to non-technical users

screen shot 2014-07-12 at 15 49 20

WDYT?

@fnordware
Copy link
Owner

I definitely like the idea of having a file size preview. SuperPNG lets people save giant images (up to the Phototoshop maximum of 2^31 - 1) and in that case we'd want to maybe just do a piece and extrapolate the final size from there.

One issue with holding the preview and saving it directly is that Photoshop uses separate callbacks for the options dialog phase and the final writing phase. So you might get the Dialog callback and not the write callback, or vice versa. I'm sure we can find a way to work around this though.

So I guess you're proposing getting rid of the current Faster Saves-Smaller Files radio button thing? I guess it's about time. How about we just make it a checkbox called "Maximum Compression" that defaults to on? That way, people saving big images can turn it off if they want and get the default PNG compression.

BTW, you ditched the Alpha channel selection, was that intentional? If we want to save space, we could turn it into a menu. I think giving control over the Alpha is one of the best things about SuperPNG.

In your mockup, you have both Dithering and Lossless checkboxes. I thought we always had dithering when the image wasn't lossless (i.e. Quantize is on).

Users can currently turn off the ICC profile only in the Save As dialog, although that might not be totally clear. I'm OK with having a separate checkbox in our dialog. But the remaining metadata is not just author information, in fact, most of the metadata will likely be in the form of a big string holding XMP.

Do people use PNG interlacing much? I'm under the impression that it's seldom used in these days of fast internets. If that's the case, I think just having a simple interlacing checkbox is enough. We can elaborate more in the manual, or link here.

@kornelski
Copy link
Contributor Author

One issue with holding the preview and saving it directly is that Photoshop uses separate callbacks for the options dialog phase and the final writing phase.

I see. But the dialog phase can still read image data, right?

So I guess you're proposing getting rid of the current Faster Saves-Smaller Files radio button thing?

The radio buttons are useful only when it takes user less time to select lower compression than it takes computer to do the compression. For small images that can be saved under a second it's not relevant.

I like the "maximum compression" checkbox idea. When it's unchecked we can treat it as "auto" and figure out parameters from image size (the larger the image the faster compression), and when it's maximum it's going to be maximum no matter how long it takes.

BTW, you ditched the Alpha channel selection, was that intentional?

My assumption was that PNG is used for its alpha channel support, so this disables the #1 feature. If users are using it, then let's put it back.

In your mockup, you have both Dithering and Lossless checkboxes. I thought we always had dithering when the image wasn't lossless (i.e. Quantize is on).

I haven't included disabled state in the mockup, but when Lossless is on the Dithering checkbox will have to be in disabled state.

It's possible to disable dithering. It makes images a bit smaller, and look a bit more glossy. In pngquant I've tried to make dithering pretty smart by default, so it's not essential to have option to disable it.

in fact, most of the metadata will likely be in the form of a big string holding XMP.

Bummer. Let's ditch that then.

Do people use PNG interlacing much?

Currently it's not an attractive option as it makes files larger for little benefit, but it may become hot again when we get smarter HTTP/2 or SPDY servers (which could send only the 1st scan of all images first, and start sending rest of images last after everything else loads, which gives impressively short time to first visually-complete render).

My main concern is that it's just a mysterious option with technical-jargon name, and sending users to the manual is a cop-out :)

@fnordware
Copy link
Owner

Yeah, the dialog phase can read pixels, even if it's in its own callback.

I'd think even web users would not always want an alpha channel when using PNG (like text or line art that doesn't float over anything), but SuperPNG also has a variety of other users. For example, 3D artists really enjoy the ability to get Alpha from the channels palette. Some After Effects users render out SuperPNG sequences, so they are particularly interested in not always using the maximum compression.

Maybe I'm just used to the way it's been, but I think I like the current Quantize checkbox for pngquant, as opposed to changing it to a Lossless checkbox and pngquant runs when it's unchecked. The reason is that PNG is lossless by default, and having the Quantize checkbox tells the user that the plug-in is actually doing something. Of course, we could change "Quantize" to something else if there's a better idea.

I don't think "interlacing" is that cryptic. It's been around since the GIF days. If our users don't know what it means, they probably shouldn't be using it.

Here's a take:

take 1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants