What image rescaling method is used? Add choices?

[laika 1957]

I couldn't find a "suggestions" thread/board here, so bear with me if this is in the wrong place, dev-guys...

As the subject says... what image rescaling is being used right now, and how come there aren't at least two or three popular choices?

The undebatable reality is that it's far from always "best" to use "the best" method (by most people considered bicubic-yadda or lanczos) because of the varying nature of the source material. Video content always differ. "Best" is highly subjective. It often happens that certain unsharp source material (f.e. that of the dodgy 720p digital camera content from more or less all recent 720-capable digital cameras and handheld camcorders, older film transferred to SD for DVD release etc.) comes out _notably better_ from simple bilinear interpolation, or in rare cases even by nearest neighbour resampling. It feels odd that the users' hands should be tied behind their backs by making the choice for them, assuming it's what they want; assuming they have the same opinion about "best".

How about giving the users a chance to select between between, say, bilinear, bicubic and lanczos - The common "worst, medium, best" choices?

[jbrjake]

what image rescaling is being used right now, and how come there aren't at least two or three popular choices?

It feels odd that the users' hands should be tied behind their backs by making the choice for them, assuming it's what they want; assuming they have the same opinion about "best".

How about giving the users a chance to select between between, say, bilinear, bicubic and lanczos - The common "worst, medium, best" choices?

HandBrake uses Lanczos.

A menu to select different scalers is not going to happen.

Why? After all, of course, it's technically possible.

Because it's a matter of project focus and feature creep. We set it to use Lanczos because it's the scaler most people want to use, most of the time.

It's a thought process like this: Say we offered multiple scalers. We would need a pop-up menu to select them. We would need to present users with this pop-up and give them an opportunity in the workflow to customize it. We would then need to document the feature to explain it to users. And yet, when most users read the documentation to figure out what it does and how to change it, they would end up leaving it at the default setting anyway. Meanwhile, it takes up space in the interface, it takes up space in the GUI parameters, preset files, queue files, and core lib parameters. Worse, it offers people a choice, asks them a question, that they usually do not need to be confronted with.

Hiding it away as a preference doesn't work very well either -- your scenarios for where other scalers are appropriate are all content-based. Preferences are for global options that users don't have to change on a source-by-source basis. Plus, putting a job-specific parameter in the prefs makes things more difficult when it comes to including that in a job state. This is why, for example, x264 options moved from the preferences to an interface tab many versions ago.

Feature creep kills open source projects, and unnecessary options impinge on usability.

Per Apple's Human Interface Guidelines:

Making Design Decisions

When making design decisions regarding features in your application, it’s important to weigh the costs, not all of which are financial, against the potential benefits. Every time you add a feature to your application, the following things can happen:

*

Your application gets larger.
*

Your application gets slower.
*

Your application’s human interface becomes more complex.
*

You spend time developing new features rather than refining existing features.
*

Your application’s documentation and help become more extensive.
*

You run the risk of introducing changes that could adversely affect existing features.
*

You increase the time required to validate the behavior of your application.

Choosing appropriate features and devoting the needed resources to implement them correctly can save you time and effort later. Choosing poor feature sets or failing to assign appropriate design, engineering, testing, and documentation resources often incurs heavier costs later when critical bugs appear or users can’t figure out how to use your product.

The following sections present several additional factors to take into consideration before adding features to your product.
Avoid Feature Cascade

If you are developing a simple application, it can be very tempting to add features that aren’t wholly relevant to the original intent of the program. This feature cascade can lead to a bloated interface that is slow and difficult to use because of its complexity. Try to stick to the original intent of your program and include only features that are relevant to the main workflow.

The best products aren’t the ones with the most features. The best products are those whose features are tightly integrated with the solutions they provide, making them the most usable.
Apply the 80 Percent Solution

During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution—that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.

If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users. Even though that smaller group of power users is likely to have good ideas for features, the majority of your user base may not think in the same way. Involving a broad range of users in your design process can help you find the 80 percent solution.

http://developer.apple.com/mac/library/ ... -TPXREF135

That said, if you really really want it and can give me some short samples of content that do look better with other scalers, I'll consider adding it to only the command line interface.

[laika 1957]

That's one fine expatiation. I find it ironic that you quote good UI measures and what not when considering f.e. the awkwardness and clumsiness of the current, labyrinthal "Picture Settings" dialog, compared to the old dialog, and when considering that, despite having scaled down the number of advanced features of x264, you still have a good deal of them left (all of which as you would surely agree, fit in the required minimum.) I consider the choice of resampler, in particular given the reality behind how vastly different results these achieve, as part of the "required minimum" of image manipulation. Good software doesn't make "big brother" choices for the user. Userland villainry is never a good practive.

When I get my cursed 720p camera back from repair I will try to catch you on freenode to hand you some examples

And with all that said, I personally would be THRILLED to see this included even in just the CLI version of HB - after all, "advanced users" adventuring on the commandline should fairly be considered tough enough to handle an extra set of options, don't you agree?

[phibertron]

I think lanczos is the right choice to keep as default scaler
But I also believe that a natural bicubic spline scaler might also be a good choice

[jonmarkus]

hm i find it strange that you (the developer guy in this thread) are fighting against this quite fundamental feature but have no problems justifying the multitude of ones already in there, that really also go against your idea on "feature/ui creep." i find this very contradictive, and counter productive.

if we would walk this path, then handbrake should not have a droplist for the detelecine option but instead just use "off/default" since that is "what most people would want, most of the time."

handbrake should not have "custom/fast/slow/slower" for deinterlace, but just go with "slower," since it is "best," and since "most people would want this."

handbrake should not have a droplist for "custom/weak/medium/strong" denoise either - let us just go with "strong," because "most people would want this, most of the time."

handbrake should not have 15 deblocking steps, but just "off/1/15" since more choices would be "too complicated."

and so on, and so on......

i personally also feel a need of being able to select rescaler. the nuances nearest/linear/bicubic/lanczos are as important as 15 deblocking steps, or 3 difference deinterlacing steps, and so on. i miss a linear rescaling mode, and i miss a simple bicubic mode (preferrably sharp bicubic).

the threat starter asks the developers not to make choices for the users, and i agree. fine if the developers do not care for adding a droplist to this in the picture setting ui for the graphical client, but !please! let us more technical in the crowd at least have it in the cli version. thank you.

[dynaflash]

... and you're point is ... ? unless a dev feels like implementing it ... it is not gonna happen. period. whining will get you no where ... fast. Period. End of discussion unless you have a patch.

Sad ? Maybe but that is just how it is. Period.

[s55]

That said, if you really really want it and can give me some short samples of content that do look better with other scalers, I'll consider adding it to only the command line interface.

Enough said. This isn't a matter up for debate.

[jbrjake]

if we would walk this path, then handbrake should not have a droplist for the detelecine option but instead just use "off/default" since that is "what most people would want, most of the time."

You mean like we used to, until a number of users presented reasonable and commonly-occurring usage scenarios that require changing the options?

handbrake should not have "custom/fast/slow/slower" for deinterlace, but just go with "slower," since it is "best," and since "most people would want this."

Bad example since scaling is not a bottleneck on encoding, and deinterlacing is.

handbrake should not have a droplist for "custom/weak/medium/strong" denoise either - let us just go with "strong," because "most people would want this, most of the time."

That makes no sense. Most of the time people don't want strong, and the choice is entirely content-dependent. Unlike the original poster in this thread, who refused to provide samples when asked, BradleyS did a bunch of empirical testing and presented us with results about what denoise settings are applicable when, and made a strong case that they need to be changed on a regular basis.

handbrake should not have 15 deblocking steps, but just "off/1/15" since more choices would be "too complicated."

Deblocking was added as a widget at the insistence of users. It needs to be changed on a very regular basis, since of course it is one of the main content-based tuning options in the encoder.

and so on, and so on......

All your examples suck. They are not germane to the discussion.

It is laughable that you claim you want this feature so badly, and yet you're utterly incapable of providing samples that demonstrate its necessity. That surely would have taken less time than typing up all this whining.

[jbrjake]

Also, there's a basic logical disconnect with pointing to existing features as a reason for adding new ones. That an interface has some bloat is not an excuse for making it yet more complex. The reason HB's interface isn't even more crufty than it already is, is that we insist on making sure additions are truly justified. As I laid out before, the "bloat" you cite all came from sustained user interest and rational, empirical cases for why they are necessary. This is just basic project management.

http://www.alwinhoogerdijk.com/2009/11/ ... -requests/

If all requests for a particular feature are coming from a small, but vocal sub-group of your users, then beware. These users may not be representative for the rest of your audience, so implementing that feature may not be as important as it seems to be.

http://www.alwinhoogerdijk.com/2009/08/ ... ing-video/

Listen to your first users, fix the bugs they report, improve the user interface where they are struggling. But be careful implementing requested features. Only implement the features *you* think make sense for your product.

http://nerdrider.com/?p=8

Adding features for the sake of it, will reduce the overall appeal of the product. Commonly this sort of bloat leads to a performance drop off in the software but even if you can avoid lowering the performance of the software you can end up with a situation of more features = more complexity = more confusion = less customer satisfaction.

http://www.theopenforce.com/2006/05/bus ... ek_on.html

I would argue that the open source systems are in many ways better than the traditional closed source on-site systems: Less complexity, better user interface, easier to use. That may not necessarily be due to the free availability of the source code, but more in the spirit of open source that focuses on the basics, not all the bells and whistles. And why is that? Because open source developers shouldn't be caught up in adding every feature under the sun in order to justify an annual upgrades.

http://r1.robgoodlatte.com/2007/04/05/u ... ture-sets/

There is an interesting relationship between the usefulness of a product and its quantity of features. Too few features—your product fails to accomplish the set of tasks your core audience demands. Too many—you risk confusing your users with intimidating interfaces.
Clearly, the fewer extraneous features the better, but that’s often unacceptable. Power users demand extra features, legacy features can’t just be abandoned. Designing interfaces for feature-bloat is almost assuredly a losing prospect